DHS/DIT Business Requirements Template

DHS/DIT

Business Requirements Definition Template

Project Name: (input here)

04/04/1812:39 下午 1 INTRODUCTION 1

2 PROJECT SUMMARY 1

2.1 Project Objective 1

2.2 Business Problem 1

2.3 Tangible and Intangible Benefits 1

2.4 Rationale for a System Solution. 1

2.5 Alignment with DHS Strategic Objectives. 1

3 GENERAL FEATURES 1

4 USER COMMUNITY 2

4.1 User Roles 2

4.2 User Locations 2

5 BUSINESS PROCESSES 2

5.1 Business Process Map – Current State 2

5.2 Business Process Map – Future State 3

5.3 Business Process Improvement 3

6 COMMON USE CASE SCENARIOS 3

7 PROJECT IMPACT 3

7.1 Related Initiatives 3

7.2 People Impacted 3

7.3 Processes Impacted 3

7.4 Systems Impacted 4

8 REQUIREMENTS 4

8.1 Layout ("Look and Feel") Requirements 4

8.2 Navigational Requirements 4

4/4/2018Business Requirements Template Revision Date: 03/15/2005 Page I 8.3 Scalability Requirements 4

8.4 Maintainability Requirements 4

8.5 System Useful Life 5

8.6 Availability Requirements 5

8.7 Performance Requirements 6

8.8 Security Requirements 6

8.9 Auditing Requirements 6

8.10 Data Archiving and Purging Requirements 6

8.11 System Interface Requirements 7

9 EXCEPTIONS TO DHS STANDARDS 7

10 IMPLEMENTATION CONSIDERATIONS 7

10.1 Implementation Requirements 7

10.2 Implementation Timeline/Phases 7

11 ASSUMPTIONS 7

12 RISK ASSESSMENT 7

13 GLOSSARY OF TERMS 8

4/4/2018Business Requirements Template Revision Date: 03/15/2005 Page II

1 Introduction

The purpose of the Business Requirements Definition Template is to provide Project Sponsors, Stakeholders, and the Development Team with a high-level overview of the business objectives of the project for the purpose of project planning.

2 Project Summary

The purpose of the Project Summary is to provide the overall vision of the project in business terms. This section may include the business problem, background, objectives, and recommendations.

2.1 Project Objective

This section re-states the confirmed project objective identified in the Work Request submission. The objective statement shall include implementation time frame requirement with justification as appropriate.

(input text here)

2.2 Business Problem

This section identifies the current business problem and/or issues this project or solution is intended to address.

(input text here)

2.3 Tangible and Intangible Benefits

This section identifies the specific benefits (tangible/intangible) to the current business model or business processes this system or project will support.

(input text here)

2.4 Rationale for a System Solution.

This section helps to define why this solution is best supported by a system solution. The rationale shall include a Benefit/Effort assessment.

(input text here)

04/04/18Business Requirements Template Revision Date: 03/15/2005 Page 1 2.5 Alignment with DHS Strategic Objectives.

This section identifies the specific features related to support of DHS strategic goals and objectives.

(input text here)

3 General Features

This section identifies the general high-level functional requirements of the proposed system. Contents will include a bullet-list of what the application is expected to do.

(input text here)

4 User Community

The purpose of the User Community section is to provide the Development Team with general information about the people who will be using the system. This section may include descriptions of the various types of users, the approximate number of users of each type, how they will be using the application, where they are located, what kinds of software (e.g. browsers) they use, and general information about their skill level.

4.1 User Roles

User Roles may be used to help define the functional layout and/or security for the application. The number of users may be used as a factor in the prioritization of functional requirements. It may also aid in determining scalability requirements. This list may also be used as a tool for estimating training and support costs if applicable.

User Classification Approx. # of users Primary Uses of the Application

4.2 User Locations

User Location information should be considered when designing the overall architecture for the application. Whether users are located throughout the state or all in one building will have an impact on the design of the system.

