How to Write a BRD: Structure, Example and Checklist
A business requirements document has one job: get the people who fund, build and use a solution to agree on what it must do, before anyone builds it. Most BRDs fail that job not because they're short, but because they're vague. Here's how to write one that gets signed off.
01What a BRD is, and what it isn't
A BRD describes what the business needs and why: the problem, the goals, the scope, the business requirements, and the functional requirements a solution must meet to deliver them. It is written for business stakeholders first, so it should read clearly to someone who has never seen the system.
It is not a technical design. Functional requirements say what the system must do; screen layouts, database fields and integration detail belong in a functional specification, a design document or user stories.
02Before you write: settle three things
- The real problem. Not "we need a new system" but "end-of-day reconciliation takes eight hours and errors are found too late to fix". The first step of the 4C Framework, Clarity, exists for exactly this.
- Who signs off. Name the people whose approval makes the BRD final. If you find out at the end, you'll rewrite it.
- How success will be measured. Cycle time, error rate, cost, compliance. If nobody can say what "done" looks like, the requirements will keep moving.
03The structure, section by section
| Section | What goes in it |
|---|---|
| 1. Document control | Version, date, author, reviewers and approvers |
| 2. Background and problem | What is happening today, why it matters and what it costs |
| 3. Objectives and success measures | What the business wants to achieve, with numbers where possible |
| 4. Scope | What is in, and just as importantly, what is out |
| 5. Stakeholders | Who is affected, who decides and who needs to be kept informed |
| 6. Current process | The as-is process, ideally as a process map with its pain points marked |
| 7. Future process | The to-be process and what changes for each role |
| 8. Business requirements | What the business must be able to do, numbered and prioritised |
| 9. Functional requirements | What the system must do to meet each business requirement: numbered, prioritised, traced to a business requirement, and often backed by a use case with its trigger, preconditions, normal flow and failure conditions |
| 10. Non-functional requirements | Security, audit, availability, performance, regulatory needs |
| 11. Reporting and notifications | Reports, alerts and who receives them |
| 12. Assumptions, constraints and dependencies | What you are relying on, and what could stop delivery |
| 13. Sign-off | Names, roles, dates and signatures |
04A worked example: a treasury bill request
Imagine a bank that lets customers subscribe to treasury bills online. Here is how a few business requirements might read in the BRD. Each is numbered, has a priority, and can be tested.
| ID | Requirement | Priority |
|---|---|---|
| BR-01 | The customer must be able to submit a treasury bill request online, choosing the tenor and amount. | Must |
| BR-02 | The system must check the customer's balance, including charges, and the account's status before accepting a request. | Must |
| BR-03 | The investment amount must be held on the customer's account as soon as the request is submitted. | Must |
| BR-04 | Every request must be reviewed by one officer and approved by another before settlement. | Must |
| BR-05 | The customer must receive an email at submission, approval or rejection, and settlement. | Should |
The functional requirements then say what the system must do to meet them. Each one traces back to a business requirement:
| ID | Functional requirement | Traces to | Priority |
|---|---|---|---|
| FR-01 | When the customer selects a tenor and amount, the system shall retrieve their available balance and account status from core banking. | BR-02 | High |
| FR-02 | If the available balance is less than the investment amount plus charges, or the account is inactive or dormant, the system shall block submission and tell the customer why. | BR-02 | High |
| FR-03 | On submission, the system shall place a hold equal to the investment amount on the customer's account. | BR-03 | High |
| FR-04 | The system shall not allow the officer who reviewed a request to also approve it. | BR-04 | High |
| FR-05 | The system shall email the customer when a request is submitted, approved, rejected and settled. | BR-05 | Medium |
Notice what's still missing: screen layouts, database fields and API names. Those belong in the design, not the BRD.
05Write requirements people can build and test from
| Weak | Strong |
|---|---|
| The system should be fast. | Search results must load within 3 seconds for 95% of requests. |
| Users should be notified. | The approver must receive an email within 5 minutes of a request entering their queue. |
| Handle errors properly. | If the balance check fails, the request must be rejected and the customer shown the reason. |
A simple test: could a tester write a pass or fail check for this requirement? If not, rewrite it.
06Five mistakes that stop sign-off
- Solutions disguised as requirements. "Build a dashboard" is a solution. "Managers must see pending approvals by branch" is a requirement.
- No out-of-scope list. Anything not excluded will be assumed to be included.
- Unresolved disagreements hidden in vague wording. Ambiguity feels like progress until testing starts.
- Missing exception handling. The happy path is rarely where projects fail.
- The wrong approvers. A BRD signed by people who can't commit budget or staff isn't really signed.
07A 20-point BRD checklist
- Version, author and approvers are listed.
- The problem is stated in business terms, with its impact.
- Objectives are measurable.
- In-scope and out-of-scope items are both listed.
- All affected stakeholders are identified.
- The as-is process is mapped.
- The to-be process is mapped.
- Every requirement has a unique ID.
- Every requirement has a priority.
- Every requirement is testable.
- Every functional requirement traces back to a business requirement.
- No requirement prescribes a technical solution without a reason.
- Exceptions and failure scenarios are covered.
- Non-functional requirements are included (security, audit, performance).
- Regulatory and compliance requirements are referenced.
- Reports and notifications are specified.
- Assumptions and dependencies are recorded.
- Open questions have owners and due dates.
- Terms and abbreviations are defined.
- Sign-off names and roles are confirmed.
08Get a first draft faster
The free BA Workbench includes a BRD generator. Map your stakeholders, process steps, RACI and compliance items, and it assembles a draft BRD you can copy or download and then refine. It won't write the thinking for you, but it removes the blank page.
09Common questions
What is the difference between a BRD and an FRS?
A BRD sets out what the business needs and why, including the functional requirements a solution must meet, and is written for business stakeholders. An FRS goes further into how the system will behave, in more technical detail, for the delivery team.
How long should a BRD be?
As long as it needs to be to remove ambiguity, and no longer. For a single process change, 10 to 20 pages is common. Length matters less than whether every requirement is clear and testable.
Who signs off a BRD?
The business owner or sponsor, plus anyone accountable for the process, budget or compliance. Agree the approvers before you start writing.
Are BRDs still used in agile projects?
Often, yes. Many organisations, especially regulated ones like banks, use a lighter BRD to agree scope and objectives, then manage detailed requirements as user stories.