Business Requirements Document (BRD)

BRD, an acronym of Business Requirements

Document is widely accepted structured document for project requirements which
defines what should be delivered in order to gain value in the project. This document is
designed to assist with the project management and the implementation during the
entire life cycle of the project. Business requirements are consist of both functional and
non-functional requirements which lead to creation or update of product, system or a
software. BRD mainly emphasize on what should be the end result and it doesnt bother
how the objective is achieved.
There are many variants of BRD known to people like SRS (System Requirement
Specification) or SRD (System Requirement Document) and FSD (Functional
Specification Document). BRD can be described as a mode of communication in
completion of a project. The main objectives of a BRD are as below:

1. It should be simple and all the involved stakeholders should agree to it.
2. It should contain more business requirements rather than technical
requirements, as the main motto of a BRD is what to achieve and not how
to achieve.
3. It should describe the business needs in clear and concise manner.
4. It should have a logical flow and can be used as an input for next
phase of the project.
The purpose of a BRD is to describe the end solution to the business requirement and
what steps should be followed in order to satisfy those needs. The BRD should refer to
the details of the existing business state and what the business owners are planning to
change in the future. Since BRD can be used as a base in the development of any
project, it should involve different stakeholders and all of them should be agreed at
common points before kick-off of the project. The possible stakeholders involved in the
development of a BRD are:

Business owner representative

Development team representative
 Subject Matter Expert
Maintenance team representative
Each of the above stakeholders should share their views and are given roles as per
the RACI (Responsible, Accountable, Consulted and Informed) matrix at the time of
document designing and the same should be followed throughout the project life-cycle.

BRD development is a team work and thus it should be clearly defined in the beginning
that who should be in the team and what work should be assigned to them. Nobody is
perfect in his work, so all the strengths and limitations should be described before the
project kick-off. There is no space for business assumptions in future so all the
assumptions and constraints should be well defined and discussed in the BRD.

There are certain prerequisites which should be cleared before designing BRD; some
bullet points are as below:

1. All the stakeholders (or project team) with designation should be

defined and described well to everyone.
2. Current environment assessment should be done which includes the
following
How business operates currently and what changes are to be
done in the future scope
Start and end point of the processes followed in the organization
Baseline information of the project
Risk assessment
3. Current performance acceptance parameters with all the variations
and tolerance
4. Support guidelines followed by business currently.
As mentioned previously, BRD should have a logical flow and easy to understand. The
most acceptable contents of a BRD are as below:

Objective of the project

Current business state, environment and system assessment
Business changes to be done
Process detail and stakeholders(with RACI) details
Accepted assumptions and constraints in the project
Impact(or Risk) Analysis
Functional Requirements
Non-functional Requirements
Schedule and Budget (optional when BRD is shared with technical
team)
Terms and Conditions (Legal information)
Finally the document should contain the the business partner sign-off with the details of
the review, comments and signature of the business partners.