Difference between functional and non-functional requirements

In this article, we will discuss two important terms used in software engineering that
are functional requirements and non-functional requirements, along with the
comparison between them. Understanding the difference between both terms helps to
ensure that the delivered product meets the expectations of the client.

So, without more delay, let's start the topic.

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.

Non-functional requirements
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, 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.

Functional Requirements Non-functional requirements

Functional requirements help to understand the They help to understand the system's
functions of the system. performance.

Functional requirements are mandatory. While non-functional requirements

are not mandatory.

They are easy to define. They are hard to define.

They describe what the product does. They describe the working of
product.

It concentrates on the user's requirement. It concentrates on the expectation

and experience of the user.

It helps us to verify the software's It helps us to verify the software's

functionality. performance.

These requirements are specified by the user. These requirements are specified by
the software developers, architects,
and technical persons.

There is functional testing such as API testing, There is non-functional testing such
system, integration, etc. as usability, performance, stress,
security, etc.

Examples of the functional requirements are - Examples of the non-functional

Authentication of a user on trying to log in to requirements are -
the system. The background color of the screens
should be light blue.

These requirements are important to system These are not always the important
operation. requirements, they may be desirable.

Completion of Functional requirements allows While system will not work only
the system to perform, irrespective of meeting with non-functional requirements.
the non-functional requirements.
 Software Requirement Specifications
The production of the requirements stage of the software development process
is Software Requirements Specifications (SRS) (also called a requirements
document). This report lays a foundation for software engineering activities and is
constructing when entire requirements are elicited and analyzed. SRS is a formal
report, which acts as a representation of software that enables the customers to
review whether it (SRS) is according to their requirements. Also, it comprises user
requirements for a system as well as detailed specifications of the system
requirements.

The SRS is a specification for a specific software product, program, or set of

applications that perform particular functions in a specific environment. It serves
several goals depending on who is writing it. First, the SRS could be written by the
client of a system. Second, the SRS could be written by a developer of the system.
The two methods create entirely various situations and establish different purposes
for the document altogether. The first case, SRS, is used to define the needs and
expectation of the users. The second case, SRS, is written for various purposes and
serves as a contract document between customer and developer.

Characteristics of good SRS

Following are the features of a good SRS document:

1. Correctness: User review is used to provide the accuracy of requirements stated in
the SRS. SRS is said to be perfect if it covers all the needs that are truly expected
from the system.

2. Completeness: The SRS is complete if, and only if, it includes the following
elements:

(1). All essential requirements, whether relating to functionality, performance,

design, constraints, attributes, or external interfaces.

(2). Definition of their responses of the software to all realizable classes of input data
in all available categories of situations.

(3). Full labels and references to all figures, tables, and diagrams in the SRS and
definitions of all terms and units of measure.

3. Consistency: The SRS is consistent if, and only if, no subset of individual

requirements described in its conflict. There are three types of possible conflict in the
SRS:

(1). The specified characteristics of real-world objects may conflicts. For example,

(a) The format of an output report may be described in one requirement as tabular but
in another as textual.

(b) One condition may state that all lights shall be green while another states that all
lights shall be blue.

(2). There may be a reasonable or temporal conflict between the two specified

actions. For example,

(a) One requirement may determine that the program will add two inputs, and another
may determine that the program will multiply them.

(b) One condition may state that "A" must always follow "B," while other requires
that "A and B" co-occurs.

(3). Two or more requirements may define the same real-world object but use
different terms for that object. For example, a program's request for user input may
be called a "prompt" in one requirement's and a "cue" in another. The use of standard
terminology and descriptions promotes consistency.

4. Unambiguousness: SRS is unambiguous when every fixed requirement has only

one interpretation. This suggests that each element is uniquely interpreted. In case
there is a method used with multiple definitions, the requirements report should
determine the implications in the SRS so that it is clear and simple to understand.

5. Ranking for importance and stability: The SRS is ranked for importance and
stability if each requirement in it has an identifier to indicate either the significance
or stability of that particular requirement.
Typically, all requirements are not equally important. Some prerequisites may be
essential, especially for life-critical applications, while others may be desirable. Each
element should be identified to make these differences clear and explicit. Another
way to rank requirements is to distinguish classes of items as essential, conditional,
and optional.

