You are on page 1of 17

BUSINESS REQUIREMENTS DEFINITION

WORKING DOCUMENT

ProjectName
DepartmentName

CompanyName

Business Requirements Document

ProjectName

This template was created by IAG Consulting for use as is. While we
have used reasonable care and skill in the creation of this template, we
do not warrant and we exclude all liability (whether arising in contract,
tort or otherwise) for the accuracy, completeness or suitability of the
content of this template and your use of it.

Revision History:
Date

Version

Name

Description of Changes

Mar. 1, 2009

1.0

IAG Consulting

Initial Creation

CompanyName

version 1.0

Page 2 of 17

Business Requirements Document

ProjectName

TABLE OF CONTENTS
BUSINESS REQUIREMENTS DEFINITION..........................................................................1
TABLE OF CONTENTS.........................................................................................................3
INTRODUCTION.................................................................................................................... 4
Executive Summary.......................................................................................................................................... 4
Purpose of this Document................................................................................................................................. 4
Business Objectives.......................................................................................................................................... 4
Project Objectives............................................................................................................................................. 4
Summary of Scope............................................................................................................................................ 4
Issues................................................................................................................................................................ 4
Constraints, Assumptions, Risks, Dependencies..............................................................................................5
Project Team..................................................................................................................................................... 5
Context Diagram............................................................................................................................................... 6
Use Case Diagram............................................................................................................................................ 7
Process Swim Lane Diagram............................................................................................................................ 8

REQUIREMENTS.................................................................................................................. 9
Functional Requirements List............................................................................................................................ 9
Business Rules List........................................................................................................................................... 9
Non-Functional Requirements List....................................................................................................................9
Information Requirements List........................................................................................................................10

PROCESS DEFINITION......................................................................................................11
1

Use-Case-Name...................................................................................................................................... 12

DATA DEFINITION.............................................................................................................. 14
Entity Relationship Diagram............................................................................................................................ 14
Entity / Use Case Table................................................................................................................................... 14
Entity-Name.................................................................................................................................................... 15

APPENDIX........................................................................................................................... 16
Appendix 1 Glossary of Terms and Acronyms..............................................................................................16

CompanyName

version 1.0

Page 3 of 17

Business Requirements Document

ProjectName

INTRODUCTION
Executive Summary
This section should describe the purpose of the BRD, the intended audience for the document, and a
summary of the objectives, scope and description of the requirements.

Purpose of this Document


Describes the purpose of the document, and the intended audience.

Business Objectives
Describe objectives that will be used to measure the success of the project. The standard for any
objective is that it meets the SMART properties, which are:
Specific
Measurable
Attainable
Results-Oriented
Time-Bounded
Objective#1

Project Objectives
Describe the product(s) or service(s) being proposed by this project to positively impact the business.
Objective#1

Summary of Scope
Please refer to the complete document as a definition of scope. The following is a summary of
the in scope and out of scope activities and scenarios:
In Scope Activities:

In Scope Scenarios:

Out of Scope:

Issues
Issue Description

CompanyName

Resolution

version 1.0

Page 4 of 17

Business Requirements Document

ProjectName

Constraints, Assumptions, Risks, Dependencies


Describe factors which limit the project including:
Constraints factors which inhibit the projects ability to deliver
Assumptions decisions made about scope, functionality, interfaces, etc. which must be confirmed
Risks quantifiable losses to the business as a result of not proceeding or as a result of failure of the
project
Dependencies an external need which the projects completion is contingent upon

Project Team
The following team members were integral in the development and contributions to this
specification:
Name

CompanyName

Role

version 1.0

Page 5 of 17

Business Requirements Document

ProjectName

Context Diagram

Context Diagram

CompanyName

version 1.0

Page 6 of 17

Business Requirements Document

ProjectName

Use Case Diagram

Use Case Diagram

CompanyName

version 1.0

Page 7 of 17

Business Requirements Document

ProjectName

Process Swim Lane Diagram

Swim Lane Diagram

CompanyName

version 1.0

Page 8 of 17

Business Requirements Document

ProjectName

REQUIREMENTS
Functional Requirements List
The following list represents the functional business requirements for the ProjectName System.
Each requirement relates to a Step of a Use Case described and modeled in the specification.
Detailed functionality, business rules, constraints and conditions for each of these requirements
can be found in the detailed description of the component associated with the requirement.
The ID # should be uniquely created to tie back to the Use Case Step for which it is first a
requirement. Use Case steps for which this is a requirement should be listed in the Use Case
Steps column.
Req. Requirement
ID #

Use Case
Steps

1.1

1.1, 2.1

The system must have the ability to do something with some


information under certain circumstances according to business rules.

Business Rules List


The following list represents the business rules related to the ProjectName System.
Each Business Rules relates to one or more Functional Requirements and/or Data Entities
described in the specification as noted in the Functional Requirements and Entity Name
columns.
Rule
ID #

Business Rule

