# Requirements Review Findings — Sample Report

> 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](/knowledge/business-analysis/), the
[elicitation checklist](/knowledge/business-analysis/checklist/), and the
[BRD review checklist](/pmo/brd/checklist/).