Government of Newfoundland and Labrador

Office of the Chief Information Officer

Corporate Services & Projects: Project Management Office

BUSINESS REQUIREMENTS DOCUMENT

<< PROJECT NUMBER >>
<< PROJECT AND NAME >>
VERSION: N.N

DATE <<YYYY-MM-DD >>

 Government of Newfoundland and Labrador
Office of the Chief Information Officer
Corporate Services & Projects: Project Management Office

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

Document Revision History

Date Version SLDC Phase / Revision Description Author
<< YYYY-MM-DD >>
<< YYYY-MM-DD >>
<< YYYY-MM-DD >>
<< YYYY-MM-DD >>
<< YYYY-MM-DD >>
<< YYYY-MM-DD >>
<< YYYY-MM-DD >>
<< YYYY-MM-DD >>
<< YYYY-MM-DD >>
<< YYYY-MM-DD >>
<< YYYY-MM-DD >>

Content changes between the current version and the previous version are identified using the Blackline
convention (i.e., additions and deletions).

<< Please refer to the guideline section located at the back of the template for additional instructions.

For the revision history, start at 0.1 for the initial draft and increment major releases as the document
progresses through each SDLC phase. Increment minor releases within the phases.

For the revision description, briefly summarize the changes from the previous version. Do not itemize the
changes. Identify differences from the previous version only. >>

BUSINESS REQUIREMENTS DOCUMENT

TEMPLATE VERSION 5.0, 2014-04-25
 Government of Newfoundland and Labrador
Office of the Chief Information Officer
Corporate Services & Projects: Project Management Office

TABLE OF CONTENTS
1 INTRODUCTION.....................................................................................................................1
1.1 Acronyms and Glossary................................................................................................................1
1.2 Purpose and Intent.......................................................................................................................1
1.3 Other Related Documents............................................................................................................1
1.4 Project Background......................................................................................................................2
1.5 Solution Scope..............................................................................................................................2
1.6 Current Solution Environment.....................................................................................................2
1.7 Stakeholder Consultations...........................................................................................................3
1.8 User Community..........................................................................................................................4
2 BUSINESS REQUIREMENTS.......................................................................................................5
3 FINANCIAL REQUIREMENTS....................................................................................................10
4 ASSUMPTIONS, DEPENDENCIES AND CONSTRAINTS.....................................................................13
4.1 Assumptions...............................................................................................................................13
4.2 Dependencies.............................................................................................................................13
4.3 Constraints.................................................................................................................................13
APPENDICES..............................................................................................................................14
GUIDELINES FOR COMPLETING THIS DOCUMENT................................................................................15

BUSINESS REQUIREMENTS DOCUMENT

TEMPLATE VERSION 5.0, 2014-04-25
 Government of Newfoundland and Labrador
Office of the Chief Information Officer
Corporate Services & Projects: Project Management Office

1 INTRODUCTION
1.1 ACRONYMS AND GLOSSARY
The following table includes definitions for any unique symbols or notations that are used in the document.

Term Definition
BRD Business requirement document
EA Enterprise Architecture
Extranet A stakeholder with a higher level of trust based on contractual agreements (e.g. business partners,
Partner Health Authorities).
GNL Government of Newfoundland and Labrador
IM Information Management
OCG Office of the Comptroller General
RFP Request for proposal
SDLC System development lifecycle
SME Subject matter expert
TRA Threat risk assessment
TRD Technical requirements document

Table 1: Acronyms and Glossary

1.2 PURPOSE AND INTENT

1.3 OTHER RELATED DOCUMENTS

Other project documents that may be related include:
 The Technical Requirements Document produced by the OCIO’s Enterprise Architecture Division
consists of technical architecture requirements (e.g., solution architecture, database architecture,
security architecture, network architecture et cetera) that align the solution with OCIO standards
and best practices (as described in the Guidelines and Best Practices for Government Technology
Solutions);

BUSINESS REQUIREMENTS DOCUMENT PAGE 1

TEMPLATE VERSION 5.0, 2014-04-25
 Government of Newfoundland and Labrador
