CPE 308
Winter 2009
Turner
SRS Checklist (adapted from Stearns material)

Use this checklist to verify your Software Requirements Specification.
Everyone is responsible for this verification; but the team editor takes the hit if there are problems.

    General
  1. Cover page contains team logo, 308 section # and date submitted.
  2. Document has page numbers.
  3. Document matches the required format.
  4. Document is of professional quality.
  5. The credits list is specified clearly, by individual. ("done by team" is explicitly disallowed)

    Consistency

  6. Each non-primitive entity in the data dictionary is used by one or more use cases.
  7. Every use case noun is in the data dictionary.
  8. All significant use cases are visible in the prototype.
  9. All views of the requirements (use cases, prototype, data dictionary) are consistent.

    English

  10. Writing meets the standards of a the WPE level 4 or greater.
  11. All English, including diagram text, is written in the 3rd person using active voice, present tense verbs.
  12. There are no words from the bad words list.

    Problem Domain

  13. All language is in the problem domain; don't discuss the UI!
    (Exception - some non-functional requirements)
  14. Each view of the requirements (Use Cases, Data Dictionary, Prototype) uses the same problem-domain words.
  15. Excepting the prototype, there is no discussion of the UI in the SRS.

    Non-functional Requirements

  16. Every requirement is concrete, specific, measurable and testable.
  17. Every requirement applies to your system.
  18. There are 3 maintainability requirements (to be provided by Prof. Stearns)

    Data Dictionary

  19. The data dictionary describes all problem domain entities in the software.
  20. There are no glossary terms in the Data Dictionary.
  21. Entries are organized hierarchically and formatted appropriately.
  22. Every primitive (not decomposed) entity must be used:
      in a composite entity
      by at least one use case

    Use Cases

  23. The proper format is used.
  24. Every non-primitive Data Dictionary entity is discussed in one or more use case.
  25. There is no discussion of the UI in the description.
  26. There is no textual discussion of Data Dictionary details.
  27. There are no design domain features described as use cases. Some common non use cases:
    1. login/logoff
    2. exit system
    3. resize window
    4. open/close window
    These are system features, not use cases.

    Glossary

  28. Every term is used in the SRS.
  29. There are no glossary terms in the Data Dictionary.

    Prototype

  30. UI follows appropriate human psychology principles
  31. UI presentation is professional (whether a prototype or storyboards)
  32. UI covers all major use cases.


Last updated on 1/31/05