Government of Newfoundland and Labrador Office of the Chief Information Officer Solution Delivery: Project Management Office

<< PROJECT NUMBER AND NAME >> BUSINESS REQUIREMENTS DOCUMENT

BUSINESS REQUIREMENT DOCUMENT TEMPLATE VERSION 4.0, 2012-06-01

PAGE 1 OF 20

Government of Newfoundland and Labrador Office of the Chief Information Officer Solution Delivery: Project Management Office

Client: Author: Version: Status Date: << Person who created the document >> << First version should be 1.0 and increment up >> << Enter status of document. i.e., Draft, Pending Sign-off, Final, et cetera >> << YYYY-MM-DD >>

This template is owned and maintained by the Project Management Office (PMO) of the Office of the Chief Information Officer (OCIO). Direct questions about this template to [email protected]

Document Revision History

Date << YYYY-MM-DD >> << YYYY-MM-DD >> << YYYY-MM-DD >> << YYYY-MM-DD >> Version Description Author

SUBMITTERS OF FINAL DOCUMENT

These signatories confirm this document was submitted by the project team as the requirements for the << Project Name >> Project. Role Project Manager Name << Print name >> Signature Date YYYY-MM-DD

BUSINESS REQUIREMENT DOCUMENT TEMPLATE VERSION 4.0, 2012-06-01

PAGE 2 OF 20

Government of Newfoundland and Labrador Office of the Chief Information Officer Solution Delivery: Project Management Office

FINANCIAL IMPLICATIONS REVIEW

These signatories confirm this document serves as the financial functionality and integration requirements for the << Project Name >> Project. Role Name Signature Date

Is financial functionality and integration a requirement for this project solution? Note: If the Departmental Comptroller identifies that financial functionality and integration is a requirement for this project, the Office of the Comptroller General (OCG) review is mandatory. Departmental Comptroller Yes (OCG signature required see below) << Print name >> No (OCG signature not required) YYYY-MM-DD

Office of the Comptroller General (OCG)

<< Print name >>

YYYY-MM-DD

REVIEWERS OF FINAL DOCUMENT

Identify the individuals who reviewed the BRD and the date that the review was completed. Signatures are not required. Role Information Management Analyst Enterprise Application Architecture Corporate Operations and Client Services RFP Review Completed << Print name >> << Print name >> << Print name >> Date YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD

APPROVERS OF FINAL DOCUMENT

These signatories confirm this document serves as the requirements for the << Project Name >> Project. Role Project / Client Sponsor
BUSINESS REQUIREMENT DOCUMENT TEMPLATE VERSION 4.0, 2012-06-01

Name << Print name >>

Signature

Date YYYY-MM-DD
PAGE 3 OF 20

Government of Newfoundland and Labrador Office of the Chief Information Officer Solution Delivery: Project Management Office

Role Solution Delivery Manager

Name << Print name >>

Signature

Date YYYY-MM-DD

BUSINESS REQUIREMENT DOCUMENT TEMPLATE VERSION 4.0, 2012-06-01

PAGE 4 OF 20

Government of Newfoundland and Labrador Office of the Chief Information Officer Solution Delivery: Project Management Office

TABLE OF CONTENTS
TABLE OF CONTENTS.......................................................................................................................5 INTRODUCTION................................................................................................................................6 BUSINESS REQUIREMENTS OVERVIEW..................................................................................................9 BUSINESS REQUIREMENTS.................................................................................................................10 ASSUMPTIONS, DEPENDENCIES AND CONSTRAINTS..................................................................................19 USER COMMUNITY...........................................................................................................................20

BUSINESS REQUIREMENT DOCUMENT TEMPLATE VERSION 4.0, 2012-06-01

PAGE 5 OF 20

Government of Newfoundland and Labrador Office of the Chief Information Officer Solution Delivery: Project Management Office