Office of the Chief Information Officer
Corporate Services & Projects: Project Management Office

 The Business Process Definition document produced by the OCIO Corporate Services & Projects
project team to model the business processes when there are no financial processes to be defined;
<< If there are financial processes, use the Financial Management and Business Process Definition
template. It is possible for neither, one or both business process templates to be used (at the
discretion of the Delivery Manager). Contact the PMO to obtain a copy of this template. >>
 The Financial Management and Business Process Definition document outlines the financial
management controls and processes followed by a department to manage and support the
business associated with a project; << Complete this document if work associated with a project
impacts or influences either of the following (with or without system integration): financial
transactions, public money, or public accounts. Contact the PMO to obtain a copy of this template.
>>
 The Risk Assessment Workbook document, produced by the OCIO’s Information Projection Division
as part of the SLDC’s Pre-TRA process, contains the solution’s information security classification and
pre-TRA checklist;
 The Information Management Assessment document, produced by the OCIO’s Information
Management Division contains client and system recommendations related to compliance with the
Management of Information Act; and
 The RFP document produced by the OCIO’s Corporate Information Management Services group (if
required) consisting of proposal requirements (e.g., proponent, contract, solution requirements et
cetera).

1.4 PROJECT BACKGROUND

1.5 SOLUTION SCOPE

1.6 CURRENT SOLUTION ENVIRONMENT

Financial Implications
OCG Process Estimated Existing
Interaction Volume Documentation
Manual

BUSINESS REQUIREMENTS DOCUMENT PAGE 2

TEMPLATE VERSION 5.0, 2014-04-25
 Government of Newfoundland and Labrador
Office of the Chief Information Officer
Corporate Services & Projects: Project Management Office

Financial Implications
OCG Process Estimated Existing
Interaction Volume Documentation
Automated

Interface

Table 2: Financial implications of the current solution

1.7 STAKEHOLDER CONSULTATIONS

The stakeholders consulted for this document are listed in the following tables in alphabetical order.

<< Identify the stakeholders for the solution and for the project, succinctly describe or categorize their
role(s), and whether they were consulted. Reference the Preliminary Scope and the Project Charter
documents for a preliminary list of stakeholders. Add additional rows as required. Indicate those with no
role as “not applicable”. >>

Stakeholder Role Consulted

Departmental Comptroller << Yes / No >>
Financial Systems Control << Yes / No >>
Office of the Comptroller General << Yes / No >>

Table 3: Business and Financial Stakeholders

Stakeholder Role Consulted

Dept Communications Division << Consult at the discretion of the client >> << Yes / No >>
Dept Information Mgmt Division << Yes / No >>
<< Consult at the discretion of the OCIO Delivery
NL Statistics Agency << Yes / No >>
Manager >>
OCIO Application & Information
<< Yes / No >>
Management Services
OCIO Enterprise Architecture << Yes / No >>
OCIO Information Management << Yes / No >>
OCIO Information Protection << Yes / No >>
BUSINESS REQUIREMENTS DOCUMENT PAGE 3
TEMPLATE VERSION 5.0, 2014-04-25
 Government of Newfoundland and Labrador
Office of the Chief Information Officer
Corporate Services & Projects: Project Management Office

Stakeholder Role Consulted

OCIO Operations & Security << Yes / No >>

Table 4: Project and Technical Stakeholders

1.8 USER COMMUNITY

The user groups that are expected to have access to the solution are listed in the following table. << Use the
same functional areas described later in this document. >>

Community
Functional Area Access
User Group Internal External Extranet Quantity
Required
Partner

Table 5 : User Community

BUSINESS REQUIREMENTS DOCUMENT PAGE 4

TEMPLATE VERSION 5.0, 2014-04-25
 Government of Newfoundland and Labrador
Office of the Chief Information Officer
Corporate Services & Projects: Project Management Office

2 BUSINESS REQUIREMENTS
REVIEWERS
The following individuals have reviewed the business requirements on the date indicated. << At the direction of the OCIO Delivery Manager, edit the
business requirement reviewers and approvers as required for the project. Wet signatures may not be required. Sign-off of changes may be handled
external to this document. >>

