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!!
Top Related