INTRODUCTION
IMPORTANT NOTES FOR COMPLETING THIS DOCUMENT
1. Each section of the Business Requirement Document (BRD) must be completed in full. If a particular section is not applicable to this project, then you must write Not Applicable and provide a reason. 2. No sections are to be deleted from this document. 3. Do not change the format or fonts used in the template. 4. All tables should have landscape orientation. 5. Text contained within << >> provides information on how to complete that section and can be deleted once the section has been completed. 6. Delete examples under each section once the section has been completed. 7. If additional categories are required, feel free to add an Other category to the end of the document. 8. Reviews and Approvals. All reviews should be completed prior to obtaining approval signatures. Delivery Manager review should be completed prior to Corporate Operations and Client Services Review. 9. This document should be submitted to Enterprise Architecture (EA) group along with the Detail Technical Presentation.

PURPOSE OF THE BUSINESS REQUIREMENT DOCUMENT

The Business Requirements Document (BRD) clearly states the functions and capabilities that the application and/or system must provide for the project to be successful (what the system and/or application must do). All known constraints, assumptions and dependencies must also be clearly defined. The BRD is the basis for all subsequent project planning, design and coding. It should describe as completely as known at this time, the systems behaviours under various conditions. The BRD does NOT contain design information or anything related to how the system will provide the functionality.

BUSINESS REQUIREMENT DOCUMENT TEMPLATE VERSION 4.0, 2012-06-01

PAGE 6 OF 20

Government of Newfoundland and Labrador Office of the Chief Information Officer Solution Delivery: Project Management Office

ACRONYMS AND GLOSSARY

The following table includes definitions for any unique symbols or notations that are used in the document, which may cause confusion with the intended message, or may result in multiple interpretations of some key terms. Term Definition

PROJECT BACKGROUND
<< Provide an introduction to the Project. This includes describing the business context of the project and an overview of the clients operation. Include a high-level overview of each of the functional business areas. >>

INTENT
<< Describe the intent of the solution. What is to be provided? If an RFP is to follow, identify what the client is buying from the vendor professional services, hardware, software, Software as a Service (SaaS), support, peripheral devices etc. >>

SOLUTION SCOPE
<< Define the scope of the solution, not the project. >>

CURRENT SYSTEM ENVIRONMENT

<< Describe the current environment does the client have an existing application? What it is? What are some of the key challenges with the system? If no automated system, is everything done manually? Describe it. If the current system has financial impacts, provide an explanation in the following table: >>

Financial Implications - High-Level

Financial Business Processes If Manual, describe. Current process interactions with OCG: Estimated Volume: If Automated, describe. Existing Interfaces:
BUSINESS REQUIREMENT DOCUMENT TEMPLATE VERSION 4.0, 2012-06-01 PAGE 7 OF 20

Government of Newfoundland and Labrador Office of the Chief Information Officer Solution Delivery: Project Management Office

Financial Implications - High-Level

Financial Business Processes Describe existing documentation for these processes:

STAKEHOLDERS
<< Identify the stakeholders who have a stake in the project departments, OCG (involvement required to develop financial business processes and/or internal controls), their clients, anyone that the system is going to provide information to such as federal agencies, et cetera. Identify the stakeholder and describe their stake in the system. >> Stakeholder Role

PROJECT OBJECTIVE
<< State the objectives of the project. What is the system going to help the client achieve? How do you know that the system delivered meets the needs of the client? >>

BUSINESS REQUIREMENT DOCUMENT TEMPLATE VERSION 4.0, 2012-06-01

PAGE 8 OF 20

Government of Newfoundland and Labrador Office of the Chief Information Officer Solution Delivery: Project Management Office

BUSINESS REQUIREMENTS OVERVIEW

DESCRIPTION
Business Requirements describe WHAT the system, process or product/service must do in order to fulfill the business need(s) and are categorized into three (3) priorities: o o o High Requirements identified as High are deemed critical to the operation of the proposed system. They represent features that the client cannot function without. Medium Requirements identified as Medium are those that are not mission critical to the clients business but could provide significant benefit to the organization. Low Requirements identified as Low are not critical to the operations of the proposed system, but would represent helpful or convenient features that would be beneficial to the client.

TEMPLATE GUIDELINES
In each of the following tables, use the following guidelines: Number Use to uniquely identify each requirement. The number should be a sequential number starting at one and should not be prefixed or reset when starting a new requirement. Requirement Use to define the business requirement ensuring each accurately describes the functionality to be delivered. Priority Use to indicate if the requirement is High, Medium or Low as defined above. Additional Information Use to describe other information related to the requirement.

