Requirements Analysis

and Specification
Unit – 2 & 3
-Abhilash Chakraborty
The goal of the requirement analysis and specification is to clearly
understand the customer requirement and to systematically organize
the requirement into a specification document.

This phase consists of two distinct activities, namely

- Requirements gathering and analysis, and
- Requirements specification
Requirements gathering and analysis

Requirements gathering :

 Study the existing documentation

 Interview
 Task analysis
 Scenario analysis
 Form analysis
Requirements gathering and analysis

Requirements analysis:

 What is the problem?

 Why is it important to solve the problem?
 Input? / output?
 Possible procedure ?
 Complexity?
 External s/w or h/w requirement !
 Etc.
Requirements gathering and analysis

Types of problem:

 Ambiguity/ anomaly
 Inconsistency
 Incompleteness
Role of a system analyst

The analyst starts requirements gathering and analysis activity by

collecting all information from the customer which could be used to
develop the requirements of the system.

He then analyzes the collected information to obtain a clear and

thorough understanding of the product to be developed, with a
view to removing all ambiguities and inconsistencies from the initial
customer perception of the problem.
Role of a system analyst

The following basic questions pertaining to the project should be clearly

understood by the analyst in order to obtain a good grasp of the
problem:

 What is the problem?

 Why is it important to solve the problem?
 What are the possible solutions to the problem?
 What exactly are the data input to the system and what exactly are the data
output by the system?
 What are the likely complexities that might arise while solving the problem?
 If there are external software or hardware with which the developed software has
to interface, then what exactly would the data interchange formats with the
external system be?
Role of a system analyst

After the analyst has understood the exact customer requirements,

he proceeds to identify and resolve the various requirements
problems.

The most important requirements problems that the analyst has to

identify and eliminate are the problems of anomalies,
inconsistencies, and incompleteness.

When the analyst detects any inconsistencies, anomalies or

incompleteness in the gathered requirements, he resolves them by
carrying out further discussions with the end-users and the customers.
Requirements specification

After all ambiguities, inconsistencies, and incompleteness have been resolved

and all the requirements properly understood, the requirements specification
activity can start.

During this activity, the user requirements are systematically organized into a
Software Requirements Specification (SRS) document.

The customer requirements identified during the requirements gathering and

analysis activity are organized into a SRS document.
Parts of a SRS document

The important parts of SRS document are:

➢ Functional requirements of the system

➢ Non-functional requirements of the system, and
➢ Goals of implementation
Parts of a SRS document

Functional requirements:
 The functional requirements part discusses the functionalities required from
the system.
 Each function fi of the system can be considered as a transformation of a
set of input data ( ii ) to the corresponding set of output data (oi ).
Parts of a SRS document

Nonfunctional requirements:
 Nonfunctional requirements deal with the characteristics of the system which
can not be expressed as functions - such as the maintainability of the system,
portability of the system, usability of the system, etc.
 Nonfunctional requirements may include:
 reliability issues,
 accuracy of results,
 human - computer interface issues,
 constraints on the system implementation, etc.
Parts of a SRS document

Goals of implementation:
 The goals of implementation part documents some general suggestions
regarding development. These suggestions guide trade-off among design
goals.
 The goals of implementation section might document issues such as revisions to
the system functionalities that may be required in the future, new devices to be
supported in the future, reusability issues, etc.
Properties of a good SRS document

 Concise: The SRS document should be concise and at the same time unambiguous,
consistent, and complete. Verbose and irrelevant descriptions reduce readability and
also increase error possibilities.
 Structured: It should be well-structured. A well-structured document is easy to understand
and modify. In practice, the SRS document undergoes several revisions to cope up with
the customer requirements. Often, the customer requirements evolve over a period of
time. Therefore, in order to make the modifications to the SRS document easy, it is
important to make the document well-structured.
 Black-box view: It should only specify what the system should do and refrain from stating
how to do these. This means that the SRS document should specify the external behavior
of the system and not discuss the implementation issues. The SRS document should view
the system to be developed as black box, and should specify the externally visible
behavior of the system. For this reason, the SRS document is also called the black-box
specification of a system.
Properties of a good SRS document

 Conceptual integrity: It should show conceptual integrity so that the reader can easily
understand it.
 Response to undesired events: It should characterize acceptable responses to undesired
