Characteristics of a good SRS An SRS should be: Correct Unambiguous Complete Consistent Ranked for importance and/or stability Verifiable Modifiable Traceable

Characteristics of a good SRS Correct An SRS is correct if every requirement stated in it is one that the software will meet. There is no tool or procedure that ensures correctness, but the customer or user can determine if the SRS correctly reflects the actual needs.

Characteristics of a good SRS Unambiguous An SRS is unambiguous only if every requirement stated in it has only one interpretation. As a minimum this requires that each characteristic of the final product be described using a single unique term. Representations that improve the requirements specification for the developer may be counterproductive in that they diminish understanding to the user and vice versa. Care should therefore be taken to ensure natural language is used so that terms are understandable to both developer and user.

Characteristics of a good SRS Complete An SRS is complete only if it includes the following elements: All significant requirements Definition of the responses of the software to all classes of input data. It is important to specify the responses to both valid and invalid input values. Full labels and references to all figures, tables, and diagrams in the SRS and definition of all terms and units of measure

Characteristics of a good SRS Consistent Consistency refers to internal consistency. It is internally consistent only if no subset of individual requirements described in it conflict. For example: Characteristics may conflict (ie, one requirement may state that all users need a password whilst another states they do not). Actions may conflict (ie one requirement states that two inputs should be added whilst another states they should be multiplied). Different terms are used for the same thing (ie, one requirement may describe a user input as a prompt whilst another may describe it as a cue).

Characteristics of a good SRS Ranked for importance and/or stability Typically all of the requirements that relate to a software product are not equally important. Some requirements may be essential (especially for life critical systems) while others may be desirable. An SRS is ranked for importance and/or stability if each requirement in it has an identifier to indicate either the importance or the stability of a particular requirement. Necessity can be ranked as essential (requirements must be provided), conditional (requirements would enhance the product) and optional (requirement may or may not be worthwhile). Stability can be expressed in terms of the number of expected changes to any requirement based on knowledge of forthcoming events that effect the organisation

Characteristics of a good SRS Verifiable An SRS is verifiable only if every requirement in it is verifiable. Nonverifiable requirements include statements such as “works well”, “good human interface” and “shall usually happen”. These requirements cannot be verified because it is impossible to define the terms “good” “well” or “usually”. An example of a verifiable statement is: “Output of the program shall be produced within 20 s of event x 60% of the time; and shall be produced within 30 s of event x 100% of time” If a method cannot be devised to determine whether the software meets a particular requirement then that requirement should be removed or revised.

Characteristics of a good SRS Modifiable An SRS is modifiable only if it’s structure and style are such that any changes to the requirements can be made easily, completely and consistently while retaining the structure and style. Modifiability generally requires an SRS to: Have an easy-to-use organisation with a table of contents, an index, and cross-referencing. Not be redundant (i.e., the same requirement should not appear in more than one place in the SRS). Redundancy itself is not an error, but it can lead to errors when a redundant document is updated as the requirement may only be updated in one of the places where it appears. The document would then be inconsistent. Whenever redundancy is necessary, the SRS should include cross-references to make it modifiable. Express each requirement separately, rather than intermixed with other requirements.

Characteristics of a good SRS 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: Backward traceability (i.e. to the previous stages of development). This depends upon each requirement explicitly referencing its source in earlier documents. 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 product enters the operation and maintenance phase. As code and design documents are modified, it is essential to be able to ascertain the complete set of requirements that may be affected by these modifications.

Characteristics of a good SRS Documenting changes The SRS may need to evolve as the development of the software progresses. It may be impossible to specify some details at the time the project is initiated. Changes may take place as deficiencies, shortcomings and inaccuracies are discovered in the SRS. Two major considerations in this process are the following: i) Requirements should be specified as completely and thoroughly as known at the time. The fact that they are incomplete should be noted. ii) A formal change process should be initiated to identify, control, track and report changes. Approved changes in requirements should be incorporated in the SRS to: Provide an accurate and complete audit trail of changes Permit the review of current and superseded portions of the SRS

Characteristics of a good SRS Prototyping Prototyping is used frequently during the requirements phase of the project. Many tools exist that allow a prototype, exhibiting some characteristics of a system to be created very quickly and easily. Prototypes are useful for the following reasons: i) The prototype provides quick feedback as the customer may be more likely to view the prototype and react to it than to read the SRS and react to it. ii) The prototype displays unanticipated aspects of the systems behaviour. Thus, it produces not only answers but also new questions. This helps reach closure on the SRS. iii) An SRS based on a prototype tends to undergo less change during development, thus shortening development time.

Characteristics of a good SRS Embedding design in the SRS A requirement specifies an externally visible function or attribute of a system A design describes a particular subcomponent of a system and/or its interfaces with other subcomponents Design should be specified in the design document not the SRS