UNIT 2: REQUIREMENTS ANALYSIS AND SPECIFICATION

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.

The goal of the requirements analysis and specification phase can be stated in a nutshell as
follows.

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.

How is the SRS document validated?

Once the SRS document is ready, it is first reviewed internally by the project team to ensure
that it accurately captures all the user requirements, and that it is understandable, consistent,
unambiguous, and complete. The SRS document is then given to the customer for review. After the
customer has reviewed the SRS document and agrees to it, it forms the basis for all future
development activities and also serves as a contract document between the customer and the
development organisation.

What are the main activities carried out during 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

The complete set of requirements are almost never available in the form of a single document
from the customer. In fact, it would be unrealistic to expect the customers to produce a
comprehensive document containing a precise description of what he wants. Further, the complete
requirements are rarely obtainable from any single customer representative. Therefore, the
requirements have to be gathered by the analyst from several sources in bits and pieces. These
gathered requirements need to be analysed to remove several types of problems that frequently occur
in the requirements that have been gathered piecemeal from different sources.
We can conceptually divide the requirements gathering and analysis activity into two separate tasks:

• Requirements gathering

• Requirements analysis

We discuss these two tasks in the following subsections.

REQUIREMENT GATHERING

Requirements gathering is also popularly known as requirements elicitation.

1.Studying existing documentation: The analyst usually studies all the available documents
regarding the system to be developed before visiting the customer site. Customers usually provide
statement of purpose (SoP) document to the developers. Typically these documents might discuss
issues such as the context in which the software is required, the basic purpose, the stakeholders,
features of any similar software developed else where, etc.

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.
 3. Task analysis: The users usually have a black-box view of a software and consider the
software as something that provides a set of services (functionalities).

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. For different types of scenarios of
a task, the behaviour of the software can be different.

For example, the possible scenarios for the book issue task of a library automation software may be:

Book is issued successfully to the member and the book issue slip is printed. The book is reserved,
and hence cannot be issued to the member.

The maximum number of books that can be issued to the member is already reached, and no more
books can be issued to the member.

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 problems in the gathered
requirements.

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.

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, he starts to systematically organise the requirements in the form of an SRS document.
The SRS document usually contains all the user requirements in a structured though an informal
form.
Characteristics of a Good SRS Document

 Concise:
 Implementation-independent:
 Traceable:
 Modifiable:
 Identification of response to undesired events:
 Verifiable:

Attributes of Bad SRS Documents

o Over-specification:
o Forward references:
o Wishful thinking:
o Noise:

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.

a) Functional requirements:
Functionality or services that the system is expected to provide.
Functional requirements may also explicitly state what the system
shouldn‘t do. Functional requirements specification should be:
 Complete: All services required by the user should be defined
 Consistent: should not have contradictory definition (also avoid ambiguity
 don‘t leave room for different interpretations)
b) Examples:

The LIBSYS system

 A library system that provides a single interface to a number of
databases of articles in different libraries.
 Users can search for, download and print these articles for personal study.

c) The user shall be able to search either all of the initial set of databases or select
a subset from it.
d) The system shall provide appropriate viewers for the user to read documents in
the document store.
e) Every order shall be allocated a unique identifier (ORDER_ID) which the user
shall be able to copy to the account‘s permanent storage area.
f) Non-Functional requirements:
Requirements that are not directly concerned with the specific functions delivered
by the system Typically relate to the system as a whole rather than the individual
system features
Often could be deciding factor on the survival of the system (e.g. reliability, cost, response
time)
g) Non-Functional requirements classifications:
h)
 Figure 2.1 Non Functional Requirement Classification

We can see from this diagram that the non-functional requirements may
come from required characteristics of the software (product requirements), the
organization developing the software (organizational requirements) or from
external sources.
The types of non-functional requirements are:
i) Product requirements

Specify the desired characteristics that a system or subsystem must possess.

Most NFRs are concerned with specifying constraints on the behavior of the executing
system.
o Performance
o Capacity
Others are more difficult to quantify and, consequently, are often stated informally
o Usability

j) Organisational requirements
Process requirements are constraints placed upon the development process
of the system Process requirements include:
o Performance
o Capacity
Others are more difficult to quantify and, consequently, are often stated informally
o Usability
k) Organisational requirements
Process requirements are constraints placed upon the development process
of the system Process requirements include:

o Requirements on development standards and methods which must be followed

o CASE tools which should be used
o The management reports which must be provided
l) Examples of process requirements
The development process to be used must be explicitly defined and must be
conformant with ISO 9000 standards
The system must be developed using the XYZ suite of CASE tools
Management reports setting out the effort expended on each identified system
component must be produced every two weeks
FORMAL SYSTEM SPECIFICATION
In recent years, formal techniques 3 have emerged as a central issue in software
engineering. This is not accidental; the importance of precise specification, modelling,
and verification is recognised to be important in most engineering disciplines. Formal
methods provide us with tools to precisely describe a system and show that a system is
correctly implemented. We say a system is correctly implemented when it satisfies its
given specification.
The specification of a system can be given either as a list of its desirable properties
(property-oriented approach) or as an abstract model of the system (model-approach).
These two approaches are discussed here.
What is a Formal Technique?
A formal technique is a mathematical method to specify a hardware and/or software
system, verify whether a specification is realisable, verify that an implementation satisfies its
specification, prove properties of a system without necessarily running the system, etc.
The mathematical basis of a formal method is provided by its specification language.
More precisely, a formal specification language consists of two sets—syn and sem, and a
relation between them.
The set syn is called the syntactic domain, the set sem is called the semantic domain,
and the relation sat is called the satisfaction relation.
For a given specification syn, and model of the system sem, if sat (syn, sem), then syn is
said to be the specification of sem, and sem is said to be the specificand of syn.
Syntactic domains
The syntactic domain of a formal specification language consists of an alphabet of
symbols and a set of formation rules to construct wellformed formulas from the alphabet.
The well-formed formulas are used to specify a system.
Semantic domains:
Formal techniques can have considerably different semantic domains. Abstract data
type specification languages are used to specify algebras, theories, and programs.
o