<< YYYY-MM-DD >>

OCIO Information Management
(name) (signature) (date)
<< YYYY-MM-DD >>
OCIO Information Protection
(name) (signature) (date)
<< YYYY-MM-DD >>
OCIO Enterprise Architecture
(name) (signature) (date)
<< YYYY-MM-DD >>
Office of the Comptroller General
(name) (signature) (date)
<< YYYY-MM-DD >>
Newfoundland Statistics Agency
(name) (signature) (date)
<< YYYY-MM-DD >>
OCIO Corporate Services
(name) (signature) (date)

APPROVERS
The following individual has approved the business requirements on the date indicated.

<< YYYY-MM-DD >>

Client Project Sponsor
(name) (signature) (date)

BUSINESS REQUIREMENTS DOCUMENT PAGE 5

TEMPLATE VERSION 5.0, 2014-04-25
 Government of Newfoundland and Labrador
Office of the Chief Information Officer
Corporate Services & Projects: Project Management Office

BUSINESS ALIGNMENT

Strategic Business Goals and Objectives Additional Information

GOAL-1:
Objective 1.1:
Objective 1.2:
GOAL-2:
Objective 2.1:
Objective 2.2:
GOAL-3:
Objective 3.1:
Objective 3.2:
Table 6: Business Alignment

LEGISLATIVE AND REGULATORY ALIGNMENT

Legislation / Regulation Additional Information

A. The solution complies with the provincial Management of Information Act (details are presented in the
information management section of this document).
B.
C.
Table 7: Legislative and Regulatory Alignment

BUSINESS REQUIREMENTS DOCUMENT PAGE 6

TEMPLATE VERSION 5.0, 2014-04-25
 Government of Newfoundland and Labrador
Office of the Chief Information Officer
Corporate Services & Projects: Project Management Office

REQUIREMENTS

Requirement << The nested requirement IDs below are for illustration purposes only. Adjust as required.>> Priority Additional Information
Data << If appropriate, include a conceptual data model in the appendix and reference it here. >>
RQ-1:
RQ-1.1:
RQ-2:
RQ-2.1:

Standards
RQ-3:
RQ-4:
Functional
RQ-5:
RQ-6:
RQ-7:
RQ-8:
Interface / Integration
RQ-9:
RQ-10:
Reporting
RQ-11:
RQ-12:
Usability
RQ-13:
BUSINESS REQUIREMENTS DOCUMENT PAGE 7
TEMPLATE VERSION 5.0, 2014-04-25
 Government of Newfoundland and Labrador
Office of the Chief Information Officer
Corporate Services & Projects: Project Management Office

Requirement << The nested requirement IDs below are for illustration purposes only. Adjust as required.>> Priority Additional Information
RQ-14:
Security
RQ-15:
RQ-16:
Client Implementation
RQ-17:
RQ-17.1:
RQ-17.1.1:
RQ-17.1.1.1:
RQ-18:
Data Conversion and Cleansing
RQ-19:
RQ-20:
Availability
RQ-21:
RQ-22:
Flexibility
RQ-23:
RQ-24:
System Capacity and Scalability
RQ-25:
RQ-26:
Performance
BUSINESS REQUIREMENTS DOCUMENT PAGE 8
TEMPLATE VERSION 5.0, 2014-04-25
 Government of Newfoundland and Labrador
Office of the Chief Information Officer
Corporate Services & Projects: Project Management Office

Requirement << The nested requirement IDs below are for illustration purposes only. Adjust as required.>> Priority Additional Information
RQ-27:
RQ-28:
Robustness
RQ-29:
RQ-30:
Information Management
RQ-31:
RQ-32:
RQ-33:
RQ-34:
Training
RQ-35:
RQ-36:
Other
RQ-37:
RQ-38:
Table 8: Business Requirements

BUSINESS REQUIREMENTS DOCUMENT PAGE 9

