Writing Quality Business Requirements Document

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. 

Writing Quality Business Requirements Document

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;

  1. assess the requirements
  2. do the GAP analysis
  3. complete the impact and risk assessment
  4. AS-IS and TO-BE analysis
  5. suggest the better alternative if available
  6. 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;

  1. Executive Summary
  2. Document version or history log
  3. Project Overview and Objective
  4. Business requirements
  5. Assumptions and Constraints
  6. Key stakeholders
  7. Project scope
  8. 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;

VersionUpdated ByReasonStatusDate
V0.01Carol LeeConstraint UpdatedUpdate14/01/2020
V0.02Will MathewAdditional Requirements Added related to claim processingUpdate13/04/2020
V1.0Carol LeeDocument ApprovedApproved15/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;

  1. Background of the project
  2. How the project will be fixing an issue or benefit the organization
  3. Why this project was a need of time
  4. What are key stakeholders
  5. Overall goal(s) and business expectations from the project.
  6. 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.RequirementPriority
B01The system should allow users to registerHigh

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. NoNameDesignationDepartmentRole
1Mathew SmithManagerClaimsApprover
2Will SmithDirectorUnderwritingApprover

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.

UATUser Acceptance Testing
SDLCSoftware 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…


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.

Leave a Reply

Top 6 Best Business Analyst Certifications Top 7 Most Wanted Career Paths For The Business Analysts How to become a business analyst without experience