BRD Review Checklist

Use this on a draft before circulating it. Pair with the BRD template for the structure and the BRD guide for the reasoning.

Document: _______________ Version: ____ Reviewer: _______________ Date: _______

1. Purpose and framing#

• [ ] The business need is stated, not a solution
• [ ] It is clear why now. What changed
• [ ] The cost of doing nothing is stated
• [ ] Someone reading it cold would understand what problem is being solved

2. Solutioning: the most common defect#

• [ ] No screens, fields, layouts or technology specified
• [ ] No supplier or product named as a requirement
• [ ] Where a solution IS mandated, it is recorded as a constraint, with who mandated it

A BRD that specifies the interface removes the design space before anyone has explored it, and locks in the analyst's first guess. If a requirement describes a screen, ask what decision the user is trying to make.

3. Requirements#

• [ ] Each has a unique identifier that will never be reused
• [ ] Each is testable. You can say in one sentence how it would be proven
• [ ] One requirement per statement, anything with "and" or "or" is split
• [ ] No user-friendly, robust, scalable, intuitive, appropriate
• [ ] Priority assigned, and not everything is "must"
• [ ] Each traces to a business objective

Count the untestable ones: ____ of ____. Anything above zero is worth a conversation; a third of the document teaches everyone that requirements are decorative.

4. Scope#

• [ ] In-scope list present
• [ ] Out-of-scope list present, and contains things people actually expect
• [ ] Interfaces to other systems identified
• [ ] Affected teams and processes named

The out-of-scope section is the cheapest dispute prevention available. "It will not cure cancer" is not the list; "it will not replace the existing approval workflow" is.

5. Non-functional requirements#

• [ ] Performance, with a number and a load condition
• [ ] Volume and expected growth
• [ ] Availability, and what it excludes
• [ ] Retention and audit requirements
• [ ] Accessibility standard named
• [ ] Security and permissions model outlined
• [ ] Personal data identified, with lawful basis

These surface late and are expensive to retrofit. Silence on them is a decision to discover them in production.

6. Assumptions, dependencies and risks#

• [ ] Assumptions listed, each with who confirms it
• [ ] Dependencies on other teams or suppliers named, with owners
• [ ] Top risks recorded and linked to the risk register
• [ ] Open questions listed with owners and dates

7. Usability of the document#

• [ ] Short enough to be read properly by the people approving it
• [ ] Sections can be reviewed independently by the people who care about each
• [ ] Terms used consistently, a glossary exists if the domain has jargon
• [ ] Version, date and status on the front

Length is not a quality signal. A tight document gets read and its contradictions get found; a long one gets approved and hides them.

8. Sign-off#

• [ ] Named approvers, not roles
• [ ] No sign-off by silence. "no response by Friday means approved" produces approvals that evaporate the moment something goes wrong
• [ ] Baseline point agreed, after which changes go through change management
• [ ] Delivery and test have both read it before it is baselined

Involving test before baseline is the cheapest quality step available, they ask "how would I prove that?" about statements everyone else read straight past.

Reviewer verdict#

Back to BRD