Guide · Business analysis

How to write a BRD: the complete 2026 guide

A senior BA's view of what actually belongs in a Business Requirements Document, why it belongs there, and how to write it without burning a week.

A Business Requirements Document is the contract between the business and the delivery team for what a piece of work is supposed to achieve. Done well, it eliminates whole categories of mid-project arguments. Done poorly, it is the document everyone blames after the launch. This guide is a practical walk-through of the structure that survives senior review, with notes on the pitfalls that quietly tank weaker BRDs.

What a BRD is — and what it is not

A BRD describes what the business needs and why. It does not specify how the system will be built. A BRD is read by sponsors, steering committees, and SMEs to confirm intent. The corresponding how-it-will-be-built document is the Functional Requirements Document (FRD) or PRD, written for delivery teams.

The most common BRD failure is collapsing this distinction. The author starts in business language and drifts into solution language: "the system shall expose an API endpoint…" — that does not belong in a BRD. The cleaner test: every BRD requirement should be unchanged whether the solution is a bespoke build, a SaaS configuration, or a process change.

The standard BRD structure (the one PMOs accept)

You can write a BRD in many orders, but the one that survives PMO review almost always includes these sections, in roughly this order:

Executive summary — one page, written last. Sponsor, project name, business outcome, the headline ask.
Business context — why this work, why now, the strategic driver. Not generic ("our customers want better service"). Specific ("the 2025 regulatory change requires X by Y").
Objectives — SMART. Each one tied to a measurable success criterion.
Scope — in-scope and, critically, explicit out-of-scope. The out-of-scope list is what stops scope creep three months in.
Business requirements — numbered (BR-001, BR-002...), each with priority (MoSCoW or H/M/L), owner, source citation, and acceptance criterion.
Non-functional requirements — by category (performance, security, reliability, usability, etc.), each with a measurable target.
Assumptions — explicit. The assumption that turns out to be wrong is the risk that materialises.
Dependencies — internal, external, regulatory.
Risks — top risks at the BRD level (the full list lives in the RAID log).
RACI — for the BRD itself and for the work it authorises.
Glossary — vocabulary, especially regulated terms.

Writing requirements that survive review

Senior reviewers reject requirements for three reasons more than any others:

Hand-waving acceptance criteria. "The system should be performant" is not a requirement; it is a wish. Replace with: "Page load p95 under 2s for 1k concurrent users." If you cannot quantify it, surface the gap rather than padding it.
Solutioned business requirements. "The system shall use a queue to handle bursts" is solution language. The business requirement is "The system shall absorb 5x normal volume during campaign windows without service degradation." How is for the FRD.
Untraceable requirements. Every BR should be traceable to a stakeholder, a source document, and an acceptance criterion. If it has no source, it is invented.

The traceability layer most BRDs skip

Traceability is the unglamorous quality that separates BRDs that hold up from BRDs that fall apart. Each BR should carry:

A stable ID (BR-001, BR-002, etc.) that downstream artefacts can reference.
A source: the stakeholder, document, or workshop where it originated.
A priority: MoSCoW (Must, Should, Could, Won't) is the most defensible.
An owner: usually the business owner of the function, not the BA.
An acceptance criterion: written in plain English, not bullet salad.
A completeness flag: is this fully validated, or is information still missing?

Storing requirements as data — not just prose — is what lets you filter, deduplicate, push to Jira, and trace from a final user story back to its originating business requirement six weeks later. A BRD that is only prose stops being useful the moment the FRD diverges.

Common pitfalls (and how to avoid them)

The "everything is a Must" trap. If half the BRs are Must, prioritisation has not happened. Force the Wont's. They are often the most informative line in the document.
The phantom stakeholder. A BR cited to "the business" is a BR with no owner. Tie every BR to a specific named role or person.
The vanishing out-of-scope. An empty out-of-scope section means scope creep is inevitable. List the obvious things you are deliberately not doing — and the reasons.
The NFR afterthought. NFRs written as "the system shall be secure" guarantee the wrong thing gets built. Specify by category and target.
Treating the BRD as final. A BRD evolves through discovery. Version it, audit changes, and require sponsor sign-off on material changes.

How long should a BRD be?

As long as it has to be and no longer. For a moderate enterprise project, 30–60 pages is typical. For a regulated programme, longer. The hard test is whether the executive summary can stand alone for the steering committee while the body holds up to a Senior BA review. If the document is short but the executive summary is fluff, it is too short. If the document is 200 pages and reviewers skim, it is too long.

Using AI to write the first draft

AI is genuinely useful for the first 70% of a BRD draft if it is given the right material to work from. The pitfall is using a general LLM with no project grounding — the output looks fluent but invents requirements, names plausible stakeholders, and skips traceability. That draft costs more to clean than it saves.

A purpose-built BA tool — Reqify's AI BRD generator — works by retrieving from your actual discovery files: transcripts, RFPs, prior BRDs, regulatory references. Every requirement cites its source. Gaps are flagged inline rather than papered over. You still own the artefact; the tool takes the typing.

What's next

Once the BRD is signed off, the next artefacts in the BA flow are the FRD (engineering-facing), the user-story backlog (delivery), and the business case (funding). Reqify generates all three with full traceability back to the BRD.