<p> Requirements Inspection/Walkthrough Checklist</p><p>Number: 2007-3- Name: Project Title/Team Title: Approved By: (signature)</p><p>Asset Type: Checklist Title: Requirements Inspection/Walkthrough</p><p>Requirements Inspection/Walkthrough Checklist</p><p>The Requirements Inspection/Walkthrough Checklist uses a set of design measures applied to the software SRS documents. These measures are characteristics of structural factors that are judged as adequate or not, rather than quantitatively measured and compared against an absolute standard. </p><p>Considerations to be checked for all designs include:  Observations and Comments (Mandatory) Presentation “Quality” (Initials and score 1-9)</p><p>1 Completeness – Specification of design is to the lowest appropriate level.</p><p>Guidance: Not all may be applicable for a  particular system (e.g., not all systems will need to consider COTs), but each check should be considered. Requirements Support Traceability to ensure coverage of all requirements Addresses issues of: Real-time requirements Performance issues (memory and timing) Spare capacity (CPU and memory) Maintainability Understandability Database requirements Loading and initialization Error handling and recovery User interface issues Software upgrades Software re-use and modifications COTS requirements All inputs and outputs Clearly and correctly identify interfaces All interfaces clearly and (appropriately) precisely defined Adequate data structures defined All error codes documented 2 Simplicity – Complexity no more than necessary Requirements Inspection/Walkthrough page 1 of 3 Checklist, version 1.0 3 Suitability– The requirements itself is good.</p><p> The requirements are well presented Assumptions are documented Major decisions are documented The requirements is expressed in precise unambiguous terms Dependencies on other functions, operating system, hardware etc. are documented The requirements follows notational conventions 4 Correctness – The requirements will lead to good software.</p><p> The logic is correct Memory and timing budgets are reasonable and achievable The requirements is understandable (i.e., easy to read, to follow logic) It is maintainable (i.e., no obscure logic); It is cohesive (i.e., proper groupings of related components/functions) COTS and GOTS have been verified to fulfill their intended purpose</p><p>5 Quality – A high quality SRS for a high quality system</p><p> Have alternate approaches been evaluated and the optimum chosen? User interface/screens have been defined/cleared with end users? Are there minimal requirements TBD’s? Are the Scenario(s) appropriate ? Are the Scenario(s) sufficiently detailed ? Are the Use Cases Clear and precise? Are all needed Use Cases included? Are all Acronyms and terms defined?</p><p>Notes/Action Items for follow-up # Action Assignee Due Date</p><p>Change History Version Date Description of Improvements 1.0 3/15/07 Based on NASA Design Walktrough checklist.. TB</p><p>Requirements Inspection/Walkthrough page 2 of 3 Checklist, version 1.0 Requirements Inspection/Walkthrough page 3 of 3 Checklist, version 1.0</p>