< Program1 Code: Project Name > <Sub-Project Name (where applicable)> Business Requirements Statement

Version 1.5

27th February 2012

This is the Banner Finance program code for the project this code may be found on the Infrastructure Plan: Initiatives & Strategy Implementation (IP:ISI)
FILENAME AND PATH Page 1 of 14

Business Requirements Statement <NAME OF PROJECT>

DOCUMENT APPROVAL

Name

Position Title

Signature

Date

Joanne Bloggs

Director, ETC

.............................................

.......................

Benvenuto Cellini

Project Manager

.............................................

.......................

Tim Finnegan

Business Analyst

.............................................

.......................

FILENAME AND PATH

Page 2 of 14

Business Requirements Statement <NAME OF PROJECT>

1 Contents
2 3 Purpose of this Document ...................................................................................................................................4 Overview ..............................................................................................................................................................4
3.1 3.2 3.3 3.4 3.5 3.6 Background (Current Situation?) ........................................................................................................... 4 Executive Summary of the Business Need ............................................................................................. 4 Scope of requirements........................................................................................................................... 5 Stakeholder List (and key contacts) ....................................................................................................... 6 Assumptions .......................................................................................................................................... 6 Dependencies ........................................................................................................................................ 7

4 5 6

Business Context Diagram ...................................................................................................................................7 Core Business Objectives .....................................................................................................................................8 Business Requirements ........................................................................................................................................9
6.1 6.2 High Level Business Process Model ....................................................................................................... 9 Requirements....................................................................................................................................... 10

Non-Functional Requirements .......................................................................................................................... 11

7.1 7.2 7.3 7.4 7.5 7.6 7.7 Security ................................................................................................................................................ 11 Availability............................................................................................................................................ 11 Reliability and Recovery ....................................................................................................................... 12 Conversion ........................................................................................................................................... 12 Other Requirements ............................................................................................................................ 12 Volumes / Activity ................................................................................................................................ 12 Data Storage Requirements ................................................................................................................. 12

8 9

Glossary of Terms.............................................................................................................................................. 13 Document Control............................................................................................................................................. 13

FILENAME AND PATH

Page 3 of 14

Business Requirements Statement <NAME OF PROJECT>

2 Purpose of this Document

The Business Requirements Statement details the business requirements as elicited by the business analyst from the key stakeholders. The document presents the requirements in a structured way that facilitates review and sign off by the designated project sponsor. Building on the high level scope of the project as defined in the project definition, the business requirements clearly state in business language what any chosen solution must do. This document captures the business requirements in a structured way, providing the basis for ensuring that the solution delivered meets the requirements. It should: Facilitate a shared understanding for all stakeholders of the business requirements Be the key input for the preparation of a functional requirements specification Facilitate the identification of possible solutions

3 Overview
The information provided here should be concise and to the point in setting the scene, defining boundaries, and adding any necessary clarity for the business requirements that follow. This may include reference to the Project Definition that includes the scope of the project or a separate scoping document.

3.1 Background (Current Situation?)

Describe at a high level, the business problem.

3.2 Executive Summary of the Business Need

Business Directives Problems & Shortcomings with Existing System Opportunities for Improvement List of Legislation/Policies/Guidelines that apply to these requirements

Describe the business objectives being addressed.

FILENAME AND PATH

Page 4 of 14

Business Requirements Statement <NAME OF PROJECT>

3.3 Scope of requirements

Indicate what is in and out of scope. Scope includes what business functions are impacted and organisational scope i.e. what organisational units are covered.

In Scope

Out of Scope

FILENAME AND PATH

Page 5 of 14

Business Requirements Statement <NAME OF PROJECT>

3.4 Stakeholder List (and key contacts)

Name Position Role / interest in this project

3.5 Assumptions
What assumptions are made in eliciting the requirements?. Include internal and external factors, e.g., legislative change.

FILENAME AND PATH

Page 6 of 14

Business Requirements Statement <NAME OF PROJECT>

3.6 Dependencies
What must happen in order to achieve the business need? e.g. executive decisions, commitment of funding and other resources, particular deadlines to be met, implied potential changes to processes at the high level.

3.7 Impacts on other business functions and projects

Outline how this project and its objectives will impact upon other business functions not covered in the scope of requirements.

Example table: Project Objective/Requirement Business function impacted Nature of impact

4 Business Context Diagram

Produce a context diagram that illustrates the essential relationships among actors, processes and information flow. Include, where possible, high level business process diagrams. Ensure that all business entities interacting to the business unit/function being described/documented have been considered.

Example:

Student
Number of allocated scholarships

Student
CSU HDRS Mgmt.
Number of allocated International Scholarships Student publications details P&A census date report

DEEWR
Invoice for All Students

DEEWR

Aus AID
FILENAME AND PATH

Aus AID

Page 7 of 14

Business Requirements Statement <NAME OF PROJECT>

ARC Council

Higher Degree Research Student (HDRS) Management

