What is a business requirement document (BRD)?
It is a document to record the functional, quality, and usability requirements into formats that are easily consumable for future analysis, architectural, and design activities, and most importantly in a format that is understandable by all business stakeholders.
The BRD is designed to take the reader from a high-level understanding of the business processes down to the detailed business requirements. It should capture the following:
- Project summary and background
- Project scope
- Operating model
- Project governance
- Business process model
- Use cases
- Assumptions and constraints
- Prioritized requirements
- Success metrics
Components of the business requirement document (BRD)
Company Overview
The BRDs start with an overview of the company explaining the company’s mission, vision, and business strategy. This section also covers company’s portfolio of products, services, customers, and service delivery. Sometimes company’s business model and operations are also included in the BRDs. This helps the solution provider to get a holistic look at the company they are undertaking the project. In some BRDs, instead of a company overview, an executive summary will be presented.
Project scope
This is the important section of the BRDs that explains the project scope in detail. This provides an outline of what is covered in the project and more importantly what is out of scope. This defines a clear boundary for the project landscape. The consensus needs to be sought out among the project stakeholders about the project scope. The project scope identifies and defines clear business goals along with project high-level outcomes.
Business goals
The business objectives of the projects should be clearly documented to align project stakeholders for successful execution. These goals provide a strategic outcome of the project and detailing the “Why” of this project is required.
Functional and non-functional requirements
This
section of the business requirement document talks about the functional and
non-functional business requirements. The functional requirements describe
essential features that the solution “must-have” to satisfy the project
stakeholder needs. The functional requirements are assigned different statuses
such as “essential”, “important” and “desirable” and these requirements can be
prioritised.
Non-functional requirements are also documented to include any
reporting, analytics, and integration requirements.
Project Roadmaps
Project roadmaps contain the schedule for project execution. It includes project milestones and stakeholder meetings along with estimated timelines. It also charts out the dependencies in project activities and contingencies. The rule of thumb is to include 20% buffer time for all activities to manage uncertainties that may arise during project execution.
Stakeholder consultation
The stakeholder consultation meeting includes items that need to be discussed with solution provider after successful project kick-off. This includes
- Business process maps
- Reporting requirements
- Operational requirements
- Service delivery mechanism
- Data privacy
- Service Level Agreements
- Existing business systems
- Business and IT architecture
- Compliance and regulatory requirements
Project risks
This section elaborates on the project risks. Project risks explain the strategic and tactical risks that the project Senior Responsible Officer (SRO) needs to manage during project implementation. The risk plan consists of risk name, risk priority, risk likelihood of occurrence, mitigation strategies, and risk owner.
Infrastructure requirements
For IT and digital transformation projects, infrastructure requirements can be included in the technical section. This includes servers, licensing costs, and so on.
Budgets
Budgets section covers phased/milestone-based payment schedules along with the disbursement amount. The budget needs to cover onboarding cost, stakeholder consultation cost, vendor cost, operation cost, and any non-essential project costs.
Project governance committee is set up to oversee the project execution. This committee includes Senior Responsible Officer (SRO), Project Director, Project Manager, business analysts, and business stakeholders. The committee meets at regular time intervals to ensure smooth project operations. The business analyst usually drafts the business requirement document. The BRDs are verified by a project manager and validated by the project director.
Benefits of documenting business requirements
- A clear understanding of business requirements – Having transparent needs documented and shared among project stakeholders reduces ambiguity and uncertainties
- Improve Flexibility and Reliability – The project risks can be mitigated easily leading to a predictable way to manage project outcomes
- Cost Efficiency – since the requirements are given to solution provider/vendors, it leads to cost saving and helps with price negotiation
- Promotes Transparency – The BRDs fosters transparency leading to improved communications between collaborators and project stakeholders
- Reduces Errors and Mistakes – Since the project requirements are documented upfront, it leads to removing misunderstanding in the implementation of a solution
- Decreases Dependency – The BRDs reduces the dependencies on external and internal stakeholders for project consultation and funding
Samples of Business requirement templates
Typical business requirement document template should contain the following elements
- Introduction
- Executive summary
- Project scope
- Functional
- Non-function requirements
- Stakeholders
- Project plan/roadmap
- Risks and mitigation plans
- Governance
- Budgets
- Additional requirements