6. Modifiability: SRS should be made as modifiable as likely and should be capable

of quickly obtain changes to the system to some extent. Modifications should be
perfectly indexed and cross-referenced.

7. Verifiability: SRS is correct when the specified requirements can be verified with

a cost-effective system to check whether the final software meets those requirements.
The requirements are verified with the help of reviews.

8. Traceability: The SRS is traceable if the origin of each of the requirements is

clear and if it facilitates the referencing of each condition in future development or
enhancement documentation.

Software Design Concepts:

Concepts are defined as a principal idea or invention that comes into our mind or in
thought to understand something. The software design concept simply means the idea
or principle behind the design. It describes how you plan to solve the problem of
designing software, the logic, or thinking behind how you will design software. It
allows the software engineer to create the model of the system or software or product
that is to be developed or built. The software design concept provides a supporting
and essential structure or model for developing the right software. There are many
concepts of software design and some of them are given below: 
The following points should be considered while designing Software: 

1. Abstraction- hide Irrelevant data 

Abstraction simply means to hide the details to reduce complexity and increases
efficiency or quality. Different levels of Abstraction are necessary and must be
applied at each stage of the design process so that any error that is present can be
removed to increase the efficiency of the software solution and to refine the
software solution. The solution should be described in broad ways that cover a
wide range of different things at a higher level of abstraction and a more detailed
description of a solution of software should be given at the lower level of
abstraction.
2. Modularity- subdivide the system 
Modularity simply means dividing the system or project into smaller parts to
reduce the complexity of the system or project. In the same way, modularity in
design means subdividing a system into smaller parts so that these parts can be
created independently and then use these parts in different systems to perform
different functions. It is necessary to divide the software into components known
as modules because nowadays there are different software available like
Monolithic software that is hard to grasp for software engineers. So, modularity in
design has now become a trend and is also important. If the system contains fewer
components then it would mean the system is complex which requires a lot of
effort (cost) but if we are able to divide the system into components then the cost
would be small.
3. Architecture- design a structure of something 
Architecture simply means a technique to design a structure of something.
Architecture in designing software is a concept that focuses on various elements
and the data of the structure. These components interact with each other and use
the data of the structure in architecture.
4. Refinement- removes impurities 
Refinement simply means to refine something to remove any impurities if present
and increase the quality. The refinement concept of software design is actually a
process of developing or presenting the software or system in a detailed manner
that means to elaborate a system or software. Refinement is very necessary to find
out any error if present and then to reduce it.
5. Pattern- a repeated form 
The pattern simply means a repeated form or design in which the same shape is
repeated several times to form a pattern. The pattern in the design process means
the repetition of a solution to a common recurring problem within a certain
context.
6. Information Hiding- hide the information 
Information hiding simply means to hide the information so that it cannot be
accessed by an unwanted party. In software design, information hiding is achieved
 by designing the modules in a manner that the information gathered or contained
in one module is hidden and can’t be accessed by any other modules.
7. Refactoring- reconstruct something 
Refactoring simply means reconstructing something in such a way that it does not
affect the behavior of any other features. Refactoring in software design means
reconstructing the design to reduce complexity and simplify it without affecting
the behavior or its functions. Fowler has defined refactoring as “the process of
changing a software system in a way that it won’t affect the behavior of the design
and improves the internal structure”.

Requirements validation
Requirements validation is the process of checking that requirements defined for
development, define the system that the customer really wants. To check issues
related to requirements, we perform requirements validation. We usually use
requirements validation to check error at the initial phase of development as the
error may increase excessive rework when detected later in the development
process.
In the requirements validation process, we perform a different type of test to check
the requirements mentioned in the Software Requirements Specification (SRS),
these checks include:
 Completeness checks
 Consistency checks
 Validity checks
 Realism checks
 Ambiguity checks
 Verifiability
The output of requirements validation is the list of problems and agreed on actions
of detected problems. The lists of problems indicate the problem detected during the
process of requirement validation. The list of agreed action states the corrective
action that should be taken to fix the detected problem.
There are several techniques which are used either individually or in conjunction
with other techniques to check to check entire or part of the system:
1. Test case generation:
Requirement mentioned in SRS document should be testable, the conducted tests
reveal the error present in the requirement. It is generally believed that if the test
is difficult or impossible to design than, this usually means that requirement will
be difficult to implement and it should be reconsidered.
2. Prototyping:
In this validation techniques the prototype of the system is presented before the
end-user or customer, they experiment with the presented model and check if it
 meets their need. This type of model is generally used to collect feedback about
