Appendix b functionaldesignphasebusinessequirementsdocument021805
- 1. FINAL <Application Name> Functional Design Phase Business Requirements Document 02.18.2005 Version 1.0
- 2. <APPLICATION NAME> NH Department of XXXXXX Functional Design Phase Business Requirements Document TABLE OF CONTENTS 1. INTRODUCTION.................................................................................................................................3 1.1 USING THIS DOCUMENT.........................................................................................................................................3 1.2 PURPOSE................................................................................................................................................................3 1.3 BUSINESS OWNERS AND CONTACTS......................................................................................................................3 1.4 SIGNOFFS...............................................................................................................................................................3 1.5 REVISION HISTORY................................................................................................................................................4 1.6 REFERENCED DOCUMENTS....................................................................................................................................4 1.7 DEFINITIONS, ACRONYMS AND ABBREVIATIONS..................................................................................................4 2. PROJECT OVERVIEW:......................................................................................................................4 3. ASSUMPTIONS, CONSTRAINTS AND SCOPE:.............................................................................4 4. PROCESS FLOWS. .............................................................................................................................5 4.1 CURRENT/EXISTING PROCESS WORKFLOW...........................................................................................................5 5. BUSINESS REQUIREMENTS: ........................................................................................................5 5.1 BUSINESS REQUIREMENTS MATRIX......................................................................................................................5 6. ACCEPTANCE CRITERIA ..............................................................................................................8 6.1 ACCEPTANCE CRITERIA MATRIX...........................................................................................................................8 7. ISSUES LOG..........................................................................................................................................8 Office of Information Technology, Agency Software Division - <Agency> 2
- 3. <APPLICATION NAME> NH Department of XXXXXX Functional Design Phase Business Requirements Document 1. INTRODUCTION 1.1 Using this Document <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 Business Owners and Contacts Name Email Phone Role John Doe Jdoe@Me.com 303-471-8344 Project Manager Joe Tester System Test Lead Jane ProdSupport Production Support Mgr Joe UserMgr User Test Lead Joe Developer Developer â Presentation Tier Jane Developer Developer â Business Tier Joe DBA Data Base Administrator Joe Tester Tester Jane Tester Tester Joe Customer Department VP Jane Customer Department Mgr Josey Customer Product Support 1.4 Signoffs Name Date Signature John Doe, PM/DM xx/xx/xx Joe Tester, System Test Lead Jane ProdSupport, Production Support Mgr Joe User Mgr, UM Joe Customer, Customer Office of Information Technology, Agency Software Division - <Agency> 3
- 4. <APPLICATION NAME> NH Department of XXXXXX Functional Design Phase Business Requirements Document 1.5 Revision History Date Reason for change(s) Author(s) 07/01/2004 First Draft John Doe 07/12/2004 Revision based on project launch committee meeting Gotta Changit 1.6 Referenced Documents Document Version/Date Author(s) Project Concept Document 1/7/2004 John User 1.7 Definitions, Acronyms and Abbreviations <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 Application Service Provider> <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..> 3. ASSUMPTIONS, CONSTRAINTS AND SCOPE: Office of Information Technology, Agency Software Division - <Agency> 4
- 5. <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 Current/Existing Process Workflow <Describe the current/existing process workflow using flow diagrams (i.e. Visio Flowcharts) and/or a detailed narrative. This section describes the tasks that are carried out in the Business Process. A number of 'scenarios' which are specific examples of performing the task should be identified for each task to the extent that they exist.> 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 Business Requirements Matrix The requirements matrices that follow present a numbered list of the requirements with a brief description, a priority and any comments. The priorities are: âą M - the requirement is mandatory âą D - the requirement is desirable âą F - the requirement is to be postponed to the future âą N - although discussed, no longer a requirement Functions/Features No. Description Priority Comments 1.0 Ability to store, search, retrieve, and print electronic images of scanned paper documents associated with an account. M Same functionality that existing in other agency application XYZ. 1.1 Automated routine for monthly reporting. D 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. M Should be consistent with other department applications. 1.x âŠâŠ.. Office of Information Technology, Agency Software Division - <Agency> 5
- 6. <APPLICATION NAME> NH Department of XXXXXX Functional Design Phase Business Requirements Document Data Capture, Storage, Conversion and Exchange No. Description Priority Comments 2.0 Import all existing electronic account information into new data repository. Verify that data meets all current business rules. M 2.1 Scan in all historical documents and associate with existing accounts where appropriate. D Requires 2.0 be completed. 2.2 Accept XML files supplied by accounts and update repository. M 2.x âŠâŠâŠ Hardware and Software Platform No. Description Priority Comments 3.0 The application must run on a Windows 2000 Server D 3.1 The repository should be built in the highest release of Oracle that is compatible with the other application components. D Mandatory where technology available 3.2 Image Scanning will take advantage of existing FileNet Solutions M 3.3 All Reporting functionality should be built using the Cognos Tool Set D 3.x âŠâŠâŠ Output/Reports No. Description Priority Comments 4.0 Account History Report. M 4.1 Account Notification Mail Merge Report. M 4.2 Data Transfer to existing accounting application for billing. D 4.3 Account Growth Report D 4.x âŠâŠâŠ Testing/Training No. Description Priority Comments 5.0 Scan, Search, Retrieve and Print Document. M 5.1 Minimum 2 months of parallel testing against existing process. M 5.2 All previously identified functions/features to be verified during acceptance testing by users. D 5.3 Create detailed and meaningful user documentation. M 5.4 Create a condensed training course (Estimate 2 Hours) to be attended by ### employee over a specified period. M Training facility will have to be reserved. Office of Information Technology, Agency Software Division - <Agency> 6
- 7. <APPLICATION NAME> NH Department of XXXXXX Functional Design Phase Business Requirements Document 5.x âŠâŠâŠ Security Requirements No. Description Priority Comments 6.0 Create detailed and meaningful user documentation. M 6.1 Create a condensed training course (Estimate 2 Hours) to be attended by ### employee over a specified period. M Training facility will have to be reserved. 6.x âŠâŠâŠ Implementation No. Description Priority Comments 7.0 Detailed plan for application roll out will be created to insure a minimum amount of operational interruption. M 7.1 All client PCâs will have supporting software loaded prior to application roll out. D Adobe reader and the Oracle client should already be on all PCâs. Filenet Software can be loaded at any time prior to roll- out 7.x âŠâŠâŠ Performance and Response Time Requirements No. Description Priority Comments 8.0 Insure all data is backed up on a nightly basis. M 8.1 There should be a Department-Wide Presentation showing the major features of the new application prior to the application roll out. D 8.2 The account community should be notified of any issues that may effect them as a result of this roll out. D 8.x âŠâŠâŠ Data Archival, Backup and Recovery Requirements No. Description Priority Comments 8.0 Insure all data is backed up on a nightly basis. M 8.1 There should be a Department-Wide Presentation showing the major features of the new application prior to the application roll out. D 8.2 The account community should be notified of any issues that may effect them as a result of this roll out. D Office of Information Technology, Agency Software Division - <Agency> 7
- 8. <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 Acceptance Criteria Matrix <List the acceptance criteria within the Table below. Include a Criteria ID, Description, Measurement, and which Requirements the acceptance criteria maps to. > 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. > Office of Information Technology, Agency Software Division - <Agency> 8