Functional
Requirements

Entity Name

Non-Functional Requirements List


The following list represents the non-functional requirements for any solution that also meets the
functional requirements.

USABILITY
Describe any requirements as it relates to making the system more efficient to use, easier to
learn, or more satisfying to use.
e.g., Ninety percent of all users must be able to use all of the functions of the system after one days
training.

RELIABILITY
Describe any requirements as it relates to the times-to-failure of the entire system based on the
life distributions of the components from which it is composed.
e.g., the mean time to failure for the entire system must be at least six months.
CompanyName

version 1.0

Page 9 of 17

Business Requirements Document

ProjectName

PERFORMANCE
Describe any requirements as it relates to system availability and response time.
e.g., Response time must be within 2 seconds for 90% of all transactions

SECURITY & ACCESS CONTROLS


Describe any requirements as it relates to access, user roles and security.
e.g., User authentication shall be via the corporate Single Sign-on system.

SUPPORTABILITY
Describe any requirements as it relates to: testability, extensibility, adaptability, maintainability,
compatibility, configurability, serviceability, installability, localizability (internationalization)
e.g., System upgrades must be performed with no impact on availability, 90% of the time.

OTHER
Many organizations may have additional Non-Functional Requirements to be formally
considered. They may include but are not limited to: Audit, Disaster Recovery and Business
Continuity, Data Retention, $Documentation & Training, Privacy, Volume & Scalability,
Infrastructure, Application Controls, Sarbanes-Oxley impacts.

Information Requirements List


The following list represents the business data requirements for the ProjectName.
Note: Each requirement relates to an Entity described and modeled in the Data Definition
section of the specification. Detailed definitions and Business Rules for each of these
requirements can be found in the detailed description of the Entity associated with the
requirement.
Req.
ID #

Requirement

Entity Name

EN.1 The system must have the ability to add/modify/delete Entity data
according to business rules.

Entity Name

EN.2 The system must have the ability to do something with some
information under certain circumstances according to business rules.

Entity Name

CompanyName

version 1.0

Page 10 of 17

Business Requirements Document

ProjectName

PROCESS DEFINITION
Copy and paste blank Use Case template below and modify to include detail for Use Cases in scope for
your project.

CompanyName

version 1.0

Page 11 of 17

Business Requirements Document

ProjectName

1.1. Use-Case-Name

Data Flow Diagram

BPMN Diagram

CompanyName

version 1.0

Page 12 of 17

Business Requirements Document

ProjectName

SUMMARY
SUMMARY USE CASE NARRATIVE
Brief description of the Use Case.

TRIGGERING EVENT(S) AND PRE-CONDITIONS

OUTCOME(S) AND/OR POST-CONDITIONS

LIST OF USE CASE SCENARIOS


Primary Scenario

High-level steps

Variation-1

High-level steps

PRIMARY SCENARIO DETAIL


1.1.1.1 Step-1

Sub-step detail

1.1.1.2 Step-2

Sub-step detail

ALTERNATE SCENARIO DETAIL: VARIATION-1


1.1.1.3 Step-1

Sub-step detail

1.1.1.4 Step-2

Sub-step detail

SPECIAL CONSIDERATIONS
Include design considerations, non-functional requirements, legal, regulatory, etc.

CompanyName

version 1.0

Page 13 of 17

Business Requirements Document

ProjectName

DATA DEFINITION
Entity Relationship Diagram

Entity Relationship Diagram

Use Case 2

Entity 10

Entity 9

Entity 8

Entity 7

Entity 6

Entity 5

C*

Entity 4

Use Case 1

Entity 3

Activity

Entity 1

Entity

Entity 2

Entity / Use Case Table

R*
D*

Use Case 3
Use Case 4
Use Case 5

U*

Use Case 6
Use Case 7
Use Case 8

* C Create, R Remove, U Update, D Display

CompanyName

version 1.0

Page 14 of 17

Business Requirements Document

ProjectName

ENTITY-NAME
DEFINITION
Describe the information that will be saved in this entity and how it will be used.

DATA
The system shall provide for the following data elements and business rules:

Data Element

Description

-id

Unique identifier

O/M1

1/N

Rules

Note: O = Optional, M = Mandatory, 1 = Single Value, N = Multi-Valued.

CompanyName

version 1.0

Page 15 of 17

Business Requirements Document

ProjectName

APPENDIX
Appendix 1 Glossary of Terms and Acronyms
Term

CompanyName

Definition

version 1.0

Page 16 of 17

Business Requirements Document

ProjectName

Note to Author
(delete from final deliverable)
Throughout this document there is instruction text which should be removed prior to publishing.
For detailed instructions on the use of this template, please review the participant guide for the
Documenting Requirements course.
Hint: To begin entering specifications for a new Use Case or Entity copy and paste the blank
Use Case or Entity template and then update with your detail.

Last Page

CompanyName

version 1.0

Page 17 of 17

You might also like