Business Requirements Definition version 5.0

Business Requirements Document

ProjectName

Business Requirements Definition

Working Document

ProjectNameDepartmentName

CompanyName

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:

DateVersionNameDescription of Changes

Mar. 1, 20091.0IAG ConsultingInitial Creation

Table of Contents

1Business Requirements Definition

Table of Contents3Introduction4Executive Summary4Purpose of this Document4Business Objectives4Project Objectives4Summary of Scope4Issues4Constraints, Assumptions, Risks, Dependencies5Project Team5Context Diagram6Use Case Diagram7Process Swim Lane Diagram8Requirements9Functional Requirements List9Business Rules List9Non-Functional Requirements List9Information Requirements List10Process Definition111Use-Case-Name12Data Definition14Entity Relationship Diagram14Entity / Use Case Table14Entity-Name15Appendix16Appendix 1 Glossary of Terms and Acronyms16

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 DescriptionResolution

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 uponProject Team

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

NameRole

Context Diagram

Context DiagramUse Case Diagram

Use Case DiagramProcess Swim Lane Diagram

Swim Lane Diagram

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. ID #RequirementUse Case Steps

1.1The system must have the ability to do something with some information under certain circumstances according to business rules.1.1, 2.1

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 RuleFunctional RequirementsEntity Name

Non-Functional Requirements List

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

UsabilityDescribe 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.

ReliabilityDescribe 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.

PerformanceDescribe 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 #RequirementEntity Name

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

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

Process Definition

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

1 Use-Case-Name

Data Flow Diagram

BPMN Diagram

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 stepsPrimary Scenario Detail

1.1 Step-1

Sub-step detail

1.2 Step-2

Sub-step detail Alternate Scenario Detail: Variation-1

1.3 Step-1

Sub-step detail

1.4 Step-2

Sub-step detail Special Considerations

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

Data Definition

Entity Relationship Diagram

Entity Relationship DiagramEntity / Use Case Table

Entity

ActivityEntity 1Entity 2Entity 3Entity 4Entity 5Entity 6Entity 7Entity 8Entity 9Entity 10

Use Case 1C*

Use Case 2R*

Use Case 3D*

Use Case 4

Use Case 5U*

Use Case 6

Use Case 7

Use Case 8

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

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 ElementDescriptionO/M

1/NRules

-idUnique identifier

Appendix

Appendix 1 Glossary of Terms and Acronyms

TermDefinition

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

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

CompanyNameversion 1.0Page 17 of 17

_1297757475.vsdEXTERNAL ENTITY

Process Name

SAMPLE CONTEXT DIAGRAM

_1297757541.vsdProcess Name

Entity

Entity

Entity

EXTERNAL ENTITY

SAMPLE DATA FLOW DIAGRAM

Data

Data

Data

_1297757563.vsdArtifact

Start

Step 1.1

~

+

Decision

Off-page Link

End

Step 1.2

SAMPLE BPMN DIAGRAM

Step 1.3

Step 1.4

_1297757620.vsdEntity 1

Entity 3

Entity 5

Entity 6

Entity 8

Entity 7

Entity 2

Entity 4

SAMPLE ERD DIAGRAM

_1297757500.vsdUseCase1

Actor1

UseCase2

UseCase3

UseCase4

UseCase5

UseCase6

UseCase7

SAMPLE USE CASE DIAGRAM

Actor3

Actor2

_1296034636.vsd

SAMPLE PROCESS SWIM LANE

User Group 1

User Group 2

System

Use Case / Step 1

Use Case / Step 2

Use Case / Step 3

Decision

Use Case / Step 4

Decision

Use Case / Step 5

Use Case / Step 6

Use Case / Step 7

Yes

F

T

Connect

Start

End

No