what we studied today!!!

Characteristics of a good SRS

1. Correct - An SRS is correct if, and only if, every requirement stated therein is one that the software shall meet.
2. Unambiguous - An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation. As a
   minimum, this requires that each characteristic of the Þnal product be described using a single unique term.
3. Complete -
   a) All signiÞcant requirements, whether relating to functionality, performance, design constraints, attributes, or external interfaces. In particular any external requirements imposed by a system specification should be acknowledged and treated.
   b) Defnition of the responses of the software to all realizable classes of input data in all realizable
   classes of situations. Note that it is important to specify the responses to both valid and invalid input
   values.
   c) Full labels and references to all fgures, tables, and diagrams in the SRS and defnition of all terms
   and units of measure
4. Consistent - Consistency refers to internal consistency. If an SRS does not agree with some higher-level document, such as a system requirements specification, then it is not correct
5. Ranked for importance and/or stability - An SRS is ranked for importance and/or stability if each requirement in it has an identiÞer to indicate either
   the importance or stability of that particular requirement.
6. Verifiable - An SRS is verifiable if, and only if, every requirement stated therein is verifiable. A requirement is verifiable if, and only if, there exists some finite cost-effective process with which a person or machine can check that the software product meets the requirement. In general any ambiguous requirement is not verifiable.
7. Modifiable - An SRS is modiÞable if, and only if, its structure and style are such that any changes to the requirements can
   be made easily, completely, and consistently while retaining the structure and style. ModiÞability generally
   requires an SRS to
   a) Have a coherent and easy-to-use organization with a table of contents, an index, and explicit crossreferencing;
   b) Not be redundant (i.e., the same requirement should not appear in more than one place in the SRS);
   c) Express each requirement separately, rather than intermixed with other requirements.
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 or enhancement documentation. The following two types of traceability are recommended:
   a) Backward traceability (i.e., to previous stages of development).
   This depends upon each requirement
   explicitly referencing its source in earlier documents.
   b) Forward traceability (i.e., to all documents spawned by the SRS).
   This depends upon each requirement
   in the SRS having a unique name or reference number.
   The forward traceability of the SRS is especially important when the software