How to Write a Business Requirements Document (BRD)

A practical step-by-step guide to writing BRDs that get approved, get built, and actually reflect what the business needs — with a full template and quality checklist.

What Is a Business Requirements Document?

A Business Requirements Document (BRD) is a formal artefact that describes what a proposed solution must do in order to meet business objectives. It defines the problem being solved, the stakeholders affected, the constraints that apply, and the specific requirements the solution must satisfy — without prescribing how those requirements are implemented.

The BRD is one of the foundational outputs of business analysis in project-based delivery environments. It bridges the gap between business strategy (why are we doing this?) and solution delivery (what does it need to do?). A well-written BRD reduces ambiguity, manages stakeholder expectations, provides a baseline for scope management, and gives developers and testers a clear target.

A poorly written BRD — vague, incomplete, or internally inconsistent — is one of the most expensive documents in corporate IT. It generates rework, delays, cost overruns, and stakeholder conflict. Learning to write a high-quality BRD is a core business analyst skill that directly affects project outcomes.

BRD vs FRD vs User Stories: What’s the Difference?

Requirements are captured in different formats depending on the delivery methodology, the complexity of the solution, and the organisation’s governance model. Understanding which artefact is appropriate — and when — is a key part of the BA’s role.

In practice, these artefacts often appear in combination. A programme-level BRD might feed into project-level user stories. A large waterfall project might use a BRD for business requirements and an FRD for the technical specification. The BA’s job is to choose the right artefact for the right audience — and to write it at the right level of detail for the stage the project is at.

BRD Structure: Section by Section

A professional BRD follows a consistent structure that allows stakeholders and reviewers to find information quickly and assess completeness. The following table shows the standard sections, what each contains, and its purpose in the document.

Step-by-Step: How to Write a BRD

Writing a BRD is not a solo desk exercise — it’s the output of a structured elicitation and analysis process. Here’s how to approach it from blank page to stakeholder sign-off.

Step 1: Understand the Business Problem Before Writing Anything

The single most common BRD failure mode is writing requirements before fully understanding the problem. BAs who jump straight to requirements are really just documenting assumptions. Before opening a document template, conduct at minimum: a project kick-off session with the sponsor, interviews with 3–5 representative users, a review of existing process documentation, and a current state process walkthrough.

The output of this discovery phase should be a clear problem statement that the project sponsor agrees with. If you can’t get sign-off on the problem statement, your requirements will be contested from the start. See our guide to requirements gathering techniques for structured approaches to discovery.

Step 2: Define and Agree Scope Before Writing Requirements

Scope is arguably the most important section of the BRD, because it determines what you’re not going to document. A scope statement should include both in-scope and out-of-scope elements. The out-of-scope list is often more valuable — it explicitly closes the door on requirements that stakeholders might otherwise try to include later.

Step 3: Identify and Register All Stakeholders

A requirement missed because a stakeholder wasn’t consulted will surface during UAT or post-go-live — both expensive moments to discover omissions. Build a stakeholder register early and keep it current. For each stakeholder, record: their role, their level of influence over the project, their primary concern, and the format and frequency of engagement they need.

Step 4: Write Requirements to a Consistent Standard

Each business requirement in the BRD should follow a consistent format and meet a quality standard before it’s included in the document. The most widely used quality framework for requirements is the SMART criteria:

• Specific — the requirement states precisely what must be true or what the system must do
• Measurable — there is a way to verify whether the requirement has been met
• Achievable — the requirement is technically and organisationally feasible
• Relevant — the requirement is directly linked to the business objective or problem
• Testable — an acceptance test can be written that will definitively confirm compliance

Step 5: Review and Quality-Check Every Requirement

Before sending a BRD for stakeholder review, conduct a quality review against the checklist below. Requirements that fail this checklist should be revised before circulation — not after.

Business Requirements Quality Checklist

Common BRD Mistakes Business Analysts Make

Even experienced BAs make these mistakes. Recognising them is the first step to producing higher-quality documentation.

• Writing requirements as solutions — ‘The system shall display a dropdown menu for status selection’ is a design decision masquerading as a business requirement. The requirement is ‘The user shall be able to filter work items by status.’ Let designers and developers determine the implementation.
• Compound requirements — ‘The system shall allow users to create and edit and delete records’ is three requirements, not one. Split them. This matters because each requirement needs its own priority, its own acceptance criteria, and its own test case.
• Passive voice that obscures responsibility — ‘Notifications shall be sent’ doesn’t say who sends them, to whom, when, or by what mechanism. Rewrite: ‘The system shall send an email notification to the assigned case manager when a new case is created.’
• Requirements that can’t be tested — ‘The system shall be user-friendly’ cannot be tested. ‘The checkout process shall be completable in 5 steps or fewer’ can be. Every requirement must be testable.
• Scope creep via requirements — requirements added late in the analysis process, often from stakeholders who weren’t engaged early, frequently push scope beyond what was agreed. Every requirement must trace back to a documented business objective or it should be deferred.
• No version control — a BRD without version history becomes a liability when stakeholders dispute what was agreed. Use document management software with version tracking, or at minimum maintain a change log at the front of the document.

Stakeholder Sign-Off: Getting Your BRD Approved

A BRD that doesn’t achieve formal stakeholder sign-off is a risk management problem. Without sign-off, stakeholders can — and often do — dispute what was agreed when delivered functionality doesn’t match their mental model.

Effective BRD sign-off follows a structured process:

1. Circulate for review with a two-week review window — give stakeholders enough time to read the document; rushing review leads to rubber-stamping
2. Conduct a walkthrough session — don’t rely on stakeholders to read documents independently; walk them through the key sections, especially scope and requirements
3. Capture and resolve all feedback — log every comment, decide whether to accept/reject/defer each one, and document the decision with rationale
4. Produce a revised version — incorporate accepted changes and circulate for final review
5. Obtain formal sign-off — a written sign-off (email confirmation is sufficient) that the signatory has reviewed and approved the document
6. Baseline the document — after sign-off, the BRD is baselined; any subsequent changes go through change control

The sign-off process also reveals which stakeholders are genuinely engaged versus those who are attending meetings but not processing information. A stakeholder who won’t commit to sign-off is signalling something — either they have unresolved concerns, or they’re not the right decision-maker and you need to escalate.

BRD in Agile Environments

Many organisations are moving away from traditional BRDs toward lighter-weight agile artefacts. This doesn’t mean BRDs are obsolete — it means their form has evolved. In hybrid and agile environments, you’ll often see:

• A lightweight ‘project brief’ or ‘problem statement’ replacing the full BRD for smaller initiatives
• A programme-level BRD providing strategic requirements, feeding into sprint-level user stories for delivery
• An ‘agile BRD’ — a shorter document focused on scope, stakeholders, and principles rather than detailed requirements
• Requirements captured directly in the product backlog with the BRD serving as a reference document rather than the primary requirements source

The agile BA who can adapt requirements documentation to fit both governance needs and agile delivery rhythms is significantly more valuable than one who insists on waterfall documentation in agile teams, or who abandons documentation discipline entirely in the name of agility. The discipline of clear, testable, traceable requirements remains as important in agile delivery as in waterfall — the format and timing just change.

Frequently Asked Questions: Business Requirements Documents

For related reading, explore our guides on requirements gathering techniques, business analysis techniques, and free business analysis templates. If you’re new to the field, our free business analyst training provides a solid foundation before tackling complex documentation like the BRD.