Location Approx. # of users Current Connection

4/4/2018Business Requirements Template Revision Date: 03/15/2005 Page 2 5 Business Processes

The Business Processes section graphically represents the current business processes related to the system, the new business processes introduced by the system, and the identified improvements supported by the new system.

5.1 Business Process Map – Current State

This section graphically, or textually, represents the current business processes related to the proposed system.

(input text here)

5.2 Business Process Map – Future State

This section graphically, or textually, represents the new business processes introduced by the proposed system.

(input text here)

5.3 Business Process Improvement

This section graphically, or textually, represents the identified improvements to current business processes supported by the system.

(input text here)

6 Common Use Case Scenarios

(This Section Optional) The Common Use Case Scenarios section provides textual descriptions of some of the common uses of the proposed system or application. This section is intended to capture the primary uses of the system, and may include narratives further describing the business processes identified in the previous section.

(input text here)

7 Project Impact

The Project Impact section identifies the known and predicted impact of the proposed solution or project.

7.1 Related Initiatives

This section lists the identified related initiatives, both internal and external to the sponsoring department. Related Initiatives are those that will impact this project, as well as those that will be impacted by this project.

(input text here)

4/4/2018Business Requirements Template Revision Date: 03/15/2005 Page 3 7.2 People Impacted

This section lists the people (stakeholders), by high-level role, impacted by the proposed solution or project.

(input text here)

7.3 Processes Impacted

This section lists the other business processes, both internal and external to DHS, impacted by the proposed solution or project.

(input text here)

7.4 Systems Impacted

This section lists the identified systems and applications, both internal and external to DHS, impacted by the proposed solution or project.

(input text here)

8 Requirements

The Requirements section defines the requirements specific to the details of the proposed system.

8.1 Layout ("Look and Feel") Requirements

Sometimes, an application must display certain logos, follow a specific color-scheme or style, and/or adhere to specific guidelines with regard to fonts, frames, etc. The Layout Requirements section should provide developers and graphic designers with the necessary guidelines that must be followed when designing the graphical user interface of the application.

(input text here)

8.2 Navigational Requirements

The purpose of the Navigation Requirements section is to provide developers with the necessary guidelines on how to design the navigation for the application. For example, users may be accustomed to a certain menu style and therefore may require the new application to follow that style or expected path of navigation.

(input text here)

8.3 Scalability Requirements

The design of a system should consider future growth, including increases in the number of users, the number of transactions being processed, and the storage of historical data. The purpose of the Scalability Requirements section is to explicitly define the growth that a proposed solution must be able to handle, thereby minimizing the risk of outgrowing a solution too soon.

4/4/2018Business Requirements Template Revision Date: 03/15/2005 Page 4 (input text here)

8.4 Maintainability Requirements

Maintainability refers to how easy it is for the end-user to modify the system, either to provide customization, or to fix bugs or other problems that arise in the system. The detailed features and development of a system can accommodate different levels of maintainability in regards to the needs of the user community. A system can be designed and developed in such a manner as to support the end- user customization of their system interface or usage, such as providing for system supported customization of reports or data entry screens (similar to “wizards” included in many packaged applications). Such system features often increase both the design and development costs, but may lower the on-going maintenance cost as the end-user is able to complete some of the customization rather than relying on the expertise and availability of development staff. In contrast, if there are not needs to support the need for end-user customization, the design and development cost can be reduced, relying on development expertise when customization or enhancements are identified.

(input text here)

8.5 System Useful Life

The design of a system should consider the period of time, including implementation date requirement, in which the system is expected to be in use before being replaced by a new system. If the purpose of a system is to simply automate a process until the “real system” or long-term system is in place, then the design needn’t be completely flexible. Flexible designs are ideal but require an up-front investment (with anticipated savings down the road in maintenance) and should not automatically be assumed as desired by the Client/Customer. The purpose of the System Useful Life section is to define the expectations of the Client/Customer with regards to how long the system will be in use and, therefore, maintained.

