How to Write a Business Requirements Document

Contents hide

1 Start with what you already know, not a blank page

2 The sections every BRD needs

3 Writing business requirements that actually work

4 A worked example: government asset management system

5 Common mistakes that weaken a BRD

6 Getting sign-off without a drawn-out review cycle

7 Frequently asked questions

8 Try Ash, Your Virtual BA

9 Further reading

Start with what you already know, not a blank page

If you have been asked to produce a BRD and you are staring at an empty document, the fastest way forward is to stop thinking of it as a document and start thinking of it as a structured argument. You are making the case that a specific problem exists, that it matters, and that a particular set of requirements will solve it. Every section of a BRD exists to support that argument.

Before you write a single heading, gather your inputs: the project initiation document or brief, any existing process maps, prior incident logs, the sponsor’s original problem statement, and whatever stakeholder notes you already have. If you are still at the point of gathering those inputs, the article on how to document your findings at the start of a business analysis project is worth reading first. Once you have your raw material, you can write the BRD in the sequence below.

The sections every BRD needs

The structure below is the one I use across most of my projects. The labels and order vary slightly depending on the organisation and methodology, but the substance is consistent whether I am working on a waterfall infrastructure project or a hybrid agile delivery.

Document control and version history. This records who owns the document, who has approved each version, and when it was last changed. It sounds administrative but it protects you when stakeholders claim they never agreed to something.
Executive summary. Two or three paragraphs that explain the problem, the proposed solution, and the expected benefit. Write this last, even though it appears first.
Project background and business context. The conditions that made this project necessary. Reference any strategic drivers, regulatory obligations, or operational failures that triggered the work.
Problem statement. A single, clear statement of what is broken, missing, or causing harm. Avoid vague language like “improve efficiency.” Say what is failing and what the impact is.
Scope. What is in scope, what is explicitly out of scope, and where the boundaries sit. This section prevents more arguments than any other part of the document.
Stakeholders. Who is affected, who has decision-making authority, and who will sign off. A stakeholder table is the clearest way to capture this. Link to your full stakeholder analysis if you have one.
Assumptions and constraints. What you are taking as given without proof, and what limits your options. Budget ceilings, technology standards, regulatory requirements, and timelines all belong here.
Business requirements. The core of the document. Each requirement states what the business needs to achieve, not how the solution should work. Use a consistent format: a unique ID, a plain-language statement, a priority, and a rationale.
Non-functional requirements. Performance, availability, security, scalability, and compliance needs. These are easy to skip and expensive to discover late.
Dependencies and interfaces. Systems, teams, or external parties that the solution must connect with or rely on.
Acceptance criteria. How you will know the requirements have been met. Write these before development starts, not after.
Approval and sign-off. Named individuals, their roles, and a signature or date-stamped approval mechanism.

Writing business requirements that actually work

Most weak BRDs fail at the requirements section itself. The requirements are either too vague to test, too prescriptive about the solution, or mixed up with functional specifications. Here is the distinction that matters in practice.

Type	What it describes	Example
Business requirement	What the business needs to achieve	The organisation must be able to record condition data for all physical assets from a single system.
Functional requirement	What the system must do to meet that need	The system must allow users to enter a condition score, date, and inspector name against any asset record.
Non-functional requirement	How the system must perform	The system must be available 98% of the time between 8am and 6pm on weekdays.
Solution assumption	A decision already made about how to meet the need	The solution will be a web-based asset management platform integrated with the existing financial system.

If you want to go deeper on the distinction between business and functional requirements, the article on BRD vs FRD covers it in detail. For now, the test I apply to every requirement I write is simple: does this statement tell the reader what the business needs, or does it tell the developer what to build? If it is the latter, it belongs in the FRD, not the BRD.

Format each requirement with a unique ID (BR-001, BR-002 etc.), a priority (Must Have, Should Have, Could Have, Won’t Have this time), and a brief rationale. The rationale is the one thing most people skip and the one thing that saves hours of argument in review sessions.

A worked example: government asset management system

I worked on a project for Organisation A, a government department managing over a dozen physical asset groups including monitoring networks, drainage schemes, and field equipment spread across multiple regional sites. Asset data was being maintained in dozens of separate spreadsheets with no single source of truth, and the finance team could not produce accurate depreciation figures at year end because the asset register and the financial system had no connection.

The project brief called for a new integrated asset management information system. My job was to write the BRD. The problem statement I drafted was: “Organisation A cannot produce accurate, timely, or consistent asset data across its business units because asset information is held in disconnected spreadsheets and manual registers. This creates financial reporting errors, prevents effective maintenance planning, and exposes the organisation to compliance risk.”

