<enter sponsor dept/bureau name>

<enter project name>

Business Requirements Document
 <enter sponsor dept or bureau name>

Document Instructions
<This document template contains directions for use or sample entries. These directions are enclosed in brackets (<
>) and are italicized. They are included to help you fill out the form. As you complete the form, delete these
instructions.

Please follow this document naming convention to facilitate document search and retrieval:

<project code (if appropriate)> <project name (abbreviated)> <document name (abbreviated)>
<version (if appropriate)>

All documents should be posted to the appropriate project folder in SharePoint. >

Document History
<The document history is a log of changes that are made to the document, who made the changes, and when. For
example, the initial creation of the document may contain the following: Version 0.1, Date 1/1/2004, Author Charlie
Brown, Status Initial creation. Subsequent updates to the document will be Version 0.2, 0.3, etc. The first published
version of the document should be Version 1.0.>

Version Date Author Status Section Revision Description

0.1 Initial Draft

1 First Published

Approvals
<The required approvals for this document are outlined in the project Change Management Plan. SharePoint
workflow approvals may be used In lieu of this Approval section. If utilizing SharePoint, attach this document to the
Change Request list item. If utilizing the document, distribute the document and request electronic signatures to
indicate approval.
Copy additional signature line and details as needed>

Your signature below indicates that this document meets its objectives and is acceptable.

Signature Signature

<Name> <Name>
<Date> <Date>
<Title> <Title>
<Role> <Role>

<enter project code & name> Page 2 of 14 Printed: 10/14/2019

Requirements Document v X.X
 <enter sponsor dept or bureau name>

Table of Contents

1 PURPOSE ................................................................................................................. 4
2 GLOSSARY AND ACRONYMS ................................................................................ 5
3 EXECUTIVE SUMMARY ........................................................................................... 9
3.1 BACKGROUND ................................................................................................... 9
3.2 OBJECTIVES ..................................................................................................... 9
3.3 IN SCOPE ......................................................................................................... 9
3.4 OUT OF SCOPE ................................................................................................. 9
4 REQUIREMENTS ELICITATION AND GATHERING ............................................. 10
4.1 APPROACH OVERVIEW ..................................................................................... 10
4.2 REFERENCES/INPUTS ...................................................................................... 10
5 BUSINESS MODEL ................................................................................................ 11
5.1 ORGANIZATIONAL PROFILE ............................................................................... 11
5.2 HIGH LEVEL ‘AS-IS’ PROCESS FLOW ................................................................. 11
5.3 HIGH LEVEL ‘TO-BE’ PROCESS FLOW ............................................................... 11
5.4 PROCESS MAPPING ......................................................................................... 12
5.5 GAP ANALYSIS ................................................................................................ 12
6 REQUIREMENTS DEFINITION .............................................................................. 13
7 APPENDIX .............................................................................................................. 14

<enter project code & name> Page 3 of 14 Printed: 10/14/2019

Requirements Document v X.X
 <enter sponsor dept/bureau name>

1 Purpose
The purpose of the Business Requirements Document (BRD) is to lay the
foundation for the design and development of a technical solution through definition
of the business’ needs and achieve the goals and objectives of the <enter project
name> project. The BRD describes the high-level business process and outlines the
business needs that will be fulfilled by the successful completion of the project. In
combination with the Requirements Traceability Matrix (RTM), it identifies actual
technical or system requirements for the solution.

The foundation for a successful project is built upon the quality and thoroughness of
requirements gathering. The BRD establishes key requirements, objectives, and
goals that drive all other subsequent lifecycle phases. The RTM describes the
business problem to be solved in terms of verifiable and traceable characteristics
and constraints. In addition to key program level requirements, the requirements
capture operational concepts and program level interfaces. The RTM should be
continuously referenced during the project lifecycle phases to ensure that the
deliverables from the project meet the approved requirements.

Signoff requirements of the BRD, inclusive of the RTM, are defined in the project’s
Change Management Plan. Approval by the project sponsor ensures the
requirements will support achieving the project’s goals and objectives.

<enter project code & name> Page 4 of 14 Business Requirements Document

 <enter sponsor dept/bureau name>

2 Glossary and Acronyms

