{Chapter 2 Requirement Analysis}

Activities involved in Software Requirement

Analysis
Software requirement means requirement that is needed by
software to increase quality of software product. These requirements
are generally a type of expectation of user from software product that
is important and need to be fulfilled by software. Analysis means to
examine something in an organized and specific manner to know
complete details about it.
Therefore, Software requirement analysis simply means complete
study, analysing, describing software requirements so that
requirements that are genuine and needed can be fulfilled to solve
problem. There are several activities involved in analysing Software
requirements. Some of them are given below:

1.Problem Recognition:
The main aim of requirement analysis is to fully understand main
objective of requirement that includes why it is needed, does it add
value to product, will it be beneficial, does it increase quality of the
project, does it will have any other effect. All these points are fully
recognized in problem recognition so that requirements that are
essential can be fulfilled to solve business problems.

2.Evaluation and Synthesis :

Evaluation means judgement about something whether it is worth or
not and synthesis means to create or form something. Here are some
tasks are given that is important in the evaluation and synthesis of
software requirement :
• To define all functions of software that necessary.
• To define all data objects that are present externally and are
easily observable.
• To evaluate that flow of data is worth or not.
• To fully understand overall behaviour of system that means
overall working of system.
• To identify and discover constraints that are designed.
• To define and establish character of system interface to fully
understand how system interacts with two or more components
or with one another.
Modeling :
After complete gathering of information from above tasks, functional
and behavioural models are established after checking function and
behaviour of system using a domain model that also known as the
conceptual model.

Specification :
The software requirement specification (SRS) which means to specify
the requirement whether it is functional or non-functional should be
developed.

Review :
After developing the SRS, it must be reviewed to check whether it can
be improved or not and must be refined to make it better and increase
the quality.

Requirements Engineering Process

Requirement Engineering is the process of defining, documenting and
maintaining the requirements. It is a process of gathering and defining
service provided by the system. Requirements Engineering Process
consists of the following main activities:
▪ Requirements elicitation
 ▪ Requirements specification
▪ Requirements verification and validation
▪ Requirements management

Requirements Elicitation:
It is related to the various ways used to gain knowledge about the
project domain and requirements. The various sources of domain
knowledge include customers, business manuals, the existing software
of same type, standards and other stakeholders of the project.
The techniques used for requirements elicitation include interviews,
brainstorming, task analysis, Delphi technique, prototyping, etc. Some
of these are discussed here. Elicitation does not produce formal models
of the requirements understood. Instead, it widens the domain
knowledge of the analyst and thus helps in providing input to the next
stage.

Requirements specification:
This activity is used to produce formal software requirement models.
All the requirements including the functional as well as the non-
functional requirements and the constraints are specified by these
models in totality. During specification, more knowledge about the
problem may be required which can again trigger the elicitation
process.
The models used at this stage include ER diagrams, data flow
diagrams(DFDs), function decomposition diagrams(FDDs), data
dictionaries, etc.
Requirements verification and validation:
Verification: It refers to the set of tasks that ensures that the software
correctly implements a specific function.
Validation: It refers to a different set of tasks that ensures that the
software that has been built is traceable to customer requirements.
If requirements are not validated, errors in the requirement definitions
would propagate to the successive stages resulting in a lot of
modification and rework.
The main steps for this process include:
The requirements should be consistent with all the other requirements
i.e no two requirements should conflict with each other.
The requirements should be complete in every sense.
The requirements should be practically achievable.
Requirements management:
Requirement management is the process of analysing, documenting,
tracking, prioritizing and agreeing on the requirement and controlling
the communication to relevant stakeholders. This stage takes care of
the changing nature of requirements. It should be ensured that the SRS
is as modifiable as possible so as to incorporate changes in
requirements specified by the end users at later stages too. Being able
to modify the software as per requirements in a systematic and
controlled manner is an extremely important part of the requirements
engineering process.

Requirement Analysis Techniques

