Are you struggling in capturing business requirements and drafting them into a quality business requirements document i.e. BRD? Is it your first BRD and you are clueless about the steps to write a powerful business requirements document? Don’t worry, you are not alone in this. Many business analysts struggle to write their first BRD.
A properly written and well-structured business requirement document is a key to the project’s success. Most of the projects fail to deliver business requirements due to the poorly written BRD therefore, the business analysts need to know – how to write a powerful business requirement document? Let’s get started and go through the process of writing BRD step by step.
What is a Business Requirement Document?
A business requirement document or BRD is high-level business requirements, goals, and objectives written in layman language that needs to be fulfilled by the to be developed system. It is a formal non-technical document that would be referred by the business stakeholders, managers, directors, etc.
The objective of the business requirement document is to outline all the requirements in a way that is easy to understand by any user. It finalizes the project’s scope and acts as a formal contract between the development team or the vendor and business stakeholders. Business provides their approval on the business requirements, project’s scope, and acceptance criteria by relying on the business requirement document.
The business requirement document consists of high-level business requirements and it is necessary to understand that, it is not the same as a functional specification document or functional requirement document. It is should simple and easy to follow document without any technical words.
Read Also… 10 Important Documents Prepared By Business Analyst
Who prepares Business Requirement Document?
Business Requirement Document or BRD is built during the analysis phase of the project. Preparing and maintaining a business requirement document is the responsibility of a business analyst.
This document is one of the outputs of the requirement elicitation process and it requires many business requirement gathering strategies to gather the complete requirements from the business stakeholders or involved SMEs and end-users. A business analyst will have many meetings and workshops with requirement business stakeholders and key users to capture the complete business requirement.
It is important to know that, it is not about only capturing AS-IS requirements but a business analyst will also;
- assess the requirements
- do the GAP analysis
- complete the impact and risk assessment
- AS-IS and TO-BE analysis
- suggest the better alternative if available
- find out the rationale of the requirements, and more.
Read Also… 23 Essential Business Analyst Skills That Are High In Demand
How to write a Business Requirement Document?
Every company has its BRD template to capture the business requirements. A business analyst supposed to refer the same while requirement elicitation process. A business requirement document template could in the word or excel format based on what your company is following.
However, every business requirement document will have the following 8 important sections to capture meaningful requirements;
- Executive Summary
- Document version or history log
- Project Overview and Objective
- Business requirements
- Assumptions and Constraints
- Key stakeholders
- Project scope
- Glossary
1. Executive Summary
Executive Summary is the high-level information about the project and it would be the first thing that a reader of the BRD will see. This section will convey the necessary information about the project to the users. It should be short but powerful enough to capture the user’s attention.
2. Document Version or History Log
Apart from these sections, you should also have the document versioning section that will highlight the changes implemented in BRD over time. It shows, when, and what changes are introduced in the BRD. It also shows the timestamp when the document got approved and baselined. It is being captured in a tabular format like below;
| Version | Updated By | Reason | Status | Date |
|---|---|---|---|---|
| V0.01 | Carol Lee | Constraint Updated | Update | 14/01/2020 |
| V0.02 | Will Mathew | Additional Requirements Added related to claim processing | Update | 13/04/2020 |
| V1.0 | Carol Lee | Document Approved | Approved | 15/05/2020 |
3. Project Overview and Objectives
This section of the BRD will be used to explain the project information in detail. All the key points that should be considered in the project should be listed here. This will help the users to understand the purpose of the project. Following should be considered while writing the project overview and objective section;
- Background of the project
- How the project will be fixing an issue or benefit the organization
- Why this project was a need of time
- What are key stakeholders
- Overall goal(s) and business expectations from the project.
- A diagram explaining the process improvement, and more.
Remember, to keep it high level because you will be writing the detailed requirement in the Business Requirement section.
4. Business requirements
As the name suggests, the business requirements section will be used to describe the requirements in detail. A business analyst should list down every requirement in this section. You shouldn’t mix two requirements in one but should keep each functionality in a separate row.
Each business requirement should have priority and serial number. The business priority could be Low, Medium, High, Critical, etc. The serial number is important because the reference to the business requirements will be used in other key documents like the traceability matrix.
| Sr. No. | Requirement | Priority |
|---|---|---|
| B01 | The system should allow users to register | High |
5. Assumptions and Constraints
The business requirement document should mention the assumption made and involved constraints like budget, time, technology, etc. Assumptions may reflect an understanding of how desired outcomes are likely to be achieved. For example, stakeholders may believe that customers will respond in a certain way to a change in how a product is delivered. This also helps in finding a way to tackle the constraints.
This should also be written point by point with each item in a separate row/line. It is very important for a business analyst to walkthrough the stakeholders on this section specifically i.e. this section of the BRD shouldn’t be missed by any stakeholder or users.
6. Key stakeholders
You shouldn’t miss to mention the key stakeholders involved in the project along with their role. A business requirement document should have key stakeholders involved in requirement gathering and the ones who will be responsible for approving the BRD documents. This will help the users to reach out to the right stakeholders in case of any clarification or conflict. It could be written in the following format;
| Sr. No | Name | Designation | Department | Role |
|---|---|---|---|---|
| 1 | Mathew Smith | Manager | Claims | Approver |
| 2 | Will Smith | Director | Underwriting | Approver |
7. Project scope
The project scope section of the business requirement document is key to make sure the vendor or development team and business stakeholders are aligning on the expectations from the project delivery. You should take some time in listing the items that are in the project’s scope and items that are out of scope.
A well-written project scope will avoid future conflict between the project teams and business stakeholders. It could be written in tabular form with a clear remark stating whether it is in Scope or Out of Scope. It should as detail as possible without any assumptions.
8. Glossary
Business requirement documents should be writing in very simple and common language however, sometimes you might use business terminologies or words that are not quite common for many users. Therefore, it is required to have a glossary section in your BRD where you would be describing all the technical or business terminology used throughout the document. This will help the users to easily follow the requirement documents.
| Term | Description |
|---|---|
| UAT | User Acceptance Testing |
| SDLC | Software Development Lifecycle |
Now, when you add and update all these sections in a document, it is called a business requirement document. As I said, each company has its BRD template but the content remains similar in all the documents. Therefore, knowing the BRD template is not important but what should be in a BRD is very crucial to know.
This doesn’t end here… a business analyst should have required skillsets and expert in requirement gathering techniques to finish the requirement elicitation process. Let’s understand the important requirement gathering techniques that are being used to gather the business requirements.
Read Also… 7 Essential Roles and Responsibilities of a Business Analyst
How to capture the Business Requirements?
There are many requirement gathering techniques used by business analysts. However, the following are the 5 requirement gathering techniques used very often by the business analysts;
1. Interview – One to One and Group
This is one of the commonly used requirement gathering approaches where a business analyst will schedule meetings to ask a set of questions. The BA will have the questions ready before joining the meeting and these questions will be related to the system to be developed and it will cover all the aspects of it.
Interviews or meetings could be set up with individual stakeholders or a group of stakeholders. Business analysts should be good at finding the right stakeholders to gather the requirements.
2. Wireframing and Prototyping
Wire-framing or Prototyping is a visual approach to gather the requirements. It is the most effective approach because the users or stakeholders will be able to relate the requirements. It draws the blue-print of the to be developed system and it is easy to visualize the business expectation. Business Analysts use various software to draw wireframes or prototypes.
3. Brainstorming
Brainstorming is not new and it is a widely used approach to find a solution to any problem. During the requirement gathering, if business stakeholders are not so sure about the functionality to be added to the system, this approach helps a lot. It is a creative approach to find a solution and generate ideas. You might have multiple ideas but using a brainstorming session, you can refine the best one which makes everyone happy.
4. Document Analysis and Research
Existing documents related to the business processes, current systems, and project documents could be very helpful to understand the business. This helps in getting the basic idea of the system and building strategies to finish requirement gathering.
5. Workshops
When you have to gather the requirements from many stakeholders then you may find an interview and group interview sessions insufficient. In such cases, business analysts use the Workshop technique. Requirement gathering workshop is used to Discover Requirements, refine requirements, Prioritize, and finalize the Scope. However, a business analyst should have strong communication and presentation skills to drive the session.
These were some of the requirement gathering techniques that are used by business analysis. Once you have the requirement, it would be easy to structure them in BRD to get business approvals.
Read Also…
- Exploring The Business Analyst Qualifications – Are You Eligible?
- Key Difference Between Business Analyst And Data Analyst That You Should Know
- Business Analyst vs Business Development | Which Is Best?
Conclusion
Business Requirements Document is one of the key documents prepared and maintained by the business analysts. It is important to have a quality business requirements document to assure the project’s access.
Now, you know the common yet important sections of a BRD and most used requirement gathering techniques that are used to gather the business requirements.
I hope you enjoyed reading this article and it helped you in drafting your powerful business requirement document. Please share it with your friends and colleagues if you liked it and subscribe to the BABeginners mailing list to get the latest post directly to your inbox.
No Responses