Business Requirements Document Template

<enter project name>

Business Requirements Document

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>

Table of Contents

1 Purpose 4

2 Glossary and Acronyms 5

3 Executive Summary 6

3.1 Background 6

3.2 Objectives 6

3.3 In Scope 6

3.4 Out of Scope 6

4 Requirements Elicitation and Gathering 7

4.1 Approach Overview 7

4.2 References/Inputs 7

5 Business Model 8

5.1 Organizational Profile 8

5.2 High Level ‘As-Is’ Process Flow 8

5.3 High Level ‘To-Be’ Process Flow 8

5.4 Process Mapping 9

5.5 Gap Analysis 9

6 Requirements Definition 10

7 Appendix 11

<enter project code & name> Requirements Document v X.X / Page 3 of 14 / Printed: 10/27/2016
<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.

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 Community Health / For this documents purposes this acronym will be used to reference the Bureau of Community Health Program Area
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 and Adult) / For this documents purposes this acronym will be used to reference to 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.
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.
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 Methodology / The Agile methodology model is a combination of iterative and 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 Methodology / The Waterfall methodology was the first Process model to be 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
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.

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].

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].

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

[Add text here].

5.2 High Level ‘As-Is’ Process Flow