2.3.3 Desirable Characteristics of an SRS 

  Some of the desirable 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

1. Correct 

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

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

3. Unambiguous

It is unambiguous if and only if every requirement stated has one and only one interpretation. Requirements are often written in natural language, which is 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.

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

5. Consistent 

 It 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. For example, suppose a requirement states that an event e is to occur before another event f. But then another set of requirements states (directly or indirectly by transitivity) that event f should occur before event e. Inconsistencies in an SRS can reflect some major problems.

6. Ranked for importance and/or stability 

Generally, all the requirements for software are not of equal importance. Some are critical, others are important but not critical, and there are some which are desirable but not very important. Similarly, some requirements are “core” requirements which are not likely to change as time passes, while others are more dependent on time. Some provide more value to the users than others. 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 the future. It can be reflected in terms of the expected change volume.

7.Modifiable

An SRS is modifiable if its structure  and style are such that any necessary change can be made easily while
preserving completeness and cosistency. Presence of redandancy is a major hindrance to modifiability,  as it can easily lead errors.For example, assume that a requirement is stated in two places and thatrequire later needs to be changed. If only one occurrence of the requirement is modified, the resulting SRS wil be inconsistent.

8.Traceable

  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. Forword traceability means that each requirement should be traceable to some design and code elements. Backword traceablity requires that it be possible to trace design and code elements to the reqirements that they support. Traceability aids verification and validation.

    Of all these characteristics, completeness is perhaps the most important and also the most difficult property to establish. One of the most common defects in requirements specification is incompleteness. Missing requirements necessitate additions and modifications to the requirements later in the development cycle, which are often expensive to incorporate. Incompleteness is also a major source of disagreement between the client and the supplier. 3.3 Requirements Specification 43 Some, however, believe that completeness in all details may not be desirable. The pursuit of completeness can lead to specifying details and assumptions that may be commonly understood. (For example, specifying in detail what a common operation like add a record means.) And specifying these details can result in a large requirements document, which has its own problems including making validation harder. On the other hand, if too few details are given, the chances of developer’s understanding being different from others’ increases, which can lead to defects in the software. For completeness, a reasonable goal is to have “sufficient detail” for the project at hand. For example, if the waterfall model is to be followed in the project, it is better to have detailed specifications so the need for changes is minimized. On the other hand, for iterative development, as feedback is possible and opportunity for change is also there, the specification can be less detailed. And if an agile approach is being followed, then completeness should be sought only for top-level requirements, as details may not be required in written form, and are elicited when the requirement is being implemented. Together the performance and interface requirements and design constraints can be called nonfunctional requirements.