Introduction
As described in the article A comprehensive guide to the major Business Analyst deliverables a BRD contains a catalogue for all of the business requirements, a priority for each and a justification.
The purpose of it is to:
- Gain a consensus and understanding of all of the business requirements in scope for the project
- Understand which of the requirements are mandatory to the extent that if they weren’t delivered the project would not be worth doing.
- Pre-requisite for being able to start system requirements to ensure traceability.
Guidelines
A business requirement document must be non-solution specific. The rationale is to separate out the what from the how. The how can change but the what should be more static. You shouldn’t have to keep changing the requirements in the document every time a different solution is discussed.
By contrast a functional specification contains system requirements. These are defined once the system boundaries are established and go into detail of the functionality required and the interactions with other people or systems.
Contents
1.Executive Summary
The first section in the BRD should be an Executive Summary. The executive summary should be no more than 1 or 2 sides.
It should set out:
1.1 Introduction
To set the context (no more than half a page).
1.2 Audience
To show the audience the BRD is aimed at and the teams impacted.
1.3 Related documentation
Any related documentation that is related such a Vision documents, Business process model documents etc.
1.4 Scope
To include in scope and out of scope
2. Functional Business Requirements
The second section is the Functional Business requirements.
Each requirement should be given a priority. See below for a template of the rating classification table to include as a guide. It can be difficult to get the business to give a priority of anything less than essential because they may fear they won’t get it otherwise.
Questions to ask to validate a essential requirement is to establish whether it is needed from day 1 and what would happen if they didn’t have it.
| Rating | Description |
| Essential (E) | This requirement is essential to the success of the project. The project cannot adequately deliver without this requirement. |
| Important (I) | This requirement is important and is extremely useful in delivering the benefits of the project. |
| Desirable (D)
|
This requirement is desirable, and is nice to have if time and cost allow it. |
Below shows an template for listing the business requirements.
| Req. Ref. | Title | Description | Priority | Source | Rationale |
- Every requirement should have a requirement reference that should not change.
- A title is included to provide a brief description of the requirement in 2-3 words.
- A description is to describe each functional requirement in business terms.
- Priority is based on the rating table above.
- Source is to provide an audit of who provided the requirement. This is useful to know who to go back to if more information is required or there is a challenge.
- Rationale is to provide the reason for why the requirement is needed and what is expected for the success of the requirement being delivered.
3. Log
A log should be kept towards the end of the document listing the following that were uncovered during the BRD processDecisions
3.1 Assumptions
3.2 Issues
3.3 Risks
3.4 Dependencies
4. Document Control
A Document control section is also needed and is normally kept at the very beginning or end of a BRD.
This section should contain the following:
4.1 Version control
| Version | Date | Summary of changes | Author |
4.2 Distribution
| Name | Role | Date issued | Reviewer or for information | Version no |
4.3 Approval
| Name | Role | Date approved and supporting evidence |
It is important to understand who needs to review and approve your BRD. It is also important to ensure the BRD gets signed off. For help on this see tips for obtaining sign off of documentation.
Thoughts? Questions? Please share in the comments.
If you have found this article useful then you might like my book – The Business Analysis Handbook – Techniques and Questions for better Business Outcomes. The book is available from www.koganpage.com and all major print and e-book retailers.