TEMPLATE VERSION 5.0, 2014-04-25
 Government of Newfoundland and Labrador
Office of the Chief Information Officer
Corporate Services & Projects: Project Management Office

3 FINANCIAL REQUIREMENTS
REVIEWERS
The following individuals have reviewed the financial requirements on the date indicated. << At the direction of the OCIO Delivery Manager, edit the
financial requirement reviewers and approvers as required for the project. Wet signatures may not be required. Sign-off of changes may be handled
external to this document. >>

<< YYYY-MM-DD >>

OCIO Project Manager
(name) (signature) (date)
<< YYYY-MM-DD >>
OCIO Delivery Manager
(name) (signature) (date)
<< YYYY-MM-DD >>
Client Department Comptroller
(name) (signature) (date)

APPROVERS
The following individuals have approved the financial requirements on the date indicated.

<< YYYY-MM-DD >>

Client Project Sponsor
(name) (signature) (date)
<< YYYY-MM-DD >>
Office of the Comptroller General
(name) (signature) (date)

BUSINESS REQUIREMENTS DOCUMENT PAGE 10

TEMPLATE VERSION 5.0, 2014-04-25
 Government of Newfoundland and Labrador
Office of the Chief Information Officer
Corporate Services & Projects: Project Management Office

REQUIREMENTS
These requirements describe the functions and features possessed by the solution to support various financial processes and best practices.

Requirement Priority Additional Information

<< Revenue Receipting >>
RQ-39: The solution supports revenue receipting as per OCG financial standards.
RQ-39.1: Support product management processes (e.g., add, update, delete product et cetera)
RQ-39.2: Support inventory management processes (e.g., add, update, void, return inventory et cetera)
RQ-39.3: Support customer management processes (e.g., add customer, store customer information, et cetera)
RQ-39.4: Support order management
RQ-39.4.1: Support online orders (e.g., validations, limits, confirmation, delivery, et cetera)
RQ-39.4.2: Support over the counter orders (e.g., validations, limits, confirmation, delivery, et cetera)
RQ-39.4.3: Support mail orders (e.g., validations, limits, confirmation, delivery, et cetera)
RQ-39.4.4: Support telephone orders (e.g., validations, limits, confirmation, delivery, et cetera)
RQ-39.4.5: Support fax orders (e.g., validations, limits, confirmation, delivery, et cetera)
RQ-39.4.6: Support e-mail orders (e.g., validations, limits, confirmation, delivery, et cetera)
RQ-39.4.7: Support order modification (e.g., reasons, validation, approvals, et cetera)
RQ-39.4.8: Support order cancellation (e.g., reasons, validation, approvals, et cetera)
RQ-39.5: Support payment processes (e.g., types, errors, issue resolution, receipting, et cetera)
RQ-39.6: Support fulfillment processes (e.g., validations, issue resolution, delivery, inventory, et cetera)
RQ-39.7: Support refund processes (e.g., initiation, recording, reasons, et cetera)
RQ-39.8: Support reconciliation processes
RQ-39.8.1: Support start-of-period processes (e.g., inventory, receipts, cash, ePayment, et cetera)
RQ-39.8.2: Support end-of-period processes (e.g., inventory, receipts, cash, ePayment, et cetera)
RQ-39.9: Support audit processes (e.g., types, stages, timing, et cetera)
<< Financial Assistance Programs >>
RQ-40: The solution supports financial assistance provisioning.
RQ-40.1: Support client management processes (e.g., add client, store client information, update client, et cetera)
RQ-40.2: Support client application management processes
RQ-40.2.1: Support client application processes (e.g., benefits, validation, reviews, et cetera)
RQ-40.2.2: Support client application modification processes (e.g., reasons, approvals, et cetera)
RQ-40.3: Support client eligibility processes (e.g., criteria, entitlement, benefit durations, approvals, et cetera)

BUSINESS REQUIREMENTS DOCUMENT PAGE 11

TEMPLATE VERSION 5.0, 2014-04-25
 Government of Newfoundland and Labrador
