Various Characteristics of SRS

1.      Accuracy

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.