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 Klariti tutorial will explain how to write a Business Requirements Document and how it relates to Systems Requirements Specification (SRS or SRD) and Functional Specifications.

Download Now for only $9.99

Download Action Plan Template

[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.

Click here to download your Business Requirements Specification Template

Business Requirements

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]

Thousands of templates to jump start your project

Acceptance Test Plan

Contingency Plan

Software Development Templates

Acquisition Plan

Conversion Plan

Software Requirements Specification

Action Plan

Cost Benefit Analysis

Software Testing

API Documentation

Database Design

Standard Operating Procedures (SOP)

Audience Analysis

Datasheet

Statement of Work

Availability Plan

Deployment Plan

System Administration Guide

Bill of Materials

Design Document

System Boundary

Business Case

Disaster Recovery Plan

System Design Document

Business Continuity

Disposition Plan

System Specifications

Business Plan

Documentation Plan

Technical Writing Templates

Business Process

Employee Handbook

Test Plan

Business Requirements

Error Message Guide

Training Plan

Business Rules

Expression of Interest

Transition Plan

Capacity Plan

Fact Sheet

Troubleshooting Guide

Case Study

Feasibility Study

Use Case

Change Management Plan

Functional Requirements

User Guide

Communication Plan

Grant Proposal

Verification and Validation Plan

Concept of Operations

Implementation Plan

White Papers

Concept Proposal

Installation Plan

Work Instructions

Configuration Management Plan

Interface Control Document

Software Development Templates

Acceptance Test Plan

Maintenance Plan

Software Requirements Specification

Acquisition Plan

Market Research

Software Testing

Action Plan

Marketing Plan

Standard Operating Procedures (SOP)

API Documentation

Needs Statement

Statement of Work

Audience Analysis

Operations Guide

System Administration Guide

Availability Plan

Policy Manual

System Boundary

Bill of Materials

Project Plan

System Design Document

Business Case

Proposal Manager Templates

System Specifications

Business Continuity

Proposal Template

Technical Writing Templates

Business Plan

Quality Assurance Plan

Test Plan

Business Process

Release Notes

Training Plan

Business Requirements

Request for Proposal

Transition Plan

Business Rules

Risk Management Plan

Troubleshooting Guide

Capacity Plan

Scope of Work

Use Case

Case Study

Security Plan

User Guide

Change Management Plan

Service Level Agreement (SLA)

Verification and Validation Plan

Communication Plan

Setup Guide

White Papers

Concept of Operations

Social Media Policy

Work Instructions

Concept Proposal

Contingency Plan

 

Configuration Management Plan

Conversion Plan