Review Checklist for User 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 user requirement have a unique identifier?
  2. Is each user requirement atomic and simply formulated? (Single sentence. Composite requirements can best be split.)
  3. Are user requirements organized into coherent groups? (If necessary, hierarchical; not more than about ten per group.)
  4. Is each user requirement verifiable (in a provisional acceptance test)? (Where possible, quantify.)
  5. Is each user requirement prioritized?
  6. Are all unstable user requirements marked as such? (TBC=`To Be Confirmed')
  7. Are all user requirements necesseary?
  8. Are the user requirements complete? Can everything not explicitly constrained indeed be viewed as developer freedom? Is a product that satisfies every requirement indeed acceptable? (No requirements missing.)
  9. Are the user requirements consistent? (Non-conflicting.)
  10. Are the user requirements sufficiently precise and unambiguous? (Which interfaces are involved, who has the initiative, who supplies what data; avoid passive voice.)
  11. Are the user requirements understandable to those who will need to work with them later?
  12. Are the user requirements realizable within budget?
  13. Do the user requirements express actual customer needs (in the language of the problem domain), rather than solutions (in developer jargon)?
  14. Are the user requirements not overly restrictive? (Allow enough developer freedom.)
  15. Is overlap among user requirements pointed out explicitly? (Redundancy; cross-reference.)
  16. Are dependencies between user requirements pointed out explicitly? Are these consistent with the priorities?
  17. Are the characteristics of users and of typical usage described in sufficient detail? (No user categories missing.)
  18. Is the operational environment described in sufficient detail, including e.g. relevant data flows in the "outside" world that do not interact directly with the system? (No external interfaces missing. No capabilities missing. Diagram included.)

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