For consultants on IT, ERP and CRM projects
Business Requirements Document Template
The document your client signs off before anything is built or bought: eight sections, testable requirements, MoSCoW priorities and an annotated CRM example.
BRD format
What goes in each section of a business requirements document
The International Institute of Business Analysis (IIBA) publishes the BABOK Guide, its standard for the practice of business analysis. The guide defines a business requirement1 as goals, objectives and outcomes that “describe why a change has been initiated and how success will be assessed.” The rows follow the template's eight sections in order, and the last column shows each one filled in for an invented CRM project.
| Section | What goes in it | In the worked example |
|---|---|---|
| 1. Purpose and scope | The business problem, success measures with today's figure, a dated target and a source for each, and what is in and out of scope. | Quote turnaround: 2 working days (median) today, the same working day for 80% of quotes by 30 Sep 2027. Source: the 2026 quote log. |
| 2. Stakeholders | Every group that will use, approve or be affected by the solution, taken from your stakeholder analysis, with one named contact each. | Field sales reps (38). Contact: Nadia Brooks, Senior Rep. Need: quotes in minutes, on site, from the customer record. |
| 3. Current process and pain points | How the work is done today, step by step, as people really do it, then each problem with its evidence. | P-03: quotes over 12% discount are sometimes sent before they are approved. Evidence: the finance controller's interview. |
| 4. Business requirements | One numbered “shall” statement per need, with a MoSCoW priority, the pain point it serves and where it came from. | BR-05, a Must serving P-03: the solution shall stop a quote with a discount over 12% being sent until a branch manager approves it. |
| 5. Non-functional requirements | How well the solution must work, from speed and access to data migration and training, each with a measure someone can test. | NFR-01: opening a customer record or searching quotes shall take no more than 3 seconds for 95% of attempts, on branch Wi-Fi. |
| 6. Assumptions and constraints | What you're treating as true without checking, who will confirm it and what changes if it's wrong. Then fixed limits, such as budget and dates. | A-02: the order system can share prices and receive orders through its standard connection. If not, BR-08 drops to Could. |
| 7. Acceptance criteria | At least one test for every Must: what the tester does, what must happen and who accepts the result. | For BR-05: create a quote at 15% discount and try to send it. It can't be sent until a branch manager approves it. |
| 8. Sign-off | Each approver's name and role, the part they sign for, their decision and the date. | The finance controller signs for BR-05 and NFR-03, and the IT manager for the non-functional requirements. |
Examples come from the annotated CRM example in the template's second document, some shortened. The company, people and figures are made up.
How it works
How do you write a business requirements document?
To write a business requirements document, start with evidence: interviews, workshops and time spent watching the work. From that, write why the project exists and how success will be measured1, then the current process and its pain points. Turn each need into a numbered, testable requirement with a priority, write an acceptance test for every must-have, and get each business owner's sign-off. In a 2014 survey, the Project Management Institute found that inaccurate requirements management was the primary cause in 47% of projects that missed their goals2.
Write each requirement so it can pass or fail. NASA's Systems Engineering Handbook has a checklist for writing a good requirement3. It says to use “shall,” keep to one thought per statement, number every requirement, and say what is needed, not how to provide it. It also flags words nobody can verify, such as fast, easy, flexible and user-friendly, so replace each with a measure someone can test. Note where every requirement came from, too, and the pain point it serves.
Then rank each requirement with MoSCoW: must have, should have, could have or won't have this time. The Agile Business Consortium's guide says a requirement with any workaround, even a painful manual one, is not a Must. It puts the safe share of Musts at no more than 60% of the effort4. Record the Won't Haves too, so nobody raises them again as new. Once each business owner has signed, changes go through change control1: their impact is understood and agreed before anyone makes them.
How it works
From workshop notes to a signed-off BRD
Download it or open it in River
Download the BRD template and the annotated CRM example free, with no account, or click Edit with AI to open both in River.
Paste your workshop notes
Optional: paste notes from workshops or interviews before you click, and River drafts each section, pointing every requirement to its source.
Settle the open points
Take every bracket and proposed priority to the client, using River's “To confirm with the client” list if it drafted the BRD.
Get it signed off
Run the eight checks under “Before you send it for sign-off,” then have the sponsor and each business owner sign their part.
- BR-05 · Must have · Finance interviewThe solution shall stop a quote over 12% discount being sent until a branch manager approves it.Accepted when: a 15% quote can't be sent before approval, and the approver's name is recorded.
- NFR-01 · Must have · Was “the system must be fast”Quote search shall take no more than 3 seconds for 95% of searches.Measured with 100 timed searches at two branches.
What you'll get
Numbered, testable requirements with MoSCoW priorities and a worked CRM example
- Eight sections, from purpose and scope to acceptance criteria and sign-off
- A rule table that turns vague requirements into testable ones
- An annotated CRM example, or a first draft from your workshop notes
Before and after
Your workshop notes in. Testable requirements out.
Workshop 1, field reps, 4 Nov. Quotes built in Excel, 'if I'm on site all day the quote waits till the evening'. Want to quote from the phone. Discounts over 12% need the manager's OK by email, sometimes sent anyway. When a rep leaves we lose their contacts. System must be fast.
P-01: Quotes wait until the rep is off site. Evidence: “if I'm on site all day the quote waits till the evening” (workshop 1, 4 Nov). BR-01: A rep shall be able to create and send a quote from a phone. Should (proposed). Serves P-01. Source: workshop 1. BR-02: The solution shall stop a quote with a discount over 12% being sent until a manager approves it. Must (proposed). Source: workshop 1. BR-03: The solution shall keep every customer contact when a rep leaves. Must (proposed). Source: workshop 1. NFR-01: Searching quotes shall take no more than [x] seconds for [95%] of attempts. To confirm with the client: How fast is fast enough?
Each requirement points to where it came from, priorities are marked proposed, and numbers your notes don't give stay in brackets.
What lands in your doc
What's inside the BRD template
- Business Requirements Document Template
Eight numbered sections with tables to fill in, each opening with a line on what belongs there. - Requirement tables with IDs and sources
Business and non-functional requirements, each row with an ID, a priority and its source or measure. - MoSCoW priorities table
What Must, Should, Could and Won't have this time mean, with a test for deciding each. - How to write a testable requirement
Seven rules, each with a weak and a testable version, plus a list of words nobody can test. - Sign-off checklist, mistakes and rules
Eight checks before sign-off, six common mistakes with their fixes, and the six rules behind the template. - Example BRD, Annotated
A complete, signed-off BRD for an invented building supplier's CRM project, with notes on why it works.
Questions consultants ask
Common questions
What is a business requirements document?
A business requirements document (BRD) sets out what a project must deliver for the business, and why, for sign-off before anything is built, configured or bought. It covers the problem and how success will be measured, who is affected and how the work runs today. Then it lists each requirement with its priority and acceptance test, in business language.
What's the difference between business and functional requirements?
Business requirements say why a change is happening and how success will be assessed, as the International Institute of Business Analysis defines them1. Functional requirements describe what the solution must do, and non-functional requirements the performance and quality it must meet. This template writes each business need as a testable “shall” statement and leaves screens and buttons to the build team or vendor.
How do you write a testable requirement?
Say who does what, under which condition, with a result someone can check. “The solution shall send reminders” can't be tested. “When a quote has had no reply for 10 working days, the solution shall remind the rep who sent it” can. If a sentence holds two requirements, split it so each one passes or fails on its own.
Can I use this as a requirements gathering template?
Yes. Take sections 2 and 3 into your workshops and interviews to record who is affected, how the work runs today and what goes wrong, with evidence. A stakeholder interview guide gives you questions for each role, and a SIPOC diagram maps the process end to end before you go into detail.
Who signs off a business requirements document?
The sponsor signs, along with a business owner for each main group affected and the IT or solution lead for the non-functional requirements. Each business owner signs only for their own area, so every requirement has a named approver. Later changes go through change control, and a change order covers any that alter your scope or fee.
Is this business requirements document template free?
Yes. Download both Word documents, the template and the annotated CRM example, free with no account. Edit with AI opens them in River, which is free to start. There you can edit the BRD, share it or ask River to change it. Paid plans add more AI use and access to the most advanced models.
What does Edit with AI do?
It opens the template in a free River workspace, with the annotated example beside it. If you paste workshop notes first, River drafts each section from them, points every requirement to its source and marks any priority it suggests as proposed. It adds no requirement your notes don't support, and lists every gap under “To confirm with the client.”
Your next step