Checkpoints:  Software Requirements Specification

• The following basic issues should be addressed:
  • 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 environments, etc.?
• Are any requirements specified that are outside the bounds of the SRS? This means the SRS
  • Should correctly define all of the software requirements,
  • Should not describe any design or implementation details,
  • Should not impose additional constraints on the software.
• Does the SRS properly limit the range of valid designs without specifying any particular design?
• Does the SRS exhibit the following characteristics?
  • Correct: Is every requirement stated in the SRS one that the software should meet?
  • Unambiguous
    • Does each requirement have one, and only one, interpretation?
    • Has the customer's language been used?
    • Have diagrams been used to augment the natural language descriptions?
  • Complete
    • Does the SRS include all significant requirements, whether related to functionality, performance design constraints, attributes, or external interfaces? 
    • Have the expected ranges of input values in all possible scenarios been identified and addressed? 
    • Have responses been included to both valid and invalid input values?
    • Do all figures, tables and diagrams include full labels and references and definitions of all terms and units of measure? 
    • Have all TBDs been resolved or addressed?
  • Consistent
    • Does this SRS agree with the Vision document, the use-case model and the Supplementary Specifications?
    • Does it agree with any other higher level specifications?
    • Is it internally consistent, with no subset of individual requirements described in it in conflict?
  • Ability to Rank Requirements
    • Has each requirement been tagged with an identifier to indicate either the importance or stability of that particular requirement?
    • Have other significant attributes for properly determining priority been identified?
  • Verifiable
    • Is every requirement stated in the SRS verifiable?
    • Does there exist some finite cost-effective process with which a person or machine can check that the software product meets the requirement?
  • Modifiable
    • Are the structure and style of the SRS such that any changes to the requirements can be made easily, completely, and consistently while retaining the structure and style?
    • Has redundancy been identified, minimized and cross-referenced?
  • Traceable
    • Does each requirement have a clear identifier?
    • Is the origin of each requirement clear?
    • Is backward traceability maintained by explicitly referencing earlier artifacts?
    • Is a reasonable amount of forward traceability maintained to artifacts spawned by the SRS?

Reference: [IEEE93]

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process