Friday, 13 May 2016

Various Characteristics of SRS

This is the first and foremost
requirement. The development team will get nowhere if the SRS which will be the
basis of the process of software development, is not accurate.

2.Correct

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

3.Complete

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

4.Traceability

Each requirement
stated in the SRS should be uniquely associated to a source such as a use case
or interaction document etc.

5.Unambiguous

SRS
must contain requirements statements that can be interpreted in one way only.
This is another area that creates significant problems for SRS development
because of the use of natural language.

6.Verifiable

An SRS is verifiable if and only if every
stated requirement is verifiable. A requirement is verifiable if there exists
some cost-effective process that can check whether the final software meets
that requirement.

7.Consistent

SRS capability functions and
performance levels are compatible, and the required quality features (security,
reliability, etc.) do not negate those capability functions. For example, the
only electric hedge trimmer that is safe is one that is stored in a box and not
connected to any electrical cords or outlets.

8.Testable

An SRS must be stated in
such a manner that unambiguous assessment criteria (pass/fail or some
quantitative measure) can be derived from the SRS itself.

9.Ranked
for importance and/or stability
Ranking specification statements according to stability and/or importance is
established in the requirements document’s organization and structure. The
larger and more complex the problem addressed by the requirements
specification, the more difficult the task is to design a document that aids
rather than inhibits understanding. Individual requirements of an SRS are hierarchically
arranged according to stability, security, perceived ease/difficulty of
implementation, or other parameter that helps in the design of that and
subsequent documents.

10.Modifiability

The SRS should
be written in such a way that it can be modified when the development team and
user feel the need. Requirements document must have a logical structure to be
modifiable.

11.Valid

A
valid SRS is one in which all parties and project participants, managers, engineers and customer
representatives, can understand, analyze, accept, or approve
it. This is one of the main reasons that most specifications are expressed in natural language.