events. These are called system response to exceptional conditions.
 Verifiable: All requirements of the system as documented in the SRS document should be
verifiable. This means that it should be possible to determine whether or not requirements
have been met in an implementation.
 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.

Note: It is essential to specify the responses to both valid and invalid values.

(3). Full labels and references to all figures, tables, and diagrams in the SRS and
definitions of all terms and units of measure.
 Features of a good SRS document:
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.
 Features of a good SRS document:
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.
 Features of a good SRS document:
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.
There are two types of Traceability:
1. Backward Traceability: This depends upon each requirement explicitly referencing its
source in earlier documents.
2. Forward Traceability: This depends upon each element in the SRS having a unique name or
reference number.
The forward traceability of the SRS is especially crucial when the software product enters the
operation and maintenance phase. As code and design document is modified, it is
necessary to be able to ascertain the complete set of requirements that may be concerned
by those modifications.
 Features of a good SRS document:
9. Design Independence: There should be an option to select from multiple design
alternatives for the final system. More specifically, the SRS should not contain any
implementation details.
10. Testability: An SRS should be written in such a method that it is simple to generate test
cases and test plans from the report.
11. Understandable by the customer: An end user may be an expert in his/her explicit domain
but might not be trained in computer science. Hence, the purpose of formal notations and
symbols should be avoided too as much extent as possible. The language should be kept
simple and clear.
12. The right level of abstraction: If the SRS is written for the requirements stage, the details
should be explained explicitly. Whereas, for a feasibility study, fewer analysis can be used.
Hence, the level of abstraction modifies according to the objective of the SRS.
Problems without a SRS document

The important problems that an organization would face if it does not develop an
SRS document are as follows:

 Without developing the SRS document, the system would not be implemented
according to customer needs.
 Software developers would not know whether what they are developing is what exactly
required by the customer.
 Without SRS document, it will be very much difficult for the maintenance engineers to
understand the functionality of the system.
 It would be very much difficult for user document writers to write the users’ manuals
properly without understanding the SRS document.
cont.

Problems with an unstructured specification

 It would be very much difficult to understand that document.

 It would be very much difficult to modify that document.
 Conceptual integrity in that document would not be shown.
 The SRS document might be ambiguous and inconsistent.
 CHARACTERISTICS OF BAD SRS:

If SRS document is written by novice then it is said to be bad SRS. It might be the
problem of contradiction, incompleteness and ambiguity, other problem that is
chances to occur are:

(a)Over specification:-
Over specification occurs when the SRS document includes how to issue. Ex:- In
case of library automation system we must not record the fact whether the
membership records are sorted in descending order by considering members first
name.
b) Forward Reference:-
This aspect specifies that, we must not include details of the requirements in the
initial stage which will be discussed later in the SRS documents. For example in case
of faster processing, the books may be kept separately by indexing with respect to
their ISBN(International standard book number). These details are irrelevant in the
initial stages 1 & 2 etc.
 CHARACTERISTICS OF BAD SRS:

(c)Wish-full Thinking:-
This aspect specifies that requirements those will be difficult to implement need not be
describe/mention in the SRS.
(d)Noise:-
Noise means irrelevant materials associated to software development which might rarely
or not used at all.
Different categories of user of SRS
documents
1. user, customer & marketing personnel
2. s/w developers
3. test engineers
4. user documentation writers
5. project managers
6. maintenance engineer
How to Write Software Use Cases in an SRS

A use case describes how a user will interact with the system. It will describe
the product from the end user’s point of view in a simple story format.

Writing out use cases forces you to think through what users will do with the
software and how it will respond.

It is the real-life visualization of the functional requirements.

