Requirements review checklist

Published 20 October 2026

A requirements review checks, before anything is built, that each requirement is needed, clear and testable, that together they are complete and consistent, and that the people who asked for them recognise what they meant. Below are a checklist to copy, the characteristics of good requirements from IEEE 830 and ISO/IEC/IEEE 29148, a worked review, the words to flag, how to run the review, a review log template, verification vs validation, and reviews in agile and with AI.

I separately remember being in a Requirements review for a feature that concluded successfully. Then later in a Design Review for that feature. And after that, Code and Unit Test reviews of the same feature. Then, months later, the feature was presented to the person who asked for it in the first place and then said, “that’s not what I wanted. I wanted xxx instead.”

Yes, this person was at the Requirements and Design reviews!

— Hacker News, 2024

A review of the wording alone would not have caught that. The checklist below has two halves: is each requirement written well, and does it say what the person who asked for it means.

Requirements review checklist

Copy it into the review invitation or the review log. Square brackets are yours to fill in.

REQUIREMENTS REVIEW CHECKLIST
Document:   [name], version [x.y]
Reviewers:  [name, role]
Date:       [   ]

EACH REQUIREMENT
[ ] Has a unique ID
[ ] States one thing (watch for "and"
    and "or")
[ ] Says what is needed, not how to
    build it
[ ] Has one meaning: no "fast", "easy",
    "user-friendly", "as appropriate"
[ ] Can be checked: a number, a message,
    a state someone can see
[ ] Is needed: someone can say what goes
    wrong without it
[ ] Has a source: a business need, a
    person or a regulation
[ ] Has a priority
[ ] Can be built within the budget and
    the date
[ ] Has acceptance criteria

THE WHOLE SET
[ ] No two requirements contradict
[ ] One term per thing, defined in the
    glossary
[ ] Errors, empty states and limits are
    covered, not only the normal case
[ ] Non-functional requirements have
    numbers
[ ] Every TBD has an owner and a date
[ ] Assumptions are written down
[ ] Out of scope is written down

WITH THE PEOPLE WHO ASKED
[ ] Each requirement was walked through
    with an example, not only read
[ ] They said in their own words what
    will happen
[ ] Open questions have owners and dates

RESULT FOR VERSION [x.y]
[ ] Accepted
[ ] Accepted with the changes logged
[ ] Review again after changes

Characteristics of good requirements

The checks come from two standards. IEEE 830-1998 lists eight characteristics of a good software requirements specification: correct, unambiguous, complete, consistent, ranked for importance and/or stability, verifiable, modifiable and traceable (IEEE 830, section 4.3). Its successor, ISO/IEC/IEEE 29148, “defines nine characteristics (dimensions) for individual software requirements” (Lubos et al., 2024): necessary, appropriate, unambiguous, complete, singular, feasible, verifiable, correct and conforming.

IEEE 830 defines a requirement as verifiable when “there exists some finite cost-effective process with which a person or machine can check that the software product meets the requirement”, and gives “works well,” “good human interface,” and “shall usually happen” as requirements that are not. On ambiguity it is blunt: “Natural language is inherently ambiguous.”

Requirements review example

The customer portal from the other templates: draft 0.9 of its requirements, reviewed by the client’s finance lead, the business analyst, a developer and a tester before version 1.0 was signed.

Each of these is a wording problem, and a careful reader finds it alone. The finding that mattered came from walking FR-016 through with a date: an invoice due on 1 June, still unpaid — what happens? The finance lead expected a second reminder after 30 days. That became an open question with the finance lead’s name on it, and the answer — not in this release — went into the out-of-scope list.

The agreed wording is the one the other templates use: FR-014 and FR-016 in the BRD example, NFR-007 in the non-functional requirement examples.

Words to flag: ambiguous requirements examples

The list follows NASA’s requirements checklist, which counts words such as “user-friendly”, “robust”, “quickly” and “other “ly” words” as unverifiable, and spells out the convention: “Shall = requirement”, “Will = facts or declaration of purpose”, “Should = goal” (NASA Systems Engineering Handbook, Appendix C). It also asks of every requirement: “What is the worst that could happen if the requirement was not included?”

