How to Write a Business Requirements Document (BRD)

TL;DR

• A BRD's core job is capturing the business need accurately — start with stakeholder analysis and elicitation, not a blank template.
• Trace every requirement back to a specific business objective, so nothing is included without a clear reason.
• Get formal sign-off from key stakeholders before the BRD is used as the basis for design or development.

For a business analyst, writing a business requirements document (BRD) is a structured process, not just filling in a template — it starts with understanding who the real stakeholders are, systematically eliciting their needs, and documenting the business case in a way that can be traced through to the eventual solution. This guide covers the full BA process, from stakeholder analysis through formal sign-off.

Quick facts

• A BRD should capture business needs and objectives, not solution design — that level of detail belongs in functional requirements or user stories.
• Requirements traceability (linking each requirement back to a business objective) is a core BA discipline that distinguishes a rigorous BRD from an informal one.
• For a lighter-weight version aimed at product teams, see How to Write a BRD.

How to write a BRD, the full business analyst process

1. Conduct stakeholder analysis first. Identify everyone affected by or with authority over the project — including less obvious stakeholders like compliance, operations, or support teams who are often overlooked but can materially affect requirements.
2. Elicit requirements systematically, using interviews, workshops, document analysis, and observation as appropriate. Relying on a single method or a single stakeholder's perspective risks missing important context or conflicting needs. See How to Run a Requirements Gathering Workshop.
3. Document the business objectives clearly and specifically, including how success will be measured. A BRD without a measurable objective can't later be evaluated for whether the project actually achieved its intended business outcome.
4. Map the current state before defining the desired future state. Understanding how the process or system currently works — including its specific pain points — grounds the requirements in real, evidenced need rather than assumption. Process mapping is a core tool here.
5. Write each business requirement so it traces back to a specific objective. This traceability is a defining BA discipline — every requirement should have a clear "why," and any requirement that can't be traced to an objective deserves scrutiny before inclusion.
6. Document assumptions, constraints, and dependencies explicitly. These materially affect what's realistically achievable and are often the source of later disputes if left unstated.
7. Define scope precisely, including what's explicitly excluded. Ambiguous scope is one of the most common sources of later conflict between stakeholders and the delivery team.
8. Circulate the draft for stakeholder review and formal sign-off. A BRD isn't complete until the key stakeholders have reviewed and explicitly agreed to it — this sign-off is what gives the document authority as the basis for subsequent design and development work.
9. Maintain the BRD as a living reference, with version control. If the business objective or key requirements change materially during the project, the BRD should be formally updated and re-approved, not silently diverge from what was actually agreed.

Why requirements traceability matters so much

A BRD without traceability can accumulate requirements that don't actually serve the stated business objective — sometimes added by a vocal stakeholder or carried over from habit. Explicitly tracing each requirement back to a specific objective forces a disciplined check: does this requirement genuinely support what we're trying to achieve? This traceability also becomes valuable later, during scope discussions or change requests, since it's much easier to evaluate a proposed change against a documented objective than against a vague, unstructured wish list.

A worked example

Business objective: "Reduce average customer support resolution time from 48 hours to 24 hours."

Requirements traced to this objective:

• "The system must display a customer's full account history on a single screen, so support reps don't need to search multiple systems." (Traces to reducing resolution time by cutting research time.)
• "The system must allow support reps to escalate a ticket to a specialist team with one click." (Traces to reducing time lost in manual handoffs.)

A requirement like "add a dark mode to the support dashboard" would clearly not trace back to this objective — flagging it during review prevents scope creep unrelated to the actual business goal.

Common mistakes when writing a BRD

• Skipping formal stakeholder sign-off, leaving the BRD without real authority when disagreements arise later in the project.
• Writing requirements that don't trace back to a specific business objective, allowing scope to drift from what the project was actually meant to achieve.
• Relying on a single elicitation method or stakeholder, missing perspectives that a broader elicitation process would have surfaced.
• Treating the BRD as a static document, not updating it when the business context or objectives shift meaningfully during the project.

FAQ

How is a BRD different from a functional requirements document? A BRD captures the business need and objective at a relatively high level; a functional requirements document specifies in detail what the system must do to satisfy those business requirements — the BRD typically comes first and the functional document is derived from it.

Who needs to sign off on a BRD? Typically the key business stakeholders and sponsor of the project — the specific list depends on the organization, but sign-off should come from whoever has the authority to confirm the documented business need and objective are accurate.

How does requirements traceability work in practice? Each requirement is typically tagged or numbered with a reference back to the specific business objective it supports, often maintained in a traceability matrix that's especially valuable in regulated or audit-sensitive environments.

What happens if requirements change after the BRD is approved? A formal change request process should be used — proposed changes are evaluated against the documented objectives and scope, and the BRD is updated and re-approved if the change is accepted, rather than informally modifying the agreed scope.