Business Requirements Document Template
Business Requirements Document Template
Business Requirements Document Template
[Project Name]
Table of Contents
1 Executive Summary
This section describes what the purpose of the document is. Its usually short, so that
someone can read it quickly and decide if it is the document they are looking for.
For example:
This Business Requirements Document (BRD) outlines the requirements for the XYZ
Solution project. It contains both functional and non-functional requirements, an overview of
the current process, as well as the proposed process once the solution is implemented. It is
used to determine what needs to be done, and as a starting point for solution design.
2 Project Description
This section describes the project that this BRD is being written for. It may explain the
purpose of the project, the current solution, any issues that are being faced, and why its
being done.
3 Project Scope
This section describes the scope of the project at a high level. It is kind of a summary of the
business requirements, so people can read this section to understand what is being done,
and what isnt being done.
3.1 In Scope
The following areas are in scope for this project:
Point 1
Point 2
Point 3
Point 4
Point 5
Point 1
Point 2
Point 3
Point 4
Point 5
4 Business Drivers
This section details the business drivers, which are the reasons why the business is
initiating this project. Why is it being done? Some common answers are:
5 Current Process
This section contains the current process that is related to this system. Its usually a process
that the business follows, that the solution aims to improve or resolve.
This can be included as either a diagram, or a list of steps. Diagrams are preferred, as they
can visually communicate processes easier.
Diagrams can be done in Microsoft Visio, otherwise, you can do them in Microsoft Word.
6 Proposed Process
This section details the proposed process, which is the process that will occur after the
solution is implemented. Perhaps more volume will be handled, or some steps are removed,
or several systems are integrated. This will depend on your project.
It should be in a consistent format to the Current Process above, so readers can switch
between the two and see the differences.
7 Functional Requirements
This is the main section and will detail the functional requirements of the project. The Priority
table describes what each of the priorities stand for, and each section below includes the
requirements
7.1 Priority
The requirements in this document are divided into the following categories:
The brackets at the end of each heading indicate the acronym given to each sections
requirements, and is used to identify the section. You should change this for each heading.
For example, a section on Authentication may be labelled AUT, and all requirements will be
labelled AUT 1, AUT 2, and so on.
Add a new number for each section by going to Insert > Quick Parts > Field. Select the Seq
type, and give it a unique value that matches this abbreviation, such as SEQ RQA.
ID: The unique ID number of this requirement. Has a number which changes
automatically
Raised By: The name of the person who raised this requirement.
8 Non-Functional Requirements
This section includes all of the non-functional requirements for the solution, such as
processing time, concurrent users, availability, etc.
This can be filled out in a similar way to the Functional Requirements section.
ID Requirement
NFR 1
NFR 2
NFR 3
NFR 4
NFR 5
NFR 6
NFR 7
NFR 8
NFR 9
9 Glossary
This section explains all of the terms and abbreviations that were used in this document, for
those who are unfamiliar with them. Not everybody who reads this document will understand
all of the terms, so this section is helpful.
Term Explanation
10 References
This section contains links to all other places that were referred to in this document. These
may include:
Web sites
Name Link
11 Appendix
This section may include any other information that does not fit in the document above. This
may include:
Analysis of existing process and benefits for the Business Drivers section.
12 Document History
This section details the history of the document at each version. Its good to know what has
changed in each version, by who, and when it happened.