Office of the Chief Information Officer
Corporate Services & Projects: Project Management Office

Requirement Priority Additional Information

RQ-40.4: Support accounts payable processes
RQ-40.4.1: Support special authorization processes (e.g., initiation, statuses, limits, et cetera)
RQ-40.4.2: Support invoice and payment processing (e.g., disbursement, remittances, et cetera)
RQ-40.4.3: Support invoice cancellation processes (e.g., reasons, approvals, et cetera)
RQ-40.4.4: Support void payment processes (e.g., reasons, validation, approvals, et cetera)
RQ-40.4.5: Support stale date cheque processes (e.g., reasons, validation, approvals, et cetera)
RQ-40.4.6: Support stop payment processes (e.g., reasons, validation, approvals, et cetera)
RQ-40.4.7: Support underpayment processes (e.g., discovery, disputes, approvals, et cetera)
RQ-40.4.8: Support emergency payment processes (e.g., scenarios, resolution, et cetera)
RQ-40.4.9: Support overpayment processes (e.g., discovery, disputes, approvals, et cetera)
RQ-40.5: Support FMS purchase order processes (e.g., availability, roles, et cetera)
RQ-40.6: Support FMS supplier maintenance processes (e.g., add supplier, change supplier name, et cetera)
RQ-40.7: Support reconciliation processes
RQ-40.7.1: Support start-of-period processes (e.g., invoices, payments, commitments, et cetera)
RQ-40.7.2: Support end-of-period processes (e.g., invoices, payments, commitments, et cetera)
RQ-40.8: Support audit processes (e.g., types, stages, timing, et cetera)
<< Revenue Impacting >>
RQ-41: The solution supports financial processes that impact revenue to the Government of Newfoundland and Labrador.
RQ-41.1: Support royalty agreement processes (e.g., agreement type, negotiation, et cetera)
RQ-41.2: Support revenue management processes (e.g., revenue determination, payment processing, et cetera)
RQ-41.3: Support FMS supplier maintenance processes (e.g., add supplier, inactivate supplier, et cetera)
RQ-41.4: Support refund processes (e.g., initiating, reasons, calculations, interest, et cetera)
RQ-41.5: Support account receivable management (e.g., initiating, reasons, calculation, interest et cetera)
RQ-41.6: Support reconciliation processes (e.g., returns, payments, refunds, segregation of duties, et cetera)
RQ-41.7: Support audit processes (e.g., types, stages, timing et cetera)
Table 9: Financial Requirements

BUSINESS REQUIREMENTS DOCUMENT PAGE 12

TEMPLATE VERSION 5.0, 2014-04-25
 Government of Newfoundland and Labrador
Office of the Chief Information Officer
Corporate Services & Projects: Project Management Office

4 ASSUMPTIONS, DEPENDENCIES AND CONSTRAINTS

4.1 ASSUMPTIONS
Factors assumed for the completion of this document that are considered to be true, real, or certain
without proof or demonstration are identified in the following table.

# Assumptions

Table 10: Assumptions

4.2 DEPENDENCIES
External factors or events that are linked to the solution (in that one has an effect on the other) are
identified in the following table. << These factors may include events such as impending legislation,
completion of a related project, release of a new message set or standard, initiation of a related project, et
cetera. >>

# Dependencies

Table 11: Dependencies

4.3 CONSTRAINTS
Factors that limit or slow the successful development, deployment or adoption of the solution are identified
in the following table. << Identify any elements that may constrain the success of the solution. These may
include legal, technological or business realities (e.g., brown outs, busy periods for client et cetera). >>

# Constraints

Table 12: Constraints

BUSINESS REQUIREMENTS DOCUMENT PAGE 13

TEMPLATE VERSION 5.0, 2014-04-25
 Government of Newfoundland and Labrador
Office of the Chief Information Officer
Corporate Services & Projects: Project Management Office

APPENDICES
A – << SAMPLE CONCEPTUAL DATA MODEL >>
<< For conceptual data models, indicate the name of the entity, the primary keys, the information
associated with each entity and the inter-relationships between entities. The following diagram is a sample
only. Replace or delete as appropriate. >>