Requirement analysis helps organizations to determine the actual
needs of stakeholders. At the same time, it enables the development
team to communicate with stakeholders in a language they understand
(like charts, models, flow-charts,) instead of pages of text.
Once the requirements are gathered, we document the requirements in
a Software Requirements Specification (SRS) document, use cases or
as User Stories, which are shared with the stakeholders for approval.
This document is easy to understand for both normal
users and developers. Any changes in the requirements are also
documented and go through a change control procedure and finalized
on approval.

Requirement Analysis Techniques

1. Business Process Model and Notation (BPMN)

Business Process Model and Notation is used to create graphs that

simplify the understanding of the business process. It is a popular
technique used by business analysts to coordinate the sequence of
messages between different participants in a related set of activities.

Fig: BPMN example

2. Flowcharts

Flowcharts depict sequential flow and control logic of a related set of

activities. They are useful for both technical and non-technical
members.
 Fig: Flowchart example

3. Gantt Charts

Gantt Charts provide a visual representation of tasks along with their

scheduled timelines. They help business analysts visualize the start and
end dates of all the tasks in a project.

Fig: Gantt Charts example

4. Gap Analysis

Gap analysis evaluates the gaps in a product’s performance to

determine whether the requirements are met or not. They
help business analysts determine the present state and target state of
a product.
 Fig: Gap analysis example

Flow-oriented modeling in software engineering

What is Flow Oriented Modeling?
The flow-oriented modeling represents how data objects are
transformed at they move through the system. Derived from structured
analysis, flow models use the data flow diagram, a modeling notation
that depicts how input is transformed into output as data objects move
through the system. Each software function that transforms data is
described by a process specification or narrative. In addition to data
flow, this modeling element also depicts control flow.

Although flow oriented modeling is perceived as an outdated technique

by some software engineers, it continues to be one of the most widely
used requirements analysis notations in use today. Flow oriented
modeling focuses on structured analysis and design, follows a top to
down methodology and uses a graphical technique depicting
information flows and the transformations that are applied as data
moves from input to output.

The modeling tools that are used to build a data flow oriented model
include context diagrams, data flow diagrams, entity relationship
diagram, control flow diagram, state transition diagram, data dictionary,
process specification and control specification. Although the data flow
diagram (DFD) and related diagrams and information are not a formal
part of UML (Unified Modeling Language), they can be used to
complement UML diagrams and provide additional insight into system
requirements and flow. The flow oriented modeling takes an input-
process-output view of a system. That is, data objects flow into the
software, are transformed by processing elements, and resultant data
objects flow out of the software.

Data Flow Diagram :

The data flow diagram represents the flows of data between different
process in a business. It is a graphical technique that depicts
information flow and transforms that are applied as data from input to
output. It provides a simple, intuitive method for describing business
processes without focusing on the details of computer systems. DFDs
are attractive techniques because they provide what users do rather
than what computers do. In DFD, there are four symbols are used :

1. Process :
The circle represents the process. An activity that changes or
transforms data flows. Since they transform incoming data to outgoing
data, all processes must have inputs and outputs on a DFD.
2. Data Flow :
The labeled arrows indicate incoming and outgoing data flow.
Movement of data between external entities, processes and data stores
is represented with an arrow symbol, which indicates the direction of
flow.
3. Data Store :
The rectangle represents an external entity. A data store does not
generate any operations but simply holds data for later access.
4. External Entity :
In Data Flow Diagrams external entities produce and consume data that
flows between the entity and the system being diagrammed.

These data flows are the inputs and outputs of the DFD. Data objects
are represented by labeled arrows, and transformations are
represented by circles. The DFD is presented in a hierarchical fashion.
That is, the first data flow model (sometimes called a level 0 DFD or
context diagram) represents the system as a whole. Subsequent data
flow diagrams refine the context diagram, providing increasing detail
with each subsequent level.

Software Requirement Specification (SRS) Format

