How to Write a Business Requirements Document (BRD)

Summary: The purpose of Business Requirement Document (BRD) is to describe in objective terms how the business solution will meet your customer’s needs and expectations.

This tutorial explains how to write a Business Requirements Document and how it relates to Systems Requirements Specification (SRS or SRD) and Functional Specifications.

Download Now!

[Learn more about these Business Requirements Specification templates]

BRD Templates – Use this Business Requirements Specification template (MS Word 24 pages) to capture the current and future needs of your business. This template pack includes a 24-page Business Requirements Specification, Use Case, Requirements Traceability Matrix and Data Model templates in Microsoft Word, Excel and Visio.

How to Write Business Requirements Specifications

If you’ve been asked to write Business Requirements Specifications (aka BRS) and don’t know where to start, then pull up a chair and we’ll show you how.

There are three immediate problems with writing Business Requirements Specifications. Once we look at these three – and define what each one should do – then writing the BRS gets much easier.

 

Business Requirements Specifications: How to Define

The problems are the words:

• Business
• Requirements
• Specifications

While each of these makes sense by itself, when you merge them together, they seem to cause confusion. I feel it may be that when we think of Requirements, we associate it to functional requirements.

When we write specifications, it is technical specifications, not business specifications that come to mind.

So where do we start with Business Requirements Specifications?

Let’s look at requirements. There are three levels of requirements.

• Business Requirements – these identify the company’s high-level objectives; these also in the Vision and Scope Document. Your business requirements are often the ‘driver’ of the project’s success. After all, the project was probably initiated to address gaps or needs in the business operations.
• User Requirements – these describe how the user (i.e. the person who will use the application in the real world) wants it to work. It has nothing to do with the underlying technology or business needs; it’s how the user want the system to perform. Most business analysts capture these in Use Case diagrams.
• Functional Requirements – once we know what the user wants, we can describe how the software/hardware/device will function in the functional requirements document (FRD). To do this correctly, we list each behavior that the software must exhibit, for example, what it needs to start a process and what it delivers on the other side.

We also need to capture non-functional requirements in the Software Requirements Specification (SRS).

What is Business Requirement Specification?

A short definition of the Business Requirements Specification should also help.

The Business Requirements Specification (BRS):

• Describes a business solution in terms of customer needs
• Captures the clients expectations
• Is used as a starting point by the software development team when designing the solution

Objectives of the Business Requirement Specification

Of course, it varies from project to project, but most will have the following in common:

The objectives of the Business Requirements Specifications are to:

• Help stakeholders reach consensus and approve funding for the project
• Serve as a reference point for all communications between the business and development.
• Provide input into the next phase for this project, i.e. developing functional and technical specs
• To clarify what is out of scope, i.e. which requirements will not be developed. This reduces assumptions and expectations that may otherwise arise.

Developing the Business Requirement Specification

The next task is to identify who should be involved in writing the BRS. At a minimum, you need the following:

• Business Owners – these represent the business and will share what the business wants to achieve. They are also responsible for identifying any risks and issues that may impact the solution.
• Process Owner – this person (or team) is responsible for developing the process flows and use cases that illustrate how the business currently functions and designing use cases that show how the business will perform when the solution is developed.
• Subject matter experts – these have in-depth knowledge of how the business operates. They are responsible for answering questions from the business analysts on how processes currently work, what gaps exists, and recommendations for improvements.
• Project Manager – is responsible for ensuring the business analysts deliver the BRS on schedule; that it is signed off by all parties and shared with the software development team for analysis.

Other individuals who may be involved in the process include the Change Manager, Product Manager, Quality Manager and IT management as needed.

Business Requirements Excel spreadsheet template

[Learn more about these Business Requirements Excel templates]

Prerequisites for Developing Business Requirement Specification

There are two main prerequisites for the BRS to succeed:

• Project Charter – The first prerequisite for the Business Requirements Specifications is the Project Charter. The Business Requirements Specification allows you to review the Project Charter and ensure that its objective, goals, scope, team, and approvers are correct.
• Current Environment Assessment – The second prerequisite is a current environment assessment. This includes a process map of the current environment highlighting areas that will be changed during the project.

Next Steps

In the next tutorial, we will look at how to develop use cases, how to write the table of contents for the BRS, and how to develop business rules.

[Learn more about these Business Requirements Specification templates]