Figure 1: Sample Conceptual Data Model

BUSINESS REQUIREMENTS DOCUMENT PAGE 14

TEMPLATE VERSION 5.0, 2014-04-25
 Government of Newfoundland and Labrador
Office of the Chief Information Officer
Corporate Services & Projects: Project Management Office

GUIDELINES FOR COMPLETING THIS DOCUMENT

This entire section is instructional only and to be removed from the main body upon completion of the
deliverable.

DOCUMENT GUIDELINES
1. Reviews and approvals:
a. Complete all reviews prior to obtaining approval signatures.
b. Reviews begin with the OCIO Delivery Manager.
c. If this document is intended to inform an RFP, include OCIO Corporate Services as a reviewer.
2. Text contained within << >> provides instructional information or examples and are to be deleted once
the section has been completed.
3. All tables should have landscape orientation.
4. Maintain the formatting styles used by this template (e.g., do not change the format or fonts).
5. Ensure document language is set to English(Canada).
6. Additional relevant information may be added as an appendix.
7. Appendices are to be individually identified and referenced from within the main body of the
document.
8. Sections 2 through 4 are to be completed in full (i.e., no section is to be deleted or left blank). If a
particular section is not applicable, then indicate “Not Applicable” and provide reasoning.
9. Delete examples under each section once the section has been completed.
10. For each new revision of this document, identify differences (i.e., insertions and deletions) from the
previous version using the Blackline convention.
11. Peer review this document for quality prior to submitting for OCIO review.

SECTION GUIDELINES
 Section 1.1 Acronyms and Glossary
 Define all acronyms.
 Define any terms that may cause confusion or may be misinterpreted.
 Section 1.2 Purpose and Intent
 This BRD is a “living document” that describes the known functions and/or capabilities required
of a solution at a point in the OCIO’s system development lifecycle. It is intended to be used in
subsequent SDLC phases and activities. Therefore, its audience will include many diverse
stakeholders.
 This document is not intended to contain solution design content (i.e., how the solution will
deliver functionality).
 State the document’s intended use (e.g. to inform a COTS RFP, a SaaS RFP, an RFI, a custom build
et cetera).
 Section 1.3 Other Related Documents
 Reference any business deliverables / documents associated with this requirements document.

BUSINESS REQUIREMENTS DOCUMENT PAGE 15

TEMPLATE VERSION 5.0, 2014-04-25
 Government of Newfoundland and Labrador
Office of the Chief Information Officer
Corporate Services & Projects: Project Management Office

 Section 1.4 Project Background

 Provide a brief introduction to the project. This includes describing the business context of the
project and the client.
 Section 1.5 Solution Scope
 Define the scope of the solution that this document describes. Indicate any components no
longer in scope (e.g., scope changes from that described in the Preliminary Scope document). Do
not duplicate the project scope as written the Project Charter.
 Section 1.6 Current Solution Environment
 Describe the current environment as it relates to the solution scope for this document. Does the
client have an existing solution? What it is? What are some of its key challenges? What is being
done manually?
 If the current solution has financial impacts (i.e., OCG interactions) then provide a high level
description.
 Section 1.7 Stakeholder Consultations
 Identify the stakeholders for the solution and for the project, what their role(s) are, and whether
they were consulted. The Preliminary Scope and the Project Charter documents should have
some business stakeholders already identified. Add additional rows as required. Indicate those
with no role as “not applicable”.
 Section 1.8 User Community
 If applicable, identify all possible user groups for the solution.
 For each user group, estimate the number of users and reference the functional areas each will
need access to. Reference the same functional areas as described in the requirements section.

