Business Process Definition & Requirements Template



BUSINESS PROCESS DEFINITION

AND

REQUIREMENTS

Project id (each project will have a project id assigned OCIO)

Project or System Name

U.S. Small Business Administration

Month, Year

Revision Sheet

|Release No. |Date |Revision Description |

|Rev. 1 |03/22/04 |Business Process Definition and Requirements Template and Checklist |

| | | |

| | | |

| | | |

| | | |

| | | |

RECOMMENDED POINT OF CONTACT FOR THIS DOCUMENT: Functional Lead within program area

The Point of Contact for the Document coordinates and insures that the document is completed. This individual as well as others in the program areas may also contribute in a collaborative fashion as is often necessary in systems development projects.

MANAGEMENT CERTIFICATION - Please check the appropriate statement.

______ The document is accepted.

______ The document is accepted pending the changes noted.

______ The document is not accepted.

We fully accept the changes as needed improvements and authorize initiation of work to proceed. Based on our authority and judgment, the continued operation of this system is authorized.

_______________________________ _____________________

NAME DATE

Project Manager

_______________________________ _____________________

NAME DATE

Program Area/Sponsor Representative

_______________________________ _____________________

NAME DATE

Program Area/Sponsor Director

_______________________________ _____________________

NAME DATE

OCIO Point of Contact

BUSINESS PROCESS DEFINITION AND REQUIREMENTS

TABLE OF CONTENTS

Page #

1.0 BUSINESS OBJECTIVES FOR PROCESS 1

2.0 Business Requirements 1

2.1 Process Flows 1

2.1.1 Existing or “As Is” Process Flow and Process Steps 1

2.1.2 Proposed or “To Be” Process Flow and Process Steps 1

2.2 New Process Requirements 2

2.3 Business Impact 3

2.3.1 Metrics to Measure Business Impact 3

2.3.1.2 Responsibility of Metrics Collection & Analysis 3

2.3.1.3 Business / System Metrics Communication Plan 3

2.3.2 Business Dependencies 3

2.3.3 Business Risks 3

2.4 Technology Impact 3

2.4.1 Technology Dependencies 3

2.4.2 Technology Risks 4

3.0 Assumptions 4

4.0 ISSUES 4

5.0 Project Success Criteria 4

NOTE TO AUTHOR: Highlighted, italicized text throughout this template is provided solely as background information to assist you in creating this document. Please delete all such text, as well as the instructions in each section, prior to submitting this document. ONLY YOUR PROJECT-SPECIFIC INFORMATION SHOULD APPEAR IN THE FINAL VERSION OF THIS DOCUMENT.

The Business Process Definition and Requirements document describes the “as is” business process definition of the existing system if applicable, the “to be” business process definition of the proposed system and the business requirements associated with the “to be business process definition.

BUSINESS OBJECTIVES FOR PROCESS

Describe the specific high level objectives for the project as it relates to the business process. As background description of the challenge or “pain” or deficiency is helpful in providing understanding of the reason for the proposed business objectives.

Business Requirements

This section describes the fundamental requirements or basis upon which the system will be built. It is very important to be specific and clear in this section as the focus of the project justification, and successful project development and implementation will be based on meeting the specific requirements outlined here.

1 2.1 Process Flows

1 2.1.1 Existing or “As Is” Process Flow and Process Steps

Describe in business terms the existing or “as is” business process flow. Business process flow is not meant to be screen, menu, or data flow. It describes the flow of work in a step by step fashion with narrative on each step

This would consist of two items:

Diagram contained of multiple diagram objects where a process number is contained in each individual process diagram.

Process Narrative This is a narrative in which each process step is listed with a narrative description.

2 2.1.2 Proposed or “To Be” Process Flow and Process Steps

Describe in business terms the proposed or “to be” business process flow. Business process flow is not meant to be screen, menu, or data flow. It describes the flow of work in a step by step fashion with narrative on each step.

This would consist of two items:

Diagram contained of multiple diagram objects where a process number is contained in each individual process diagram.

Process Narrative This is a narrative in which each process step is listed with a narrative description.

2.1.2 Proposed or “To Be” Process

2 2.2 New Process Requirements

Based on the proposed or “to be” process flow defined, list in specific discrete fashion a narrative for each proposed business process requirement. For requirement provide a narrative step description, narrative requirement description and suggested priority level (e.g. high, medium, low). If there are requirements related to new reporting, for each reporting requirement include field such as report name, definition/purpose, fields required, data source, real time/historical, existing/new, frequency, input, suggested priority level.

The following are categories of requirements which should be defined:

Business Requirements

e.g. “need to provide a 30 day turnaround from application to approval.”

System Requirements

e.g. “24 by 7 system availability 6days per week”

Reporting Requirements

e.g. “Report to produce a count of new applications by state for each week by application type”

Data Requirements

e.g. “based on fields in the report, need specific data elements from the following data sources “

Security Requirements

The need for securing the system to be developed should be stated in section including levels of access that can be granted

e.g. “headquarters’ staff may have read only access the following specific data measures”

Personnel Requirements

The following table should contain a list of everyone who will play a role in the development of the system.

|Name |Organization |Role |

| | | |

| | | |

| | | |

| | | |

Support Requirements

The following table should contain a list of everyone who will play a role in the ongoing maintenance of the system following implementation.

|Name |Organization |Role |

| | | |

| | | |

| | | |

| | | |

3 2.3 Business Impact

This section identifies how the proposed process changes will impact the business.

1 2.3.1 Metrics to Measure Business Impact

.2.3.1.1 Measurable Business Metrics to be Used

This section needs to identify in business terms, and identification of metrics that will be used to measure business impact in terms of meeting the business objectives.

2 2.3.1.2 Responsibility of Metrics Collection & Analysis

This section needs to identify the organizations and individuals who are responsible for collecting, analyzing and disseminating the metrics that will be collected over a specified time period to access the business impact this project has had when it was implemented.

3 2.3.1.3 Business / System Metrics Communication Plan

This section needs to identify the organizations, and associated individuals, in which metrics related to this project (application), will be communicated to.

4 2.3.2 Business Dependencies

This section should include organizational, project or process dependencies.

e.g. “this project is dependent upon the program area being able to allocate a full time functional lead by June”

5 2.3.3 Business Risks

This section should identify any business risks. As reference see SDM Risk Assessment document for a listing of the risks including those normally identified and required in connection with completing the OMB 300 form.

4 2.4 Technology Impact

This section needs to identify how supporting technology will be affected by the proposed process change. It should identify specific tools that will be affected.

1 2.4.1 Technology Dependencies

This section should include organizational, project or process dependencies.

e.g. “this project is dependent upon receiving detail data that will provided at the completion of the automation project which is planned for December”

2 2.4.2 Technology Risks

This section should identify any technical risks. As reference see SDM Risk Assessment document for a listing of the risks including those normally identified and required in connection with completing the OMB 300 form.

Assumptions

Describe key assumptions that provide for project success.

ISSUES

Most projects will have major issues or open points at time of submission to management. List the major open issues or points and the plans for addressing them.

Project Success Criteria

Here the program area staff identify specific criteria for project success.

Some example criteria are shown below:

“I’d like to have this system in place by October”

“I’d like to have all of our partners using this system by next year”

-----------------------

Business Process Definition and Requirements Authorization Memorandum

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

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download