statement of business requirements sobr template

XX Site (SoBR)(Type actual Program/Project name in front of “Statement of Business Requirements (SoBR)” and change to 36 Font and delete this note)

CR ID:PTT ID: (as applicable)

Prepared By: XX Person

[email protected]

Version: 1.0Version Date:May 25, 2008

IMPORTANT NOTICE FROM IT STANDARDS: This template provides the mandatory content for its deliverable. All mandatory information must be addressed. If information is not provided where

requested in the template, explanation is needed for justification. Additional items may be added to this template to meet specific needs. A group may use their own format as long as this content from this template is

addressed. Please delete this notice prior to publishing your own version of this document.

Confidential & ProprietaryThis documentation is extremely sensitive; please limit distribution. No part of this document may be photocopied, disclosed, or otherwise provided to third parties.

XX Site (SoBR)Version: 1.0, May 25, 2008

CHANGES FROM THE PREVIOUS VERSIONS

The Changes from the Previous Version section identifies all changes that have been entered into the newest version of this document. The change details in the below table pertain to the template. Please delete this and the details prior to publishing your own version of this document.

Reference Changes From Previous Version - Change Details:

Version Number

VersionDate

Section Number

ChangeAuthor(s)

Change Details

1.0

Proprietary i


TABLE OF CONTENTSPage

1. STATEMENT OF BUSINESS REQUIREMENTS................................2

1.1. Scope of SoBR....................................................................................................2

1.2. Business Objectives............................................................................................2

1.3. Constraints, Assumptions, Dependencies and Risks..........................................2

1.4. Detailed Business Requirements........................................................................4

1.5. Process Flow High-Level Business Process Impact(s) (As Required)................6

1.6. Business Use Case (As Required)......................................................................8

1.7. Business Rules (As Required)............................................................................9

1.8. Data Integrity Requirements (As Required)........................................................9

1.9. Non-Functional Requirements (If Applicable)....................................................10

2. FUNCTIONAL REQUIREMENTS......................................................11

2.1. Functional Requirements (Provided by Development)......................................11

3. ADMINISTRATION............................................................................12

3.1. Contact List.......................................................................................................12

3.2. Glossary............................................................................................................12

3.3. Appendices.......................................................................................................12

3.4. Exhibits..............................................................................................................13

4. Document Organizational Signoffs.....................................................14

Proprietary ii


INTRODUCTION

The Statement of Business Requirements (SoBR) template is intended for use by the business/project sponsor and internal IT business analyst. It is intended to capture relevant business objectives and requirements salient to the project or program to be developed. Large, complex, or integrated projects and programs may require additional information or sections which can be added to the SoBR as needed. Specifically, this document is intended to:

Establish the Prioritized Business Objectives. Articulate Prioritized Business Requirements. Establish existing / as-is business process flows and business use cases (on an as needed

basis). Inclusion of process flows and use cases will be determined through a combination of sponsor

and program needs. The inclusion of either item is a decision that will be made by the Business Analyst, based on sponsor needs or requirements, in addition to inputs from the Program or Project Manager.

Document constraints, assumptions, dependencies and risks. Provide the functional requirements from IT Development based upon and tied to the Business

Requirements from the sponsor/client

Proprietary 1


1. Statement of Business Requirements

1.1. Scope of SoBR

The Scope of this project is to redesign the current About You U.S. site and the International Landing page & Money vertical.

1.2. Business Objectives

The Business Objectives section displays a list of business objectives that were requested in the Sponsor Document /EPAS Customer Request (CR) and are being addressed in this document.

Priority Number

OBJ-ID Business Objective Description BREQ IDs

OPRI-n OBJ-n BREQ-n, BREQ-n

OPRI-n

1.3. Constraints, Assumptions, Dependencies and Risks

1.3.1. Constraints – This section identifies constraints that apply to the Customer Request (CR). It includes restrictions or limitations, either internal or external to the project or company organizations (i.e. sales, provisioning, field operations, financial, order entry, etc.) that will affect the performance of the project or program. Constraints inhibit or hinder action; restrict the freedom in designing and delivering a solution. Requirements are not included in this section as they are covered in section 1.4.

Constraint ID Constraint Description

CONS-1 Completion of US + Int’l Your Toolkit (HR Toolbox and Manage Your Workforce) wireframes based on date (TBD) agreed upon by IT and HR

1.3.2. Assumptions – This section identifies the critical assumptions that apply to the Customer Request (CR). Assumptions are the conditions and factors of the project, environment, or personnel that are considered true, real, or certain without proof or demonstration. These may include best-guess decisions. Requirements are not included in this section as they are covered in section 1.4.

Assumption ID

Assumption Description

ASUM-1

ASUM-2

Proprietary 2


ASUM-3

1.3.3. Dependencies – This section identifies the dependencies that apply to the Customer Request (CR). Requirements are not included in this section as they are covered in section 1.4.

Dependency ID

Dependency Description

DEP-n

1.3.4. Risks – This section identifies the outcome of the risk assessment that applies to the Customer Request (CR) from a business perspective as opposed to delivery related risks that are captured later in the Project Tracking Tool (PTT). A risk is an uncertain circumstance or event that, should it occur, would have an adverse effect on the program/project’s objectives.

The essential elements of risks listed below include risks surrounding tangible and intangible assets, asset value, threats, vulnerabilities, safeguards, consequences and likelihood of threat. Business, regulatory, legal, technology, trading partner and human resources risks should also be considered.

Requirements are not included in this section as they are covered in the next section.

Risk IDRisk Description Risk Ranking

(Low/Medium/High)

Risk-n

Proprietary 3


1.4. Detailed Business Requirements

The Detailed Business Requirements section provides proposed detailed business requirements. This section could also contain reporting requirements, invoicing requirements and legal/regulatory requirements.