<A general list of common terms and acronyms are listed. Provide any project-specific terms or acronyms
that may be used within this document; remove any that do not apply.>

Table: Terms and Acronyms Used in This Document

Term/Acronym Definition
ALS Ambulance Licensure Service
BIIT Bureau of Informatics & Information Technology
BEMS Bureau of Emergency Medical Services
BRD Business Requirements Document – Details the business solution for a
project including the documentation of customer needs and
expectations.
Bureau of For this documents purposes this acronym will be used to reference the
Community Bureau of Community Health Program Area
Health
CDC Centers for Disease Control and Prevention
CLA Clinical Laboratory Improvement Act
ConEd Continuing Education
DOB Date of Birth
DOH Department of Health
DBA Database Administrator
DW Data Warehouse – A system used for reporting and data analysis,
which is a central repository of integrated data from one or more
disparate sources.
ELC Epidemiology and Laboratory Capacity for Infectious Diseases – A
cooperative agreement established in 1995 to distribute resources to
domestic public health departments to strengthen the nation’s infectious
disease infrastructure.
ELR Electronic Laboratory Reporting – the electronic transmission from
laboratories to public health of laboratory reports which identify
reportable conditions.
EMS Emergency Medical Services
FI# Field Investigation ID Number
HIV/AIDS For this documents purposes this acronym will be used to reference the
HIV/AIDS Program Area
HL7 Health Level Seven – An application protocol for electronic data
exchange in healthcare environments.
IDE/VPD (EPI) For this documents purposes this acronym will be used to reference the
Infectious Disease/Vaccine Preventable Disease (Epidemiology)
Program Area
LEAD (Childhood For this documents purposes this acronym will be used to reference to
and Adult) LEAD Program Area
LOINC Logical Observation Identifiers, Names and Codes – a database and
universal standard for identifying medical laboratory observations. It
was created and is maintained by the Regenstrief Institute, a US
nonprofit medical research organization.

<enter project code & name> Page 5 of 14 Business Requirements Document

 <enter sponsor dept/bureau name>

Term/Acronym Definition
NPI National Provider Identifier – a unique 10-digit identification number
issued to health care providers in the United States by the Centers for
Medicare and Medicaid Services (CMS). The NPI has replaced the
unique physician identification number (UPIN) as the required identifier
for Medicate services, and is used by other payers, including
commercial healthcare insurers.
NOFUN No Follow-Up Necessary
MCF Medical Command Facility
MMG Message Mapping Guide
MMWR Morbidity & Mortality Weekly Report – a weekly epidemiological digest
for the United States published by the Centers for Disease Control and
Prevention (CDC). It is the main vehicle for publishing public health
information and recommendations that have been received by the CDC
from state health departments. Material published in the report is in the
public domain and may be reprinted without permission.
MTM Microsoft Test Manager – Microsoft Test Manager is used to help test
the application is being built. MTM stores the test plans and results on
Team Foundation Server (TFS).
NHSN National Healthcare Safety Network – The nation’s most widely used
healthcare-associated infection tracking system. NHSN provides
facilities, states, regions, and the nation with data needed to identify
problem areas, measure progress of prevention efforts, and ultimately
eliminate healthcare-associated infections.
NNDSS National Notifiable Diseases Surveillance System – A nationwide
collaboration that enables all levels of public health—local, state,
territorial, federal, and international—to share notifiable disease-related
health information. Public health uses this information to monitor,
control, and prevent the occurrence and spread of state-reportable and
nationally notifiable infectious and noninfectious diseases and
conditions.
OBR Observation Request Segment (part of an HL7 message)
OBX Observation/Result Segment (part of an HL7 message)
OPS Operational Support
PA-NEDSS Pennsylvania National Electronic Disease Surveillance System
PHINMS Public Health Information Network Messaging System – CDC’s
implementation of Secure and Reliable Messaging System.
PII Patient Identifiable Information – any information that can be used to
distinguish or trace an individual’s identity, such as name, social
security number, date and place of birth, mother’s maiden name, or
biometric records.
PMO Project Management Office
QA Quality Assurance
QIO Quality Improvement Organization – In each State will provide special
technical assistance to a small number of nursing homes in need of
assistance with quality improvement efforts
QRS Quick Response Service
Rhapsody A commercial (Orion) Enterprise Application Integration engine.