(input text here)

8.6 Availability Requirements

The purpose of the Availability Requirements section is to define the level of system availability needed by users, in order to determine how much downtime can be tolerated without incurring excessive business costs or disruption of operations. While 100%, “24/7”, availability is ideal, development and operational costs increase as more availability is needed. In reality, many systems can afford some amount of downtime, both during low-usage times to allow for backups, system maintenance, etc., and, occasionally, during peak usage times to deal with unexpected interruptions. This section will include information about expected usage times (including times outside of regular business hours when users are expected to need access to the system), impact on users if the system experiences an unplanned outage during scheduled operational time, length of time the system can be unavailable (both with and without advance planning) before causing excessive negative impact on the business, and how far in advance users must be notified of a planned system outage.

(input text here)

4/4/2018Business Requirements Template Revision Date: 03/15/2005 Page 5 8.7 Performance Requirements

The purpose of the Performance Requirements section is to explicitly define the minimum performance expectations for the application. Typically, all applications (specifically Web applications) should follow industry standards for accessing a Web page, submitting a form, etc. Performance requirements may depend upon the nature of the transaction (whether or not timing is critical) or how much data is being processed. For example, performance will be a critical issue for a 911 operator, but not as critical for an accounting system. Performance will also be dependent upon the hardware and software on both the Client and the Server.

(input text here)

8.8 Security Requirements

The purpose of the Security Requirements section is to:

 Define how users need to access the application (input text here)  Define restrictions in application functionality for each User Group (input text here)  Determine the level of complexity required for the Security Design (whether Security roles should be dynamic and flexible, or predefined and static) (input text here)

8.9 Auditing Requirements

The purpose of the Auditing Requirements section is to define any information that should be stored automatically by the system and viewed, but not modified, by any user through the “front-end” (graphical user interface) of the system. Auditing information provides reliable controls to minimize fraud and promote data integrity.

(input text here)

8.10 Data Archiving and Purging Requirements

After a system has been in use for a period of time, data volumes grow and performance is sacrificed. If certain information is no longer needed, it could be purged to improve performance. If certain information is needed, but only occasionally, it could be archived to improve performance. The purpose of the Data Archiving and Purging Requirements section is to explicitly define what information should be purged or archived, and when.

(input text here)

4/4/2018Business Requirements Template Revision Date: 03/15/2005 Page 6 8.11 System Interface Requirements

The purpose of the System Interface Requirements section is to describe other systems with which the application must interface, the data that will be shared between the systems, and to what extent the systems must interact.

(input text here)

9 Exceptions to DHS Standards

The Exceptions to DHS Standards section identifies exceptions to known DHS standards, and defines the business and technical reasons for considering or requiring the exception.

(input text here)

10 Implementation Considerations

10.1 Implementation Requirements

The Implementation Requirements section captures identified requirements to be included in the implementation for the proposed solution or project. Please clarify what is expected here.

(input text here)

10.2 Implementation Timeline/Phases

The Implementation Timeline/Phases section defines at a high-level the anticipated timeline and steps associated with the continued efforts in support of the proposed project completion. Information is defined with the objective of providing functional value-add within a target window. Phases can be considered sequential enhancements to a base solution, where each phase is completed and adds additional value-add functionality to the previous implementation.

(input text here)

11 Assumptions

The Assumptions section lists assumptions identified during the data gathering and assessment activities.

(input text here)

12 Risk Assessment

The Risk Assessment section lists those issues identified during the data gathering and assessment activities.

(input text here)

4/4/2018Business Requirements Template Revision Date: 03/15/2005 Page 7 13 Glossary of Terms

The Glossary of Terms section defines those terms and acronyms identified during the assessment activities. (Include appropriate acronyms and terminology)

(input text here)

4/4/2018Business Requirements Template Revision Date: 03/15/2005 Page 8