In this example : The Context of HDRS management viewed from CSU as a whole (in other words all In/Output to external entities/parties). The Context of HDRS Management viewed from Research Masters point of view (in other words all In/Output to internal/external entities/parties.

5 Core Business Objectives

State clearly the objectives to be met by the business solution.

Objective ID number

Core business Objective

Business Owner

Business importance (Mandatory/High Priority/Optional) Mandatory

(E.g.: 1

To track all stock movements in a timely manner.

Warehouse Manager

FILENAME AND PATH

Page 8 of 14

Business Requirements Statement <NAME OF PROJECT>

6 Business Requirements
6.1 High Level Business Process Model
The high level business process model a decomposition from the context diagram. The model may include the high level information inputs and outputs for each process.

FILENAME AND PATH

Page 9 of 14

Business Requirements Statement <NAME OF PROJECT>

6.2 Requirements
The analyst may choose to represent requirements in an alternative fashion to that presented here, e.g., via user stories , scenarios or whatever is appropriate to the situation and audience. At the least, requirements should be easily referenced and have ownership ascribed. The business requirements should include legislative /compliance requirements to be met.

e.g., Manage Warehouse Inventory Requirement ID Business Requirement Owner Mandatory/Highly Desirable /Desirable. Business Process Related to Core Business Objective (may be to more than one) E.g. 1. The Warehouse inventory should be updated within 15 minutes when new stock is received. Warehouse Manager Mandatory Receipt Incoming Stock To track all stock movements in a timely manner.

FILENAME AND PATH

Page 10 of 14

Business Requirements Statement <NAME OF PROJECT>

7 Non-Functional Requirements
This section should cover the commonly needed non-functional requirements that can be identified at business requirements stage. More detailed NFRs will be identified in the functional requirements specification.

This section is used to identify the broader business requirements that apply across the entire system, rather than relate to specific processes.

7.1 Security
Identify: Any need to control access to the solution (e.g. authentication) specify the business need for this, not the solution to how it might be achieved. The classification/sensitivity information/data being handled.

7.2 Availability
This can be approached in two ways: When will the solution need to be used? When will be business processes identified in the Business Requirements (if so) be performed.

E.g.: The Inventory Management solution should be available between 7am to 7pm Monday to Friday, and 10am to 5pm Saturday and Sunday. E.g.: Process Receipt Incoming Stock Operating Hours 7am to 3pm Monday to Friday 10am to 2pm Saturday and Sunday Ship Customer Order 12pm to 7pm Monday to Friday 10am to 5pm Saturday Order Stock 9am to 5pm Monday to Friday 12pm to 5pm Sunday

FILENAME AND PATH

Page 11 of 14

Business Requirements Statement <NAME OF PROJECT>

7.3 Reliability and Recovery

Detail the recovery requirements, e.g. The Inventory Management solution must be available 99% of the time during Available hours. In the event of failure, inventory data must be available within 4 hours, and the ability to maintain inventory for incoming and outgoing stock within 24 hours.

7.4 Conversion
Briefly outline any data conversion/migration requirements.

7.5 Other Requirements

Identify any other overall requirements for the desired solution, such as conformance to standards, specific user interface needs. Consider government standards.

7.6 Volumes / Activity

It is important to be able to predict and plan for increases in processing capacity requirements. With respect to the key processes relating to interactive system functions we will enumerate the expected loads as follows: Ref Process Transactions / Day Transaction / Annum Min 2500 Max 35000

Min Receipt Incoming Stock 10

Max 180

7.7 Data Storage Requirements

All new systems or system functions incur additional storage needs. With respect to the conceptual model perform an initial estimate of storage needs so as to highlight any potential large storage demand as follows: Entity Estimated Volume 350 Additions Per Annum 25 Growth P.A. 8%

Stock Catalogue

Note: Cover the high volume entities or entities that are likely to have a real impact.

FILENAME AND PATH

Page 12 of 14

Business Requirements Statement <NAME OF PROJECT>

8 Glossary of Terms
Term (E.g. HECS Definition Higher Education Contribution Scheme)

9 Document Control
Document Status and Revision History

Version DRAFT 1.2 1.3 1.4

Author C.Cox C.Cox C.Cox C.Cox

Issue date 13th October 26th October 16th November 21st February 2012

Revisions

Draft for review and comment by the BA team Version posted to the project lifecycle framework. The following proposed adjustments to this document relate to the discussion at the FR specification workshop (17/2/12) on how to cover off on two sections of the FR checklist, namely 2.1 Impact on current business processes and 2.2 Legislative and compliance requirements. With regard to section 2.1 , the conclusion reached at the workshop was that the impact on current business processes is already adequately provided for by section 5 Core business objectives combination with section 6.2 Requirements. What have not been explicitly covered are the impacts on other business functions not covered in the scope of requirements. Also the impacts on other projects. The proposed changes therefore are:

FILENAME AND PATH

Page 13 of 14

Business Requirements Statement <NAME OF PROJECT>

1. Adjustment to Section 6.2 Requirements to include a prompt regarding catering for legislative /compliance requirements. 2. A new section: section 3.7 Impacts on other business functions and projects . A sample table is suggested here this is not prescriptive.

Document Distribution

No. 1. 2. 3.

Recipient

Position

FILENAME AND PATH

Page 14 of 14