What should a business requirements document (BRD) include ? Is a common question that followers of business analyst mentor often ask.
Typically, a business requirements document (BRD), is produced in a waterfall type project setting. Historically, however, it does not need to be and a BRD has been used in projects using incremental project approaches. In agile a lightweight vision document
fulfils a similar purpose.
It is helpful to produce a document that brings together artefacts as part of the initiation of a project. The content of BRD varies from organisation to organisation and project to project depending on which sets of business analysis templates are being used.
The style, depth, and nature of the BRD should reflect the project context and be sufficient to meet the needs of the project.
When done well, the business requirements document (BRD) directs the project and keeps everyone aligned. The BRD provides a basis to gain consensus and understanding of all the business requirements in scope for the project.
Table of Contents
What are Business Requirements?
The IIBA BABOK guide defines a business requirement as a representation of goals, objectives and outcomes that describe why a change has been initiated and how success will be assessed.
Structure of Business Requirements Document (BRD)
The usage, clarity, and relevance of a BRD is enhanced by a clearly defined structure. A well-structured document helps with the development of the BRD and enables reviewers to identify omissions and errors and project team members to use the content to help deliver the project.
The BRD may be sectioned in several ways – a typically structure is details as follows:
- Introduction and Background
- Business Process
- Solution Context
- Requirements Catalogue
- Data Models
- Glossary of Terms
- Business Rules
- Log
The sections provide the basis for a business requirements document template.
Introduction and Background
It is helpful for context and to provide business focus to describe the business situation and business drivers for the project. This section describes the business problems and business opportunity.
It serves to clarify the business objectives and scope of the work and ensure that all stakeholders are aware of the business context for the requirements and the solution.
Business Process
This section is often used to provide and describe the business process context for the scope of the work. Typically, this section may include a representation of the as-is business processes and if some initial work has been done on the vision of the to-be processes.
Both the as-is and to-be business processes provides a basis to document and highlight business problems and opportunities.
Both business processes also provides a good reference point to trace the requirements in the requirements catalogue.
Solution Context
Diagrams such as solution context diagrams and use case diagrams provide a useful visually depiction of scope. Very often a project is introducing or transforming a particular solution context so depicting this as a diagram helps to draw the boundary of solution scope.
Requirements Catalogue
The detailed and individual requirements can be defined using text and grouped in terms of functional and non-functional requirements. Each requirement can be prioritised by using techniques such as MoSCoW method, whether the requirement is a must have, should have, could have, or would have. Understanding which of the requirements are important in terms of priority to the extent that if they weren’t delivered the project would not be worth doing.
Data Model
An entity relationship diagram (ERD) or business domain model sets out the data requirements for the solution. It is preferable to build a data model that describe the data requirements and the ERD or business domain model compliments a glossary by providing a relationship of the data objects.
Glossary of Terms
A key element is the glossary of terms to ensure that a common language is used throughout the project. A glossary of terms overcomes problems when users, stakeholders or project members are unfamiliar with certain business terminology.
Business Rules
An optional section to include in a BRD are business rules – sometimes requirements can be complex and sophisticated and having a section to describe business rules can be helpful.
Log
An optional section to include in a BRD is a log listing the following that was uncovered during the business requirements document (BRD) process:
- Risks
- Assumptions
- Issues
- Dependencies
Business Requirements Document Template
A Business Requirements Document (BRD) template is a structured framework used to capture and document the detailed business requirements for a specific project, product, or initiative. It serves as a formal communication tool between stakeholders, project teams, and developers, ensuring everyone involved understands the objectives and scope of the project. A well-defined BRD template helps in reducing ambiguity, minimises misunderstandings, and facilitates smooth project execution.
A business requirements document template in a Microsoft Word format is included in the business analysis template package provided by Business Analysis Doctor. The package also includes a BRD document sample so that you get an idea of what a completed BRD example.
Conclusion – Business Requirements Document (BRD)
It is important to consider which elements of business requirements document (BRD are needed by your project or engagement. Context counts – so consider your organisational working practices, approaches, and business analysis templates.
A well put together business requirements document (BRD) provides a good foundation to direct the project and keeps everyone aligned.