• 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: [IE830]



Rational Unified Process   2003.06.13