Business requirements document template
What a BRD is for, a template with every section explained, a filled example, and where it sits next to a PRD and an SRS.
Where this comes from
The section structure is the conventional one used in business analysis practice; the template wording and the example are ours. Nothing here is a measurement.
What a BRD is
A business requirements document states what the business needs from a project and why: the problem, the objectives, who is affected, and how success will be measured. It deliberately says little about the product or the system. It is the document the sponsor signs, and the one every later requirement should trace back to.
| Document | Answers | Written by | Read by |
|---|---|---|---|
| BRD | Why are we doing this, and what does the business need? | Business analyst, sponsor | Sponsor, stakeholders |
| PRD | What must the product do for its users? | Product manager | Design, engineering |
| SRS | Exactly how must the system behave? | Analyst, architect | Engineering, QA |
The template
# Business requirements: <project name>
## 1. Summary
Two or three sentences: the problem, the proposed change, the expected result.
## 2. Business objectives
- OBJ-1 <measurable objective, with a number and a date>
## 3. Background and problem
What happens today, what it costs, and why now.
## 4. Scope
In scope:
- <capability or process>
Out of scope:
- <what this project deliberately does not change>
## 5. Stakeholders
| Stakeholder | Interest | Involvement |
|-------------|----------|-------------|
| <role or team> | <what they need> | approve / consult / inform |
## 6. Business requirements
- BR-001 <what the business needs, not how> (priority: must/should/could; objective: OBJ-1)
## 7. Constraints and assumptions
- Constraint: <budget, deadline, regulation, system that can't change>
- Assumption: <something believed true, to be confirmed>
## 8. Risks
- <risk> — <impact> — <mitigation>
## 9. Success measures
- <metric>: <baseline> → <target> by <date>
## 10. Open questions
- Q1 <question> — owner: <name> — needed by: <date>
## 11. Approval
| Name | Role | Date |
|------|------|------|A filled example: self-service password reset
# Business requirements: Self-service password reset
## 1. Summary
40% of support tickets are account lockouts handled by hand. A self-service
reset should remove most of them and cut time-to-access for users.
## 2. Business objectives
- OBJ-1 Reduce lockout tickets by 75% within 3 months of launch.
- OBJ-2 Median time from lockout to access under 5 minutes.
## 4. Scope
In scope: password reset by email for all customer accounts.
Out of scope: admin accounts, SMS reset, single sign-on accounts.
## 6. Business requirements
- BR-001 Customers can regain access without contacting support. (must; OBJ-1, OBJ-2)
- BR-002 The reset process must not reveal whether an email has an account. (must; security policy)
- BR-003 Support can see that a reset happened when a customer calls. (should; OBJ-1)
## 9. Success measures
- Lockout tickets per week: 120 → 30 by end of Q2.
## 10. Open questions
- Q1 Do enterprise customers on SSO need a different flow? — owner: IT leadBR-001 becomes a user story, and the story becomes testable requirements; that chain is shown end to end in the user story template and the PRD template.
What makes a BRD useful later
- Numbered objectives with numbers in them. "Improve customer experience" can't be traced to or measured against; OBJ-1 with a target can.
- An explicit out-of-scope list. Most scope arguments in delivery are about something the BRD never ruled out.
- Every business requirement points at an objective. A requirement that serves no objective is either missing an objective or shouldn't be there.
- Open questions with owners. A question without an owner is still open at launch.
From BRD to something you can build
A BRD is usually written once, signed, and then left behind as the work moves to stories and tickets. The link from a line of code back to the business objective is lost in that hand-off, which is why "why does it work this way?" is so hard to answer a year later.
Entalpa keeps that chain as linked records: stakeholders, the stories they need, and the requirements written from those stories, each with priority, acceptance criteria and status, plus open questions raised before anything is built. A coding agent reads it over MCP, so the requirements the code is written against are the same ones the business signed off, and the whole set exports as ReqIF, CSV or Markdown when someone needs a document again.
Questions this raises
What is a business requirements document?
A document that states what the business needs from a project and why: objectives, scope, stakeholders, business requirements, constraints and how success will be measured. It describes needs, not the solution.
What is the difference between a BRD and a PRD?
A BRD describes the business need and the expected outcome. A PRD describes what the product must do for its users to meet that need. The BRD comes first, and each PRD requirement should trace back to it.
What is the difference between a BRD and an SRS?
A BRD is written for the business and says why and what at a high level. An SRS is written for engineering and QA and specifies the system's behaviour in detail, including non-functional requirements.
Who writes the BRD?
Usually a business analyst, with the project sponsor and stakeholders. The sponsor approves it.
Entalpa gives your agent one locked source of truth
Structured, traceable requirements your agent reads over MCP — so it works from a curated spec instead of reconstructing your project every session. Free to start, no card, and reading or writing your project over MCP never spends credits.
Other guides