BA skills guide
How to write a Business Requirements Document (BRD)
A BRD is a core BA deliverable. It translates business problems into structured requirements that teams can act on. Here’s the structure, with examples and a template you can use in your portfolio.
What is a BRD?
A Business Requirements Document captures what a project or system must do to satisfy business needs. It is written before any technical design begins and serves as the contract between stakeholders and the delivery team.
The BA writes the BRD after gathering requirements from stakeholders through interviews, workshops, and observation. It bridges the gap between the business problem and the solution — answering “what do we need?” before anyone asks “how do we build it?”
BRD vs FRD vs PRD
These three documents are often confused because they overlap in practice. Many organizations combine them into one. Here’s how to distinguish them when they are separate.
WHAT the business needs
Business Analyst
Stakeholders, executives, project sponsors
WHAT the system will do
Business Analyst / Systems Analyst
Dev team, QA, architects
WHAT the product team will build
Product Manager
Design, engineering, marketing
In practice, many organizations combine the BRD and FRD into one document. When a hiring manager asks to see your BRD, they usually want to see all three layers in one coherent document.
The 8-section BRD structure
Every BRD is different, but strong ones share the same eight sections. Use this as your template and fill in the specifics for each project.
Executive Summary
One paragraph that captures what the project is, why it exists, and what success looks like. Written last, placed first. An executive should be able to read only this section and understand the full picture.
Project Background
Why are we doing this? Describe the business problem or opportunity, what triggered this initiative, and what happens if we do nothing. Include relevant history — prior attempts, failed solutions, or market changes that created urgency.
Stakeholders
Who is involved, what their role is, and what they care about. Distinguish between decision-makers (who can approve changes), contributors (who provide input), and those who are informed. A RACI matrix works well here.
Business Objectives
What outcomes do we want from this project? Frame objectives in measurable terms and link them to OKRs or KPIs where possible. Example: 'Reduce manual invoice processing time by 40% within 6 months of launch.'
Scope
What is IN scope and what is explicitly OUT of scope. The out-of-scope list is as important as the in-scope list — it prevents scope creep and sets expectations. Be specific: 'Mobile app is out of scope for v1; web only.'
Functional Requirements
What the system must do. Written as user stories or a numbered feature list with acceptance criteria per item. Every requirement must be testable — if you can't write a test for it, rewrite the requirement.
Non-Functional Requirements
Performance, security, scalability, availability, and accessibility constraints. These define how the system must behave, not what it must do. Example: 'The system must respond to search queries in under 1.5 seconds for up to 500 concurrent users.'
Assumptions & Dependencies
What are you assuming to be true that has not been confirmed? What must happen before this project can succeed — third-party APIs, internal team availability, legal sign-off, data migration? Document it here so risks are visible.
Good requirements vs bad requirements
The most common mistake in requirements writing is using vague, untestable language. Every requirement must be specific enough that you can write a test for it and get a clear pass or fail.
How to use this for your BA portfolio
You don’t need a real client project to demonstrate BRD skills. A well-written fictional BRD shows the same competency — and it’s what most entry-level BAs use to get their first role.
How to approach it
Pick a product you use every day — your gym app, your bank's mobile app, a local business that could benefit from software.
Write a fictional BRD using the 8-section structure above. Keep it to 3–5 pages. Depth matters more than length.
Focus your effort on Section 05 (Scope) and Section 06 (Functional Requirements). Those are what interviewers look at first.
Make sure every requirement in Section 06 passes the testability check — if you can't write a test for it, rewrite it.
Pro tip
Include a version history table at the top of your BRD with columns for version number, date, author, and change summary. It signals professionalism and shows you understand how real documents are maintained in organizations.
Next steps
Build BA skills in the Business Analyst track
The BA track covers requirements gathering, stakeholder management, process modeling, and the tools BAs use day-to-day.