REQUIREMENT GUIDELINES
Requirements describe WHAT the solution, process or product/service does in order to fulfill the business
need(s). Use the following guidelines to complete the requirement sections:
 Requirement – Describe requirements in a manner that is:
 Uniquely identified (use the REQ-Level styles defined in this template to uniquely and
hierarchically number each requirement; elaborate a requirement through nesting);
 Unambiguous and concise (e.g., do not use “is capable of providing…” or “has the ability to
provide…” et cetera);
 Cohesive (i.e., has a singular focus);
 Reviewed and validated (e.g., by business SMEs) as documented in the project charter;
 Realistic and achievable;
 Consistent (i.e., not duplicated or contradictory);
 Testable; and
 Traceable back to a business need or source.
 Priority – Use the following three categories to prioritize requirements (do not introduce and mix
other prioritization methods such as the MoSCoW method):
 High to indicate a solution element that is critical to the client’s business function and operation;
 Medium to indicate a non-critical solution element that provides significant benefit to the client;
and

BUSINESS REQUIREMENTS DOCUMENT PAGE 16

TEMPLATE VERSION 5.0, 2014-04-25
 Government of Newfoundland and Labrador
Office of the Chief Information Officer
Corporate Services & Projects: Project Management Office

 Low to indicate a non-critical solution element that provides a helpful or convenient feature that
is beneficial to the client.
 Additional Information – Include any information related to the requirement (e.g., hyperlinks to
related online content). Where appropriate:
 Reference the associated business process model within the Business Process Definition
document; and
 Identify the owner (e.g., source) of the requirement.

BUSINESS REQUIREMENTS
Use the following guidelines to complete Section 2:
 Business Alignment – Identify the strategic, tactical, and operational goals/objectives that the
solution is expected to achieve (e.g., CYFS Child Care Strategy). These are documented from the
client executive’s perspective. The benefits section of the Business Case and Preliminary Scope
documents may provide insight.
 Legislative and Regulatory Alignment – Identify the legislation or regulation that the solution is
expected to comply with. Legislation may be federal or provincial. Regulations may be internal (e.g.,
departmental) or external (e.g., municipal). Elaborate what the solution needs without duplicating
requirements in other areas of the BRD. Compliance may be process related (e.g., “The solution
facilitates payment of approved debt charges due in accordance with the Financial Administration
Act”) or feature related (e.g., “The solution generates certificates as per Section 9(j) of the
Apprenticeship and Certification Act”). Provide a link to the legislation in the Additional Information
s column.
 Data Requirements – Describe any information that the solution is expected to store. If
applicable, include a conceptual data model (e.g., an entity-relationship diagram) and describe the
model’s requirements.
 Standards Requirements – Highlight any business standards that the solution is expected to
utilize or conform to. Include any standards not covered by the financial requirements or the
technical requirement document. These standards may be process related (e.g., Generally Accepted
Accounting Principles), information related (e.g., ICD-10-CA or the 10th revision of the International
Classification of Diseases Canadian version), data quality related (e.g., the NL Statistics Agency’s
Newfoundland and Labrador communities list), interoperability related (e.g., HL7 v2.x or Health
Level Seven version 2.x), accessibility related (e.g., W3C or World Wide Web Consortium standards),
branding related (e.g., Government of Newfoundland and Labrador Brand Signature Guidelines),
OCIO related (e.g., Web Development Standards and Implementation Guidelines), et cetera.
 Functional Requirements – Identify the solution functions required to fulfill the business need.
For example, “The solution notifies the user’s manager when a new timesheet is submitted.”
Hierarchically elaborate requirements.
 Reporting Requirements – Describe the informational outputs generated and/or managed by the
solution (e.g. report frequency, required run dates / times, recipients, export formats, data source,
distribution methods, et cetera).
 Interface / Integration Requirements – Describe the linkages between the solution and its
external components and stakeholders. Identify the external component (e.g., interfaces to other
BUSINESS REQUIREMENTS DOCUMENT PAGE 17
TEMPLATE VERSION 5.0, 2014-04-25
 Government of Newfoundland and Labrador
Office of the Chief Information Officer
Corporate Services & Projects: Project Management Office

applications, user interfaces, and communication interfaces such as electronic mail, browsers,
electronic forms). Describe each linkage in detail where possible. For example: one-way or two-
way; real-time or overnight batch; push or pull; message sets; protocols; frequency et cetera.
 Usability Requirements – Identify the user abilities and experience expectations the solution
