Free BA template
Business requirements document (BRD) template
A practical BRD template with short guidance for each section and a filled example from a fictional online shop.
A business requirements document (BRD) records what the business needs from a change and why, before anyone decides how to build it. It gives sponsors, analysts, designers and testers one agreed reference for the problem, the objectives, the scope and the requirements, and it is the document people return to when someone asks "was this in scope?".
This template covers the sections most organisations expect. Keep the sections that help your readers and remove the rest: a short, current BRD is more useful than a long, out-of-date one. For a complete worked document, see the business requirements document example.
How to use it
- Read the guidance for each section. Use the filled fictional example to see the level of detail that is useful.
- Switch the example off if you want a clean template, then press Download as .md to save a Markdown file you can open in any editor, Confluence or a Git repository.
- Or press Print or save as PDF for a paper copy or a PDF made by your browser. Buttons and site navigation are left out of the printout.
- Fill the sections with your own project. Give every requirement an ID and a priority so you can trace it to acceptance criteria and tests later.
BRD template
Private by design. What you type stays in your browser. Nothing is sent to BA Mentorship. Nothing is saved either: copy or download your work before you close the tab.
The download includes the example only while it is shown. The example describes a fictional company, Marlow Online Store; every name and number is invented.
Document control
Record the version, author, date and status so readers know whether they hold the latest copy.
- Project name
- Version
- Author
- Date
- Status (Draft, In review, Approved)
Fictional example: Project: Show delivery costs earlier at checkout. Version 0.3, author A. Rao (business analyst), 14 October 2026, status In review.
Executive summary
Two or three sentences a busy sponsor can read: the problem, the proposed change and the expected benefit.
- Problem in one sentence
- Proposed change
- Expected benefit
Fictional example: Many Marlow Online Store customers leave checkout at the final step, where delivery costs first appear. We propose showing the delivery cost on the basket page. We expect fewer abandoned checkouts and fewer "unexpected cost" complaints.
Background and problem statement
Describe the current situation and the evidence for the problem. Separate what you observed from what people believe.
- Current situation
- Evidence (data, complaints, interviews)
- Who is affected
Fictional example: Order data for July to September shows 41% of checkouts that reach the payment step are abandoned. Support logged 230 complaints mentioning delivery cost in the same period. Stakeholders believe price is the cause; the data so far shows only that abandonment happens at the step where delivery cost appears.
Business objectives
Write objectives that are specific and measurable, with a time frame. Each requirement later should support at least one objective.
- Objective ID
- Objective
- Measure and target
- By when
Fictional example: OBJ-1: Reduce checkout abandonment at the payment step from 41% to 30% within three months of release. OBJ-2: Halve monthly complaints that mention delivery cost by the end of the next quarter.
Scope
List what is in scope and, just as important, what is out of scope for this change.
- In scope
- Out of scope
Fictional example: In scope: showing the delivery cost on the basket page for UK addresses; a delivery cost estimate before sign-in. Out of scope: changing delivery prices, international delivery, the mobile app.
Stakeholders
Name the roles who are affected, decide or must be consulted, and how they will be involved.
- Stakeholder or role
- Interest
- Involvement (decides, consulted, informed)
Fictional example: Head of E-commerce (sponsor, decides); Customer Support Lead (consulted: complaint data); Logistics Manager (consulted: delivery pricing rules); Finance (informed).
Current state (as-is)
Summarise how the process works today, ideally with a simple process diagram or numbered steps.
- Current steps
- Pain points
Fictional example: 1. Customer adds items to basket. 2. Customer signs in. 3. Customer enters address. 4. Delivery cost appears on the payment step. Pain point: the cost appears after three steps of effort.
Future state (to-be)
Describe how the process will work after the change, and what is different for each affected role.
- Future steps
- What changes for each role
Fictional example: 1. Customer adds items to basket. 2. Basket shows the delivery cost for a default UK postcode, with a link to change it. 3. Customer signs in and pays. Support can point customers to the basket estimate.
Business requirements
One requirement per row, each with an ID, a priority and the objective it supports. State the need, not the design.
- ID
- Requirement
- Priority (MoSCoW)
- Supports objective
- Acceptance criteria
Fictional example: BR-01 (Must, OBJ-1): The basket must show the delivery cost before the customer signs in. BR-02 (Should, OBJ-1): The customer can change the postcode used for the estimate. BR-03 (Could, OBJ-2): The help page explains how delivery cost is calculated.
Non-functional requirements
Quality rules such as performance, availability, accessibility and security, each with a measurable target.
- Category
- Requirement
- Measure
Fictional example: NFR-01 Performance: the delivery estimate appears within 2 seconds for 95% of basket views. NFR-02 Accessibility: the estimate and postcode field meet WCAG 2.1 AA.
Assumptions
Things you believe are true but have not confirmed. Each one is a risk if it turns out to be wrong.
- Assumption
- Owner to confirm
Fictional example: Delivery prices for UK addresses depend only on postcode and basket weight (Logistics Manager to confirm).
Constraints
Fixed limits on the solution: budget, deadlines, technology, regulation or policy.
- Constraint
- Source
Fictional example: Must go live before the November sale; must use the existing delivery pricing service.
Dependencies
Other teams, systems or decisions this change relies on.
- Dependency
- Owner
- Needed by
Fictional example: The pricing service team must expose a delivery estimate for anonymous baskets by 1 November.
Risks
What could stop the objectives being met, how likely and serious it is, and what you will do about it.
- Risk
- Likelihood
- Impact
- Response
Fictional example: Estimates could differ from the final delivery cost (medium likelihood, high impact on trust). Response: label the figure as an estimate and recalculate it on the payment step.
Success measures
How and when you will check that the objectives were met after release.
- Measure
- Baseline
- Target
- When measured
Fictional example: Payment-step abandonment: baseline 41%, target 30%, measured weekly for 12 weeks after release.
Glossary
Define terms that readers outside the team may not know, or that mean different things to different people.
- Term
- Meaning
Fictional example: Abandoned checkout: a session that reaches the payment step and ends without a placed order within 30 minutes.
Approval and sign-off
Who must approve this document before work starts, and the date of each approval.
- Name and role
- Decision
- Date
Fictional example: Head of E-commerce: approved, 21 October 2026. Logistics Manager: approved with comments, 22 October 2026.
Questions and explanations
What is the difference between a BRD, an FRD and an SRS?
A BRD states what the business needs and why. A functional requirements document (FRD) describes how the solution must behave to meet those needs. A software requirements specification (SRS) adds detailed technical and quality requirements for the build. Many teams combine them or use user stories instead; what matters is that the business need is written down and agreed.
Who writes and approves a BRD?
Usually a business analyst writes it, working with the sponsor, subject matter experts and the delivery team. The sponsor and key stakeholders approve it. Record each approval and its date in the sign-off section so everyone knows which version was agreed.
How long should a BRD be?
As short as it can be while still answering the questions your readers will ask. A small change might need two pages; a large programme might need many more. If a section has nothing useful to say for your project, write "Not applicable" and why, rather than filling it with general text.
Can I use this template at work?
Yes. The template is free to use and adapt for your own projects. The filled example describes a fictional company and is there only to show the level of detail; replace it with your own content.
These tools are free practice aids from BA Mentorship. They use simple, transparent rules, not AI, and they do not assess or certify your work. BA Mentorship is not affiliated with IIBA, PMI or IREB.