<enter project code & name> Page 6 of 14 Business Requirements Document

 <enter sponsor dept/bureau name>

Term/Acronym Definition
RTM Requirements Traceability Matrix – a process of documenting the links
between the requirements and the work products developed to
implement and verify those requirements. The RTM captures all
requirements and their traceability in a single document.
SAMS CDC’s Secure Access Management Services – formerly SDN – A
federal information technology (IT) system that gives authorized
personnel secure access to non-public CDC applications. The SAMS
partner portal is a website designed to provide centralized access to
public health information and computer applications operated by the
United States Centers for Disease Control and Prevention. SAMS
provides healthcare facilities and partners, such as state health
departments and QIOs, with secure and immediate access to the
NHSN application.
SDLC Software development lifecycle – A software development lifecycle is
essentially a series of steps, or phases, that provide a model for the
development and lifecycle management of an application or piece of
software.
SDLC Agile The Agile methodology model is a combination of iterative and
Methodology incremental process models with focus on process adaptability and
customer satisfaction by rapid delivery of working software product.
The Agile methods break the product into small incremental builds.
These builds are provided in iterations. Each iteration typically lasts
from about one to three weeks. Every iteration involves cross
functional teams working simultaneously on various areas like planning,
requirements analysis, design, coding, unit testing and acceptance
testing. At the end of the iteration a working product is displayed to the
customer and important stakeholders.
SDLC Waterfall The Waterfall methodology was the first Process model to be
Methodology introduced. It is also referred to as a linear-sequential life cycle model.
It is very simple to understand and use. In a waterfall model, each
phase must be completed before the next phase can begin and there is
no overlapping in the phases.
SDN CDC’s Secure Data Network – Provides a strong suite of security
controls to host applications and exchange data between CDC
programs and public health partners
SNOMED Systematized Nomenclature of Medicine – is a systematic, computer-
processable collection of medical terms, in human and veterinary
medicine, to provide codes, terms, synonyms and definitions which
cover anatomy, diseases, findings, procedures, microorganisms,
substances, etc.
STD For this documents purposes this acronym will be used to reference the
Sexually Transmitted Disease Program Area
TB For this documents purposes this acronym will be used to reference the
Tuberculosis Program Area
TFP Test for Production

<enter project code & name> Page 7 of 14 Business Requirements Document

 <enter sponsor dept/bureau name>

Term/Acronym Definition
TFS Team Foundation Server – Team Foundation Server is a Microsoft
product that provides source code management, reporting,
requirements management, project management (for both agile
software development and waterfall teams), automated builds, lab
management, testing, and release management capabilities. It covers
the entire application lifecycle.
UAT User Acceptance Testing – This is the last phase of the software testing
process. During UAT, actual software users test the software to make
sure it can handle required tasks in real-world scenarios, according to
specifications.
VRSR Voluntary Rescue Service Recognition
VSTS Visual Studio Team Services – a set of cloud-powered collaboration
tools that work with your existing version of Team Foundation Server
and Microsoft Test Manager.

<enter project code & name> Page 8 of 14 Business Requirements Document

 <enter sponsor dept/bureau name>

3 Executive Summary
<If a project charter does not exist, this section is intended to provide a brief, one-page summary
describing the purpose, background, objectives, and scope for the overall project. Sign-off of the
document provides a foundation for the project team and base criteria for decision-making,
prioritization, and issue resolution.

Delete this section if the project has an approved charter.>

[Enter the Executive Summary text here]

3.1 Background
<Provide high-level description of the problem/opportunity which originated the project.>

[Add text here].

3.2 Objectives
<List top 3-5 objectives, including success criteria/measurements>

[Add text here].

3.3 In Scope
<List top processes, features, and/or functions addressed by the project>

[Add text here].

3.4 Out of Scope

<List top processes, features, and/or functions NOT addressed by the project>

[Add text here].

<enter project code & name> Page 9 of 14 Business Requirements Document

 <enter sponsor dept/bureau name>

4 Requirements Elicitation and Gathering

4.1 Approach Overview

< In this section, provide a summary describing the approach, methods, and documentation of the
business requirements, including: project drivers, key project stakeholders, main functions that will
be performed by the system, and a general requirements documentation timeline.>