The scope section was where the first serious friction appeared. The infrastructure team wanted the BRD to include a requirement for real-time public query functionality, so that members of the public could report faults or check asset status. The project sponsor had explicitly excluded this from scope in the original brief. When I raised this with the infrastructure lead, he pushed back firmly, arguing that the exclusion had been a mistake and that the system was incomplete without it. I held the scope boundary and documented his objection in the assumptions and constraints section as a deferred requirement, flagged for a future phase. That note later became the basis for a separate project.

The business requirements I produced for the core asset register module included requirements like:

BR-004: Organisation A must be able to record primary attributes for each asset, including type, material, dimensions, quantity, and construction date, in a single consolidated system. Priority: Must Have. Rationale: Current data fragmentation prevents reliable financial reporting and lifecycle planning.

BR-012: Organisation A must be able to produce financial asset reports from the same system used to maintain the physical asset register, without manual data re-entry. Priority: Must Have. Rationale: Current manual reconciliation between asset spreadsheets and the financial system causes year-end reporting errors.

The non-functional requirements section drew directly from the technical constraints the organisation’s ICT team provided, including availability targets (98% during business hours), integration requirements with the existing financial management system, and support for field staff using handheld devices in areas without reliable connectivity. These constraints shaped the solution options significantly and would have been missed entirely if I had stopped after writing the functional requirements.

Common mistakes that weaken a BRD

Writing requirements as solutions. “The system shall have a dropdown menu for asset type” is a design decision, not a business requirement. Keep the what separate from the how.
Skipping the rationale. Without a rationale, every requirement looks equally optional to a developer or project manager trying to cut scope under budget pressure.
Leaving assumptions implicit. If you assume the solution will integrate with an existing system, write it down. Unwritten assumptions become disputed facts six months later.
Getting sign-off too late. Circulate a draft for review before it is polished. Stakeholders who feel consulted during drafting cause fewer problems at formal sign-off.
Mixing business and functional requirements. It confuses developers, creates traceability problems, and makes the document harder to maintain as the project evolves.

Getting sign-off without a drawn-out review cycle

Send the draft BRD to stakeholders with a clear cover note that identifies the three or four decisions you most need them to confirm, rather than asking them to review the whole document. Most stakeholders will not read 30 pages carefully, but they will respond to a targeted question. Ask them specifically to confirm the problem statement, the scope boundary, and the Must Have requirements. Once those three things are agreed, everything else can move.

If you do not have a template to work from, the BRD template in Word format on this site gives you a ready-made structure you can populate directly from the steps in this article.

Writing a BRD from scratch is genuinely straightforward once you accept that your job is not to produce a perfect document but to capture a shared understanding in a form that can be tested, traced, and approved. The friction you encounter along the way, whether that is a stakeholder pushing to expand scope, a sponsor who changes the problem statement after week two, or an ICT team that adds technical constraints at the last minute, is not a sign that something has gone wrong. It is the work. Document it, resolve it, and move forward.

Frequently asked questions

What should be included in a business requirements document?

A BRD should include a project background, problem statement, scope, stakeholder list, assumptions and constraints, business requirements, non-functional requirements, dependencies, acceptance criteria, and a sign-off section. Each business requirement should have a unique ID, a plain-language statement, a priority, and a rationale. The level of detail varies by project but those core sections are consistent across most methodologies.

What is the difference between a business requirements document and a functional requirements document?

A BRD describes what the business needs to achieve, while an FRD describes what the system must do to meet those needs. Business requirements focus on outcomes and problems to solve, whereas functional requirements specify system behaviours and features. In practice the two documents are often produced in sequence, with the FRD derived from the BRD.

How long should a business requirements document be?

There is no fixed length, but most BRDs for mid-sized projects run between 10 and 30 pages. The right length is whatever it takes to clearly document the problem, scope, requirements, and acceptance criteria without padding. A shorter, well-structured BRD is almost always more useful than a longer, poorly organised one.

How do you write business requirements that are clear and testable?

Write each requirement as a statement of what the business must be able to do, not how the system should do it, and pair it with an acceptance criterion that describes how you will verify it has been met. Avoid vague words like improve, enhance, or support without specifying what success looks like. Using a consistent format with a unique ID, priority, and rationale for every requirement makes them significantly easier to test and trace.

Who approves a business requirements document?

The project sponsor or business owner typically holds final approval authority for a BRD. Key stakeholders including the project manager, lead subject matter experts, and sometimes the solution architect or IT lead are usually required to review and confirm their sections before formal sign-off. Capturing named approvers and their sign-off dates in the document itself is important for governance and change control.

Try Ash, Your Virtual BA

If you have read through this guide and you are ready to start drafting, Ash can help you build your BRD section by section right now. Ash is a virtual BA assistant trained on real business analysis practice, and it can walk you through each part of the document, prompt you for the right information, and help you write requirements that are clear, testable, and properly structured. You do not need a template and you do not need to start from scratch on your own. Try Ash Virtual BA and have your first draft ready faster than you think.