Functional Requirements

These are the requirements that the end user specifically demands as basic
facilities that the system should offer. All these functionalities need to be
necessarily incorporated into the system as a part of the contract.
These are represented or stated in the form of input to be given to the system, the
operation performed and the output expected. They are the requirements stated
by the user which one can see directly in the final product, unlike the non-
functional requirements.

 Functional requirements define a function that a system or system element must be

qualified to perform and must be documented in different forms. The functional
requirements describe the behavior of the system as it correlates to the system's
functionality.
 Functional requirements should be written in a simple language, so that it is easily
understandable. The examples of functional requirements are authentication, business
rules, audit tracking, certification requirements, transaction corrections, etc.
 These requirements allow us to verify whether the application provides all
functionalities mentioned in the application's functional requirements. They support
tasks, activities, user goals for easier project management.
 There are a number of ways to prepare functional requirements. The most common
way is that they are documented in the text form. Other formats of preparing the
functional requirements are use cases, models, prototypes, user stories, and diagrams.

Example:
 What are the features that we need to design for this system?
 What are the edge cases we need to consider, if any, in our design?

Non-Functional Requirements
These are the quality constraints that the system must satisfy according to the
project contract. The priority or extent to which these factors are implemented
varies from one project to another. They are also called non-behavioral
requirements. They deal with issues like:
 Portability
 Security
 Maintainability
 Reliability
 Scalability
 Performance
 Reusability
 Flexibility

Non-functional requirements are not related to the software's functional aspect. They can be
the necessities that specify the criteria that can be used to decide the operation instead of
specific behaviors of the system. Basic non-functional requirements are - usability,

1
reliability, security, storage, cost, flexibility, configuration, performance, legal or regulatory
requirements, etc.

They are divided into two main categories:

Execution qualities like security and usability, which are observable at run time.

Evolution qualities like testability, maintainability, extensibility, and scalability that

embodied in the static structure of the software system.

Non-functional requirements specify the software's quality attribute. These requirements

define the general characteristics, behavior of the system, and features that affect the
experience of the user. They ensure a better user experience, minimizes the cost factor. Non-
functional requirements ensure that the software system must follow the legal and adherence
rules. The impact of the non-functional requirements is not on the functionality of the
system, but they impact how it will perform. For a well-performing product, atleast some of
the non-functional requirements should be met.

Example:
 Each request should be processed with the minimum latency?
 System should be highly valuable.

Difference between Functional Requirements and Non-

Functional Requirements:
Functional Requirements Non Functional Requirements

A functional requirement defines a A non-functional requirement defines the

system or its component. quality attribute of a software system.

It places constraints on “How should the

It specifies “What should the software
software system fulfill the functional
system do?”
requirements?”

Non-functional requirement is specified

Functional requirement is specified by by technical peoples e.g. Architect,
User. Technical leaders and software
developers.

It is mandatory. It is not mandatory.

It is captured in use case. It is captured as a quality attribute.

2
 Functional Requirements Non Functional Requirements

Defined at a component level. Applied to a system as a whole.

Helps you verify the functionality of the Helps you to verify the performance of
software. the software.

Functional Testing like System, Non-Functional Testing like

Integration, End to End, API testing, etc Performance, Stress, Usability, Security
are done. testing, etc are done.

Usually easy to define. Usually more difficult to define.

Example
Example
1) Emails should be sent with a latency
1) Authentication of user whenever
of no greater than 12 hours from such an
he/she logs into the system.
activity.
2) System shutdown in case of a cyber
2) The processing of each request should
attack.
be done within 10 seconds
3) A Verification email is sent to user
3) The site should load in 3 seconds
whenever he/she registers for the first
when the number of simultaneous users
time on some software system.
are > 10000

User Requirements
User requirements are typically written when discussing the use cases for a project. The
requirements definition is done with the customer or product managers that know how the
embedded system will be used by the user.
Many user requirements deal with how a user will interact with a system and what that user
expects. If there is a screen or human machine interface aspect to the system, a user
requirement may be based on what happens when the user selects an action on the screen.
Maybe with a button press not only does a process start, but it also switches to another screen
and provides an audible notification. When user requirements such as these are written down,
they can often break into multiple system requirements later due to switching of screens, the
maximum delays in starting the process, and finally what the next screen should look like.
One pitfall is starting to try to write the system requirements during a user requirement
meeting. This often detracts from gaining insight into the requirements of the user, and key
functionality pieces could be missed.
In fact, as alluded to earlier, it is often better to keep user requirements and system
requirements separate in their tracking and reporting. The user requirements are often more
readable, understandable, and provide a better sense of how the system will operate. Even
though user requirements may lack specifics on what really needs to occur in the system,
they are still valuable in that they can provide the overarching system functionality
expectations.

3
Finally, when writing user requirements, it is a good idea to have traceability in terms of
where the user requirement originated. Whether it is from a single customer or product
manager, understanding where it came from is important. When capturing user requirements,
there are times when separate user sessions may develop conflicting requirements. Being
able to go back to the originator and understand the use case better can help facilitate the
deciphering of conflicting user requirements. It could come from differing standpoints, like
an operator vs. a maintenance person, so being able to go back and resolve those differences
becomes important.

System Requirements Document

What is System Requirements Document?
System Requirements Document is also known as System Requirements Specifications.
System requirements document is a set of documentation that describes the behavior and
features of a software or system. It comprises of various elements that attempt to characterize
the functionality needed by the client to satisfy their users. In other words, the system
requirements document (SRD) describes the system-level performance and functional
requirements for a system.

System Requirements Document or System Requirements Specification is defined as a

document which defines what the software will do and how it will be required to perform,
and it also defines the functionality the software needs to satisfy all stakeholders (users,
business) requirements.

What is Included in a System Requirement Document?

While the SRD capacities as an outline for dealing with the extent of a project, it eventually
characterizes the functional and non-functional requirements of the system. The document
doesn't layout design or technology solutions. These decisions will be taken by the
developers later.

The well-written system requirement document should:

o Split the problem into manageable parts.

o Notify design specifications i.e., SRD needs to comprise adequate information on software
requirements to present an effective design.
o Gives feedback to the customer or client.
o For testing and validation, serve as a reference.

According to the IEEE standards, SRDs must cover the following important topics.

4
 o Quality
o Security/Privacy
o Functional capabilities
o Safety
o Performance levels
o Constraints and Limitations
o Data Structure/Elements
o Reliability
o Interfaces

Main Elements of System Requirements Document

Based on the procedure employed (Waterfall vs. agile), the degree of convention and detail
in the SRS will differ, however in general, system requirement document or system
requirement specification contains a description of the system requirements, functional
requirements, technical requirements, acceptance criteria, assumptions and constraints. We
have explained each of these in more detail below:

5
Constraints and Assumption
The constraints and assumption section will underline the lack of any design imposed by the
client on the system design, resulting in removing some options from being considered by the
developers. This section also comprises assumptions which are made by the team of
requirement engineering at the time of requirements gathering and analysis. If there is an
incorrect assumption, it is needed to re-evaluate the system requirements specification in
order to ensure that the documented requirements are still valid.

Functional and System Requirements

This segment normally comprises a hierarchical arrangement of requirements, with the
functional/business requirements at the uppermost level and the detailed system requirements
are listed as their child items.

Mostly in the form of statements, the requirements are written like "System requires the
capability to do x," with supporting information comprised as required.

6
Technical Requirements
This part is utilized to list any of the non-functional requirements, which basically
personifies the technical environment that the product requires to work in and incorporate the
technical limitations that it requires to work under. These technical requirements are
important in deciding how high-level functional requirements can decompose into more
definite system requirements.