# 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*.

<!--
Guidance: How to use this template
- Use one copy per review. Reviewers fill section 2 (individual checks)
  while reading, log every finding in section 4, and the moderator
  completes section 3 (set checks) and section 5 (summary).
- Review a manageable batch. A reviewer reads carefully for about two
  hours; split larger documents into several reviews.
- Log defects against requirement IDs, never against page numbers that
  will move.
- The author fixes, the moderator verifies. Do not close a defect only
  because the author says it is fixed.
-->

## Review details

<!-- Guidance: Identify what was reviewed, which version, by whom and with what entry criteria. Pitfall: reviewing a document that is still changing, so findings point at text that no longer exists. -->

| 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

<!-- Guidance: List what the reviewers need beside the item: the parent requirements, glossary and style guide. Pitfall: reviewing child requirements without the parent, so "necessary" cannot be judged. -->

| 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

<!-- Guidance: IR-01 to IR-09 use the 29148 names of the characteristics of individual requirements; IR-10 to IR-14 are additional writing checks. Ask each question of every requirement. Mark findings in the defect log with the check ID, for example IR-05. Pitfall: reading for content only and missing the structural defects that cause the most test trouble. -->

| 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

<!-- Guidance: RS-01 to RS-05 use the 29148 names of the characteristics of a requirement set; RS-06 and RS-07 are additional checks. These checks look at the set as a whole and are usually done by the moderator or a lead reviewer after the individual reading. Pitfall: approving a set of perfect individual requirements that together leave a whole mode or interface unspecified. -->

| 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

<!-- Guidance: One row per finding. Classify severity so the moderator can decide the exit: Major (would cause wrong design or test), Minor (unclear but likely to be read correctly), Editorial (format or spelling). Pitfall: arguing about fixes during the meeting; log the defect and let the author propose the fix. -->

| 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

<!-- Guidance: Summarise the counts, compute the defect density, and record the exit decision with its reason. Use the same measure across reviews so the trend in the business analysis plan means something. -->

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.