# Business Requirements Document

**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.