RECOMMENDED WORDING FOR WRITING REQUIREMENTS

Use of the word must to describe a requirement as in the system must is acceptable only within each Functional Area Description.

BUSINESS REQUIREMENT DOCUMENT TEMPLATE VERSION 4.0, 2012-06-01

PAGE 9 OF 20

Government of Newfoundland and Labrador Office of the Chief Information Officer Solution Delivery: Project Management Office

BUSINESS REQUIREMENTS
BUSINESS REQUIREMENTS
Business requirements identify the strategic, tactical and operational needs along with the goals and/or objectives of the sponsoring organization. These are always documented from a management perspective. Priority # Requirements
H - High M Medium L Low

Additional Information

REGULATORY REQUIREMENTS
Regulatory requirements address legislative or legal requirements of a business. They can be internal or external regulations. These are non-negotiable. << Simply specifying that the system should adhere to a law or legislation is not an acceptable requirement. Elaborate on how the business system will meet the regulation. e.g., The system must record and store the name and address of all passengers travelling on the ferry as per the Federal Government Safety Act. >> Priority # Requirements
H - High M Medium L Low

Additional Information

FUNCTIONAL REQUIREMENTS
Process requirements identify what the product should do in order to fulfill the business need. << e.g., The system should notify the users manager when a new timesheet is submitted >> Note: For each process, copy and paste additional sections and rows as required.
BUSINESS REQUIREMENT DOCUMENT TEMPLATE VERSION 4.0, 2012-06-01 PAGE 10 OF 20

Government of Newfoundland and Labrador Office of the Chief Information Officer Solution Delivery: Project Management Office

Functional Area 1 - << Identify area >>

Description: << Provide a brief description of the functional area to be included in the solution. (e.g. Scheduling, Purchase orders, Suppliers, Vessel Maintenance, et cetera) The description should summarize the detailed requirements identified in the table below. Every requirement listed below should logically map back to the summary description. Functional Area descriptions represent the mandatory process requirements of the system within the resulting Request for Proposal (RFP). Use the word must within the summary paragraph only. Use the word should in the Requirements column below. >> Priority # Requirements
H - High M Medium L Low

Additional Information

Functional Area N - << Identify area >>

Description: << Provide a brief description of the functional area to be included in the solution. (e.g. Scheduling, Purchase orders, Suppliers, Vessel Maintenance, et cetera) The description should summarize the detailed requirements identified in the table below. Every requirement listed below should logically map back to the summary description. Functional Area descriptions represent the mandatory process requirements of the system within the resulting Request for Proposal (RFP). Use the word must within the summary paragraph only. Use the word should in the Requirements column below. >> Priority # Requirements
H - High M Medium L Low

Additional Information

FUNCTIONAL AREA SUMMARY

<< Copy and paste the Functional Area Description from each Functional Area into the table below. This table will be copied into the resulting RFP as the mandatory Functional Requirements. >> Functional Areas

BUSINESS REQUIREMENT DOCUMENT TEMPLATE VERSION 4.0, 2012-06-01

PAGE 11 OF 20

Government of Newfoundland and Labrador Office of the Chief Information Officer Solution Delivery: Project Management Office

REPORTING REQUIREMENTS
Reporting requirements identify what reports the application and/or system must be able to manage. << e.g. Frequency of report, required run dates / times, recipients of reports, format, data source, distribution methods, storage as it applies to reporting. >> Priority # Requirements
H - High M Medium L Low

Additional Information

INTERFACE / INTEGRATION REQUIREMENTS

Interface Requirements identify what information is needed to ensure that the system will communicate properly with external components. << e.g. Application integration (e.g. FMS, Statistics Canada, Revenue Canada, et cetera), user interfaces (e.g. message display, navigation links, et cetera), communication interfaces (e.g. e-Mail, Web Browser, Electronic forms, et cetera), interfaces to other systems to complete daily/weekly data exchanges, et cetera. >> Priority # Requirements
H - High M Medium L Low

Additional Information

