Business Requirements Document (BRD) Template and Example

October 22, 2026 · 6 min read

A business requirements document (BRD) records why a project exists and what the business needs from it, before anyone decides how to build it. It is written for the people who fund and approve the work, and it is the reference when someone later asks why a feature is there.

This page gives you a template to copy, explains what each section must answer, and shows a short example.

What a BRD covers

A BRD answers four questions: what business problem are we solving, what outcome do we want, what is in and out of scope, and what must be true for the project to count as a success. It stays at the level of business needs. Screens, data models and technology choices belong in later documents.

It sits next to two other documents that are often confused with it:

• A BRD states business needs and objectives.
• A PRD describes the product's behaviour for the team that builds it.
• An SRS is a detailed technical specification. See the software requirements document template.

Small projects often need only one of them. Larger or regulated ones keep the layers separate so that approvers and engineers each read what they need.

The BRD template

Copy this and fill it in. Remove sections that do not apply, but note why they were removed.

1. Document control
   Version, date, author, approvers, status.

2. Executive summary
   One paragraph: the problem, the proposed outcome, the expected value.

3. Business problem and opportunity
   Current situation, who is affected, cost of doing nothing.

4. Objectives and success criteria
   Objective | Measure | Baseline | Target | Review date

5. Scope
   In scope / Out of scope.

6. Stakeholders
   Name or role | Interest in the project | Influence | Approval needed?

7. Business requirements
   ID | Requirement | Priority | Rationale / source

8. Assumptions and constraints
   Budget, deadlines, regulations, existing systems, dependencies.

9. Risks and open questions
   Risk | Likelihood | Impact | Mitigation | Owner

10. Cost and benefit overview
    Rough investment, expected benefit, and how confident you are in both.

11. Approval
    Who signs off, what they are signing, and when.

How to fill in each section

Executive summary and business problem

Write the summary after the rest. It is the only part some approvers will read, so it must stand on its own: the problem, the proposed outcome and why it matters now.

In the problem section, describe the situation without proposing a solution. "Orders are re-entered by hand into two systems, which causes errors and delays" is a problem. "We need an integration" is a solution wearing a problem's clothes.

Objectives and success criteria

An objective states a business result. Pair every objective with a measure, a baseline and a target, and say when it will be reviewed. If you do not have a baseline yet, make collecting it an early task instead of guessing.

Be honest about what you can influence. A project can reduce manual re-entry; it may not control whether sales go up.

Scope

List what is in, and be equally explicit about what is out. Out-of-scope items are not an insult to anyone's idea; they are how you stop a project from quietly doubling in size.

If you are using this BRD as an input to a statement of work, the scope section is the part that will be carried over almost directly. The guide to how to scope a software project covers that step.

Stakeholders

Name the people or roles who care about the outcome, what they care about, and who must approve. Missing a stakeholder is a common reason for late changes: someone appears in month three with a requirement that was always theirs.

Business requirements

Write requirements as needs, not features: "Finance can reconcile a customer's invoices against payments without exporting data" rather than "add an export button". Give each one an ID, a priority and a source, meaning who said it or which document it comes from. The source matters later, when two requirements conflict and you need to know who to ask.

Assumptions, constraints, risks

Constraints are fixed facts: a deadline tied to an event, a regulation, a system you cannot change. Assumptions are beliefs you have not confirmed. Keep them in separate lists, because an assumption that turns out false changes the plan, while a constraint never does.

For every risk, name an owner. A risk without an owner is a worry, not a plan.

Cost and benefit overview

Give a rough figure and say how rough it is. A range with its assumptions is more useful than a precise-looking number with none. If an estimate is a rule of thumb, say so.

A short filled-in example

The example is invented and abbreviated.

Executive summary
Wholesale customers currently request order status and invoice copies by
email. A customer portal would let them look this up themselves and free the
support team for other work.

Objectives
O1. Reduce support contacts about order status and invoice copies.
    Measure: share of tickets in these two categories. Baseline: to be taken
    from the last three months of tickets. Target: agreed with the support lead.

Scope
In: order status, invoice download, sign-in for existing customers.
Out: ordering, payment, address changes.

Business requirements
BR-1 | Customers can see the status of their orders | Must |
       Source: support lead interview
BR-2 | Customers can download invoices | Should |
       Source: finance team request

Constraints
Order data lives in the existing ERP and cannot be changed during this project.

Open questions
Which system is the source of truth for order status? Owner: operations lead.

Common mistakes

• Writing the solution into the problem. Approvers then approve a feature, not a need.
• Objectives without measures. "Improve customer experience" cannot be checked.
• No out-of-scope list. Expectations expand to fill the silence.
• Requirements with no source. When they conflict, nobody knows whom to ask.
• A document that stops at approval. Update it when a decision changes, or it quietly becomes fiction.

Getting from raw material to a first draft

Most of the information for a BRD already exists in kickoff decks, emails, interview notes and call transcripts. The slow work is pulling it into one structure. Discovery Phase AI reads such files and drafts the discovery stages for you to correct, and you can look at a finished example in the example report, built from an invented project. If you are earlier in the process, the discovery phase checklist lists what to collect first.

Whatever you use to write it, keep the BRD short, tie every requirement to a business objective, and keep it current.