Business Requirements Document (BRD)
A BRD structure that survives delivery — measurable objectives, atomic testable requirements, and an out-of-scope section that prevents arguments later.
No sign-up. No email. Markdown — edit it in anything.
When to use it
Before design or build starts, once a sponsor and a measurable objective exist.
Who fills it in
Business analyst, with a named decision-maker per area.
Works alongside: Project Plan · Test Plan
The template
Instruction lines are marked with > — delete them
once the document is filled in.
Project: _______________ Version: 0.1 Date: _______________ Author: _______________ Sponsor (decision-maker): _______________ Status: Draft / In review / Baselined
Delete every instruction line (marked
>) before circulating. If a section does not apply, write "Not applicable" and why — do not delete it.
1. Purpose and background#
One page. What changed to make this worth doing now? Why not do nothing?
The situation today:
What triggered this:
Why now:
2. Business objectives#
Measurable, or it is not an objective. "Improve efficiency" is not measurable. "Reduce claim processing from 6 days to 2" is.
| # | Objective | Current | Target | How measured | Owner |
|---|---|---|---|---|---|
| O1 | |||||
| O2 |
3. Scope#
In scope -
Out of scope
This list prevents more arguments than the in-scope list. Be specific.
-
Deferred (agreed, but not now)
| Item | Why deferred | Revisit when |
|---|---|---|
4. Stakeholders#
| Name / role | Area | Consulted or Decides | Contact |
|---|---|---|---|
| Decides | |||
| Consulted |
Exactly one decision-maker per area. If two people decide, nobody does.
5. Current state#
How it works today:
Known workarounds:
The spreadsheet someone maintains on the side is a requirement nobody wrote down. List them.
Pain points, with evidence:
6. Business requirements#
Numbered permanently — never renumber. Withdrawn requirements are marked withdrawn, not deleted; downstream documents reference these numbers. One need per requirement. Anything containing "and" or "or" usually needs splitting.
BR-001 — [short name]#
| Priority | Must / Should / Could / Won't |
| Need | What the business must be able to do. Describe the outcome, not the screen. |
| Rationale | Why. This survives the person who wrote it. |
| Acceptance criteria | How we will prove it was delivered. If you cannot write the test, the requirement is not specific enough yet. |
| Source | Who asked, and when. |
| Depends on |
BR-002 — [short name]#
| Priority | |
| Need | |
| Rationale | |
| Acceptance criteria | |
| Source | |
| Depends on |
Copy the block as needed.
7. Non-functional requirements#
These surface late and are expensive to retrofit. Fill them in now.
| Area | Requirement | How measured |
|---|---|---|
| Performance | ||
| Availability | ||
| Capacity / volume | ||
| Security | ||
| Accessibility | ||
| Data retention | ||
| Auditability | ||
| Supportability |
8. Business rules#
Constraints that hold regardless of implementation. e.g. "A claim over 50,000 requires two approvers."
| # | Rule | Source | Applies to |
|---|---|---|---|
| BizR-1 |
9. Assumptions and dependencies#
| # | Assumption | If it turns out false | Owner |
|---|---|---|---|
| A1 |
| # | Dependency | On whom | Needed by |
|---|---|---|---|
| D1 |
10. Constraints#
| Type | Constraint | Imposed by |
|---|---|---|
| Regulatory | ||
| Budget | ||
| Timeline | ||
| Technology |
11. Success criteria and acceptance#
Agree this BEFORE build. Sign-off is judged against this section.
This is successful when:
Acceptance process:
Who signs off:
12. Risks#
| # | Risk | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|---|
| R1 | H/M/L | H/M/L |
A risk without an owner is a worry, not a risk.
13. Glossary#
Every term two departments define differently. Often the most valuable page here.
| Term | Definition | Agreed by |
|---|---|---|
14. Approval#
| Name | Role | Decision | Date |
|---|---|---|---|
| Approved / Rejected |
"No response by Friday means approved" produces approvals that evaporate the moment something goes wrong. Get an explicit yes.
Change log#
| Version | Date | Change | Author |
|---|---|---|---|
| 0.1 | Initial draft |
Standards this is based on#
Checked 2026-08-04.
| Reference | Status |
|---|---|
| ISO/IEC/IEEE 29148:2018 | Current (confirmed 2024; a revision is in development). Source of the requirement characteristics below |
| BABOK v3 | Business analysis body of knowledge |
| ISO/IEC/IEEE 12207 / 15288 | Software and system life cycle processes |
The characteristics a requirement must have (29148 §5.2), worth checking each one against:
Necessary — remove it and something is lost · Appropriate — right level of detail for this document · Unambiguous — one interpretation only · Complete — needs nothing else to be understood · Singular — one need, no "and" · Feasible — achievable within constraints · Verifiable — you can prove it was met · Correct — accurately states the need · Conforming — follows the agreed format.
If a requirement fails verifiable, it is not a requirement yet. That single test removes most of what makes BRDs unusable.