Unit-III Requirement Analysis

and Specification
 Syllabus

Requirements gathering and analysis:- Requirements

gathering, Requirements analysis
Software requirement specification:- users of SRS
document, characteristics of a good SRS document,
Attributes of Bad SRS documents, important
categories of customer Requirements, Functional
requirements, Traceability, organization of the SRS
document.
 Requirements analysis and specification
• Requirements analysis and specification to be a very important phase of software
development life cycle .
• Experienced developers take considerable time to understand the exact requirements
of the customer and to document those. They know that without a clear
understanding of the problem and proper documentation of the same, it is
impossible to develop a satisfactory solution.
• The requirements analysis and specification phase starts after the feasibility study
stage is complete and the project has been found to be financially viable and
technically feasible.
• The requirements analysis and specification phase ends when the requirements
specification document has been developed and reviewed.
• The requirements specification document is usually called as the software
requirements specification (SRS) document.
 Requirements analysis and specification
• The goal of the requirements analysis and specification phase is to clearly
understand the customer requirements and to systematically organise the
requirements into a document called the Software Requirements Specification (SRS)
document.
• The engineers who gather and analyse customer requirements and then write the
requirements specification document are known as system analysts.
• The SRS document is the final outcome of the requirements analysis and
specification phase.
• Requirements analysis and specification phase mainly involves carrying out the
following two important activities:
• Requirements gathering and analysis
• Requirements specification
 REQUIREMENTS GATHERING AND ANALYSIS

• Requirements gathering and analysis activity divided into two separate tasks:
• Requirements gathering
• Requirements analysis
Requirements Gathering
• Requirements gathering is also popularly known as requirements elicitation.
• The primary objective of the requirements gathering task is to collect the requirements
from the stakeholders.
• A stakeholder is a source of the requirements and is usually a person, or a group of
persons who either directly or indirectly are concerned with the software.
• The important ways in which an experienced analyst gathers requirements:
1. Studying existing documentation
2. Interview
3. Task analysis
4. Scenario analysis
5. Form analysis
 REQUIREMENTS GATHERING

1. Studying existing documentation: The analyst usually studies all the available
documents regarding the system to be developed before visiting the customer site.
2. Interview: Typically, there are many different categories of users of a software. Each
category of users typically requires a different set of features from the software.
Therefore, it is important for the analyst to first identify the different categories of users
and then determine the requirements of each.
3. Task analysis: The analyst tries to identify and understand the different tasks to be
performed by the software. For each identified task, the analyst tries to formulate the
different steps necessary to realise the required functionality in consultation with the
users.
4. Scenario analysis : A task can have many scenarios of operation. The different
scenarios of a task may take place when the task is invoked under different situations.
5. Form analysis: In form analysis the exiting forms and the formats of the notifications
produced are analysed to determine the data input to the system and the data that are
output from the system.
 REQUIREMENTS ANALYSIS

• After requirements gathering is complete, the analyst analyses the gathered

requirements to form a clear understanding of the exact customer requirements and
to weed out any
• The main purpose of the requirements analysis activity is to analyse the gathered
requirements to remove all ambiguities, incompleteness, and inconsistencies from
the gathered customer requirements and to obtain a clear understanding of the
software to be developed. problems in the gathered requirements.
 REQUIREMENTS ANALYSIS

• The following basic questions pertaining to the project should be clearly understood
by the analyst before carrying out analysis:
1. What is the problem?
2. Why is it important to solve the problem?
3. What exactly are the data input to the system and what exactly are the data output
by the system?
4. What are the possible procedures that need to be followed to solve the problem?
5. What are the likely complexities that might arise while solving the problem?
6. If there are external software or hardware with which the developed software has to
interface, then what should be the data interchange formats with the external
systems?
 REQUIREMENTS ANALYSIS

