Requirements Review Findings — Sample Report
What a review of a requirements document should produce — findings ranked by what they will cost in delivery, with the untestable requirements counted rather than characterised.
Markdown. No sign-up, no email.
This is an illustrative example. The document reviewed, figures and findings are composed to show the shape of a useful review, not drawn from a named engagement.
Document reviewed: Customer onboarding — Business Requirements v0.9 Reviewer: _______ Date: _______ Recommendation: not ready to baseline — three findings must be resolved first
Summary#
The document is well organised and covers the happy path thoroughly. Three findings will cost delivery time if it is baselined as it stands, and one of them will not be discovered until testing.
| # | Finding | Severity | Cost if unresolved |
|---|---|---|---|
| 1 | 23 of 61 requirements are not testable | High | Ambiguity resolved by developers, differently each time |
| 2 | No out-of-scope section | High | Every request becomes a negotiation |
| 3 | Exception behaviour absent for 4 of 7 flows | High | Discovered in testing; late rework |
| 4 | Non-functional requirements missing | Medium | Retrofitted, expensively |
| 5 | Two requirements conflict | Medium | Resolved by whoever builds it first |
| 6 | Sign-off by silence proposed | Low | Approvals that evaporate under pressure |
Finding 1 — 23 of 61 requirements cannot be proved#
Counted, not characterised. The reviewer's opinion of a document is arguable; a count is not.
Typical examples:
| Ref | As written | Problem |
|---|---|---|
| BR-014 | "The system shall be user-friendly" | No test exists |
| BR-022 | "Onboarding shall be fast" | No number, no condition |
| BR-031 | "The system shall support bulk uploads and validate them appropriately" | Two requirements; "appropriately" undefined |
| BR-047 | "Errors shall be handled gracefully" | Describes an intention |
Recommendation: rewrite each to name an actor, a trigger and an observable result. BR-022 becomes something like: a returning customer completes onboarding in under 4 minutes, measured from first form field to confirmation.
Finding 2 — no out-of-scope section#
The document says what the system will do and never what it will not.
This is the cheapest dispute prevention available and it is absent. Based on the stakeholder interviews referenced in the appendix, at least four expectations exist that are not in scope — migration of historical records, a bulk import tool, integration with the legacy CRM, and a mobile interface.
Recommendation: list them explicitly as excluded, and circulate that list specifically to the people who raised them.
Finding 3 — exception behaviour absent#
Four of seven flows describe only the successful path. Nothing states what happens when:
- A required document upload fails midway
- A duplicate application is submitted
- Identity verification returns an inconclusive result
- The verification provider is unavailable
The third is the most consequential: inconclusive is neither pass nor fail, and it is the case a delivery team will implement by guessing.
Recommendation: an exception table per flow — condition, expected behaviour, what the user sees.
Finding 4 — non-functional requirements missing#
No statement on: expected volume, peak concurrency, availability target, retention, accessibility standard, or audit requirements.
These surface late and are expensive to retrofit. Accessibility in particular is a design constraint rather than a feature, and a standard should be named before design begins.
Finding 5 — two requirements conflict#
BR-009 requires identity verification before an account is created. BR-038 requires an account to exist before documents can be uploaded, and verification requires an uploaded document.
As written these cannot both be satisfied. This is a business decision about the onboarding sequence, not something delivery should resolve.
Recommendation: take to the business owner. Surface the conflict rather than choosing.
Finding 6 — sign-off by silence#
The approval section proposes that no response within five working days constitutes approval.
Approvals obtained this way evaporate the moment something goes wrong, and they encourage reviewers not to read. Name approvers and require a positive response.
What is good, and should be kept#
- Requirements are numbered with stable identifiers
- Each traces to a stated business objective
- The glossary is genuine and defines terms used inconsistently elsewhere in the organisation
- Assumptions are listed with named confirmers
Recommended next step#
Half a day rewriting the 23 untestable requirements with the business owner and the test lead present. That session usually resolves findings 3 and 5 as a by-product, because asking "how would we prove this?" surfaces the exceptions and the contradiction without needing to hunt for them.
Why this report counts rather than describes. "The requirements are vague" is an opinion and invites disagreement. "23 of 61 cannot be proved, here they are" is a fact with a work estimate attached, and it produces a session rather than an argument.
See business analysis, the elicitation checklist, and the BRD review checklist.