Software Requirements Specification (SRS) Checklist (Alfred Hussein, University of Calgary)

1. Is the SRS correct? Each requirement in the SRS is free from error. This requires that each requirement statement accurately represent the functionality required of the system to be built. While the other categories within this checklist result in errors, this category of errors is concerned with the technical nature of the application at hand. In other words, the requirement is just plain wrong. For example, if the problem domain states that the XYZ system is to provide a response to input within 5 seconds and the SRS requirement specifies that the XYZ system will respond within 10 seconds, the requirement is in error. 2. Are the requirements in the SRS unambiguous, precise, and clear? Each requirement in the SRS is exact and unambiguous, there is one and only one interpretation for every requirement. The meaning of each requirement is easily understood and is easy to read. Requirement statements should be short, explicit, precise and clear. Rambling verbose descriptions are generally subject to interpretation. Each requirement should have a specific purpose and represent a specific characteristic of the problem domain. When writing the requirement, try to imagine that the requirement is to be given to ten people who are asked for their interpretation. If there is more than one such interpretation, then the requirement is probably ambiguous. It is also important to remain objective when writing requirements, never assume that everyone will understand the requirement the way you understand it. At a minimum, all terms that could have multiple meanings should be defined in a glossary where its meaning is made more specific. The difficulty of ambiguity stems from the use of natural language which in itself is inherently ambiguous. It is recommended that checklists of words and grammatical constructs that are particularly prone to ambiguity be used to aid in identifying possible errors of this type. Refer to Appendix B for a checklist of potential ambiguity indicators.

3. Is the SRS complete? An SRS is considered complete if all requirements that are needed for the specification of the requirements of the problem have been defined and the SRS is complete as a document. The following qualities indicate a complete SRS:

Everything the software is supposed to do is included in the SRS. This includes functionality, performance, design constraints, or external interfaces. This is a difficult quality to judge because it requires a complete understanding of the problem domain. It is further complicated by the implication that something is missing in the SRS, and it is not a simple process to find something that is not present by examining what is present. Definitions of the responses of the software to all realizable classes of input data in all realizable classes of situations is included. This includes the responses to both valid and invalid input. This implies that for every input mentioned in the SRS, the SRS specifies what the appropriate output will be. Conformity to the applicable SRS standard. If a particular section is not applicable, the SRS should include the section number and an explanation of why it is not applicable. All pages are numbered; all figures and tables are numbered, named and referenced; all terms and units of measure are provided; and all referenced material, and sections are present. This is completeness from a word-processing perspective. No sections are marked "To Be Determined (TBD)". The use of "TBD" in a section of the SRS should be avoided whenever possible. If this is unavoidable, each TBD should be appended with a notation that explains why it can't be completed, what needs to be done to complete the section, who will complete the section and when it will be completed. This ensures that the TBD is not interpreted as an excuse to delay completion of the SRS indefinitely. By including the name of the responsible individual and the date, we insure that the TBD expires at some point.

4. Is the SRS verifiable or testable? An SRS is verifiable if and only if every requirement statement is verifiable. A requirement is verifiable if and only if there is some finite cost-effective way in which a person or machine can check to see if the software product meets the requirements. There should be some quantitative way to test the requirement. When looking at the testability of a requirement consider if it can be tested by actual test cases, analysis or inspection. There are a number of reasons why a requirement may not be verifiable:

The requirement is ambiguous. This leads to non-verifiability, there is no way to verify software that exhibits ambiguous traits. Using non-measurable quantities such as "usually" or "often" implies the absence of a finite test process. Refer to Appendix C for additional nonquantifiable measures.

5. Is the SRS consistent? An SRS is consistent if and only if the stated requirements do not conflict with other stated requirements within the SRS. Inconsistency can manifest itself in a number of ways.

Conflicting terms: Two terms are used in different contexts to mean the same thing. The term prompt to denote a message to have a user input data is used in one requirement while the term cue is used by another requirement to mean the same thing. Conflicting characteristics: Two requirements in the SRS demand the software to exhibit contradictory attributes. For example, one requirement states all inputs shall be via a menu interface while another states all inputs shall be via a command language. Temporal or logical inconsistency: Two parts of the SRS might specify conflicting timing characteristics or logic. For example, one requirement may state that system A will occur only while system B is running and another requirement may conflict by stating that system A will occur 15 seconds after the start of system B.

A logic inconsistency may be one requirement stating that the software will multiply the user inputs, another requirement may state that the software will add the user inputs. Inconsistency can also occur between the requirements and their source. It is important to insure that the terminology used is the same as the terminology used in the source documents. Using the same vocabulary as the source documents works towards solving this form of inconsistency. 6. Does the SRS deal only with the problem? The SRS is a statement of the requirements that must be satisfied by the problem and they are not obscured by design detail. Requirements should state "what" is required at the appropriate system level, not "how". In some cases, a requirement may dictate how a task is to be accomplished, but this is always a customer prerogative.

