You are on page 1of 8

Requirements Peer Review Checklist

Document Status Version:

Version number – 0.n for draft, n.n for signed off and subsequent updates DD MMMM YYYY

Release Date:

acronyms & abbreviations Term Description 82341718. Role Project sponsor Project stakeholders Subject matter experts Project manager Name & Title Signature Date Definitions.doc Page 2 of 8 .Document control Contacts Author Title Phone Email Active? Change record Revision Date Version No Author / Editor Changes Made Distribution This document has been distributed to the following people: Name Title Sections to Review Issue Date Approvals Update roles as required for your project.

..............5 8 Design neutrality...................................................................7 14 Scope.............................................6 10 Level of detail – High-level requirements................................................................................................................................................................7 16 Traceability.......7 15 Design Constraints.................................................................................doc Page 3 of 8 .............................................................................................................4 3 Clarity.................................................................................................................................................Table of contents Introduction................................................................................................................................................6 11 Level of detail – detailed requirements............................................................4 1 Compliance with standards.................................................................7 82341718..6 12 Requirements Singularity........................................7 13 Definition of Inputs and Outputs...............................5 7 Usability........................................................................................................................................................................................................................................................................5 5 External interfaces.......................................6 9 Readability................................................................................................................................4 2 Completeness of specifications..........................................................................................................................................................................................................4 4 Consistency..........................................5 6 Testability.........................................................................................................................................................................

applicable standards specify that certain material should be included in the requirements specification.Introduction The Requirements Peer Review Checklist defines the criteria to be used during a peer review of a software requirements specification. data transformations. make a notation to this effect under “Issues and Comments. place a check () in the box if the checklist item is satisfied. design constraints. then this should be noted under “Issues and Comments.” Focus  Does the requirements document comply with relevant standards and guidelines such as those for accessibility and usability? Issues and Comments 1 Compliance with standards • Guidance: If.” 2 Completeness of specifications • • Does the requirements document address all known requirements? Have ‘TBD’ requirements been kept to a minimum. for example. or eliminated entirely? Guidance: A requirements specification should address such elements as control flow. and this material is missing. Otherwise. For each checklist item below. and user interface. 3 Clarity • Are the requirements clear enough to inform the forward . without any explanation. list any problem areas or exceptions under “Issues and Comments. This checklist may be used for high-level and detailed requirements documents.” Guidance: If any waivers to applicable standards have been granted.

increase clarity.Focus document/specification? Guidance: High-level requirements must be clear and comprehensive enough to inform the Detailed requirements document. This helps to reduce ambiguity. Detailed requirements must be sufficiently detailed to inform a Functional specification. and show testability. 7 Usability • Are all requirements with a usability impact clearly identified as such? 82341718. terminology. and level of functionality? Are business rules mutually compatible? 5 External interfaces • Have external interfaces been adequately defined? 6 Testability • • • Are the requirements testable? Are the testing considerations of all relevant requirements explicitly and clearly labeled? Will the testers be able to determine whether each requirement has been satisfied? Guidance: The requirements document should state how every requirement will be tested.doc Page 5 of 8 .  Issues and Comments 4 Consistency • • Are the requirements consistent in notation.

there are generally two levels of requirements.doc Page 6 of 8 . This checklist is designed to be used only with high-level and detailed requirements documents. not software jargon? 10 Level of detail – High-level requirements • • Are the requirements at a fairly consistent level of detail? Should any particular requirement be specified in more detail? Guidance: At BVO. 9 Readability • Does the requirements specification use the language of the intended testers and users of the system. design neutrality does not apply. one should show that requirements are consistent with the selected product line architecture. Instead. the requirements should concentrate on what the software needs to do. there is typically a functional specification. highlevel and detailed. In the case where a system or subsystem is being configured from a product line. In addition. rather than how these actions will be performed? Guidance: In other words. 11 Level of detail – detailed requirements • • Are the requirements at a fairly consistent level of detail? Should any particular requirement be specified in more detail? In less detail? 82341718.Focus • Are all usability testing considerations made explicit and clear?  Issues and Comments 8 Design neutrality • Does the requirements document state what actions are to be performed. rather than how it will do it.

16 Traceability 82341718. or 1 nanosecond response to the user. the required inputs to and outputs from the software system.. topic. 12 Requirements Singularity • Does each requirement address a single concept. been fully defined? Have the required data transformations been adequately specified? 14 Scope • • Does the requirements document adequately define boundaries for the scope of the target solution? Are any essential requirements missing? 15 Design Constraints • Are all stated design and performance constraints realistic and justifiable? Guidance: An example of an unrealistic constraint might be 100% availability of the system.doc Page 7 of 8 .e. element. or value? Guidance: Avoid compound requirements that do not clearly delineate the parts with separate identifiers. i. 13 Definition of Inputs and Outputs • • Have the internal interfaces.Focus • Is every high-level requirement decomposed into at least one more detailed requirement?  Issues and Comments Guidance: Ensure that every detailed requirement decomposes a higherlevel one.

Focus • • Dose each requirement can be traceable to its backward or forward requirement artifacts? Are any detailed requirements orphaned?  Issues and Comments 82341718.doc Page 8 of 8 .