How to Write a BRD That Actually Gets Used

Problem#

Most Business Requirements Documents are written to be approved, not to be used. They are long, they are vague where it counts, and once signed they are never opened again. Delivery teams rediscover the requirements through conversation, and the BRD becomes an artefact whose only function was to unblock a gate.

You can spot a shelfware BRD by two symptoms. First, it describes a solution — screens, fields, technology — before anyone has agreed the problem. Second, its requirements cannot be tested: "the system should be user-friendly" cannot pass or fail, so it will never be verified, so it is not a requirement. It is a hope.

The result is predictable. Scope arguments in month three that should have happened in week one. Features nobody can trace to a business need. A UAT phase where the business says "this isn't what we asked for" and nobody can prove otherwise.

Business Impact#

• Rework. Requirements discovered during build cost far more than requirements discovered during analysis — and the later they surface, the more finished work they invalidate.
• Scope disputes without an arbiter. When the document is ambiguous, the loudest voice wins. That is not a governance model.
• Untestable acceptance. If a requirement has no acceptance criteria, UAT becomes a matter of opinion, and sign-off becomes a negotiation.
• Lost traceability. Without a link from business need to feature to test, you cannot answer "why does this exist" or "what breaks if we remove it."
• Vendor risk. In an outsourced build, the BRD is what you are contractually buying. Ambiguity is priced — always in the supplier's favour.

Concept#

A BRD answers one question: what does the business need, and how will we know it was delivered? Nothing else belongs in it.

The distinction that causes the most confusion:

A BRD that starts naming database fields has skipped two documents and locked in a solution before the problem is agreed. A BRD that never gets specific enough to test has not done its job either. The line is: describe the outcome precisely, leave the mechanism open.

Architecture#

A BRD that gets used has these sections, in this order:

1. Purpose and background — why this exists now. One page. What changed to make this worth doing.
2. Business objectives — measurable. "Reduce claim processing time from 6 days to 2." Not "improve efficiency."
3. Scope — in scope, out of scope, and explicitly deferred. The out-of-scope list prevents more arguments than the in-scope list.
4. Stakeholders — who decides, who is consulted, who is affected. Name the decision-maker per area.
5. Current state — how it works today, including the workarounds. Workarounds are requirements in disguise.
6. Business requirements — numbered, atomic, testable. The core of the document.
7. Business rules — constraints that hold regardless of implementation ("a claim over 50,000 requires two approvers").
8. Assumptions and dependencies — what must be true for this to work, and what you are relying on someone else to deliver.
9. Constraints — regulatory, budget, timeline, technology you must live with.
10. Success criteria and acceptance — how sign-off will be judged. Agree this before build.
11. Risks — with owner and mitigation, not a list of worries.
12. Glossary — every term that two departments define differently.

The requirements themselves need a consistent shape:

BR-014   Claim rejection reason
Priority: Must
Need:    An approver must record why a claim was rejected, from an agreed list.
Rationale: Regulator requires reason-level reporting; today reasons live in free text
           and cannot be aggregated.
Acceptance: A rejected claim cannot be saved without a reason code. Reason codes are
           reportable in aggregate for any date range.
Source:  Compliance (J. Rivera), audit finding 2026-11

Every field earns its place. Rationale survives the person who wrote it. Acceptance is what makes it testable. Source is who to ask when it is challenged in month four.

Step-by-Step Guide#

1. Establish the objective before the requirements. If you cannot state a measurable business objective, you are not ready to write requirements. Go back to the sponsor.

2. Map the current state, including workarounds. The spreadsheet someone maintains at the side of the process is a requirement nobody wrote down.

3. Interview for problems, not features. When a stakeholder asks for a button, ask what they would do with it. The answer is the requirement; the button is one possible solution.

4. Write each requirement atomically. One need per requirement. "The system must allow approval and rejection with comments" is three requirements wearing one number.

5. Write acceptance criteria at the same time. If you cannot write the test, the requirement is not specific enough yet. Do it now, not in UAT.

6. Prioritise with a forced distinction. MoSCoW works only if "Must" is genuinely constrained. If everything is a Must, nothing is.

