Functional Design Phase Business Requirements Document
Functional Design Phase Business Requirements Document
<Application Name>
Functional Design Phase
Business Requirements Document
02.18.2005
Version 1.0
TABLE OF CONTENTS
<APPLICATION NAME>
NH Department of XXXXXX
Functional Design Phase Business Requirements Document
1.
INTRODUCTION..........................................................................................................................3
1.1
1.2
1.3
1.4
1.5
1.6
1.7
2.
PROJECT OVERVIEW:...............................................................................................................4
3.
4.
PROCESS FLOWS.........................................................................................................................5
4.1
5.
BUSINESS REQUIREMENTS:....................................................................................................5
5.1
6.
ACCEPTANCE CRITERIA..........................................................................................................8
6.1
7.
ISSUES LOG...................................................................................................................................8
<APPLICATION NAME>
NH Department of XXXXXX
Functional Design Phase Business Requirements Document
1. INTRODUCTION
1.1
<The text enclosed in the less-than/greater-than symbols is included for the benefit of the person writing the
document and should be removed before the document is finalized.>
Requirements for software systems should be customized to the needs of the project building the system. This
template is one of many documents related to this software development project. It is organized such that it can be a
stand-alone document or combined with other Functional Design Phase documents, i.e. Functional Design, Solution
Alternatives, based on the particular project. Please refer to Section 1.6 Referenced Documents for a listing of
additional project-specific documentation.
1.2
Purpose
The purpose of this document is to serve as a basis for defining the Business Requirements from the Users
perspective. The Business Requirements are to be composed by the Customer/User with some assistance from an
DOIT/Technical team. The requirements contained within this document should stipulate what is needed, rather
than how these needs will be met. Upon completion and approval of the business requirements, DOIT will define in
detail all the system functions necessary to satisfy the business requirements which will be documented within the
Functional Design Document.
1.3
John Doe
Joe Tester
Jane ProdSupport
Joe UserMgr
Joe Developer
Jane Developer
Joe DBA
Joe Tester
Jane Tester
Joe Customer
Jane Customer
Josey Customer
1.4
Phone
303-471-8344
Role
Project Manager
System Test Lead
Production Support Mgr
User Test Lead
Developer Presentation Tier
Developer Business Tier
Data Base Administrator
Tester
Tester
Department VP
Department Mgr
Product Support
Signoffs
Name
Date
Signature
xx/xx/xx
<APPLICATION NAME>
NH Department of XXXXXX
Functional Design Phase Business Requirements Document
1.5
Revision History
Date
Author(s)
07/01/2004
First Draft
John Doe
07/12/2004
Gotta Changit
1.6
Referenced Documents
Document
1.7
Version/Date
1/7/2004
Author(s)
John User
<This section contains definitions, acronyms and abbreviations referred to within this document that may need to be
clarified to assist the reader in understanding the meaning and/or intent of the information contained within this
document. Some examples are shown below. Please populate this section based on the specific content you provide
for the Business Requirements for your project.>
<ASP
<Back-end
That portion of an application that the users do not interact with directly, relative to the
client/server computing model, a front-end is likely to be a client and a back-end to be a
server.>
<Back-office
The internal business functions of a company such as finance, accounting, legal, human
resources and operations.>
<COTS
Commercial off-the-shelf. Describes ready-made products that can easily be obtained. The
term is sometimes used in military procurement specifications.>
2. PROJECT OVERVIEW:
<Document an overview of this project. Information may include a narrative regarding the business needs that
will be met through this project, the Stakeholders/Customers that will be impacted, a description of the reasons
this project is being performed, an impact statement, and other relevant project level information..>
<APPLICATION NAME>
NH Department of XXXXXX
Functional Design Phase Business Requirements Document
<Describe any constraints on the project that have a significant impact on the business requirements. (e.g.
technology constraints, performance, requirements, end user characteristics, validations requirements, project
constraints, etc.) Describe any assumption, background or dependency of the process, its use, the operational
environment, or significant project issues. Define questions to be answered during the User Walk-Through.
Define what will not be completed within the project, i.e. what is out of Scope.>
4. PROCESS FLOWS.
4.1
5. BUSINESS REQUIREMENTS:
<List requirements within the Business Requirements Matrix. We have included examples of requirement
groups/categories, i.e. Functions/Features, Data Capture, Storage, Conversion and Exchange, Hardware and
Software Platform, Output/Reports, Testing/Training, Security Requirements, Implementation, Performance
and Response Time, Data Archival, Backup and Recovery. These requirement categories can be modified to
better reflect the requirements of your project. For example, if you are releasing a new version of an existing
application, you may want to categorize requirements by application component. Make sure that information
within other project documentation, Functional Design, Solution Options, Technical Design, and Test
Plan/Cases Documents, mirrors the categorization of these requirements for tracability.>
<A table format is recommended. All requirements should be numbered for tracking between this document
and the Functional Design, the Chosen Option, the Technical Design, and the Test Plan Documents.>
5.1
The requirements matrices that follow present a numbered list of the requirements with a brief description, a priority
and any comments. The priorities are:
Functions/Features
No.
Description
Priority
1.0 Ability to store, search, retrieve, and print electronic images of scanned
paper documents associated with an account.
1.1 Automated routine for monthly reporting.
1.2 The electronic format must follow an intuitive flow for data entry and
provide features such as highlighting, table driven drop down lists, pre
populated fields, re-centering and capturing system dates.
1.x ..
Comments
Same functionality that existing in
other agency application XYZ.
D
Should be consistent with other
department applications.
<APPLICATION NAME>
NH Department of XXXXXX
Functional Design Phase Business Requirements Document
Description
Priority
2.0 Import all existing electronic account information into new data
repository. Verify that data meets all current business rules.
2.1 Scan in all historical documents and associate with existing accounts
where appropriate.
Comments
2.x
Description
Priority
3.1 The repository should be built in the highest release of Oracle that is
compatible with the other application components.
3.2 Image Scanning will take advantage of existing FileNet Solutions
D
M
3.3 All Reporting functionality should be built using the Cognos Tool Set
Comments
3.x
Output/Reports
No.
Description
Priority
Comments
4.x
Testing/Training
No.
Description
Priority
Comments
M
M
<APPLICATION NAME>
NH Department of XXXXXX
Functional Design Phase Business Requirements Document
5.x
Security Requirements
No.
Description
Priority
Comments
6.x
Implementation
No.
Description
Priority
7.0 Detailed plan for application roll out will be created to insure a minimum
amount of operational interruption.
7.1 All client PCs will have supporting software loaded prior to application
roll out.
Comments
7.x
Description
Priority
8.2 The account community should be notified of any issues that may effect
them as a result of this roll out.
8.x
Comments
Description
Priority
8.2 The account community should be notified of any issues that may effect
them as a result of this roll out.
Comments
<APPLICATION NAME>
NH Department of XXXXXX
Functional Design Phase Business Requirements Document
8.x
6. ACCEPTANCE CRITERIA
<Include a statement/summary of the acceptance criteria.>
6.1
Criteria Id.
Description
Measurement
Requirement(s)
Validated
7. ISSUES LOG
<The issues log is a table that tracks any issues that arise after this document is approved and signed. Its purpose is
to update the document while leaving the original content intact. The issues log can be maintained in an Excel
worksheet and pasted into this Word document.
The issues log should include the following details:
Issue Number
Date Logged
Requirement Number (a reference to the original requirement that is impacted)
Issue description
Resolution description
Date Resolved
Decision Made By
The issues log worksheet can also be used to track all requirements, design/development, and/or solution alternatives
issues that occur after the corresponding documentation is signed. >