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:

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.
Role Project sponsor Project stakeholders Subject matter experts Project manager Name & Title Signature Date

Definitions, acronyms & abbreviations

Term Description

82341718.doc

Page 2 of 8

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

82341718.doc

Page 3 of 8

Introduction
The Requirements Peer Review Checklist defines the criteria to be used during a peer review of a software requirements specification. This checklist may be used for high-level and detailed requirements documents. For each checklist item below, place a check () in the box if the checklist item is satisfied. Otherwise, list any problem areas or exceptions 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

Compliance with standards

Guidance: If, for example, applicable standards specify that certain material should be included in the requirements specification, and this material is missing, without any explanation, then this should be noted under Issues and Comments. Guidance: If any waivers to applicable standards have been granted, make a notation to this effect under Issues and Comments.

Completeness of specifications
Does the requirements document address all known requirements? Have TBD requirements been kept to a minimum, or eliminated entirely?

Guidance: A requirements specification should address such elements as control flow, data transformations, design constraints, and user interface.

Clarity
Are the requirements clear enough to inform the forward

Focus document/specification? Guidance: High-level requirements must be clear and comprehensive enough to inform the Detailed requirements document. Detailed requirements must be sufficiently detailed to inform a Functional specification.

Issues and Comments

Consistency
Are the requirements consistent in notation, terminology, and level of functionality? Are business rules mutually compatible?

External interfaces
Have external interfaces been adequately defined?

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. This helps to reduce ambiguity, increase clarity, and show testability.

Usability
Are all requirements with a usability impact clearly identified as such?

82341718.doc

Page 5 of 8

Focus Are all usability testing considerations made explicit and clear?

Issues and Comments

Design neutrality
Does the requirements document state what actions are to be performed, rather than how these actions will be performed?

Guidance: In other words, the requirements should concentrate on what the software needs to do, rather than how it will do it. In the case where a system or subsystem is being configured from a product line, design neutrality does not apply. Instead, one should show that requirements are consistent with the selected product line architecture.

Readability
Does the requirements specification use the language of the intended testers and users of the system, 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, there are generally two levels of requirements, highlevel and detailed. In addition, there is typically a functional specification. This checklist is designed to be used only with high-level and detailed requirements documents.

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.doc

Page 6 of 8

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.

12 Requirements Singularity
Does each requirement address a single concept, topic, element, or value?

Guidance: Avoid compound requirements that do not clearly delineate the parts with separate identifiers.

13 Definition of Inputs and Outputs

Have the internal interfaces, i.e., the required inputs to and outputs from the software system, 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, or 1 nanosecond response to the user.

16 Traceability

82341718.doc

Page 7 of 8

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