During requirements analysis, the analyst needs to identify and resolve three main
types of problems in the requirements:
• Anomaly
• Inconsistency
• Incompleteness
Anomaly: Anomaly is an ambiguity in a requirement. When a requirement is
anomalous, several interpretations of that requirement are possible.
Inconsistency: Two requirements are said to be inconsistent, if one of the
requirements contradicts the other .
Incompleteness: An incomplete set of requirements is one in which some requirements
have been overlooked. An experienced analyst can detect most of these missing
features and suggest them to the customer
 SOFTWARE REQUIREMENTS SPECIFICATION
(SRS)
• After the analyst has gathered all the required information regarding the software to
be developed, and has removed all incompleteness, inconsistencies, and anomalies
from the specification, developer systematically organise the requirements in the
form of an SRS document.
• Among all the documents produced during a software development life cycle, SRS
document is probably the most important document and is the toughest to write.
• SRS document as the documentation of a contract between the development
team and the customer .
 SOFTWARE REQUIREMENTS SPECIFICATION
(SRS)
Users of SRS Document
1. Users, customers, and marketing personnel
2. Software developers
3. Test engineers
4. User documentation writers
5. Project managers
6. Maintenance engineers
 SOFTWARE REQUIREMENTS SPECIFICATION
(SRS)
1. Users, customers, and marketing personnel: These stakeholders need to refer to the
SRS document to ensure that the system as described in the document will meet their
needs. Remember that the customer may not be the user of the software, but may be
some one employed or designated by the user .
2. Software developers: The software developers refer to the SRS document to make sure
that they are developing exactly what is required by the customer.
3. Test engineers: The test engineers use the SRS document to understand the
functionalities, and based on this write the test cases to validate its working. They need
that the required functionality should be clearly described, and the input and output
data should have been identified precisely.
4. User documentation writers: The user documentation writers need to read the SRS
document to ensure that they understand the features of the product well enough to be
able to write the users’ manuals.
5. Project managers: The project managers refer to the SRS document to ensure that they
can estimate the cost of the project easily by referring to the SRS document and that it
contains all the information required to plan the project.
6. Maintenance engineers: The SRS document helps the maintenance engineers to under-
stand the functionalities supported by the system. A clear knowledge of the
functionalities can help them to understand the design and code.
 Uses of a well-formulated SRS document

1. Forms an agreement between the customers and the developers

2. Reduces future reworks

3. Provides a basis for estimating costs and schedules

4. Provides a baseline for validation and verification

5. Facilitates future extensions

 Characteristics of a Good SRS Document
• The skill of writing a good SRS document usually comes from the experience gained
from writing SRS documents for many projects.
• IEEE Recommended Practice for Software Requirements Specifications[IEEE830]
describes the content and qualities of a good software requirements specification
(SRS).
• Characteristics of a Good SRS Document
1. Concise
2. Implementation-independent
3. Traceable
4. Modifiable
5. Identification of response to undesired events
6. Verifiable
 Characteristics of a Good SRS Document
1. Concise: The SRS document should be concise and at the same time unambiguous,
consistent, and complete.
2. Implementation-independent: The SRS should be free of design and
implementation decisions unless those decisions reflect actual requirements. It
should only specify what the system should do and refrain from stating how to do
these.
The SRS document should describe the system to be developed as a black box, and
should specify only the externally visible behaviour of the system. For this reason,
the SRS document is also called the black-box specification of the software being
developed.
 Characteristics of a Good SRS Document

3. Traceable: It should be possible to trace a specific requirement to the design elements

that implement it and vice versa. Traceability is also important to verify the results of a
phase with respect to the previous phase and to analyse the impact of changing a
requirement on the design elements and the code.
4. Modifiable: Customers frequently change the requirements during the software
development due to a variety of reasons. An SRS document is often modified after the
project completes to accommodate future enhancements and evolution. A wellstructured
document is easy to understand and modify. But it become difficult as it would require
changes to be made at large number of places in the document.
5. Identification of response to undesired events: The SRS document should discuss the
system responses to various undesired events and exceptional conditions that may
arise.
6. Verifiable: All requirements of the system as documented in the SRS document should
be verifiable. This means that it should be possible to design test cases based on the
description of the functionality as to whether or not requirements have been met in an
implementation. Any feature of the required system that is not verifiable should be
listed separately in the goals of the implementation section of the SRS document.
 Attributes of Bad SRS documents
