For consultants on IT, ERP and CRM projects
Business Requirements Document Template
Eight sections from purpose and scope to sign-off, with numbered, testable requirements, MoSCoW priorities, a bad-versus-good rule table and an annotated CRM example.
- 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. BR-02: The solution shall stop a quote with a discount over 12% being sent until a manager approves it. Must (proposed). BR-03: A manager shall be able to move all of a leaving rep's accounts, with their history, to another rep. Must (proposed). 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.
Why it works
What goes in a business requirements document?
A business requirements document template sets out what a project must deliver for the business, in terms the business can sign off before anyone builds, configures or buys a system. The IIBA's BABOK Guide defines a business requirement as goals, objectives and outcomes that “describe why a change has been initiated and how success will be assessed.” This BRD template has eight sections for IT, ERP and CRM projects, from purpose and scope to acceptance criteria and sign-off.
The heart of a BRD is the numbered list of business requirements. Each is one testable statement with a MoSCoW priority: must, should, could or won't have this time. The Agile Business Consortium says Must Haves should not exceed 60% of the effort. A rule table puts weak and testable versions side by side, following NASA's guidance to avoid words like “fast” and “user-friendly” that nobody can test. Every Must Have then gets an acceptance test.
The second doc is an annotated example: an invented building supplies firm moving 50 sales staff from spreadsheets onto a CRM, with a note on why each section works. Download both as Word files with no account. Or use it as a requirements gathering template: paste your workshop notes, and River drafts numbered requirements that each point to their source, with proposed priorities and open questions listed. Record each workshop with the meeting minutes template, find themes across interviews with interview synthesis, and watch the work itself with a process observation study.
What lands in your doc
What's inside the BRD template
- Purpose, scope and success measures
The business problem, measures with today's figure and a target, and what is in and out of scope. - Stakeholders and the current process
Each group with a named contact, how the work is done today, and pain points with their evidence. - Numbered business requirements
One testable statement per row, with a MoSCoW priority, the pain point it serves and where it came from. - A testable requirement rule table
Seven rules with weak and testable versions side by side, plus the words nobody can test. - Non-functional requirements to sign-off
Performance, access, data and integration with measures, then assumptions, constraints, acceptance tests and a sign-off table. - An annotated CRM example
A complete BRD for an invented building supplies firm moving its sales team onto a CRM, with notes on why each section works.
How it works
From workshop notes to a signed-off BRD
Open the template
Click Edit with AI. The BRD opens in River with the annotated CRM example beside it.
Paste your workshop notes
Optional. Paste notes from a workshop or interview, and River drafts numbered, testable requirements with their sources.
Confirm with the client
Proposed priorities and missing numbers are listed as questions, ready for your next workshop.
Get it signed off
Run the checklist, then have the sponsor and each business owner sign for their own area.
Questions consultants ask
Common questions
What is a business requirements document?
A business requirements document (BRD) is a written agreement of what a project must deliver for the business. It says why the project is happening, who it affects, what the business needs and how everyone will know it is done. It is written in business language and signed off before a system is built, configured or bought.
What's the difference between business and functional requirements?
In BABOK terms, business requirements say why a change is happening and how success is judged, while functional requirements describe what the solution must do. Many consulting BRDs, this one included, write the business needs as testable “shall” statements and leave screen-level detail to the build team or the vendor's specification.
How do you write a testable requirement?
Write one statement with one subject, say who does what under which condition, and use numbers instead of adjectives. “The system shall be fast” can't be tested. “Quote search shall take no more than 3 seconds for 95% of searches” can. If you can't say how you would check a requirement, it isn't finished.
What is MoSCoW prioritization?
MoSCoW sorts requirements into Must have, Should have, Could have and Won't have this time. A Must is something go-live can't happen without. The Agile Business Consortium, which maintains the method, advises keeping Musts to no more than 60% of the effort, so Shoulds and Coulds can be dropped if time runs short.
Can I use this as a requirements gathering template?
Yes. Run your workshops against sections 2 and 3 to capture who is affected, how the work happens today and what goes wrong. To map the process at a high level first, from suppliers to customers, use the SIPOC diagram template. Then paste your notes, and River turns each need into a numbered requirement.
Who signs off a BRD?
The sponsor, a business owner for each main group affected, and usually the IT or solution lead for the non-functional requirements. Each signs for their own area. After sign-off, changes go through change control with their effect on cost and dates, the same way a statement of work handles changes in scope.
Does River write the requirements for me?
Only a first draft, and only from the notes you paste. Each requirement points to where it came from, priorities are marked as proposed, and numbers your notes don't give stay in brackets. River never adds a requirement your notes don't support. You and the client decide what goes in and how each one ranks.
Your next step
More for your project
Get the requirements signed before anyone builds
Open the BRD with an annotated CRM example beside it, or paste your workshop notes for a first draft with every requirement sourced.