# BRD Review Checklist

> Use this on a draft before circulating it. Pair with the
> [BRD template](/templates/brd/) for the structure and the
> [BRD guide](/pmo/brd/) 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](/pmo/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](/pmo/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

| | |
|---|---|
| Untestable requirements found | |
| Solutioning found | |
| Missing non-functional areas | |
| Ready to circulate | yes / no |
| Blocking issues | |