Information Technology Division (ITD)
<Project Name>
Business Requirements Document
March 18, 2016
Version <1.0>
[Note: Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included
to provide guidance to the author and should be deleted before publishing the document. A
paragraph entered following this style will automatically be set to normal (style=Body Text).]
[To customize automatic fields (which display a gray background when selected), select
File>Properties and replace the Title, Subject and Company fields with the appropriate
information for this document. After closing the dialog, automatic fields may be updated
throughout the document by selecting Edit>Select All and right-click on the document. This
brings up the Update Table of Contents dialog box. Select “Update Field” and then select “Update
Entire Table” and press OK.
For Headers and Footers, view the header or footer, select the field and right click on it. Do the
same update process as described above.
<Project Name>
Business Requirements Document
Version: <1.0>
Date: 03/18/2016
Revision History
Date
Version
Description
Author
<dd/mm/yyyy>
1.0
Original structure design
<name>
<dd/mm/yyyy>
<x.x>
<details>
<name>
-1-
<Project Name>
Business Requirements Document
Version: <1.0>
Date: 03/18/2016
Table of Contents
1.
INTRODUCTION / OVERVIEW ......................................................................................................................3
1.1
1.2
SCOPE .............................................................................................................................................................3
DEFINITIONS, ACRONYMS AND ABBREVIATIONS ............................................................................................3
2.
BUSINESS RULES..............................................................................................................................................3
3.
GENERAL REQUIREMENTS ..........................................................................................................................3
4.
FUNCTIONAL REQUIREMENTS ...................................................................................................................3
4.1
4.2
4.3
4.4
4.5
ACTOR PROFILES SPECIFICATION ...................................................................................................................4
ESSENTIAL USE CASE DIAGRAM ....................................................................................................................4
ESSENTIAL USE CASE SPECIFICATIONS ..........................................................................................................4
ESSENTIAL USE CASE DIAGRAM ....................................................................................................................5
FUNCTION HIERARCHY DIAGRAM ..................................................................................................................5
5.
BUSINESS REQUIREMENTS NOT BEING IMPLEMENTED ...................................................................5
6.
ACCEPTANCE ...................................................................................................................................................5
-2-
<Project Name>
Business Requirements Document
1.
Version: <1.0>
Date: 03/18/2016
Introduction / Overview
[The introduction of the Business Requirments Document should provide an overview of the
entire document.
1.1
Scope
[This section of the document should describe the scope of this docuement
1.2
Definitions, Acronyms and Abbreviations
[A reference should be made to the glossary which will contain the definitions for this project]
2.
Business Rules
The goal of defining the business rules for the <project name> is to clarify the data and access
validation efforts to be incorporated into the developed system. This document will provide the
development team with data requirements and validation parameters to be applied when
executing the required functions of the system. Knowing and documenting the <project name>
rules will enable development efforts to be implemented effectively and will also provide the
necessary awareness of these rules to those involved with the system definition efforts.
User roles may also be further “restricted” based on additional parameters and these too will need to be
provided in developing specifications for the system and for the system security model. This document
will not define rules related to roles and authority.
Business Rule and Validation Requirements
3.
Rule Type
(Data Validation,
Business Constraint,
Computation)
General Requirements
This section describes general requirements.
4.
Functional Requirements
This section describes the Functional requirements part of the Business Requirements. In Use
case approach, the Functional Requirements comprises of Actor Profile Specification, Essential
-3-
<Project Name>
Business Requirements Document
Version: <1.0>
Date: 03/18/2016
Use case diagram and Essential Use case specification in narrative text form. In Oracle Designer
approach the Functional Requirements comprises of Business Unit Definition Report, Function
Hierarchy Diagram and Function Definition Report
4.1
Actor Profiles Specification
This section describes all the Actors and their profiles within the context of the Business
Requirements being documented. An Actor is a person, organization or an external system/subsystem/program that has interactions with the Application. Actors, by definition, are external to the
system with which they are having interactions. Actors have goals that are achieved by use
cases. Typically, Actors have behavior and are represented by the roles they play in the use
cases. An Actor stimulates the system by providing input and/or receiving something of
measurable value from the system.
4.2
Essential Use Case Diagram
This section is applicable only to Use case approach. This section depicts the Business
Requirements in the form of Essential Use case diagram. In the Use case approach, the
Functional Requirements are decomposed into a number of Essential Use cases. Essential use
cases are of primary importance early in a project’s requirements/analysis phase. Their purpose
is to document the business process that the Application must support without bias to technology
and implementation.
4.3
Essential Use Case Specifications
This section is applicable only to Use case approach. This section describes each Essential Use
case in narrative text form. A use case typically has one basic course of action and one or more
alternate courses of actions. The basic course of action is the main start-to-finish path that the
use case will follow, where as the alternate courses represent the infrequently used paths and
exceptions, error conditions etc. The complete business logic of a use case such as basic course
of action, alternate course of action, pre-condition, post-condition etc is not depicted in the Use
case diagram. Rather they are documented in narrative style in use case specifications.
Use Case Id : ##
Use Case Name
Description
Actors
Business Rules
List the business rules of Section 3.6 that this use
case references. Mention only the Business rule
Id here. Provide hyperlinks to the business rules
of section 3.6.
Basic Flow
Alternate Flows
-4-
<Project Name>
Business Requirements Document
Version: <1.0>
Date: 03/18/2016
Non-Functional Requirements
Pre-Conditions
Post-Conditions
Extension Points
Extension Condition
Extending Use Case
List of <<included>> use
cases
List of <<extended>> use
cases
List of “inherited from
(parent)” use cases
4.4
Essential Use Case Diagram
This section is applicable only to Use case approach. This section depicts the Business
Requirements in the form of Essential Use case diagram. In the Use case approach, the
Functional Requirements are decomposed into a number of Essential Use cases. Essential use
cases are of primary importance early in a project’s requirements/analysis phase. Their purpose
is to document the business process that the Application must support without bias to technology
and implementation.
4.5
Function Hierarchy Diagram
This section is applicable only to Designer approach. This section depicts the Business
Requirements in the form of Function Hierarchy Diagram (FHD). In the Oracle Designer
approach, the Functional Requirements are decomposed into a number of Business Functions.
5.
BUSINESS REQUIREMENTS NOT BEING IMPLEMENTED
This section describes business requirements not being implemented.
6.
Acceptance
By accepting this Non-Functional Requirements you are agreeing to the details contained in this
document. No changes will be made to this agreement without additional acceptance from each party
signed below.
Project Manager
Name
<approver name here>
Action:
Comments:
Title
<approver title here>
Recommend Approval [ ]
-5-
Role
<approver role here>
Recommend Rejection [ ]
<Project Name>
Business Requirements Document
Version: <1.0>
Date: 03/18/2016
Signature:
Date:
Technical Manager
Name
<approver name here>
Action:
Comments:
Title
<approver title here>
Recommend Approval [ ]
Role
<approver role here>
Recommend Rejection [ ]
Title
<approver title here>
Recommend Approval [ ]
Role
<approver role here>
Recommend Rejection [ ]
Title
<approver title here>
Recommend Approval [ ]
Role
<approver role here>
Recommend Rejection [ ]
Signature:
Date:
Program Area Manager
Name
<approver name here>
Action:
Comments:
Signature:
Date:
PMO
Name
<approver name here>
Action:
Comments:
Signature:
Date:
-6-
<Project Name>
Business Requirements Document
Sponsor
Name
<approver name here>
Action:
Comments:
Version: <1.0>
Date: 03/18/2016
Title
<approver title here>
Recommend Approval [ ]
Signature:
Date:
-7-
Role
<approver role here>
Recommend Rejection [ ]