Software Requirement

Specification(SRS)

Topics Covered:

Software requirement specification(S

RS)

Authors of SRS

Need of SRS

Characteristics of SRS

Components of SRS

Behavioral /Non-behavioral

requirements

Software Requirement Specification(SRS)

SRS is a set of documents that specify the functional, performance,

design and interface requirements of the proposed system. In SRS the

external behavior of the problem, user interfaces, erroneous situations,

performance and design constraints, standard compliance, recovery etc

are included which can not be modeled during problem analysis.

Thus an SRS clearly defines:

External interfaces of the system.

Functional and non-functional requirements of the system.

Authors of SRS document-

SRS written by customer->

It defines the needs and expectations of the user.

SRS written by the developer of the system->

It serves as a contract document between customers and developers.

Need of SRS:

A basic purpose of software requirements specification is to bridge the

communication gap between the parties involved in the development

project. SRS is the medium through which the client and user needs are

accurately specified to the developer. Some of the benefits or needs of

SRS are as follows:

An SRS establishes the basis for agreement between the client and

the supplier on what the software product will do.

An SRS provides a reference for validation of the final product.

A high quality software is a pre-requisite to high quality software.

A high quality SRS reduces problem of changes and rework.

SRS bridges communication gap between developer and clients.

Characteristics of SRS:

To satisfy the basic goals SRS should have certain properties. Some of

the desirable properties or characteristics are:

-Correct -Consistent

-Complete -Ranked for importance and/or stability

-Unambiguous -Modifiable

-Verifiable -Traceable

Correctness:

An SRS is correct if every requirement included in the SRS

represents something required in the final system.

Correctness basically involves examining each requirement to make

sure it represents user requirements.

Completeness:

An SRS is complete if everything software has to do and the

responses of the software to all classes of input data are specified in

the SRS.

Unambiguous:

An SRS is unambiguous if and only if every requirement stated in it

has only one interpretation.

Unambiguity can be achieved by using formal specification language.

Verifiable:

An SRS is verifiable if and only if every stated requirement can be

checked whether the final software meets the requirements.

Verification of requirements is done through reviews.

Consistent:

An SRS is consistent if there is no requirement conflicts with other.

Inconsistencies or conflicts in SRS may lead to major problems, so

specifications should be consistent.

Ranked for importance/stability:

In SRS for each requirement the importance and stability of the

requirement can be ranked as critical, important, desirable etc. Some

requirements have more chances of changes in future but some are

not likely to change, accordingly ranking should be done.

Modifiable:

An SRS is modifiable if its structure and style could be changed

easily while preserving completeness and consistency.

Traceable:

An SRS is traceable if the origin of each of its requirements is clear

and it facilitates the referencing of each requirement in future.

Traceability aids verification and validation.

Components of SRS:

1) Functional requirements: Functional requirements specify which

outputs should be produced from the given inputs, relationship

between the input & output of the system, source of data input,

range of valid inputs etc.

2) Performance requirements: This component of an SRS specifies the

performance constraints on the software. It is of 2 types:

a)Static Requirements

b)Dynamic Requirements

a) Static requirements: are one which do not impose the constraints

on execution behavior of the system. These include number of

terminals to be supported, number of simultaneous users & the

number of files to be processed & their sizes.

b) Dynamic requirements: are one which specify constraints on

execution behavior of the system. These include response time and

throughput constraints. These requirements should be stated in

measurable units.

3) Design constraints: An SRS should specify all constraints related to

design such as standards to be followed, resource limits, operating

environment, reliability, security requirements & policies.

4) External interface requirements: All the interactions of the s/w with

people, h/w & other s/w should be clearly specified. A user manual

should be created with all user commands, screen formats,

feedbacks, error messages. The h/w interface requirements like

memory restrictions, current use & load of the h/w should be given.

The s/w interface includes interface with OS & other applications.

Behavioral/Non-behavioral requirements

1) Behavioral requirements: These define precisely what inputs are

expected, what outputs will be generated & details of relationship

between inputs and outputs.

2) Non-behavioral requirements: All applications have additional

requirements that define the overall qualities or attributes of the s/w.

Some of the attributes which can be specified in SRS are:

-Reliability -Efficiency -Testability -Reusability

-Usability -Maintainability -Portability -Robustness

Thanks!!