SOFTWARE REQUIREMENT SPECIFICATION (SRS)

The software project is initiated by the client's needs. In the beginning, these needs are in the
minds of various people in the client organization. The requirements analyst has to identify
the requirements by talking to these people and understanding their needs. SRS is the
medium through which the client and user needs are accurately specified to the developer.
SRS forms the basis of software development. Another important purpose of developing SRS
is helping the clients understand their own needs.

• An SRS establishes the basis for agreement between the client and the supplier on what the
software product will do.

This basis for agreement is frequently formalized into a legal contract between the
client (or the customer) and the developer (the supplier). So, through SRS, the client
clearly describes what it expects from the supplier, and the developer clearly
understands what capabilities to build in the software.

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

That is, the SRS helps the client determine if the software meets the requirements.
Without a proper SRS, there is no way a client can determine if the software being
delivered is what was ordered, and there is no way the developer can convince the
client that all the requirements have been fulfilled.

• A high-quality SRS is a prerequisite to high-quality software.

Finally, we show that the quality of SRS has an impact on cost (and schedule) of the
project. We have already seen that errors can exist in the SRS. We saw earlier that the
cost of fixing an error increases almost exponentially as time progresses. That is, a
requirement error, if detected and removed after the system has been developed, can
cost up to 100 times more than removing it during the requirements phase itself.

• A high quality SRS reduces the development cost.

Hence, the quality of the SRS impacts customer (and developer) satisfaction, system
validation, quality of the final software, and the software development cost. The
critical role the SRS plays in a software development project should be evident from
these.

Characteristics of an SRS

1. Correct

2.Complete

3.Unambiguous

4.Verifiable
5.Consistent

6. Ranked for importance and/or stability

7.Modifiable

8. Traceable

An SRS is correct if every requirement included in the SRS represents something required in
the final system.

An SRS is complete if everything the software is supposed to do and the responses of the
software to all classes of input data are specified in the SRS.

An SRS is unambiguous if and only if every requirement stated has one and only one
interpretation. Requirements are often written in natural language, which are inherently
ambiguous. If the requirements are specified in a natural language, the SRS writer has to be
especially careful to ensure that there are no ambiguities. One way to avoid ambiguities is to
use some formal requirements specification language

An SRS is verifiable if and only if every stated requirement is verifiable. A requirement is

verifiable if there exist some cost-effective process that can check whether the final software
meets that requirement.

An SRS is consistent if there is no requirement that conflicts with another. Terminology can
cause inconsistencies; for example, different requirements may use different terms to refer to
the same object. There may be logical or temporal conflict between requirements that causes
inconsistencies. This occurs if the SRS contains two or more requirements whose logical or
temporal characteristics cannot be satisfied together by any software system.

An SRS is ranked for importance and/or stability if for each requirement the importance and
the stability of the requirement are indicated. Stability of a requirement reflects the chances
of it changing in future.

An SRS is modifiable if its structure and style are such that any necessary change can be
made easily while preserving completeness and consistency. Presence of redundancy is a
major hindrance to modifiability, as it can easily lead to errors.

An SRS is traceable if the origin of each of its requirements is clear and if it facilitates the
referencing of each requirement in future development.

Forward traceability means that each requirement should be traceable to some design and
code elements. Backward traceability requires that it be possible to trace design and code
elements to the requirements they support.

Components of an SRS

Conceptually, any SRS should have these components

• Functionality

• Performance

• Design constraints imposed on an implementation

• External interfaces.

Functional requirements specify which outputs should be produced from the given inputs.
They describe the relationship between the input and output of the system. For each
functional requirement, a detailed description of all the data inputs and their source, the units
of measure, and the range of valid inputs must be specified.

Performance Requirements

This part of an SRS specifies the performance constraints on the software system. All the
requirements relating to the performance characteristics of the system must be clearly
specified. There are two types of performance requirements: static and dynamic.

Static requirements are those that do not impose constraint on the execution
characteristics of the system. These include requirements like the number of terminals to be
supported, the number of simultaneous users to be supported, and the number of files that the
system has to process and their sizes. These are also called capacity requirements of the
system.

Dynamic requirements specify constraints on the execution behaviour of the system.

These typically include response time and throughput constraints on the system. Response
time is the expected time for the completion of an operation under specified circumstances.
Throughput is the expected number of operations that can be performed in a unit time.

Design Constraints

There are a number of factors in the client's environment that may restrict the choices of a
designer.

An SRS should identify and specify all such constraints.

Standards Compliance:

This specifies the requirements for the standards the system must follow. The
standards may include the report format and accounting procedures. There may be
audit tracing requirements, which require certain kinds of changes, or operations that
must be recorded in an audit file.

Hardware Limitations:

The software may have to operate on some existing or predetermined hardware, thus
imposing restrictions on the design. Hardware limitations can include the type of
 machines to be used, operating system available on the system, languages supported,
and limits on primary and secondary storage.

Reliability and Fault Tolerance:

Fault tolerance requirements can place a major constraint on how the system is to be
designed. Fault tolerance requirements often make the system more complex and
expensive. Requirements about system behaviour in the face of certain kinds of faults
are specified.

Security:

Security requirements are particularly significant in defence systems and many

database systems. Security requirements place restrictions on the use of certain
commands, control access to data, provide different kinds of access requirements for
different people, require the use of passwords and cryptography techniques, and
maintain a log of activities in the system