Researchers call these patterns requirements smells. A tool that flagged them, tried on requirements from three companies and a university, found on average 82% of them, and 59% of its warnings were real (Femmer et al., 2017). The same paper gives the reason to run such a check before the meeting: reviewers “could be distracted by superficial quality defects such as the aforementioned vague formulations or loopholes.”

How to run a requirements review

1. Review a numbered version. Changes after the review make a new version, so “what did we review?” always has an answer — the signed one becomes the requirements baseline.
2. Invite the people who can say no later: the person who asked for it or will accept it, a developer, and a tester. Someone who worked from 1996 to 2005 for the on-board shuttle software group, the team in Fast Company’s “They Write the Right Stuff”, describes “Requirements Reviews with Customer, Requirements Analysts, and Testers all sitting around the same table going over them word by word” (Hacker News, 2017).
3. Check the words first, with the table above or a tool, so the meeting is spent on meaning.
4. Send the document ahead, and do not count on it being read. In a thread on getting stakeholders to read past the summary slide, one commenter: “if you NEED people to know the information, you can’t rely on them to read it themselves. You need to verbally give them the information, otherwise you can assume no one looked at it.” (r/businessanalysis, 2026).
5. Walk through examples, not sentences. For each requirement, take a real case — a date, an amount, a user — and have the person who asked say what happens.
6. Log every finding with the requirement, the problem, the decision and an owner. Decisions that settle a question go into the project’s decision log.
7. End with a result for the version: accepted, accepted with the logged changes, or review again. Then get it signed — the requirements sign-off template has the wording.
8. Next time, review what changed. A new version needs its differences reviewed, not the whole document again.

Reviews range from informal to formal. In a walkthrough, the author leads the others through the document and they ask questions; an inspection is “a very formal type of peer review where the reviewers are following a well-defined process to find defects”, based on the method Michael Fagan developed at IBM; IEEE 1028 sets out the roles and steps for both (Wikipedia). For most projects a walkthrough with this checklist is enough; regulated work may call for an inspection.

Requirements review template: the review log

REQUIREMENTS REVIEW LOG
Document:   [name], version [x.y]
Date:       [   ]
Reviewers:  [name, role]
            [name, role]

FINDING 1
Requirement:  [ID]
Problem:      [the check it fails]
Decision:     [new wording, or why it
              stays as it is]
Owner:        [name]
Due:          [date]

FINDING 2
Requirement:  [   ]
Problem:      [   ]
Decision:     [   ]
Owner:        [   ]
Due:          [   ]

OPEN QUESTIONS
Q1  [question]
    Owner: [name]   By: [date]

RESULT
[ ] Accepted
[ ] Accepted with the changes above
[ ] Review again after changes
Next version: [x.y]

Requirements verification vs validation

The two are often put as Barry Boehm’s questions: “Are you building the right thing?” and “Are you building it right?” (Wikipedia). The opening quote is a review that verified and did not validate.

Requirements review in agile

In Scrum or Kanban the review happens story by story, in backlog refinement: a story is ready when it passes the INVEST checks and has acceptance criteria the person who asked has agreed. The checklist above still applies to each story; the “whole set” checks apply to the epic or the release. Two in particular are easy to lose one story at a time: contradictions between stories, and non-functional requirements that belong to no story.

Getting the review done at all is a complaint of its own. Asked what they hate most about being a business analyst, one commenter answered: “Getting stakeholders to review and sign off requirements. Either they never get looked at and the project goes on with no structure or they’re not read and approved.” (r/businessanalysis, 2026).

Reviewing requirements with AI

An AI model can do the verification half. In one study, a model checked requirements against the ISO 29148 characteristics and “effectively identified the majority of flawed software requirements”; the authors add: “Nevertheless, manual verification is still required, given the low precision values, as false positives may occur” (Lubos et al., 2024). One developer describes the workflow: “I wrote a description, loose set of requirements then had the AI review the requirements for completeness and consistency, then draft them into a requirements.md file” (Hacker News, 2026).

The validation half stays with people. A model can say that “in good time” is vague; it cannot say that the finance lead expected a second reminder. When an AI coding agent writes the requirements as well, the question of who reviews the spec comes first.

Where Specroot fits

This is the problem Specroot works on: review findings and decisions kept with the requirement and the version they were made on, so the next review starts from what changed. Specroot for agencies and consultancies.