the requirement of the user.
3. Requirements Reviews:
In this approach, the SRS is carefully reviewed by a group of people including
people from both the contractor organisations and the client side, the reviewer
systematically analyses the document to check error and ambiguity.
4. Automated Consistency Analysis:
This approach is used for automatic detection of an error, such as
nondeterminism, missing cases, a type error, and circular definitions, in
requirements specifications.
First, the requirement is structured in formal notation then CASE tool is used to
check in-consistency of the system, The report of all inconsistencies is identified
and corrective actions are taken.
5. Walk-through:
A walkthrough does not have a formally defined procedure and does not require
a differentiated role assignment.
 Checking early whether the idea is feasible or not.
 Obtaining the opinions and suggestion of other people.
 Checking the approval of others and reaching an agreement.

Requirements Elicitation & Aanalysis

Requirements elicitation is perhaps the most difficult, most error-prone and most
communication intensive software development. It can be successful only through
an effective customer-developer partnership. It is needed to know what the users
really need. 
 Requirements elicitation Activities:
Requirements elicitation includes the subsequent activities. Few of them are listed
below – 
 Knowledge of the overall area where the systems is applied.
 The details of the precise customer problem where the system are going to be
applied must be understood.
 Interaction of system with external requirements.
 Detailed investigation of user needs.
 Define the constraints for system development.
Requirements elicitation Methods:
There are a number of requirements elicitation methods. Few of them are listed
below – 
1. Interviews
2. Brainstorming Sessions
3. Facilitated Application Specification Technique (FAST)
4. Quality Function Deployment (QFD)
5. Use Case Approach
The success of an elicitation technique used depends on the maturity of the analyst,
developers, users, and the customer involved. 
1. Interviews: 
Objective of conducting an interview is to understand the customer’s expectations
from the software. 
It is impossible to interview every stakeholder hence representatives from groups
are selected based on their expertise and credibility. 
Interviews maybe be open-ended or structured. 
1. In open-ended interviews there is no pre-set agenda. Context free questions may
be asked to understand the problem.
2. In structured interview, agenda of fairly open questions is prepared. Sometimes a
proper questionnaire is designed for the interview.

2. Brainstorming Sessions: 
 It is a group technique
 It is intended to generate lots of new ideas hence providing a platform to share
views
 A highly trained facilitator is required to handle group bias and group conflicts.
 Every idea is documented so that everyone can see it.
 Finally, a document is prepared which consists of the list of requirements and
their priority if possible.

3. Facilitated Application Specification Technique: 

It’s objective is to bridge the expectation gap – difference between what the
developers think they are supposed to build and what customers think they are
going to get. 
A team oriented approach is developed for requirements gathering. 
Each attendee is asked to make a list of objects that are- 
1. Part of the environment that surrounds the system
2. Produced by the system
3. Used by the system
Each participant prepares his/her list, different lists are then combined, redundant
entries are eliminated, team is divided into smaller sub-teams to develop mini-
specifications and finally a draft of specifications is written down using all the
inputs from the meeting. 
4. Quality Function Deployment: 
In this technique customer satisfaction is of prime concern, hence it emphasizes on
the requirements which are valuable to the customer. 
3 types of requirements are identified – 
 Normal requirements – 
In this the objective and goals of the proposed software are discussed with the
customer. Example – normal requirements for a result management system may
be entry of marks, calculation of results, etc
 Expected requirements – 
These requirements are so obvious that the customer need not explicitly state
them. Example – protection from unauthorized access.
 Exciting requirements – 
It includes features that are beyond customer’s expectations and prove to be very
satisfying when present. Example – when unauthorized access is detected, it
should backup and shutdown all processes.

5. Use Case Approach: 

This technique combines text and pictures to provide a better understanding of the
requirements. 
The use cases describe the ‘what’, of a system and not ‘how’. Hence, they only give
a functional view of the system. 
The components of the use case design includes three major things – Actor, Use
cases, use case diagram. 
1. Actor – 
It is the external agent that lies outside the system but interacts with it in some
way. An actor maybe a person, machine etc. It is represented as a stick figure.
Actors can be primary actors or secondary actors. 
 Primary actors – It requires assistance from the system to achieve a goal.
 Secondary actor – It is an actor from which the system needs assistance.