SRS documents written by novices frequently suffer from a variety of problems. Some of
the problems are
Over-specification: It occurs when the analyst tries to address the “how to” aspects in
the SRS document. For example, in the library automation problem, one should not
specify whether the library membership records need to be stored indexed on the
member’s first name or on the library member’s identification (ID) number . Over-
specification restricts the freedom of the designers in arriving at a good design
solution.
Forward references: One should not refer to aspects that are discussed much later in
the SRS document. Forward referencing seriously reduces readability of the
specification.
Wishful thinking: This type of problems concern description of aspects which would be
difficult to implement.
Noise: The term noise refers to presence of material not directly relevant to the software
development process.
Important categories of customer Requirements
A good SRS document, should properly categorize and organise the requirements into
different sections [IEEE830].
As per the IEEE 830 guidelines, the important categories of user requirements are the
following.
An SRS document should clearly document the following aspects of a software:
• Functional requirements
• Non-functional requirements
— Design and implementation constraints
— External interfaces required
— Other non-functional requirements
• Goals of implementation.
Important categories of customer Requirements
Functional requirements
• The functional requirements capture the functionalities required by the users from
the system.
• consider a software as offering a set of functions {fi} to the user .
• These functions can be considered similar to a mathematical function f : I → O,
meaning that a function transforms an element (ii) in the input domain (I) to a value
(oi) in the output.
• Each function fi of the system can be considered as reading certain data ii, and
then transforming a set of input data (ii) to the corresponding set of output data (oi).
• The functional requirements of the system, should clearly describe each
functionality that the system would support along with the corresponding input and
output data set.
Important categories of customer Requirements
Non-functional requirements
• The non-functional requirements are non-negotiable obligations that must be
supported by the software.
• The non-functional requirements capture those requirements of the customer that
cannot be expressed as functions
• Non-functional requirements usually address external interfaces, user interfaces,
maintainability, portability, usability, maximum number of concurrent users,
timing, and throughput (transactions per second, etc.).
• The non-functional requirements can be critical in the sense that any failure by the
developed software to achieve some minimum defined level in these requirements
can be considered as a failure and make the software unacceptable by the
customer.
• The IEEE 830 standard recommends that out of the various non-functional
requirements, the external interfaces, and the design and implementation
constraints should be documented in two different sections.
• The remaining non-functional requirements should be documented later in a
section and these should include the performance and security requirements.
Important categories of customer Requirements
Non-functional requirements
Design and implementation constraints:
• Design and implementation constraints are an important category of non-
functional requirements describe any items or issues that will limit the options
available to the developers.
• Some of the example constraints can be—corporate or regulatory policies that needs
to be honoured; hardware limitations; interfaces with other applications; specific
technologies, tools, and databases to be used; specific communications protocols to
be used; security considerations; design conventions or programming standards to
be followed, etc.
• Consider an example of a constraint that can be included in this section—Oracle
DBMS needs to be used as this would facilitate easy interfacing with other
applications that are already operational in the organisation.
Important categories of customer Requirements
Non-functional requirements
External interfaces required:
• Examples of external interfaces are— hardware, software and communication
interfaces, user interfaces, report formats, etc.
• To specify the user interfaces, each interface between the software and the users
must be described.
• The description may include sample screen images, any GUI standards or style
guides that are to be followed, screen layout constraints, standard buttons and
functions (e.g., help) that will appear on every screen, keyboard shortcuts, error
message display standards, and so on.
• One example of a user interface requirement of a software can be that it should be
usable by factory shop floor workers who may not even have a high school degree.
The details of the user interface design such as screen designs, menu structure,
navigation diagram, etc. should be documented in a separate user interface
specification document.
Important categories of customer Requirements
Non-functional requirements
Other non-functional requirements:
• This section contains a description of non- functional requirements that are
neither design constraints and nor are external interface requirements.
• An important example is a performance requirement such as the number of
transactions completed per unit time.
• Besides performance requirements, the other non-functional requirements to be
described in this section may include reliability issues, accuracy of results, and
security issues.
Important categories of customer Requirements
Non-functional requirements
Goals of implementation
• The ‘goals of implementation’ part of the SRS document offers some general
suggestions regarding the software to be developed.
• The goals of implementation section might document issues such system
functionalities that may be required in the future, easier support for new devices to
be supported in the future, reusability issues, etc.
• These are the items which the developers might keep in their mind during
development so that the developed system may meet some aspects that are not
required immediately.
• It is useful to remember that anything that would be tested by the user and the
acceptance of the system would depend on the outcome of this task, is usually
considered as a requirement to be fulfilled by the system and not a goal and vice
versa.
 How to classify the different types of requirements?