How to Write Software Use Cases in an SRS
ORGANISATION OF AN SRS DOCUMENTS:-
1. INTRODUCTION
1.1 purposes
1.2 scopes
1.3 definition acronyms & abbreviation
1.4 references
1.5 overview
2. THE OVERALL DESCRIPTION
2.1 Product Perspective
2.1.1 system interfaces
2.1.2 interfaces
2.1.3 h/w interfaces
2.1.4 s/w interfaces
2.1.5 communications requirements
2.1.6 memory constraints
2.1.7 operation
2.1.8 site adaptation requirements
2.2 product function
2.3 user characteristics
2.4 constraints
2.5 operating environments
2.6 user environments
2.7 assumptions & dependencies
2.8 apportioning of requirements
ORGANISATION OF AN SRS DOCUMENTS:-
3. SPECIFIC REQUIREMENTS
3.1 external interfaces
i) user interfaces
ii) h/w interfaces
iii) s/w interfaces
iv) communication interfaces
3.2 functions
3.3 performance requirements
3.4 logical database requirements
3.5 design constraints
3.5.1 standard compliance
3.6 s/w system attribute
3.6.1 reliability
3.6.2 availability
3.6.3 security
3.6.4 maintainability
3.6.5 portability
3.7 organizing the specific requirements
3.7.1 system mode
3.7.2 user class
3.7.3 objects
3.7.4 feature
3.7.5 stimulus
3.7.6 response
3.7.7 functional hierarchy
3.8 additional comments
ORGANISATION OF AN SRS DOCUMENTS:-

4. SUPPORTING INFORMATION
4.1 table of content & index
4.2 appendixes
A Software Requirement Specification (SRS)
Example
Here is a trimmed down example of an SRS document for an enterprise chat app called eChat:
Introduction
This document details the project plan for the development of “eChat.”
It is intended for developers, designers, and testers working on “eChat” as well as project investors.
This plan will include a summary of:
 how the system will function
 the scope of the project from the development viewpoint
 the technology used to develop the project, and
 the metrics used to determine the project’s progress
 Overall Description
Companies need remote communication tools, especially now that more people are working from
home. The problem is that most companies end up using multiple applications to accomplish this:
one for text chat, one for video chat, and one for conferences and meetings. “eChat” will solve
this problem by combining these features in one application.
Customers
The customers will be enterprise companies. It will not target the general public.
A Software Requirement Specification (SRS)
Example
Functionality
 Users should be able to sign up with enterprise LDAP accounts.
 Users should be able to create ad hoc chat groups comprising sets of users and send
private messages to individual users.
 Users should be able to have text chats that they can break into threads.
 The application should be able to handle group video chat of up to 100 users at a time.
Platform
The application will be developed in React Native to enable the creation of a web-based
application, an iOS mobile app, and an Android mobile app.
These applications will connect to a REST API built with .NET Core to store and retrieve data from a
MySQL database.
Authentication will be through existing LDAP installations.

Development Responsibilities
The developers on the “eChat” team will be responsible for writing all the code for the application,
developing the database, and managing releases.
A Software Requirement Specification (SRS)
Example

User Class and Characteristics

There will be a class of users called admin that will have permissions to access all functionality of the app,
including:
 Creating channels where multiple users can interact
 Making these channels public to the entire company or private for a group of people
 Deleting these channels
 Archiving these channels
Standard users will have access to all functionality of the app except those listed above.

System Features
Functional Requirements
 Users should be able to create ad hoc chat groups comprising sets of users and send private
messages to other users.
 Users should be able to have text chats that they can break into threads.
 Chats should be able to be archived indefinitely so users can reference past chats.
 Users should be able to upload files to chats for reference.
 External Interface Requirements
A Software Requirement Specification (SRS)
Example
User Interfaces
 Front-end software: React Native
 Back-end software: .NET Core
 Database software: MySQL
 LDAP connection: Authentication in an enterprise environment

Hardware Interfaces
 Both Mac and Windows operating systems through their default web browser
 iPhone
 Android
 Non-Functional Requirements

Performance Requirements
 The application should load and be usable within 3 seconds
 The application should update the interface on interaction within 2 seconds
 The database should be normalized to prevent redundant data and improve performance
 The database should be distributed to prevent outages
A Software Requirement Specification (SRS)
Example
Safety Requirements
 Databases should use sharding to be redundant to prevent loss of data.
 Backups of the databases should be done hourly and be kept for one week.

Security Requirements
 Any keys used for the REST API should be stored securely.
 Only the REST API should be able to connect to the databases.
 Databases should be behind a firewall.

Software Quality Attributes

 Availability: Because this application is critical to business communication, we will have a goal of four
nines(99.99%) availability.
 Correctness: The application should never allow anyone to read messages or discussions not intended
for that person.
 Maintainability: The application should use continuous integration so that features and bug fixes can
be deployed quickly without downtime.
 Usability: The interface should be easy to learn without a tutorial and allow users to accomplish their
goals without errors.