Business Requirements Document Template

Introduction: How to Use This Template

The business requirements document can be used to record the functional, quality, and usability
requirements into formats that are easily consumable for future analysis, architectural and design
activities, and most importantly, in a format that is understandable by all business partners.

To use this template, simply replace the text in dark grey with information customized to your
organization. When complete, delete all introductory or example text and convert all remaining text to
black prior to distribution.

1
Info-Tech Research Group
 [Insert Company Title]

[Insert Title]
Business Requirements Document Template

Version 1.0
[Insert Date]

2
Info-Tech Research Group
Document Revision History
Every change to this document (subsequent to initial sign-off) must be recorded in the revision history
chart below. Modifications to this document will be documented in the following chart. There are no
exceptions. Note that the Project Sponsor and the Project Manager must sign off any changes to the
requirements document.

Document Location: < Insert file path here >

Version Date Author/Editor Description

1.0 January 1, 2016 Full name and title Initial version of this document.

3
Info-Tech Research Group
Related Documentation and Material
List all supporting documentation for this project. Be sure to include all relevant materials, including
Project Charter, Request for Proposals, Business Cases, Master Requirements, Requirements
Checklists, Features Lists, relevant marketing materials, etc. This will be used as a reference point for
others on the project to gain insight into the background of the project, as well as provide direction on
what to research.

The following is a list of documentation directly related to this project:

Name of Document Version Date Document Location

Project Charter 1.0 January 1, 2016 < Insert file path here >
Request for Proposal 1.0 January 1, 2016
Business Case 1.0

4
Info-Tech Research Group
Glossary of Terms and Acronyms
To provide clarity for everyone who references this document and to ensure consistency throughout,
define any terms or acronyms that are commonly used as part of this project. Include terms used both by
a consultant or vendor (if applicable) and the company. Be sure to include any business and IT terms or
acronyms that might also be used. The following chart may be useful.

To provide clarity, terms and acronyms used in this document are defined as follows:

Term / Abbreviation Definition

PDS Project Definition Statement
BRD Business Requirements Document
UML Unified Modeling Language
RFP Request for Proposal
SME Subject Matter Expert

Insert more rows as needed.

5
Info-Tech Research Group
 Table of Contents

Introduction: How to Use This Template................................................................................................. 1

Document Revision History...................................................................................................................... 3
Related Documentation and Material....................................................................................................... 4
Glossary of Terms and Acronyms............................................................................................................ 5
Table of Contents....................................................................................................................................... 6
Introduction................................................................................................................................................ 7
Intended Audience..................................................................................................................................... 7
Project Summary and Background.......................................................................................................... 8
Requirements Gathering.............................................................................................................................. 8
Operating Model...................................................................................................................................... 8
Business Process Model.............................................................................................................................. 8
SIPOC-MC Diagrams................................................................................................................................. 10
Sub-process X....................................................................................................................................... 10
Use Cases................................................................................................................................................. 11
Elicitation Techniques Employed............................................................................................................... 11
Prioritized Requirements List..................................................................................................................... 12
Implementation Considerations............................................................................................................. 13
Assumptions and Constraints.................................................................................................................... 13
Sign-Off – < Version X.X >....................................................................................................................... 13
Appendix A: Communication and Meeting History...............................................................................15

6
Info-Tech Research Group
Introduction
This document provides the requirements for the proposed product name or project name.

Provide a brief overview of this project. You can copy text from the project proposal/charter, paste it here,
and shorten it.

Provide a short description of the product being specified and its purpose, including relevant benefits,
objectives, and goals. Relate the product to corporate goals or business strategies. If a separate vision
and scope document is available, refer to it rather than duplicating its contents here.

The purpose of this document is to record the functional, quality, and usability requirements into formats
that are easily consumable for future analysis, architectural, and design activities, and most importantly in
a format that is understandable by all business partners.

This document is designed to take the reader from a high-level understanding of the business processes
down to the detailed automation requirements.

Intended Audience
This is a brief description of who should be reading this document and what they should get from it.

There are < insert number here > main audiences for this document:

Audience How This Document Will Be Used

Project Sponsor  To understand and approve the requirements which define
the overall scope of the project.
Business Analyst  To review process descriptions and automation requirements
to ensure nothing is missed from their perspective.
 To provide input on requirements priorities.
IT Manager  To provide input into whatever other requirements or design
artifacts are needed to develop the approved requirements.
 To provide input into test plans/sets/cases based on