7. Walk it back through stakeholders individually. Group review produces agreement in the room and disagreement afterwards.

8. Build the traceability matrix as you go. Requirement → design → test case. Retrofitting an RTM is painful; maintaining one is not.

9. Baseline and version it. Once approved, changes go through change control. A BRD that is edited silently is not a baseline.

Best Practices#

• Number requirements permanently. Never renumber. Deleted requirements are marked withdrawn, not removed — downstream documents reference those numbers.
• State the negative. "Out of scope: migrating historical claims prior to 2024." Explicit exclusions are the cheapest scope control available.
• Quantify everything quantifiable. "Fast" is not a requirement; "returns within 2 seconds for 95% of requests" is.
• Record who asked. Requirements without a named source get challenged and cannot be defended.
• Keep the glossary honest. If Finance and Operations mean different things by "active customer", the glossary is the most valuable page in the document.
• Length is not a quality signal. A tight 20-page BRD outperforms a 200-page one, which nobody reads and which therefore hides its own contradictions.

Common Mistakes#

• Solutioning. Specifying screens, fields and technology in a BRD removes the design space before anyone has explored it — and locks in the analyst's guess.
• Untestable requirements. "User-friendly", "robust", "scalable", "intuitive". Each needs a measurable definition or it will never be verified.
• Compound requirements. Anything containing "and" or "or" usually needs splitting, because half of it can pass while half fails.
• Missing non-functionals. Performance, availability, retention, auditability, accessibility. These surface late and are expensive to retrofit.
• No out-of-scope section. Guarantees a scope dispute later.
• Sign-off by silence. "No response by Friday means approved" produces approvals that evaporate the moment something goes wrong.
• Freezing too early. A baseline is not a prohibition on learning. It is a requirement that changes be visible and decided, not absorbed.

Example#

A claims team wanted "a dashboard." The first draft BRD specified charts, filters and a layout.

Reframed to the business need, it became three requirements:

The dashboard still got built. But BR-002 defined what "useful" meant, BR-003 turned out to be the requirement that actually reduced SLA breaches, and BR-004 came from a regulatory obligation nobody had mentioned in the original request. None of that was visible while the conversation was about charts.

Download#

A BRD template with the section structure, requirement shape and a starter traceability matrix is in the Templates library. Pair it with the Project Plan template.

FAQ#

What is the difference between a BRD and an FRD?#

The BRD states what the business needs and why; the FRD states what the system must do about it. "We are losing orders at checkout" is a BRD statement. "When card authorisation is declined, the basket is retained and an alternative payment method offered" is an FRD statement. Mixing them produces a document that commits to a solution before the need is agreed.

Who should write the BRD?#

A business analyst working with the sponsor, not the delivery team alone and not the business alone. Written purely by the business it tends to describe a solution somebody already has in mind; written purely by delivery it tends to encode what is convenient to build.

How long should it be?#

As long as the requirements need and no longer. Length is not a quality signal — a tight document gets read and its contradictions get found, while a long one gets approved and hides them.

Do we need a BRD on an agile project?#

Something has to state the business need durably. Stories are ephemeral and get closed; in six months nobody reads a closed story, but somebody will need to know what the eligibility rule was and why. Keep it lighter, keep it living, but do not assume the backlog is a substitute.

What if the business cannot express requirements without describing screens?#

That is normal and not an obstacle. Take the screen description and ask what decision the person is trying to make or what task they are trying to complete. The requirement is underneath it — the worked example above is exactly this conversation.

How do we handle requirements that conflict?#

Surface the conflict explicitly and take it to the sponsor rather than resolving it quietly in favour of whoever asked most recently. Conflicting requirements are information about competing priorities, and the resolution is a business decision, not an analysis one.

When should a BRD be baselined?#

When enough is agreed that changes should be visible and decided rather than absorbed. Baselining is not a prohibition on learning — it is the point after which change goes through Change Management and gets costed.

Related Articles#

Continue with FRD for translating business needs into system behaviour, SRS for the engineering specification, RTM for traceability, and UAT for proving the requirement was actually met.

What else is coming for BRD