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. Word (.docx), watermarked and version-controlled. Markdown source also available.
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.