Row BREQ-ID BREQ-ID Priority

(High, Medium,

Low)

Business Requirement Description

1. BREQ-1

2. BREQ-2

3. BREQ-3

4. BREQ-4

5. BREQ-5

6. BREQ-6

7. BREQ-7

8. BREQ-8

9. BREQ-9

10. BREQ-10

11. BREQ-11

12. BREQ-12

13. BREQ-13

14. BREQ-14

15. BREQ-15

16. BREQ-16

17. BREQ-17

18. BREQ-18

1.5. Process Flow High-Level Business Process Impact(s) (As Required)

The High-Level Business Process Impacts section contains high-level business process flows that identify the activities/sub-processes that are impacted, and which Use Cases depict the impacts. Include a process flow illustration whenever possible.

Proprietary 4


Process ID: BPROC-n

Process Title:

Related Objectives: OBJ-n, OBJ-n

Involved Organizations:

Business Process Activity

High Level Business Process Description Use Case ID

Activity-nUCASE-n or

blank

Proprietary 5


1.6. Business Use Case (As Required)

The Business Use Case section provides proposed detailed use cases, as required. Inclusion of Business Use Cases will be determined through a combination of Sponsor and Program needs. The inclusion is a decision that will be made based on sponsor needs or requirements, in addition to inputs from the Program or Project Manager.

The Business Use Case section may be repeated as many times as necessary to service all impacted Business Processes.

Use Case ID: UCASE-n

Business Processes Serviced:

BPROC-n, BPROC-n

Use Case Data Type

Use Case Data Description

Summary:

Primary Actors:

Secondary Actors:

Related Use Cases:

References:

Primary Flow of Events

Sequence Event DescriptionBREQ ID

BREQ ID PRIORITY BRULE ID

Preconditions:

Step nAssign for new reqs

Assign for new rules

Post Conditions: Alternative Flow of Events

Sequence Event DescriptionBREQ ID

BREQ ID PRIORITY

BRULE ID

Preconditions:

Step nAssign for new reqs

Assign for new rules

Post Conditions:

Proprietary 6


1.7. Business Rules (As Required)

The Business Rules section contains the business rules for successful fulfillment of the project objectives outlined in the SoBR.

Business Rule ID

New Business Rule Description Use Case IDs Requirement Source

BRULE-1 UCASE-n, UCASE-n

Functional Area:

POC:

1.8. Data Integrity Requirements (As Required)

Provide detailed requirements that address data integrity issues. Include migration, capacity planning, security, and conversion considerations as applicable.

Data Integrity Requirement

IDData Integrity Requirement Description Requirement Source

DIREQ-n Functional Area:

POC:

Proprietary 7


1.9. Non-Functional Requirements (If Applicable)

The Non-Functional Requirements section describes the non-functional requirements, which include requirements related to response time, number of users, service level agreements (SLAs), number of transactions, general desktop, etc.

Non-Functional

Requirement ID

Non-Functional Requirement Description Requirement Source

NFREQ-n Functional Area:

POC:

1.9.1. Potential Project Revenues/Expenses – This section identifies the potential annual revenue and/or potential expense reduction associated to the project being requested by the sponsor/client. List the possible benefits in the form of cost efficiencies/cost avoidance. Also list what the impact will be if this request is not implemented. This information should be available from the Original Project Request.

1.9.2. Number of customers impacted (if applicable) – This section identifies the number of customers impacted by the project. This information should be available from the Original Project Request.

1.9.3. End to End Testing – Identify if the business will participate and require end to end testing. This information should be available from the Original Project Request.

Proprietary 8


2. Functional Requirements

2.1. Functional Requirements (Provided by Development)

A functional requirements specification describes what is required to meet the users' business needs. Functional requirements specify which actions the design must provide in order to benefit the system's users. Functional requirements capture the intended use and behavior of the system and are based upon the needs, user, and task analysis of the current system. The functional requirements tie directly back to the detailed business requirements stated in section 1.4 of this document. For traceability, the business requirements ID (BREQ-ID) and the functional requirements ID (FREQ-ID) must be included in the matrix below to demonstrate a clear linkage(s) between the functional requirement(s) and the business requirement(s).

Row BREQ-ID

FREQ-ID

FREQ-ID Priority

(High, Medium,

Low)

Functional Requirement Description

Obj-ID

Priority

1. BREQ-n FREQ-n OBJ-n OPRI-n

2.

3.

4.

5.

Proprietary 9


3. Administration

3.1. Contact List

The Project Contributors/Contacts section lists all of the participants that assisted in the production of the document.

Name Email Address Organization Location Phone Number

3.2. Glossary

The Glossary contains an alphabetical list of key terms, acronyms, definitions, used in this document which are not commonly used in the MCI business environment or would help the reader understand the contents of this document.

Acronym Key Terms Definition

3.3. Appendices

The Appendices section records optional, text-based documentation, which may be included for clarity.

Document Name Version Date Location (i.e. web site)

Proprietary 10


3.4. Exhibits

The Exhibits section contains tangible items, such as diagrams, with the name of the author, exhibit date, and location.

Exhibit Name Author Date Location (i.e. web site)

Proprietary 11


4. Document Organizational SignoffsThe Document Organizational Signoffs section contains official signoffs of the responsible Organization(s). There must be a signoff from the sponsoring organization who submitted the original Statement of Business Requirements (SoBR). Signoff by the sponsoring organization project manager is required as well as POCs of the other impacted functional areas.

Document Organizational Signoffs

Name of Person Sponsor Group Date

Name of Person Functional Area Date



Proprietary 12

statement of business requirements sobr template

Documents

events sequence preconditions

data integrity requirements

document organizational signoffs

original project request

process flow high

id priority

business objectives

functional requirements