Requirements must be detailed enough to specify "what" is required, yet provide sufficient freedom so design is not constrained. Avoid telling the designer "how" to do this job, instead state "what" has to be accomplished. 7. Is each requirement in the SRS feasible? Each requirement in the SRS can be implemented with the techniques, tools, resources and personnel that are available within the specified cost and schedule constraints. Set performance bounds based on system requirements and not state-of-the-art capability. Specify what functions and performance attributes the user requires and yet do not commit to any particular physical solution. Requirements should not be technologyoriented. If growth capability is to be included, state and place bounds on it. Vague growth statements are generally useless. The level to which a "hook" is to be designed into the system should be clearly identified. 8. Is the SRS modifiable? An SRS is modifiable if its structure and style are such that any necessary changes to the requirements can be made easily, completely, and consistently. This attribute of an SRS is more concerned with the format and style of the SRS as opposed to the actual requirements themselves. Modifiability of an SRS requires the following:

The SRS has a coherent and easy-to-use organization, with a table of contents, an index, and cross-references if necessary. This will allow easy modification of the SRS in future updates. The SRS should have no redundancy, that is, a requirement should not be in more than one place in the SRS.

Redundancy itself is not an error, it is a technique, which can be used to improve readability, but it also can reduce modifiability. The difficulty here is that a requirement may be repeated in another requirement to make the second requirement clearer. If the first requirement needs to be changed, there are now two locations to change. If the change is made in only the first location, the SRS can become inconsistent. Though a cross-reference can help to alleviate this problem, redundancy should not be used unless absolutely necessary. If references to a previous requirement are necessary, do so by paragraph reference. 9. Is the 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.

Each requirement should be contained in a single, numbered paragraph so that it may be referred to in other documents. This will facilitate backward traceability to source documents and forward traceability to software design documents and test cases. Preferably the requirement should be titled as well. Grouping of several requirements in a single paragraph should be avoided, unless interrelated requirements cannot be separated and still provide clarity. There are two types of traceability:

Backward traceability implies that we know why every requirement in the SRS exists. Each requirement explicitly references its source in previous documents. Forward traceability implies that all documents that follow the SRS are able to reference the requirements. This is done by each requirement in the SRS having a unique name or reference number.

10. Does the SRS specify design goals? Design goals should be used with discretion. All requirements must be met even if the design goal is not satisfied. Quantitative design goals must have a requirement associated with them. 11. Does the SRS use the appropriate specification language? The use of "shall" statements is encouraged, as this implies a directive to express what is mandatory. The use of "shall" requires a sense of commitment. Unwillingness to make such a commitment may indicate that the requirement, as currently stated, is too vague or is stating "how" and not "what", etc. "Will" statements imply a desire, wish, intent or declaration of purpose. "Should" or "may" are used to express non-mandatory provisions. It is recommended that "will, should and may" not be used in writing requirements unless absolutely necessary.

APPENDIX A
Software Requirements Specification (SRS) Summary Checklist 1. 2. 3. 4. 5. 6. 7. 8. 9. Is the SRS correct? Are the requirements in the SRS nonambiguous, precise, and clear? Is the SRS complete? Is the SRS verifiable or testable? Is the SRS consistent? Does the SRS deal only with the problem? Is each requirement in the SRS feasible? Is the SRS modifiable? Is the SRS traceable?

10. Does the SRS specify design goals? 11. Does the SRS use the appropriate specification language?

APPENDIX B.
Checklist of Words and Grammatical Constructs Prone to Ambiguity

Incomplete lists, typically ending with "etc.", "and/or", and "TBD". Vague words and phrases, such as "generally", "normally", "to the greatest extent", and "where practicable". Imprecise verbs, such as "supported", "handled", "processed", or "rejected". Implied certainty, such as "always", "never", "all", or "every". Passive voice, such as "the counter is set." (by whom?) Every pronoun, particularly "it" or "its" should have an explicit and unmistakable reference. Comparatives, such as "earliest", "latest", "highest". Words ending in "est" or "er" should be suspect. Words whose meanings are subject to different interpretations between the customer and contractor such as: o Instantaneous o Simultaneous o Achievable o Complete o Finish o Degraded o A minimum number of o Nominal/normal/average o Peak/minimum/steady state o As required/specified/indicated o Coincident/adjacent/synchronous with.

APPENDIX C
Nonquantifiable Measures These words signify non-quantifiable measures that can indicate that a requirement can not be verified or tested:

Flexible Modular Efficient Adequate Accomplish Possible (possibly/correct(ly)) Minimum required/acceptable/reasonable Better/higher/faster/less/slower/infrequent

Some/worst Usually/often To the extent specified To the extent required To be compatible/associated with