What a completed business requirements document actually looks like
One of the most common questions I get from early-career BAs is some version of: “I’ve got the template, but I don’t know what a real one looks like when it’s done.” That’s a completely reasonable place to be. Templates give you the skeleton. They don’t show you the muscle and fat.
In this article I’m going to walk you through a business requirements document sample drawn from real BA practice, section by section, and show you what each part should contain, how detailed it needs to be, and where things typically go sideways. I’m also going to include a worked example based on an HR workflow automation project so you can see how the pieces connect.
If you want the underlying template structure before reading further, the BRD template in Word format gives you a clean starting point. But this article is about what goes inside it.
The sections that matter most in a real BRD
A completed BRD typically runs nine sections. Not all of them carry equal weight. Here’s what each one needs to do and what a real entry looks like.
1. Document history and approvals
This is administrative but it matters more than people give it credit for. The revision history table records who changed what and when. The approvals table records who signed off. On Project X, a workflow automation programme in the public sector, we had a version conflict six weeks into delivery because two stakeholders were working from different drafts. The revision history would have caught it. After that, I never skipped updating it.
A completed entry in the revision history table looks like this:
| Version | Date | Author | Change Summary |
|---|---|---|---|
| 0.1 | March 2024 | BA Lead | Initial draft for stakeholder review |
| 0.2 | April 2024 | BA Lead | Updated scope following Workshop 2; three requirements removed |
| 1.0 | April 2024 | BA Lead | Final version approved by steering group |
2. Introduction
The introduction covers document purpose, intended audience, scope inclusions and exclusions, related documents, and a glossary of terms and acronyms. This section is often underdone. The exclusions are just as important as the inclusions. On Project X, we explicitly excluded casual employee processes from scope. That single line in the exclusions section saved us two months of scope creep when a manager tried to add casual onboarding halfway through delivery.
The document purpose statement should be one tight paragraph. On Project X it read something like: “This document identifies, documents, and seeks agreement on the business requirements for the HR Forms Management System at Organisation B. These requirements will form the basis for a phased implementation, prioritised to deliver maximum immediate benefit to HR operations.”
That’s the tone. Specific, scoped, purposeful.
3. Organisational context
This section answers the question: why does this project exist? It contains a mission statement, background narrative, problem statement, and vision. The problem statement is the most analytically demanding part of the whole document. On Project X the three main problems were physical handling of paperwork creating service bottlenecks, manual coordination of approvals consuming significant HR staff time, and double data entry between the HR system and payroll.
I’d written these up clearly and the HR manager agreed with all of them in the workshop. Two weeks later, the head of payroll pushed back hard, arguing that the double entry problem was overstated and that integration with the payroll system was out of scope. This forced a difficult conversation with the project sponsor about whether the problem statement accurately reflected the full situation, or just the HR perspective. We ended up rewording the double entry problem to acknowledge it as a known issue to be addressed in a later phase, not the current one. The lesson: your problem statement needs sign-off from everyone it implicates, not just your primary sponsor.
You can read more about structuring this part of the document in the article on writing a business problem statement.
4. System overview
This section describes the current system and proposed system, the scope of change, and the business benefits. The current system description needs to go beyond just listing the software in use. It needs to capture how data moves, where manual intervention happens, and where the gaps are. On Project X this meant documenting that HR forms were printed, manually approved by delegates, scanned, uploaded to the records management system, and then re-keyed into the HR platform. That description, written plainly, made the case for change more powerfully than any diagram.
The proposed system section summarises the capabilities being introduced: online form processing, automated workflow and notifications, data validation, and improved reporting. It should be readable by someone who hasn’t been in the workshops. A context diagram showing the functional areas of the new system alongside this section is highly effective.
The scope of change table is essential for controlling what gets built. On Project X it looked like this:
| Phase | Process Group | Business Processes Included |
|---|---|---|
| 1 | Employee On-boarding | New employee setup, contract extensions |
| 2 | Position Management | Reclassifications, management of existing positions |
| 3 | Allowances and Salary | Salary claims, reimbursements |
5. Implementation overview
This section states the project objectives, constraints, assumptions, dependencies, and implementation approach. The constraints section is where you record the uncomfortable realities: fixed delivery dates, funding limits, resource availability. On Project X a constraint was that a working prototype had to be demonstrated to the steering group within twelve weeks of project kickoff. That constraint shaped every prioritisation decision we made during requirements analysis.
The dependencies section is where you document what the project relies on that sits outside your control. On Project X we noted that Organisation B’s change management programme needed to be active and resourced before any deployment, because most of the HR processes had been re-engineered and staff would need to be trained in new ways of working. This was flagged as a risk at the time. The change management programme was not, in fact, adequately resourced, and this caused delays post-delivery.
6. Requirements conventions
This short section explains how requirements are written and prioritised in the document. The priority terminology used on Project X was Essential (must be delivered for the project to succeed) and Desirable (should be delivered if possible). Each requirement was tagged with a REQ number and an owner who had validated it. This made traceability straightforward during delivery.
Using consistent priority labels matters more than you might expect. When the development team is making decisions about what to build first, having clearly labelled Essential requirements gives them a clear reference point. If you want to understand more about how this connects to requirements traceability, the requirements traceability matrix guide is worth reading alongside this one.
7. Business requirements
This is the core of the document. Requirements are organised by business process, each with a description, a process diagram, and a numbered requirements table. On Project X the employee on-boarding process had a swim-lane process diagram showing the sequence of steps from the manager submitting a new employee request through to ICT Services provisioning network access. The requirements traced directly to steps in that diagram.
A sample requirement from that process:
- REQ01 – When a new employee record is submitted and approved, automatically generate a notification to the ICT Services team to create network and email credentials. Priority: Essential. Owner: HR Manager, Workshop 3.
Notice what makes this a useful requirement: it has a trigger, an action, a recipient, and a priority. It doesn’t describe how the system should do it. That’s for the functional specification.
8. System requirements
This section captures both functional requirements (what the system must do) and non-functional requirements (how the system must perform). Examples of non-functional requirements from Project X included operating within Organisation B’s desktop standard environment, complying with the information security policy including role-based access controls, and meeting specific performance standards for form processing times.
The distinction between business requirements and system requirements matters, and it’s worth understanding before you write this section. If you’re unsure how they relate, the article on BRD versus FRD explains the difference clearly.
9. Definitions
The definitions section captures roles, domain terms, and acronyms. On Project X the domain terms table included entries for the HR platform, the records management system, and specific HR process names that had different meanings in different business units. Getting these agreed early avoided ambiguity in the requirements themselves.
The things a template won’t tell you
Looking at a business requirements document sample only gets you so far. What the sample doesn’t show you is the negotiation that happened before the document was written: the workshops where requirements shifted, the stakeholder who argued a requirement was out of scope, the version that had to be revised after a senior manager changed their mind about what the project was trying to achieve.
A completed BRD is a record of all of that work. Every section reflects a conversation that happened, a decision that was made, or a constraint that was accepted. When you write your own, treat it as documentation of real analysis, not a form-filling exercise.
The document is also never truly finished during the project. It’s a living reference. On Project X we updated the constraints section twice and revised the scope of change table once before delivery was complete. Version control and the document history table made that manageable rather than chaotic.
A well-constructed business requirements document sample shows you the structure, the language, and the level of detail to aim for. But the quality of what ends up in it depends entirely on the quality of the analysis and stakeholder engagement that preceded it. No template substitutes for that work.
Try Ash, Your Virtual BA
Now that you’ve seen how a completed BRD is structured and what goes in each section, you might be ready to start writing your own. Ash, the Virtual BA at businessanalyststoolkit.com, can help you draft any section of a BRD based on the context of your project, from the problem statement through to individual requirements tables. Whether you’re starting from scratch or trying to fill in a section you’re not confident about, Ash can accelerate the work. Try Ash Virtual BA and see how quickly you can move from blank page to structured draft.
Frequently asked questions
What does a completed business requirements document look like?
A completed BRD includes document history, organisational context, a problem statement, current and proposed system descriptions, a scoped list of business requirements organised by process, system requirements, and a definitions section. Each requirement is numbered, prioritised, and attributed to a validated owner.
How long should a business requirements document be?
Length varies by project complexity. A straightforward internal system project might produce a 15 to 20 page BRD. A large enterprise programme can run to 50 pages or more. What matters is that each section contains substantive, agreed content rather than placeholder text.
What is the difference between a BRD and an FRD?
A BRD captures what the business needs and why. An FRD describes how a system will fulfil those needs in functional terms. The BRD comes first and drives the FRD. Business requirements describe outcomes and rules; functional requirements describe system behaviour.
How do you write requirements in a BRD?
Each requirement should start with a verb, be written from the user’s perspective, and describe a need rather than a solution. Give each requirement a unique ID, a priority, and a named owner. Avoid combining multiple needs into a single requirement.
What should be in the problem statement section of a BRD?
The problem statement should describe the current situation in practical business terms, identify the specific issues causing pain, and explain why the status quo is not acceptable. It should be agreed by all affected stakeholders, not just the project sponsor.
Further reading
- Successfully Documenting Requirements for a Project | IIBA® Business Analysis Blog
- Business Requirements at the Core: How to Uncover, Model, and Align Analysis with Real Business Needs | IIBA
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.