Software Requirements Specification Checklist
I have a small checklist to verify that the software requirements specification is useable by the developer and the tester.
Nature of the SRS: Does the SRS answer the following questions ?
Functionality – What is the software supposed to do ?
External interfaces – How does the software interact with people, the system’s hardware, other hardware, and other software?
Performance – What is the speed, availability, response time, recovery time of various software functions, etc.?
Attributes – What are the portability, correctness, maintainability, security, etc. considerations?
Design constraints imposed on an implementation – Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s) etc.?
Design or project requirements should be absent from the SRS.
Characteristics of a good SRS:
It should correctly define all of the software requirements.
It should not describe any design or implementation details.
It should not impose additional constraints on the software.
An SRS should be
e) Ranked for importance and/or stability
An SRS is complete if, and only if, it includes the following elements:
- All significant requirements, whether relating to functionality, performance, design constraints attributes, or external interfaces. In particular any external requirements imposed by a system speci fication should be acknowledged and treated.
- Definition 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.
- Full labels and references to all figures, tables, and diagrams in the SRS and definition of all terms and units of measure.
An SRS is modifiable 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. Modifiability generally requires an SRS to
- Have a coherent and easy-to-use organization with a table of contents, an index, and explicit crossreferencing
- Not be redundant (i.e., the same requirement should not appear in more than one place in the SRS)
- Express each requirement separately, rather than intermixed with other requirements