In order to form a good SRS, here you will see some points which can
be used and should be considered to form a structure of good SRS.
These are as follows :
1. Introduction
• (i) Purpose of this document
• (ii) Scope of this document
• (iii) Overview
2. General description
3. Functional Requirements
4. Interface Requirements
5. Performance Requirements
6. Design Constraints
7. Non-Functional Attributes
8. Preliminary Schedule and Budget
9. Appendices
Software Requirement Specification (SRS) Format as name suggests, is
complete specification and description of requirements of software that
needs to be fulfilled for successful development of software system.
These requirements can be functional as well as non-functional
depending upon type of requirement. The interaction between different
customers and contractor is done because its necessary to fully
understand needs of customers.
Depending upon information gathered after interaction, SRS is
developed which describes requirements of software that may include
changes and modifications that is needed to be done to increase quality
of product and to satisfy customer’s demand.
1. Introduction :
• (i) Purpose of this Document –
At first, main aim of why this document is necessary
and what’s purpose of document is explained and
described.
• (ii) Scope of this document –
In this, overall working and main objective of
document and what value it will provide to customer is
described and explained. It also includes a description
of development cost and time required.
• (iii) Overview –
In this, description of product is explained. It’s simply
summary or overall review of product.

2. General description :
In this, general functions of product which includes objective of
user, a user characteristic, features, benefits, about why its
importance is mentioned. It also describes features of user
community.

3. Functional Requirements :
In this, possible outcome of software system which includes
effects due to operation of program is fully explained. All
 functional requirements which may include calculations, data
processing, etc. are placed in a ranked order.

4. Interface Requirements :
In this, software interfaces which mean how software program
communicates with each other or users either in form of any
language, code, or message are fully described and explained.
Examples can be shared memory, data streams, etc.

5. Performance Requirements :
In this, how a software system performs desired functions
under specific condition is explained. It also explains required
time, required memory, maximum error rate, etc.

6. Design Constraints :
In this, constraints which simply means limitation or restriction
are specified and explained for design team. Examples may
include use of a particular algorithm, hardware and software
limitations, etc.

7. Non-Functional Attributes :
In this, non-functional attributes are explained that are
required by software system for better performance. An
example may include Security, Portability, Reliability,
Reusability, Application compatibility, Data integrity, Scalability
capacity, etc.

8. Preliminary Schedule and Budget :

In this, initial version and budget of project plan are explained
which include overall time duration required and overall cost
required for development of project.
9. Appendices:
In this, additional information like references from where
information is gathered, definitions of some specific terms,
acronyms, abbreviations, etc. are given and explained.

What is the need for an SRS document?

Software Requirements Specification is usually the first deliverable for
any software project. As they say, first impression is the best
impression!, and you should ensure that even the first draft of an SRS is
of high quality.
The benefits of a good SRS are,
• A contract between the customer and the software vendor – A
good SRS document specifies all the features required in the
final system including technical requirements and interface
requirements. SRS document is used by the customer to
determine whether the software vendor has provided all the
features in the delivered software system. To the Software
vendor it provides a solid foundation to fix the scope of the
software system.
• Enables costing and pricing of the project – A well-defined SRS
enables software developers to accurately estimate the amount
of effort required to build the software product. Function point
analysis and SMC are some the techniques adopted for
estimating effort.
• Input for detailed design – A good SRS enables experienced
developers to convert the requirements directly to a technical
design. For example, a well-defined data dictionary can be easily
converted to a database specification.
• Management of customer expectations – Since SRS precisely
defines project scope, it ensures that customer expectations
don’t change during software development. If they do, SRS can
be modified and costing/pricing can be done again on the
changes required.

Characteristics of SRS
Software requirements specification should be accurate, complete,
efficient, and of high quality, so that it does not affect the entire project
plan. An SRS is said to be of high quality when the developer and user
easily understand the prepared document. Other characteristics of SRS
are discussed below.

1. Correct: SRS is correct when all user requirements are stated in the requirements
document. The stated requirements should be according to the desired system. This
implies that each requirement is examined to ensure that it (SRS) represents user
requirements. Note that there is no specified tool or procedure to assure the
 correctness of SRS. Correctness ensures that all specified requirements are