[Add text here].

4.2 References/Inputs
<Identify the sources of information/reference materials that were used to develop the
Requirements Plan, such as:

1. Author name, title, and publication date.

2. Author name, title, and publication date.>

[Add text here].

<enter project code & name> Page 10 of 14 Business Requirements Document

 <enter sponsor dept/bureau name>

5 Business Model
<Describe the current environment in detail to help identify and support the needs and goals
described in the previous section. Consider the following list of questions to help define the current
environment
 What are the current problems faced (without the system) today?
 What problems should this system solve?
 Do you have to do things manually that you would like to automate?
 Do you have performance problems that need to change?
 Do you have functional limitations that you would like to change?
 Are you using packages that force you to constrain your business functionality to the
boundaries of the package?>

[Add text here].

5.1 Organizational Profile

<Describe the organizational entities (program area, bureau, etc.) that are involved in or will be
affected by the system being developed or modified. At a minimum, answer these questions: Who
(including titles and roles) will be using the system? What are their levels of expertise?>

[Add text here].

5.2 High Level ‘As-Is’ Process Flow

<A high level process flow depicts pictorially the business function information. It can be a valuable
tool when explaining to others the business functions of a system. A process flow can illustrate the
following elements: What elements are in place when the process is initiated? Who is responsible for
initiating/performing the process? What are the inputs and outputs of the process? Who (or what) is
the recipient of the process outputs? What procedural steps are completed during the process?
What are the exit criteria of the process (i.e., what must be satisfied before the process ends? This
information can be developed in Visio using a basic flow, use case or swim lane diagram. >

[Add text or process flow diagram here].

5.3 High Level ‘To-Be’ Process Flow

<This section should include an introduction describing the major functional areas of the system from
users’ perspectives. If the new system has been segmented into subsystems, the functional
requirements are defined by subsystems. The project team defines, by subsystems, those functions
which the new system must perform in order to achieve the objectives and realize the benefits >

<A high level process flow depicts pictorially the business function information. It can be a valuable
tool when explaining to others the business functions of a system. A process flow can illustrate the
following elements: What elements are in place when the process is initiated? Who is responsible for
initiating/performing the process? What are the inputs and outputs of the process? Who (or what) is
the recipient of the process outputs? What procedural steps are completed during the process?
What are the exit criteria of the process (i.e., what must be satisfied before the process ends? This
information can be developed in Visio using a basic flow, use case or swim lane diagram. >

[Add text or process flow graphic here.

<enter project code & name> Page 11 of 14 Business Requirements Document
 <enter sponsor dept/bureau name>

5.4 Process Mapping

<Processing Mapping allows the reader to quickly see how the current functions will be addressed
by the proposed solution. This can be done in narrative form or can be depicted in a table format.
This method is especially useful if there are multiple system modules or multiple systems within a
solution.

[Add text or table here]

5.5 Gap Analysis

<A gap analysis compares the ‘as-is’ and ‘to-be’ processes and identifies which functional areas
may not be fully addressed by the solution. Recommended mitigating strategies and/or business
process redesign should also be included.>

[Add text here]

<enter project code & name> Page 12 of 14 Business Requirements Document

 <enter sponsor dept/bureau name>

6 Requirements Definition

To ensure traceability throughout the project lifecycle and adherence to the change
management process, each detailed requirement for the project is defined within the
RTM.

Requirements usually reflect a need from the business/program area and is a condition
or capability that must be met or possessed by a system, product, service, result, or
component to satisfy a contract, standard, specification, or other formally imposed
document. Requirements include the quantified and documented needs, wants, and
expectations of the sponsor, customer or other stakeholder. A requirement may include
technical components if there is a specific business need associated with a technology
platform, approach, or solution.

<Please refer to the PMM templates to access the RTM tool. Please delete the descriptive text and insert
a link to the RTM or embed the document here.>

<enter project code & name> Page 13 of 14 Business Requirements Document

 <enter sponsor dept/bureau name>

7 Appendix
<In this section add any additional information relevant to this document’s subject matter. >

[Enter text here]

<enter project code & name> Page 14 of 14 Business Requirements Document