• Aspects which can be expressed as transformation of some input data to some
output data (i.e., the functions of the system) should be documented as the
functional requirement.
• Any other requirements whose compliance by the developed system can be verified
by inspecting the system are documented as non- functional requirements.
• Aspects whose compliance by the developed system need not be verified but are
included as suggestions to the developers are documented as goals of the
implementation.
 Functional Requirements
• In order to document the functional requirements of a system, it is necessary to
first learn to identify the high-level functions of the systems by reading the informal
documentation of the gathered requirements.
• The high-level functions would be split into smaller sub-requirements
• A high-level function is one using which the user can get some useful piece of work
done.
• Example: ATM transaction during withdrawal of money.
• Each high-level requirement typically involves accepting some data from the user
through a user interface, transforming it to the required response, and then
displaying the system response in proper format.
• A high-level function transforms certain input data to output data.
 Functional Requirements
• The different scenarios are essentially different behaviour exhibited by the system
for the same high-level function.
• Typically, each user input and the corresponding system action may be considered
as a sub-requirement of a high-level requirement.
• Thus, each high-level requirement can consist of several sub-requirements.
• The rectangles and circles alternate in the execution of a single high-level function
of the system, indicating a series of requests from the user and the corresponding
responses from the system.
• Typically, there is some initial data input by the user . After accepting this, the
system may display some response (called system action )
Functional Requirements
 Traceability
• Traceability means that it would be possible to identify (trace) the specific design
component which implements a given requirement, the code part that corresponds
to a given design component, and test cases that test a given requirement.
• Thus, any given code component can be traced to the corresponding design
component, and a design component can be traced to a specific requirement that it
implements and vice versa.
• Traceability analysis is an important concept and is frequently used during software
development.
• For example, by doing a traceability analysis, we can tell whether all the
requirements have been satisfactorily addressed in all phases.
• It can also be used to assess the impact of a requirements change.
• That is, traceability makes it easy to identify which parts of the design and code
would be affected, when certain requirement change occurs.
• It can also be used to study the impact of a bug.
 Traceability
• To achieve traceability, it is necessary that each functional requirement should be
numbered uniquely and consistently.
• Proper numbering of the requirements makes it possible for different documents to
uniquely refer to specific requirements.
• For example the functional requirements have been numbered R.1, R.2, etc. and
the sub-requirements for the requirement R.1 have been numbered R.1.1, R.1.2,
etc.
 Organisation of the SRS Document
• IEEE 830 standard SRS document has been intended to serve as a guideline for
organizing a requirements specification document into sections and allows the
flexibility of tailoring it, as may be required for specific projects.
• Depending on the type of project being handled, some sections can be omitted,
introduced, or interchanged by the analyst.