BRD (Business Requirements Document): what it contains and how to write one
A BRD, or business requirements document, describes what a solution must achieve for the business, not how it will be built. It is the shared language between business and IT: the business confirms what it needs, and the vendor or development team designs the solution from it. A good BRD saves time, money and nerves because it surfaces misunderstandings before development starts.
When you need a BRD
- before selecting a vendor or issuing a tender,
- before developing a new system or a major change,
- when several departments with different expectations depend on the solution,
- when you need to agree contractually what will be delivered and how it will be accepted.
BRD vs. functional specification
The BRD speaks the language of the business: which problem we solve, which processes change, what users must be able to do and how we recognise success. The functional specification (FSD) builds on it and describes how the system will work: screens, fields, integrations, rules. BRD first, FSD second.
BRD structure
1. Introduction and purpose – the project, the audience of the document and how it will be approved.
2. Business objectives – what the solution must achieve, ideally measurably.
3. Scope – what is in scope and what is explicitly out.
4. Stakeholders – who uses the solution, who decides and who supports it.
5. Current and future state – how work is done today, what does not work and how it should work after the change.
6. Business requirements – a list of requirements with a unique ID, description, priority (MoSCoW: must, should, could, won’t) and source.
7. Non-functional requirements – performance, security, availability, data protection, languages.
8. Assumptions, constraints and dependencies – budget, deadlines, existing systems, legislation.
9. Acceptance criteria – how the business will accept the solution.
10. Glossary – so everyone understands the same words the same way.
How to write a good requirement
A good requirement is unambiguous, testable and independent of the technical solution.
- ❌ “The system must be fast and simple.”
- ✅ “A sales rep finds the customer’s communication history within 10 seconds of entering the customer name.”
Every requirement needs an owner and a priority. If it cannot be tested, it is a wish, not a requirement.
Common mistakes
- A solution instead of a requirement (“we want a button in the right corner”).
- Missing scope, so the project grows uncontrolled.
- Requirements without priorities – everything is a “must”, so nothing is.
- No acceptance criteria, so at the end nobody can say whether it is done.
Example: a BRD created in Baaito
The brief we gave Baaito:
A company wants to replace paper and e-mail approval of leave and business trips. Employees request via web and mobile, the manager approves with one click, HR sees an overview and exports to the payroll system. 300 employees, 3 branches.
Sample document
Business Requirements Document — Digital Leave and Business Trip Approval
The first pages of a real document Baaito generated from the brief above.
Business Requirements Document — Digital Leave and Business Trip Approval
Document Purpose
This Business Requirements Document establishes the initial business-requirement baseline for replacing paper- and e-mail-based approval of employee leave and business-trip requests.
It is intended for review and governance by the business owner, business analyst, product owner, delivery team, quality assurance, employees, managers, HR, and payroll stakeholders. The governed subject is the business capability for submitting, approving, reviewing, and exporting leave and business-trip information.
Included in this baseline are the stated needs for:
- Employee request submission through web and mobile channels.
- Manager approval using one click.
- HR visibility through an overview.
- Export of information to the payroll system.
- Support for a company of 300 employees across 3 branches.
Business context, scope boundaries, stakeholder accountability, business priorities, detailed rules, data definitions, process controls, service expectations, acceptance authorities, and approvals are TBD — business context, scope, stakeholder, business-needs, policy, and approval inputs are required.
Business Context and Objectives
The supplied brief identifies a current situation in which leave and business-trip approvals are handled using paper and e-mail. The desired business outcome is to replace this approach with a process supporting web and mobile requests, one-click manager approval, HR overview, and payroll-system export.
The affected organizational context is a company with 300 employees across 3 branches. The specific legal, policy, operational, payroll, and organizational drivers are TBD — approved business-context and objective inputs are required.
Objectives
| Objective ID | Objective | Evidence | Status |
|---|---|---|---|
| O-01 | Replace paper- and e-mail-based approval of leave and business trips. | Request brief | Confirmed as a stated objective |
| O-02 | Enable employees to submit leave and business-trip requests through web and mobile channels. | Request brief | Confirmed as a stated desired capability |
| O-03 | Enable managers to approve requests with one click. | Request brief | Confirmed as a stated desired capability |
| O-04 | Provide HR with an overview of relevant requests and enable export to the payroll system. | Request brief | Confirmed as a stated desired capability |
Current-state measures, target outcomes, success measures, implementation timing, and objective priorities are TBD — approved objective definitions and baseline measures are required.
Scope
The scope is partially defined by the request brief.
Included
- Leave requests.
- Business-trip requests.
- Employee submission through web.
- Employee submission through mobile.
- Manager approval using one click.
- HR overview of requests.
- Export to the payroll system.
- The company population of 300 employees across 3 branches, subject to confirmation of applicability.
Excluded or Not Yet Defined
- Specific leave and business-trip categories.
- Eligibility rules and approval routing.
- Delegation, escalation, rejection, cancellation, and amendment handling.
- Detailed payroll interface scope and export format.
- User authentication and authorization arrangements.
- Notifications and reminders.
- Reporting beyond the HR overview.
- Historical-data migration.
- Branch-specific process variations.
- Technical architecture and implementation mechanisms.
These exclusions are not confirmed permanent exclusions; they are TBD — an approved scope definition is required.
Interfaces with the payroll system are within the stated business scope, but the data boundary, timing, ownership, and export responsibilities are TBD — payroll-interface requirements are required.
The authority to approve scope changes is TBD — an accountable business owner or decision authority must be identified. Dependencies that may change the scope include payroll-system capabilities, company policies, branch practices, and approval rules; details are TBD — dependency and policy inputs are required.
Stakeholders and Users
The following parties are explicitly identified or directly named in the supplied brief. Their detailed responsibilities and decision rights require confirmation.
- Employees: Expected users who submit leave and business-trip requests through web and mobile. Their detailed needs, consultation role, and acceptance involvement are TBD — stakeholder input is required.
- Managers: Expected approvers who approve requests with one click. Their approval authority, delegation arrangements, and acceptance role are TBD — stakeholder and approval-authority inputs are required.
- HR: Expected users who view an overview and export information to the payroll system. HR ownership of data, process rules, and acceptance is TBD — HR stakeholder input is required.
- Payroll system or payroll function: Downstream consumer of exported information. Interface ownership, data requirements, and acceptance responsibility are TBD — payroll stakeholder input is required.
- Business owner: Required to confirm objectives, scope, priorities, and approvals. Identity and authority are TBD — governance input is required.
- Business analyst, product owner, delivery team, and quality assurance: Intended consumers or contributors to the requirements baseline. Their specific responsibilities are TBD — governance and delivery-role inputs are required.
Template used: Business Requirements Document (BRD, EN)
Baaito prepared the BRD in a proven structure, prioritised the requirements and marked missing information to be completed.
How to do it faster
Describe the need in your own words or attach existing material. Baaito asks follow-up questions about what the BRD is still missing and creates a Word or PDF document. On the web and in Microsoft Teams and Copilot.
FAQ
Who writes the BRD? Usually a business analyst together with the process owner and key users.
How detailed should a BRD be? Detailed enough for a vendor to estimate the solution and for the business to accept it. Technical details belong in the functional specification.
Does a BRD replace user stories? No. The BRD sets the objectives and scope. In agile delivery, user stories are derived from it as smaller requirements refined over time.