Requirements Review Checklist Template

Requirements inspection: review details, per-requirement checks by 29148 characteristic, set checks, defect log, defect density summary, sign-off

Requisitos y análisisEstándarISO/IEC/IEEE 29148:2018 5.2.5 and 5.2.6 (names only); INCOSE GtWR v4review checklistActualizada 29 oct 2026

Abrir en el editorDescargar .md

Cómo usar: Use it when a requirements document or batch is ready for peer review or inspection. Fill the review details and reference list first, then log findings against check IDs. The main pitfall is reviewing for content only and missing ambiguity, compound and unverifiable requirements.

Vista previa

Requirements Review Checklist: [Document or requirement set]

Inspection checklist for individual requirements and for a requirement set, with a defect log and a review summary. The checks are grouped by the characteristics of well-formed requirements and requirement sets named in ISO/IEC/IEEE 29148:2018 (subclauses 5.2.5 and 5.2.6), and the writing checks follow the themes of the INCOSE Guide to Writing Requirements (version 4). Both are cited by name only; the questions are original. Replace every [bracketed] value and every row marked Example.

Review details

Field	Value
Review ID	[REV-REQ-001]
Item reviewed	[Document ID, title and version, or requirement ID range]
Review type	[Inspection / Walkthrough / Desk check]
Moderator	[@moderator]
Author	[@author]
Reviewers and focus	[@name (testability), @name (domain), @name (security)]
Requirements in scope	[Number]
Entry criteria met	[Yes / No: document frozen, IDs assigned, spelling checked]
Preparation time	[Hours per reviewer]
Review meeting date	YYYY-MM-DD
Exit decision	[Accept / Accept after rework / Re-review]

1. Scope and references

Reference	Version	Why reviewers need it
[Parent requirements, for example StRS or business requirements]	[Version]	To judge necessity and traceability
[Glossary]	[Version]	To check terms
[Style guide, for example `requirements/ears-requirements-style-guide`]	[Version]	Sentence patterns
[Interface and data definitions]	[Version]	To check consistency

2. Checks for each requirement

Check	Characteristic or theme	Question to ask	Typical defect
IR-01	Necessary	Does it trace to a parent need, rule or constraint, and would something be lost without it?	Gold plating, a requirement nobody asked for
IR-02	Appropriate	Is it written at the right level for this document, without design detail?	"The system shall use a PostgreSQL table" in a stakeholder requirement
IR-03	Unambiguous	Can it be read only one way?	"Fast", "user-friendly", "and/or", "where possible"
IR-04	Complete	Does it state the condition, the subject, the action and the measure needed to act on it?	Missing units, tolerance or trigger
IR-05	Singular	Does it state one need only?	Two capabilities joined by "and"
IR-06	Feasible	Can it be achieved within known technology, cost and schedule?	A target no component can meet
IR-07	Verifiable	Can a test, analysis, inspection or demonstration prove it?	No measurable criterion
IR-08	Correct	Does it state the need as the source meant it?	Wrong value copied from a workshop note
IR-09	Conforming	Does it follow the project template, ID scheme and style guide?	Missing attributes, wrong sentence pattern
IR-10	Attributes	Are source, priority, owner, status and verification method filled?	Empty source
IR-11	Terms	Is every term in the glossary and used consistently?	"Customer" and "client" for one role
IR-12	Wording	Is it in active voice with a defined subject and "shall" (or the agreed keyword)?	"It should be possible to..."
IR-13	Wording	Does it avoid vague quantifiers, open lists and escape clauses?	"Including", "such as", "if possible", "as appropriate"
IR-14	Wording	Is it free of pronouns whose reference is unclear?	"It shall send them to it"

3. Checks for the requirement set

Check	Characteristic or theme	Question to ask	Result
RS-01	Complete	Are all modes, states, interfaces, user classes and quality attributes covered? Is there a "to be determined" list with owners?	[Pass / Finding]
RS-02	Consistent	Are there conflicting requirements, duplicate IDs, or the same thing stated twice with different values?	[Pass / Finding]
RS-03	Feasible	Can the set as a whole be met within the constraints, considering trade-offs between requirements?	[Pass / Finding]
RS-04	Comprehensible	Can the intended readers understand the set, its structure and how it relates to other documents?	[Pass / Finding]
RS-05	Able to be validated	Can it be shown that the set, if met, satisfies the stakeholder needs within the constraints?	[Pass / Finding]
RS-06	Traceable	Does every requirement trace up to a source and down to a verification item (`requirements/traceability-matrix`)?	[Pass / Finding]
RS-07	Bounded	Is the scope and system boundary clear, with external interfaces named?	[Pass / Finding]

4. Defect log

ID	Requirement	Check	Severity	Description	Proposed fix	Status
D-01 (Example)	SYS-FR-014	IR-05	Major	Combines booking confirmation by e-mail and by text message, which are verified separately	Split into SYS-FR-014 and SYS-FR-015	Fixed, verified
D-02 (Example)	SYS-PR-003	IR-04	Major	"Search shall be fast": no load, measure or percentile	State response time at a given load and percentile	Open
D-03 (Example)	SYS-FR-022	IR-03	Minor	"Where possible" makes the requirement optional	Remove or state the condition	Fixed, verified
D-04 (Example)	Set	RS-01	Major	No requirement covers the maintenance mode	Add requirements or record as open issue	Open
D-05 (Example)	SYS-FR-030	IR-11	Editorial	"Client" used; glossary term is "customer"	Use glossary term	Fixed, verified
[D-nn]	[ID]	[Check]	[Major / Minor / Editorial]	[Description]	[Fix]	[Open / Fixed / Verified / Rejected]

5. Review summary

The example figures below describe the whole review; the defect log above shows five of its 18 findings.

Measure	Value
Requirements reviewed	Example: 120
Major defects	Example: 5
Minor defects	Example: 10
Editorial defects	Example: 3
Total defects	Example: 18
Defects per 100 requirements	Example: 15.0
Most frequent check	Example: IR-04 Complete
Exit decision	Example: Accept after rework; moderator verifies the 5 major fixes

Exit rule used: [for example, no open major defects, and minor defects fixed or accepted by the author with the moderator's agreement].

Sign-off

Role	Name	Decision	Date
Moderator	[@name]	[Decision]	YYYY-MM-DD
Author	[@name]	[Rework done]	YYYY-MM-DD

Standard and licence note

Structure aligned with the characteristics of individual requirements (necessary, appropriate, unambiguous, complete, singular, feasible, verifiable, correct, conforming) and of requirement sets (complete, consistent, feasible, comprehensible, able to be validated) named in ISO/IEC/IEEE 29148:2018, Systems and software engineering: Life cycle processes: Requirements engineering, subclauses 5.2.5 and 5.2.6. The writing checks reflect the themes of the INCOSE Guide to Writing Requirements, version 4 (INCOSE-TP-2010-006-04, 2023), cited by name only. The questions, examples and defect classes are original text written for this collection. As of October 2026 the 2018 edition of 29148 is current and a revision is in development; check the current editions before use. Official text: ISO, IEC and IEEE, purchase or licensed access at https://www.iso.org/standard/72089.html; INCOSE, purchase through the INCOSE Store at https://www.incose.org/. Related templates: requirements/business-analysis-plan, requirements/traceability-matrix, requirements/system-requirements. Template licence: MIT.

Plantillas relacionadas

Requisitos y análisis