performed correctly.
2. Unambiguous: SRS is unambiguous when every stated requirement has
only one interpretation. This implies that each requirement is uniquely
interpreted. In case there is a term used with multiple meanings, the
requirements document should specify the meanings in the SRS so that it is
clear and easy to understand.
3. Complete: SRS is complete when the requirements clearly define what the
software is required to do. This includes all the requirements related to
performance, design and functionality.
4. Ranked for importance/stability: All requirements are not equally
important, hence each requirement is identified to make differences among other
requirements. For this, it is essential to clearly identify each requirement.
Stability implies the probability of changes in the requirement in future.
5. Modifiable: The requirements of the user can change, hence requirements
document should be created in such a manner that those changes can be
modified easily, consistently maintaining the structure and style of the SRS.
6. Traceable: SRS is traceable when the source of each requirement is clear
and facilitates the reference of each requirement in future. For this, forward
tracing and backward tracing are used. Forward tracing implies that each
requirement should be traceable to design and code elements. Backward tracing
implies defining each requirement explicitly referencing its source.
7. Verifiable: SRS is verifiable when the specified requirements can be verified
with a cost-effective process to check whether the final software meets those
requirements. The requirements are verified with the help of reviews. Note that
unambiguity is essential for verifiability.
8. Consistent: SRS is consistent when the subsets of individual requirements
defined do not conflict with each other. For example, there can be a case when
different requirements can use different terms to refer to the same object. There
can be logical or temporal conflicts between the specified requirements and
some requirements whose logical or temporal characteristics are not satisfied.
For instance, a requirement states that an event ‘a’ is to occur before another
event ‘b’. But then another set of requirements states (directly or indirectly by
transitivity) that event ‘b’ should occur before event ‘a’.

COMPONENTS OF THE SRS

Introduction to Components of the SRS
In previous section, we discussed various characteristics that will help
in completely specification the requirements. Here we describe some
of system properties that an SRS should specify. The basic issues, an
SRS must address are:
• Functional requirements
• Performance requirements
• Design constraints
 • External interface requirements
Conceptually, any SRS should have these components. Now we will
discuss them one by one.
1.Functional Requirements
Functional requirements specify what output should be produced from
the given inputs. So they basically describe the connectivity between
the input and output of the system. For each functional requirement:
1. A detailed description of all the data inputs and their sources, the
units of measure, and the range of valid inputs be specified:
2. All the operations to be performed on the input data obtain the
output should be specified, and
3. Care must be taken not to specify any algorithms that are not parts of
the system but that may be needed to implement the system.
4. It must clearly state what the system should do if system behaves
abnormally when any invalid input is given or due to
some error during computation. Specifically, it should specify the
behaviour of the system for invalid inputs and invalid outputs.
2. Performance Requirements (Speed Requirements)
This part of an SRS specifies the performance constraints on the
software system. All the requirements related to the performance
characteristics of the system must be clearly specified. Performance
requirements are typically expressed as processed transaction s per
second or response time from the system for a user event or screen
refresh time or a combination of these. It is a good idea to pin down
performance requirements for the most used or critical transactions,
user events and screens.
3. Design Constraints
The client environment may restrict the designer to include some
design constraints that must be followed. The various design
constraints are standard compliance, resource limits, operating
environment, reliability and security requirements and policies that may
have an impact on the design of the system. An SRS should identify and
specify all such constraints.
Standard Compliance: It specifies the requirements for the standard the
system must follow. The standards may include the report format and
according procedures.
Hardware Limitations: The software needs some existing or
predetermined hardware to operate, thus imposing restrictions on the
design. Hardware limitations can includes the types of machines to be
used operating system availability memory space etc.
Fault Tolerance: Fault tolerance requirements can place a major
constraint on how the system is to be designed. Fault tolerance
requirements often make the system more complex and expensive, so
they should be minimized.
Security: Currently security requirements have become essential and
major for all types of systems. Security requirements place restriction
s on the use of certain commands control access to database, provide
different kinds of access, requirements for different people, require the
use of passwords and cryptography techniques, and maintain a log of
activities in the system.
4. External Interface Requirements
For each external interface requirements:
1. All the possible interactions of the software with people hardware
and other software should be clearly specified,
2. The characteristics of each user interface of the software product
should be specified and
3. The SRS should specify the logical characteristics of each interface
between the software product and the hardware components for
hardware interfacing.