2. Use cases – 
They describe the sequence of interactions between actors and the system. They
capture who(actors) do what(interaction) with the system. A complete set of use
cases specifies all possible ways to use the system.
3. Use case diagram – 
A use case diagram graphically represents what happens when an actor interacts
with a system. It captures the functional aspect of the system. 
 A stick figure is used to represent an actor.
 An oval is used to represent a use case.
 A line is used to represent a relationship between an actor and a use case.
 S/w Architecture design and style.
The software needs the architectural design to represents the design of software.
IEEE defines architectural design as “the process of defining a collection of
hardware and software components and their interfaces to establish the framework
for the development of a computer system.” The software that is built for computer-
based systems can exhibit one of these many architectural styles. 
Each style will describe a system category that consists of : 
 
 A set of components(eg: a database, computational modules) that will perform a
function required by the system.
 The set of connectors will help in coordination, communication, and cooperation
between the components.
 Conditions that how components can be integrated to form the system.
 Semantic models that help the designer to understand the overall properties of
the system.
The use of architectural styles is to establish a structure for all the components of
the system. 
Taxonomy of Architectural styles: 
 
1. Data centered architectures: 
 A data store will reside at the center of this architecture and is accessed
frequently by the other components that update, add, delete or modify the
data present within the store.
 The figure illustrates a typical data centered style. The client software access
a central repository. Variation of this approach are used to transform the
repository into a blackboard when data related to client or data of interest for
the client change the notifications to client software.
 This data-centered architecture will promote integrability. This means that the
existing components can be changed and new client components can be
added to the architecture without the permission or concern of other clients.
 Data can be passed among clients using blackboard mechanism.
2. Data flow architectures: 
 This kind of architecture is used when input data to be transformed into
output data through a series of computational manipulative components.
 The figure represents pipe-and-filter architecture since it uses both pipe and
filter and it has a set of components called filters connected by pipes.
 Pipes are used to transmit data from one component to the next.
 Each filter will work independently and is designed to take data input of a
certain form and produces data output to the next filter of a specified form.
The filters don’t require any knowledge of the working of neighboring filters.
  If the data flow degenerates into a single line of transforms, then it is termed
as batch sequential. This structure accepts the batch of data and then applies a
series of sequential components to transform it.
3. Call and Return architectures: It is used to create a program that is easy to
scale and modify. Many sub-styles exist within this category. Two of them are
explained below. 
 Remote procedure call architecture: This components is used to present in a
main program or sub program architecture distributed among multiple
computers on a network.
 Main program or Subprogram architectures: The main program structure
decomposes into number of subprograms or function into a control hierarchy.
Main program contains number of subprograms that can invoke other
components. 
 

1. Object Oriented architecture: The components of a system encapsulate data

and the operations that must be applied to manipulate the data. The coordination
and communication between the components are established via the message
passing.
2. Layered architecture: 
 A number of different layers are defined with each layer performing a well-
defined set of operations. Each layer will do some operations that becomes
closer to machine instruction set progressively.
 At the outer layer, components will receive the user interface operations and
at the inner layers, components will perform the operating system
interfacing(communication and coordination with OS)
 Intermediate layers to utility services and application software functions.
 
Software Design Process
Software design is a mechanism to transform user requirements into some suitable
form, which helps the programmer in software coding and implementation. It deals
with representing the client's requirement, as described in SRS (Software
Requirement Specification) document, into a form, i.e., easily implementable using
programming language.

The software design phase is the first step in SDLC (Software Design Life Cycle),
which moves the concentration from the problem domain to the solution domain. In
software design, we consider the system to be a set of components or modules with
clearly defined behaviors & boundaries.

Objectives of Software Design

Following are the purposes of Software design:

1. Correctness:Software design should be correct as per requirement.
2. Completeness:The design should have all components like data structures,
modules, and external interfaces, etc.
3. Efficiency:Resources should be used efficiently by the program.
4. Flexibility:Able to modify on changing needs.
5. Consistency:There should not be any inconsistency in the design.
6. Maintainability: The design should be so simple so that it can be easily
maintainable by other designers.