possesses or conforms to. These requirements address user friendliness and how the user
interfaces (e.g., screens) are designed with consideration for the different types of users and their
skill sets. For example: online field help; pop-up calendars for date fields; feedback to users on
tasks; progress bars; hourglasses; pick lists to minimize data entry and improve data quality; save
documents in progress et cetera.
 Security Requirements – Identify the security, confidentiality, integrity and privacy issues
affecting access to the solution, use of the solution, and protection of the data the solution uses or
creates (e.g. roles, access areas, user privileges, number of people in each role, et cetera). The
solution’s information security classification within the Risk Assessment Workbook provided by the
OCIO Information Protection Division may prescribe some security requirements.
 Client Implementation Requirements – Identify any specific business-driven requirements
related to client implementation (e.g., user locations, regional requirements, multiple time zones,
business user support model, data centres, disaster recovery sites, documentation, deployment,
normal business hours, extended business hours, business days, maximum acceptable service
outage et cetera).
 Data Conversion and Cleansing Requirements – Identify specific solution components needed
to convert and/or cleanse data from external sources (e.g., one-time data migration from various
legacy systems, ongoing data imports from interfaced systems).
 Availability Requirements – Identify business-driven expectations of the solution’s planned
uptime and unplanned downtime. Reference the availability classification within the Pre-TRA’s
Information Security Classification summary.
 Flexibility Requirements – These requirements measure the ease of adding new capabilities to
the product (i.e., expandability, extensibility). For example: add new modules for additional
functionality; add new message types to a message set; add new codes to a code set et cetera.
 System Capacity and Scalability Requirements – Identify the expected load on the system in
the near term and in the future. Reference a timeframe. For example, how many users are likely to
access the solution concurrently, how many users is the solution expected to support, how many
transactions is the solution expected to process per time period, at peak load, in five years?
 Performance Requirements – Identify any business-driven expectations of what the solution
needs to do efficiently (e.g., complex query response time, maximum duration to complete a task
within an overall business process, upload time et cetera).
 Robustness Requirements – Describe how the solution continues to function and responds to
invalid inputs, defects in connected software and hardware components or unexpected operating
conditions (e.g., recovery of changes made to the database prior to the incident, error trapping and
system administrator notification et cetera).
 Information Management Requirements – Address the solution’s compliance with the
Management of Information Act. Use the system recommendations in the Information
BUSINESS REQUIREMENTS DOCUMENT PAGE 18
TEMPLATE VERSION 5.0, 2014-04-25
 Government of Newfoundland and Labrador
Office of the Chief Information Officer
Corporate Services & Projects: Project Management Office

Management Assessment document. Check if the client’s business requires any additional
functions, features, capabilities et cetera.
 Training Requirements – These support people change management and adoption by identifying
all user, help desk and support training required for implementation as well as ongoing operations.
For example: required materials; level of training; number of participants; duration of training et
cetera.
 Other Requirements – Identify any additional requirements that do not fit within the previously
defined categories.

Requirements gathering may uncover technical requirements. For example, elaboration of a business
requirement may be technical in nature (e.g., clustering for high availability applications). Discuss these
requirements with the assigned OCIO EA Prime for possible inclusion in the TRD.

FINANCIAL
Complete Section 3 if there are financial requirements (note: the financial processes will be documented in
the Financial Management and Business Process Definition document).

Organize this section according to the structure set forth in Appendix B of the Financial Management and
Business Process Definition document where there are three primary financial functions: Revenue
Receipting, Financial Assistance Programs and Revenue Impacting.

For primary financial functions that do not apply, indicate that the solution does not involve those
functions. For example:
 The solution does not require revenue receipting.
 The solution does not require financial assistance program support.
 The solution does not impact GNL revenue.

For secondary financial processes that do not apply, indicate that the solution is not required to support
them.

BUSINESS REQUIREMENTS DOCUMENT PAGE 19

TEMPLATE VERSION 5.0, 2014-04-25