Review Checklist for Software Requirements Document

This checklist is NOT intended as a starting point to write a document.
It does NOT necessarily cover all aspects relevant for this type of document.
This checklist is intended only as an aid in checking a completed document.

Also see

  1. Does each software requirement have a unique identifier?
  2. Is each software requirement verifiable? (If possible, formalize, quantify.)
  3. Is each software requirement prioritized?
  4. Are all unstable software requirements marked as such? (TBC=`To Be Confirmed')
  5. Is each software requirement traced back to the URD, and, where relevant, is an explanation included?
  6. Are the software requirements complete? (All user requirements are covered; all relevant input situations are accounted for.)
  7. Are the software requirements consistent? (Implementable.)
  8. Is overlap among software requirements pointed out explicitly? (Redundancy; cross-reference.)
  9. Is the intial system state clearly specified?
  10. Do the software requirements express a logical model, rather than implementation? (Unless this is a user requirement.)
  11. Are the software requirements expressed in a structured way, as a hierarchy of abstractions?
  12. Is it sufficiently clear that the structure (partitioning into parts) of the logical model is intended only to improve the understanding and is not intended to restrict the implementation by requiring that this structure is maintained? (Unless stated to the contrary because of the user requirements.)
  13. Are the software requirements sufficiently formalized? (Mathematical.)
  14. Are critical properties of the software requirements proved?
  15. Is all formalized and diagrammatic material accompanied by sufficient explanatory text in natural language?
  16. Are design decisions that restrict developer freedom (w.r.t. the user requirements), documented explicitly and motivated?
  17. If applicable, is a user interface prototype described in detail? Is this prototype explicitly linked to the logical model or the specific software requirements? Is the version of this prototype stated, and can this prototype be recovered for later experimentation?
  18. Are exploratory prototypes described for those areas where the project team lacks experience? (In appendices.)
  19. Are backward and forward traceability matrices between user requirements and software requirements included? Were these matrices inspected for completeness (every UR is fully covered by one or more SRs) and minimality (every SR is fully justified by one or more URs)?

©2001, Tom Verhoeff (TUE)
Feedback about this page is welcome