USABILITY REQUIREMENTS
Usability requirements identify what users abilities and expectations of usage experiences the product must conform to. Meant to address user friendliness and how the user interfaces (screens) are designed with consideration for the different types or users and their skill sets. << e.g. On-line field help, pop-up calendars for date fields, feedback to users on tasks, progress bars, hourglasses, minimize data entry through use of pick lists, save documents in progress, et cetera. >>

BUSINESS REQUIREMENT DOCUMENT TEMPLATE VERSION 4.0, 2012-06-01

PAGE 12 OF 20

Government of Newfoundland and Labrador Office of the Chief Information Officer Solution Delivery: Project Management Office

Priority # Requirements
H - High M Medium L Low

Additional Information

TRAINING REQUIREMENTS
Training requirements identify all user, help desk and support training required. << e.g. required materials, level of training, number of participants, duration of training, et cetera. >> Priority # Requirements
H - High M Medium L Low

Additional Information

SECURITY REQUIREMENTS
Security requirements identify the security, confidentiality, integrity and privacy issues affecting access to the product, use of the product, and protection of the data the product uses or creates. << e.g. Roles, access areas, user privileges, number of people in each role, et cetera. >> Priority # Requirements
H - High M Medium L Low

Additional Information

CLIENT IMPLEMENTATION REQUIREMENTS

Client Implementation requirements identify specific impacts to the client during implementation. << e.g. Out of town, overtime, busy periods for client, et cetera. >>
BUSINESS REQUIREMENT DOCUMENT TEMPLATE VERSION 4.0, 2012-06-01 PAGE 13 OF 20

Government of Newfoundland and Labrador Office of the Chief Information Officer Solution Delivery: Project Management Office

Priority # Requirements
H - High M Medium L Low

Additional Information

DATA CONVERSION

AND

CLEANSING REQUIREMENTS

Data Conversion requirements identify the specific requirements pertaining to data conversion and cleansing << e.g. Migration of employee data from current application to new application, data cleansing efforts, et cetera. >> Priority # Requirements
H - High M Medium L Low

Additional Information

AVAILABILITY REQUIREMENTS
Availability requirements identify a measurement of the planned uptime during which the system is actually available for use and fully operational. These requirements should be documented in terms of application and required availability. << e.g. Available 24x7, 365 days a year, et cetera. >> Priority # Requirements
H - High M Medium L Low

Additional Information

FLEXIBILITY REQUIREMENTS
Flexibility (augmentability and expandability) requirements measure the ease of adding new capabilities to the product.
BUSINESS REQUIREMENT DOCUMENT TEMPLATE VERSION 4.0, 2012-06-01 PAGE 14 OF 20

Government of Newfoundland and Labrador Office of the Chief Information Officer Solution Delivery: Project Management Office

<< e.g. Ability and ease of adding new functionality, modifying existing functionality, adding additional content, et cetera >> Priority # Requirements
H - High M Medium L Low

Additional Information

SYSTEM CAPACITY AND SCALABILITY REQUIREMENTS

System Capacity and Scalability requirements identify the expected load on the system, how many users are likely to access the system concurrently, system usage and the system attributes. << e.g. Average number of concurrent users; maximum number of concurrent users, average number transactions processed per day, maximum number of transactions processed per day, et cetera. >> Priority # Requirements
H - High M Medium L Low

Additional Information

PERFORMANCE REQUIREMENTS
Performance requirements identify what the application and/or system must do efficiently. << e.g. Response time, maximum duration to execute a task, upload time, et cetera. >> Priority # Requirements
H - High M Medium L Low

Additional Information

BUSINESS REQUIREMENT DOCUMENT TEMPLATE VERSION 4.0, 2012-06-01

PAGE 15 OF 20

Government of Newfoundland and Labrador Office of the Chief Information Officer Solution Delivery: Project Management Office

ROBUSTNESS REQUIREMENTS
Robustness requirements identify the degree to which the product continues to function properly when confronted with invalid inputs, defects in connected software and hardware components or unexpected operating conditions. << e.g. Ability for the solution to recover all changes made in the file up to one minute prior to the failure, et cetera >> Priority # Requirements
H - High M Medium L Low

Additional Information

INFORMATION MANAGEMENT REQUIREMENTS

