C hapter 6

Templates

T his chapter contains templates for artifacts that the BA is responsible for or con-
tributes to. As described in the Business Requirements Document (BRD) template
that follows, the manner in which BA documentation is compiled into larger, aggre-
gate documents is non-standard in the industry. This chapter provides a suggested tem-
plate for a comprehensive BRD, an alternative configuration into a number of documents,
each with its own focus, and separate templates for each of the individual types of require-
ments documentation so that these may be easily reconfigured as required for the project.
The BRD template supports ITIL guidelines and is methodology-neutral, using generic
headings wherever possible, with suggestions about what artifacts to include in each sec-
tion based on the approach used in the project.

Business Requirements Document (BRD) Template

At present, there is no universally accepted standard in the industry for the contents of a
BRD, with practices varying widely based on what the subject of the document—the “busi-
ness requirements”—actually refer to. In the following template (and throughout this
book), a business is a private or public organization (such as a government department); a
requirement is a capability that a solution must provide or a condition that it must meet;
and a business requirement is any requirement made on behalf of the business (i.e., one that
originates from the business side), whether the target of the requirement is the business
area or the IT system. (In other usages, for example, the term may refer only to high-level
business objectives and requirements.) The Business Requirements Document, as described
in the template included in this handbook, consolidates all of the requirements stemming

241
242 Chapter 6 ■ Templates

from the business and conforms, in principle, to the concept of the Requirements Package
referred to by the BABOK®. (The BABOK® does not use the term BRD.)
Ideally, the BRD is an electronic assembly of smaller components placed under version
control. The level of detail that is viewable in the BRD should be adjustable as appropri-
ate for its intended readers. Separate housing of the subdocuments should allow them to
be assembled into various other packages and views, as appropriate.
An example of an alternative configuration for the documentation follows the BRD tem-
plate.

Business
Requirements
Document
Project No. ___________
Priority ______________
Target date: __________

Approved by:

Name, Department Date

Name, Department Date

Name, Department Date

Prepared by: ____________ Date: ____________

Version no.:
 Business Requirements Document (BRD) Template 243

The template is generic with respect to methodology while providing guidance on tailor-
ing it to specific approaches, such as use-case analysis, structured analysis, UML, and
BPMN.

BRD Table of Contents

Version Control
Revision History
RACI Chart
External References
Glossary
Executive Summary
Overview
Background
Objectives
Requirements
Proposed Strategy
Product/Solution Scope
Included in Scope
Excluded from Scope
Constraints
Business Case
Business Services and Processes
Impact of Proposed Changes on Business Services and Processes
Business Service and Process Overview Diagrams
Business Process Workflow Requirements
Business Service Level (Non-Functional) Requirements
Actors
Workers
Business Actors
Other Systems
Role Map
Business Rules
State Diagrams
244 Chapter 6 ■ Templates

IT Requirements
User Requirements
User Task Overview Diagram
User Task Descriptions
IT Service Level (Non-Functional) Requirements
System State Requirements
Testing State
Disabled State
Static Model
Static Model: Diagrams
Multiplicity Rules Table
Entity Documentation
Test Plan
Quality Assurance Responsibilities
QA Standards and Guidelines
Review and Audit Plan
Quality Records
Tools, Techniques, and Methodologies
Testing Activities
Preparatory Activities
White-Box Testing
“Fit for Purpose” Testing
Non-Functional Testing
User-Acceptance Testing
Deployment Plan
Training
Conversion
Scheduling of Jobs
Rollout
End-User Procedures
Post-Implementation Follow-Up
Other Issues
Sign-Off
 Business Requirements Document (BRD) Template 245

Version Control
(Track revisions made to this document in Table 6.1.)

RACI Chart
The RACI chart in this subsection of the BRD describes the roles played by team members
and stakeholders in the production of the artifact. RACI is an acronym for Responsible,
Accountable, Consulted, and Informed, representing the ways that a stakeholder may be
involved with a process or an artifact. The following codes are used in Table 6.2. Note that
an additional Supports classification has been added to further clarify roles associated with
this document:
* Authorize Has ultimate signing authority for any changes to the document.
R Responsible Responsible for creating this document.
A Accountable Accountable for accuracy of this document (for example, the
project manager).
S Supports Provides supporting services in the production of this document.
C Consulted Provides input.
I Informed Must be informed of any changes.

