Business requirements document (BRD) template

Published 18 October 2026

A business requirements document (BRD) says why a project is being done and what the business needs from it — the goals, the scope, who is affected and how success will be measured — before anyone decides what the software will do. The sponsor signs it, and the functional specification is written from it. Below is a free template, a filled-in example for a customer portal, and how a BRD differs from an FRD, an SRS and a PRD.

User stories in the brd? Yuck. A list of epics maybe. I always see the brd to be the 30,000 ft view document.

— r/businessanalysis, 2023

What is a business requirements document?

A BRD stays at the level of the business. It names the problem, the outcome and the boundaries; it does not design the software. Kept short, it is the page someone new can read to understand the project. One commenter thinks of it as “a simple 1-2 pager” (r/businessanalysis, 2024); another wants “a one pager that anyone coming into the project can read over in 5 min” (r/businessanalysis, 2023).

What a BRD includes

1. Summary: the project in three sentences.
2. Business objectives, each one measurable.
3. Background: how things work today, and what goes wrong.
4. Scope: what is in, and what is out.
5. Stakeholders: who asked, who decides, who is affected.
6. Business requirements: one statement each, with an ID, a priority and where it came from.
7. Success measures: how you will know, after launch, that it worked.
8. Constraints: budget, dates, regulation, systems that must stay.
9. Assumptions and dependencies.
10. Risks.
11. Open questions, each with an owner and a date.
12. Changes since the last version.
13. Sign-off.

BRD template

Copy it into Google Docs, Word or Confluence. Everything in square brackets is yours to fill in.

BUSINESS REQUIREMENTS DOCUMENT

Project:   [project name]
Version:   [x.y]
Status:    [draft / in review / signed
           off]
Author:    [name, role]
Sponsor:   [name, role]

1. SUMMARY
   [what the project is, why now, and what
   it should change, in three sentences]

2. BUSINESS OBJECTIVES
   BO-[n]:  [objective, with a number and
            a date]

3. BACKGROUND
   Today:     [how the work is done now]
   Problem:   [what goes wrong, and what
              it costs]

4. SCOPE
   In scope:      [business areas,
                  processes, users]
   Out of scope:  [what someone might
                  assume is in, but is
                  not]

5. STAKEHOLDERS
   [name, role]:  [asked for it / decides
                  / affected]

6. BUSINESS REQUIREMENTS
   BR-[n]:  [what the business needs, not
            how the software does it]
            Priority:  [must / should /
                       could]
            Source:    [who asked, where]
            Serves:    BO-[n]

7. SUCCESS MEASURES
   [measure]:  from [today's value] to
               [target] by [date]

8. CONSTRAINTS
   [budget, dates, regulation, systems
   that stay]

9. ASSUMPTIONS AND DEPENDENCIES
   [   ]

10. RISKS
   [risk]:  [what we will do about it]

11. OPEN QUESTIONS
   [question]:  [owner], by [date]

12. CHANGES SINCE THE LAST VERSION
   [x.y], [date]:  [what changed, and the
                   change request number]

13. SIGN-OFF
    (one block per person)
   Name:      [   ]
   Role:      [   ]
   Decision:  [approved / approved with
              comments / rejected]
   Version:   [x.y]
   Date:      [   ]

BRD example

Part of a BRD for a customer portal — the same project as the functional specification example:

Project:   Customer portal
Version:   1.0
Sponsor:   Finance director

2. BUSINESS OBJECTIVES
   BO-1:  Cut the calls to the service
          desk about invoices by half
          within six months of launch.
   BO-2:  Get invoices paid sooner.

4. SCOPE
   In scope:      business customers;
                  invoices, payments,
                  account details
   Out of scope:  consumer customers;
                  changes to the billing
                  system itself

6. BUSINESS REQUIREMENTS
   BR-01:  Customers can see their own
           invoices and payment status at
           any time, without calling us.
           Priority: must
           Source: service desk
           Serves:   BO-1
   BR-03:  Shorten the time invoices stay
           unpaid.
           Priority: must
           Source: finance director
           Serves:   BO-2

7. SUCCESS MEASURES
   Invoice calls to the service desk:
       from 900 a month to 450 by
       month six
   Average days from invoice to payment:
       from 41 to 30 by month six

Business requirements vs functional requirements

A business requirement stays true whatever the software looks like. A functional requirement is one way the software meets it — and one business requirement often needs several:

If a requirement names a screen, a button or a field, it is functional and belongs one level down. If it would still be true after a redesign, it belongs in the BRD. The other types — user requirements, business rules, constraints and more — are in types of requirements.

BRD vs FRD vs SRS vs PRD

The names overlap from one company to the next. On a client project the BRD comes first, then a functional specification or an SRS, with each requirement traced back to the business requirement it answers. A product team may write a PRD instead. Some teams write a vision and scope document in place of a BRD: the same business requirements, with a vision statement and the scope split by release.

How to write a BRD

1. Start from the problem, with the sponsor. What goes wrong today, what it costs, and what would count as fixed. A discovery phase is where most of this comes from.
2. Write objectives you can measure. Even when the CEO asked for the project, write down what it must achieve: “This will help you measure whether you have succeeded or failed” (r/businessanalysis, 2021).
3. Write what is out of scope as carefully as what is in. “Make sure to add in the scope section: what is not in scope” (r/businessanalysis).
4. Keep each requirement at the level of the business, with an ID, a priority and its source, so the functional requirements can point back to it. For the priority, one way is MoSCoW.
5. Keep it short. Detail belongs in the functional specification.
6. Review it with the people affected — the requirements review checklist has the checks — then get it signed on one version: the requirements sign-off template works for a BRD too.
7. After sign-off, change it only through a change request — with a new version, and the old one kept.

Do you need a BRD in agile?

Opinions split. One commenter: “First step is to realise it’s not 2003 and BRD’s are useless” (r/businessanalysis, 2024). Others keep one because the backlog tool is not where the business reads:

Office is the only format that stakeholders outside of a development team understand and will interact with. Jira is an internal tool - a great one for software development. But it is not a general business tool.

— r/businessanalysis, 2021

In a product team with the product owner in the room, a short brief and the backlog can do the job. On a client project with a budget to agree, the business-level agreement still has to be written down and signed — whether it is called a BRD, a project brief or the first part of the statement of work.

Keeping the BRD and the backlog in step

The trouble starts when the same requirements live in the BRD and in Jira. One post listed the process its author follows:

1. Create requirements in Jira.
2. Copy them into the BRD.
3. Get them reviewed by subject-matter experts.
4. Update the BRD from their feedback.
5. Update Jira to match the BRD.
6. Send the BRD to the development team and the other teams.
7. Update the BRD from their feedback.
8. Update Jira to match again.

The annoying parts are steps 5, 7, 8.

And it is not just about updating manually, but also that I may miss out updating JIRA if there are many requirements.

— r/businessanalysis, 2021

A reply: “Do a traditional BRD first to share outside the team, then when its signed off, copy/paste it into Jira and deliver” (r/businessanalysis). That keeps one copy at a time — until the first change after sign-off. From then on, give every story the ID of the business requirement it serves, and change the BRD only through change requests, so the two can be compared instead of re-typed.

Where Specroot fits

This is the problem Specroot works on: business requirements, the functional requirements and the work built from them, kept as one versioned set — instead of a signed document and a backlog kept in step by hand. Specroot for agencies and consultancies.