DHS/DIT
Business Requirements
Definition Template
Project Name: (input here)
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.
2
3
GENERAL FEATURES
2
4
USER COMMUNITY
2
4.1
User Roles
2
4.2
User Locations
2
5
BUSINESS PROCESSES
3
5.1
Business Process Map – Current State
3
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
4
7.3
Processes Impacted
4
7.4
Systems Impacted
4
8
REQUIREMENTS
4
8.1
Layout ("Look and Feel") Requirements
4
8.2
Navigational Requirements
4
Business Requirements Template
Revision Date: 03/15/2005
Page I
8.3
Scalability Requirements
4
8.4
Maintainability Requirements
5
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
Business 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)
Business 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
4.2
Approx. # of users
Primary Uses of the Application
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
Business 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)
Business 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.
Business 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 enduser 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)
Business 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:



8.9
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)
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)
Business 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 valueadd 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)
Business 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)
Business Requirements Template
Revision Date: 03/15/2005
Page 8