External References
(In Table 6.3, list all other documents referenced in this document.)

Glossary
(List all terms, acronyms, and abbreviations used in this document, and provide defini-
tions or links to entries in the project Glossary.)

Executive Summary
(This is a one-page summary of the document, divided into the following subsections.)

Overview
(This subsection of Executive Summary is a one-paragraph introduction that explains the
nature of the project.)

Background
(This subsection of Executive Summary provides details leading up to the project that
explain why the project is being considered. Discuss the following where appropriate:
marketplace drivers, business drivers, and technology and other drivers.)
246 Chapter 6 ■ Templates

Table 6.1 Revision History

Version # Date Authorization Responsibility (Author) Description
 Business Requirements Document (BRD) Template 247

Table 6.2 RACI Chart for This Document

Name Position * R A S C I

Table 6.3 External References

Document Location Publisher Author

Objectives
(This subsection of Executive Summary details the business objectives addressed by the
project.)

Requirements
(This subsection of Executive Summary is a brief summary of the requirements addressed
in this document.)

Proposed Strategy
(This subsection of Executive Summary recommends a strategy for proceeding based on
alternatives.)
248 Chapter 6 ■ Templates

Product/Solution Scope
(Following is a brief description of what is to be included and excluded from the product
or solution, divided into the following subsections.)

Included in Scope
(This subsection of Product/Solution Scope is a brief description of the business area and
services covered by the product or solution.)

Excluded from Scope

(This subsection of Product/Solution Scope briefly describes business areas and services
not covered by the product or solution.)

Constraints
(This subsection of Product/Solution Scope lists predefined requirements and conditions.)

Business Case
(Describe the business rationale for this project and document Critical Success Factors
[CSFs]. This section may contain estimates on cost/benefit, Return on Investment [ROI],
payback [length of time for the project to pay for itself], market-share benefits, and so
on. Quantify each cost or benefit so that business objectives may be measured after imple-
mentation. )

Business Services and Processes

(Complete this section if the project involves changes to the workflow of business ser-
vices and processes. Include all impacted business services and processes, regardless of
whether or not they have an IT component.)

Impact of Proposed Changes on Business Services and Processes

(Summarize the impact of changes on the business area in Table 6.4 by identifying the
business services and end-to-end processes impacted by the project. If your project
employs business use-case modeling, model each end-to-end process as a business use
case. If your project is using Structured Analysis, model each as a high-level process.)

Business Service and Process Overview Diagrams

This subsection of Business Services and Processes provides an overview of the business
processes impacted by the project. Include diagrams that depict new or changed business
services and processes and link them to the actors that initiate them or participate in car-
rying them out. Include all impacted business services—regardless of whether they have
an IT component or not.
 Business Requirements Document (BRD) Template 249

Table 6.4 Impact of Proposed Changes on Business Services and Processes

Business [N]ew/ Desired Current Stakeholders/ Priority
Service or [C]hanged Functionality Functionality Systems
Process (If a Change)

If your project is using the business use-case modeling approach, include business use-
case diagrams here, indicating business service and end-to-end business processes as
business use cases.
If your project is using Structured Analysis, include business-perspective Data Flow Dia-
grams (DFDs), indicating business services and end-to-end business processes as well as
External Entities (actors); model process input and output requirements using data flows.

Business Process Workflow Requirements

This subsection describes the workflow for each business service and process impacted
by the project. If necessary, describe existing (As-Is) workflow as well as the new (To-Be)
workflow. Workflow diagrams (swimlane workflow diagrams, activity diagrams, BPDs,
etc.) are the preferred documentation for cross-functional processes because of the way
they visually convey the responsibilities of each participant. (See the BA Toolkit chapter
of this book for details on each diagram type.) Diagrams may be augmented with, or sub-
stituted by, text, typically using a template included as part of the methodology used on
the project.
If your project is using the business use-case modeling approach with UML, document
the interaction with the business area textually (for example, using the Business Use-Case
Description Template provided in this chapter) and augment with an activity diagram if
the flows connect in complex ways. Document the internal workflow used to carry out
the process graphically, using activity diagrams with partitions.