Business Requirements Document

<>

<>

<< Project Name and Number>>

Business Requirements Document

Client:
Author:	<< Person who created the document >>
Version:	<< First version should be 1.0 and increment up >>
Status	<< Enter status of document. i.e., Draft, Pending Sign-off, Final, et cetera >>
Date:	<< YYYY-MM-DD >>

Submitters OF FINAL DOCUMENT

These signatories confirm this document was submitted by the project team as the requirements for the << Project Name >> Project.

Role	Name	Signature	Date
Project Manager	<< Print name >>		YYYY-MM-DD
Project Lead	<< Print name >>		YYYY-MM-DD
Business Analyst	<< Print name >>		YYYY-MM-DD
<>	<< Print name >>		YYYY-MM-DD

Reviewers OF FINAL DOCUMENT

Identify the individuals who reviewed the BRD and the date that the review was completed. Signatures are not required.

Role	Review Completed	Date
Project Sponsor		YYYY-MM-DD
Client		YYYY-MM-DD
<>		YYYY-MM-DD

APPROVers OF FINAL DOCUMENT

These signatories confirm this document serves as the requirements for the << Project Name >> Project.

Role	Name	Signature	Date
Project / Client Sponsor	<< Print name >>		YYYY-MM-DD
Application Delivery Manager	<< Print name >>		YYYY-MM-DD
<>	<< Print name >>		YYYY-MM-DD

Table of Contents

Table of Contents 3

Introduction 4

Business Requirements 6

Assumptions, Dependencies and Constraints 7

Glossary 8

Introduction

Purpose of the Business Requirement Document

The Business Requirements Document (BRD) clearly states the functions and capabilities that the application and/or system must provide for the project to be successful (what the system and/or application must do). All known constraints, assumptions and dependencies must also be clearly defined.

The BRD is the basis for all subsequent project planning, design and coding. It should describe as completely as known at this time, the system’s behaviours under various conditions. The BRD does NOT contain design information or anything related to how the system will provide the functionality.

Project Background

<< Provide an introduction to the Project. This includes describing the business context of the project and an overview of the client’s operation. Include a high-level overview of each of the business areas. >>

Project Scope

<< Define the scope of the solution, not the project. >>

Project Purpose

<< State the purpose of the project. What is the system going to help the client achieve? How do you know that the system delivered meets the needs of the client? >>

Stakeholders

<< Identify the stakeholders who have a stake in the project – departments, their clients, anyone that the system is going to provide information to or collection information from. Identify the stakeholder and describe their stake in the system. >>

Business Requirements

Functional Requirements

#	Requirements	Priority H - High M – Medium L – Low	Additional Information
1	The system MUST…
2	The system SHOULD…
3	The system COULD…
4	The system WON’T…

Non-Functional Requirements

#	Requirements	Priority H - High M – Medium L – Low	Additional Information
1	The system MUST…
2	The system SHOULD…
3	The system COULD…
4	The system WON’T…

Assumptions, Dependencies and Constraints

Assumptions

Identify any assumptions; factors that, for planning purposes are considered to be true, real or certain without proof or demonstration

#	Assumptions
1

Dependencies

Identify any factors that are linked together where each has some effect on the other. These may include things like availability of project resources, users or stakeholders, equipment, business processes and regulatory approvals.

#	Dependencies
1

Constraints

Identify any factors that limit or place constraints on the development of the solution. These may include but are not limited to regulatory, technological or business realities.

#	Constraints
1

Glossary

Item	Description
BA	Business Analyst
BRD	Business Requirements Document
PM	Project Manager
RTM	Requirements Traceability Matrix

Business Requirement Document	Page of
Template Version #, <>
document number V#