Course:

Software Engineering
_____________________
Topic: Software Requirement Specification
REQUIREMENTS ANALYSIS AND SPECIFICATION
• Before we start to develop our software, it becomes quite essential for us to understand and

document the exact requirement of the customer. Experienced members of the development

team carry out this job. They are called as system analysts.

• 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 remove all ambiguities and inconsistencies from the initial

customer perception of the problem.

Causes of failed software projects
• Incomplete requirements 13.1%

• Lack of user involvement 12.4%

• Lack of resources 10.6%

• Unrealistic expectations 9.9%

• Lack of executive support 9.3%

• Changing requirements & specifications 8.8%

• Lack of planning 8.1%

• System no longer needed 7.5%

• Failures to understand the requirements led the developers to build the wrong system.
Requirement Goals
Understand the requirements in appropriate detail.

• Define the requirements in a manner that is clear to the client. This may be a written

specification, prototype system, or other form of communication.

• Define the requirements in a manner that is clear to the people who will design, implement,

and maintain the system.

• Ensure that the client and developers understand the requirements and their implications.
Steps in the Requirements Phase
The requirements part of a project can be divided into several stages:

• Analysis to establish the system's services, constraints, and goals by

consultation with client, customers, and users.

• Modeling to organize the requirements in a systematic and comprehensible

manner.

• Define, record, and communicate the requirements.

REQUIREMENTS ANALYSIS AND SPECIFICATION
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?
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/she resolves them by carrying out further discussions with the

end-users and the customers.

Software Requirement Specification (SRS)

SRS is a document created by system analyst after the requirements are collected

from various stakeholders.

• SRS defines how the intended software will interact with hardware, external

interfaces, speed of operation, response time of system, portability of software

across various platforms, maintainability, speed of recovery after crashing, Security,

Quality, Limitations etc.

• The requirements received from client are written in natural language. It is the

responsibility of the system analyst to document the requirements in technical

language so that they can be comprehended and used by the software development

team.
SRS should come up with the following features:

• User Requirements are expressed in natural language.

• Technical requirements are expressed in structured language,

which is used inside the organization.

• Design description should be written in Pseudo code.

• Format of Forms and GUI screen prints.

• Conditional and mathematical notations for DFDs etc.

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
Functional requirements:-

The functional requirements part discusses the functionalities required from the system. The system is
considered to perform a set of high-level functions

Nonfunctional requirements:-

Nonfunctional requirements deal with the characteristics of the system which cannot be expressed as
functions - such as the maintainability of the system, portability of the system, usability of the system,
etc.

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. These are the items which the developers might
Properties of a good SRS document

The important properties of a good SRS document are the following:

• 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
• 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.

Problems without a SRS document
The important problems that an organization would face if it does not develop a 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 will be very much difficult for user document writers to write the users’ manuals properly
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 unambiguous and inconsistent.