prioritized requirements.
Business/Stakeholder Manager  To review process descriptions and automation requirements
to ensure nothing is missed from their perspective.
 To provide input on requirements priorities.

7
Info-Tech Research Group
Project Summary and Background
In a paragraph, describe the scope of the project for which you are gathering requirements. This should
come from your project intake form.

Requirements Gathering
Operating Model
The operating model captures on one page key information related to the service/project. Including
governance, business standards, key customers, major&and
Governance sub processes. When building requirements
Leadership
for a project / service you may use multiple techniques at multiple stages to obtain requirements for each.

Standards & Work Practices

Supplier Customer
Processes Processes

Infrastructure

Business Process Model

Use this section to graphically depict the current state of the process. The practice of business process
modeling is used to highlight a need to change a process or to identify issues that need to be corrected.
Use the following information from Sparx Systems to guide in developing a business process model.
A business process is a collection of activities designed to produce a specific output for a particular
customer or market. It implies a strong emphasis on how the work is done within an organization, in
contrast to a product’s focus on what is done. A process is a specific ordering of work activities across

8
Info-Tech Research Group
time and place, with a beginning, an end, and clearly defined inputs and outputs: a structure for action
(Sparx Systems).

Source: Sparx Systems

[For Example]:

You may choose to include a brief description of other processes that are part of a larger process but not
within the scope of this project to give a better picture and understanding to the reader.

9
Info-Tech Research Group
SIPOC-MC Diagrams
A good SIPOC-MC helps establish the boundaries of each process, and provides a concise definition of
the expected outcomes and required inputs. Insert the SIPOC-MC models created throughout the
elicitation phase.

Sub-Process Name

Supplier Input

Process

Output Customer

Metric Control

Sub-process X

10
Info-Tech Research Group
Use Cases
Use cases give projects direction and guidance from the business perspective. Insert any and all use
cases built throughout the requirements gathering process.

Elicitation Techniques Employed

Use this section to inform stakeholders who participated in elicitation, which techniques were employed,
and to verify if requirements were validated by end stakeholders.

Insert the table from the Requirements Gathering Documentation Tool, Identify Stakeholders tab.

Stakeholde Level of Level of Elicitation Requirements

Stakeholder
r Group Influence Impact Technique Validated
Sponsor
Project
Groups
User

11
Info-Tech Research Group
 Architects
Stakeholder
Specialty
Project Team

Prioritized Requirements List

Requiremen
Stakeholder Core Function Description Categorization Priority
t
Performance Should Have
Function #1.1 Security Must Have
Operational & Must Have
Environmental
Performance Must Have

Function #1.2

Function #1.3

12
Info-Tech Research Group
 Function #2.1

Function #2.2

Function #2.3

Function #3.1

Implementation Considerations
Assumptions and Constraints
Few projects begin with absolute certainty. Each assumption is an "educated guess," a likely
condition, circumstance, or event, presumed known and true in the absence of absolute certainty.

Each constraint is a limiting condition, circumstance, or event, setting boundaries for the project
process and expected results. Once identified, these assumptions and constraints shape a
project in specific, but diverging ways – assumptions bring possibilities, and constraints bring
limits (ITtoolkit.com).
The following assumptions and/or constraints have guided the scope and context for this
requirements document:
Assumptions:
E.g. Business subject matter experts will be available 50% of their time for the
requirements gathering phase.
Constraints:
E.g. Limit tool customization to enable future vendor upgrades.

Sign-Off – < Version X.X >

13
Info-Tech Research Group
The undersigned have read and reviewed the contents of the attached Requirements and Use
Case documents and agree they meet the business needs. We approve of what has been stated
and authorize the project team to proceed.

Business Sponsor Date

IT Leader Date

Privacy Compliance Officer Date

< Name >

14
Info-Tech Research Group
Appendix A: Communication and Meeting History
The purpose of this detail is to summarize meetings held during the requirements gathering process.
Keeping this detail is designed to help avoid circular arguments. Fill in all communication and meeting
history in the following table.

Meeting
Version Attendees Details
Date
January 1,
1.0 Full names and titles Focus, key decisions, etc.
2012
….. ….. ….. …..

(Add more rows as necessary).

_____________________________________________________

For acceptable use of this template, refer to Info-Tech's Terms of Use. These documents are intended to
supply general information only, not specific professional or personal advice, and are not intended to be
used as a substitute for any kind of professional advice. Use this document either in whole or in part as a
basis and guide for document creation. To customize this document with corporate marks and titles,
simply replace the Info-Tech information in the Header and Footer fields of this document.

15
Info-Tech Research Group