The Information Management requirements are meant to ensure that systems have the ability to delete records at the end of their lifecycle in compliance with the Management of Information Act. << These are standard IM Requirements that are required for all applications. For those projects proceeding to an RFP, these requirements may be deleted as they are included in the OCIO RFP template. >> Priority # Requirements
H - High M Medium L Low

Additional Information

The Application must have the capability to purge data based on an approved RRDS with: Procedures detailing the process; The capability to delay the disposition process in the event that data is required for ongoing litigation, ATIPPA request, audits, etc.; and The capability of producing a disposition report. The Application must maintain an Audit trail which captures at a minimum: Additions/modifications to user access rights/permissions; Any and all action taken on an electronic record or its metadata; The identity of the user carrying out the action; The date and time of the action;

BUSINESS REQUIREMENT DOCUMENT TEMPLATE VERSION 4.0, 2012-06-01

PAGE 16 OF 20

Government of Newfoundland and Labrador Office of the Chief Information Officer Solution Delivery: Project Management Office

Priority # Requirements
H - High M Medium L Low

Additional Information

The Audit trail may not be altered; and The Audit trail of a record must be retained as long as the record to which it pertains. Where migration or conversion is required, original data, associated metadata and audit trails (if available) must be retained and preserved. (refresh, snapshot etc.)

FINANCIAL REQUIREMENTS
The Financial Requirements are meant to ensure that systems impacting Government financial systems follow the correct financial processes. If the system will impact financial systems, then the Office of the Comptroller General (OCG) must have involvement. Priority
H - High M Medium L Low

# 1 2 3 4

Requirements Vendor / Customer Creation Accounts Payable (process invoices, produce cheques or EFTs, refunds) Accounts Receivable (produce invoices, process payments on account and process overpayments) Revenue Receipting: CCR The internal departmental receipting of revenue at various departmental locations using the CCR application. CWR The online receipting of revenue via the CWR application and ePayment Broker from the general public. Other Online The online receipting of revenue via a departmental specific application and ePayment Broker. Payroll Services (taxable benefit or other Canada Revenue Agency related reporting) Employee Data Loans (disburse, collect) Grants (provide, or equity investments) Procurement / Purchasing (generate requisitions) Budgeting / Forecasting Program Financial Information Encumbering Funds Track available funds via budget / encumbrance

Additional Information

5 6 7 8 9 10 11 12 13

BUSINESS REQUIREMENT DOCUMENT TEMPLATE VERSION 4.0, 2012-06-01

PAGE 17 OF 20

Government of Newfoundland and Labrador Office of the Chief Information Officer Solution Delivery: Project Management Office

Requirements recording within GL Conduct valuation / measurement of inventory and / or tangible capital assets Financial Reporting

Priority
H - High M Medium L Low

Additional Information

14 15

BUSINESS REQUIREMENT DOCUMENT TEMPLATE VERSION 4.0, 2012-06-01

PAGE 18 OF 20

Government of Newfoundland and Labrador Office of the Chief Information Officer Solution Delivery: Project Management Office

ASSUMPTIONS, DEPENDENCIES AND CONSTRAINTS

ASSUMPTIONS
Identify any assumptions; factors that, for planning purposes are considered to be true, real or certain without proof or demonstration # Assumptions

DEPENDENCIES
Identify any factors that are linked together where each has some effect on the other. These may include things like availability of project resources, users or stakeholders, equipment, business processes and regulatory approvals. # Dependencies

CONSTRAINTS
Identify any factors that limit or place constraints on the development of the solution. These may include but are not limited to regulatory, technological or business realities. # Constraints

BUSINESS REQUIREMENT DOCUMENT TEMPLATE VERSION 4.0, 2012-06-01

PAGE 19 OF 20

Government of Newfoundland and Labrador Office of the Chief Information Officer Solution Delivery: Project Management Office

USER COMMUNITY
Complete the following table on the user community for this solution. Community User Internal External Extranet Partner* Quantity Functional Area Access Required << e.g. Court case management files, purchase orders >>

<< e.g. Clerk, System Administrator >>

<< identify estimate number of users >>

* Extranet Partner is a user with a higher level of trust based on contractual agreements (e.g. business partners, Health Authorities).

BUSINESS REQUIREMENT DOCUMENT TEMPLATE VERSION 4.0, 2012-06-01

PAGE 20 OF 20