Northrop Grumman Information Technology, Defense Enterprise Solutions
Peer Review Checklist for Requirements Document
Identification
Use the following summary information when referring to this document:
Reviewer Name
Review Date
Review Product, Version, Author
Project
POC for checklist change requests
Instructions
<POC Name>
Use this checklist to perform Peer Reviews of a Requirement Document (RD). This
checklist covers a generic Requirements Document. It can be used as the basis for more
specific document checklists such as System Specification, Software Requirements
Specification, and Interface Requirements Specification. Complete a separate checklist
for each review product.
Go through each checklist item sequentially, checking the entire review product for
conformance before moving on to the next checklist item. Checking off an item is your
professional approval of the product under review concerning that item. Use the
following symbols to record your review of each checklist item:
 = Item checked and no defects found
 = Item checked and defects or issues found, or
 = Item does not apply to this review product.
As part of the Peer Review process, send any change requests for this checklist to the
POC identified above.
Check the review product for clarity, readability, conciseness, and ambiguities.
1. Clarity
1.1
1.2
1.3
1.4
1.5
1.6
1.7
 Every requirement is uniquely labeled.
 The information is communicated clearly to the intended audience. Graphical / diagrammatic
techniques (such as Use Cases and Data Flow Diagrams) are used as necessary.
 The information is presented unambiguously for the intended audience. That is, only one
reasonable interpretation exists.
 Notes are separated from the core of the document through stylistic convention. Notes
generally assist understanding of the information without adding to it.
 Terms are clearly defined.
 All acronyms are spelled out the first time they are used.
 An acronym list is included.
2. Completeness Check the review product to ensure it is complete, within and of, itself. That is, the
product is fully described according to the requirements and/or design of the product,
and the product is targeted toward its intended audience.
2.1
2.2
2.3
2.4
2.5
106749929




The system / application is clearly identified in accordance with project standards.
A system overview is provided.
An overview of the RD itself is provided.
All needed requirements (functional, performance, interface, environment, quality attributes,
and mandatory design constraints) are included.
 The RD specifies the required response of the system / application to all realizable classes
of input data in all realizable classes of situations, both valid and invalid input values.
Page 1 of 3
28 January 2003
Northrop Grumman Information Technology, Defense Enterprise Solutions
Peer Review Checklist for Requirements Document
2.6
2.7
2.8
2.9
3. Compliance
3.1
3.2
4. Consistency
4.1
4.2
4.3
4.4
5. Correctness
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12




The RD specifies any required standards conformity.
Every TBD (To Be Determined) and TBR (To Be Resolved) is uniquely identified.
Each TBD and TBR has a documented plan to resolve.
All TBDs and TBRs that have been previously resolved are updated in the RD.
Check the review product to ensure that it complies with all applicable internal (within
Northrop Grumman Information Technology [NGIT] Defense Enterprise Solutions
[DES]), contractual, and project-specific standards.
 The document layout / format complies with the customer / project standard / template.
 Diagramming techniques conform to the specified standard(s).
Check the review product for consistency within itself and with other related products.
 Diagramming techniques are consistent within the document.
 Terms are used consistently throughout the document and related documents.
 A consistent set of attributes is defined for each requirement.
 No requirement is in conflict with other requirements.
Check the each requirement for correctness.
 Necessary (1): The system will fail to do what the customer needs done (not merely prefers)
without this requirement.
 Necessary (2): Specifies what the system must do and not the how, i.e., is at the
requirements level, not design approach, except for mandatory design constraints.
 Granularity: A single customer need is stated.
 Correct: Accurately reflects what the customer needs the system / application to do.
 Verification Method is specified: Each requirement is to be verified by one of four methods
(or a combination of them): Test, Demonstration, Inspection, Analysis.
 Verifiable: There exists (preferably specified within the RD) a cost-effective process to
confirm that the system / application meets the requirement.
 Feasible: The system / application under development can reasonably meet the
requirement.
 Clearly Stated / Unambiguous: Only one reasonable interpretation exists. There are no
ambiguous terms, such as: may, minimize, user-friendly, optimum, flexible, fast, etc.
 Unique: This requirement is not duplicated by any other requirement.
 Complete: The requirement describes the conditions under which the requirement applies,
including input, operational modes, and triggering events.
 Prioritized: A ranking or priority level is included.
 Supportable: Includes an explanation or rationale justifying the need for the requirement.
6. Maintainability Check the review product to ensure that it is maintainable for its expected life and
volatility.
6.1
6.2
6.3
6.4
6.5
106749929
 The POC for change requests is clearly identified in the document.
 Every trade-off is included (or referenced).
 Where feasible, data derived from other sources, such as an automated tool, are captured in
a data-driven mode to reduce rework.
 The RD has a coherent and usable organization / structure. For example, a hierarchical
structure starting from most general at the top to most specific at the bottom.
 The document follows the “write once, read many” principle. I.e., does not copy items
multiple times; writes it once, then refers / links to it.
Page 2 of 3
28 January 2003
Northrop Grumman Information Technology, Defense Enterprise Solutions
Peer Review Checklist for Requirements Document
7. Reusability
7.1
7.2
Check the review product to ensure that reusable components have been utilized to
build the review product where applicable, and to maximize the review product’s
reusability within, and outside of, the current project.
 There are no duplicate / redundant requirements.
 Requirements from other projects / repositories have been reused where feasible.
Check the review product to ensure that it is appropriately marked for security
purposes, and that all applicable security issues have been addressed.
8. Security
8.1
8.2
 The document is appropriately marked.
 The document describes the security requirements to be implemented.
9. Traceability
Check the review product to ensure that its statements/functionality can be traced back
to its original requirements or predecessor work products, and on to successive work
products. Note: This is often covered in a Requirements Traceability Matrix that should
be reviewed in conjunction with the Requirements Document.
9.1
9.2
 All necessary reference documents are cited.
 Every source requirement (Statement of Work, Concept of Operations, System Specification,
etc.) is accounted for in the RD.
 Each requirement includes a reference to its source (backward traceability).
 Each requirement is traceable (i.e., identified clearly so it can be traced) to the design and
verification plan (forward traceability).
9.3
9.4
Check the review product for any other potential defects (e.g., appearance,
performance, testing, identification, version control, etc.).
10. Other
10.1
10.2
106749929
 The document is free of grammatical, syntactical, and spelling errors.
 The document contains a table of contents.
Page 3 of 3
28 January 2003