EPLC_Boundary_Document_v3 0.doc

Boundary Document

Food and Drug Administration

<Project Name & Release Version #>

ENTERPRISE PERFORMANCE LIFECYCLE

BOUNDARY DOCUMENT

Document Version Number: <#.#> Document Version Date: <mm/dd/yyyy> Notes to the Author

[This document is a template of a Boundary Document for a project. The template includes instructions to the author, boilerplate text, and fields that should be replaced with the values specific to the project.

· Blue italicized text enclosed in square brackets ([text]) provides instructions to the document author, or describes the intent, assumptions and context for content included in this document.

· Blue italicized text enclosed in angle brackets (<text>) indicates a field that should be replaced with information specific to a particular project.

· Text and tables in black are provided as boilerplate examples of wording and formats that may be used or modified as appropriate to a specific project. These are offered only as suggestions to assist in developing project documents; they are not mandatory formats.

When using this template, the following steps are recommended:

1. Replace all text enclosed in angle brackets (e.g., <Project Name>) with the correct field document values. These angle brackets appear in both the body of the document and in headers and footers. To customize fields in Microsoft Word (which display a gray background when selected) select File->Properties->Summary and fill in the appropriate fields within the Summary and Custom tabs.

After clicking OK to close the dialog box, update all fields throughout the document selecting Edit>Select All (or Ctrl-A) and pressing F9. Or you can update each field individually by clicking on it and pressing F9.

These actions must be done separately for any fields contained with the document’s Header and Footer.

2. Modify boilerplate text as appropriate for the specific project.

3. To add any new sections to the document, ensure that the appropriate header and body text styles are maintained. Styles used for the Section Headings are Heading 1, Heading 2 and Heading 3. Style used for boilerplate text is Body Text.

4. To update the Table of Contents, right-click on it and select “Update field” and choose the option - “Update entire table”.

5. Before submission of the first draft of this document, delete this instruction section “Notes to the Author” and all instructions to the author throughout the entire document.]

VERSION HISTORY

[Provide information on how the development and distribution of the Boundary Document will be controlled and tracked. Use the table below to provide the version number, the author implementing the version, the date of the version, the name of the person approving the version, the date that particular version was approved, and a brief description of the reason for creating the revised version.] Version Number Implemented

By Revision

Date Approved

By Approval

Date Description of and Reason for Change

Table of Contents

61.0 OVERVIEW

61.1 Purpose

61.2 Background

62.0 MISSION

62.1 System/Project Mission

72.2 Objectives

72.3 Goals

72.4 Critical Success Factors

72.5 Performance Measures

83.0 REQUIREMENTS STATEMENT

83.1 Existing Methods and Procedures

83.2 Required Capabilities

83.2.1 FUNCTIONAL NEEDS

83.2.2 INFORMATIONAL NEEDS

93.2.3 SECURITY/PRIVACY OF INFORMATION

93.2.4 VOLUME ESTIMATES

93.2.5 CONCEPTUAL INTERFACE REQUIREMENTS

103.2.6. DATA INTERFACE STANDARDS

104.0 Business Assumptions and Constraints

104.1 Business and User Stakeholders

104.2 Conceptual Organizational Structure and Impacts

134.3 Conceptual Organizational Support

134.4 Business and User Community Assumptions And Constraints

145.0 PROJECT RISKS

156.0 RETURN ON INVESTMENT

157.0 REFERENCES <optional section>

158.0 DEFINITIONS <optional section>

159.0 INDEX <optional section>

16APPENDIX A: BOUNDARY DOCUMENT APPROVAL

17APPENDIX B: REFERENCES

18APPENDIX C: KEY TERMS

1.0 OVERVIEW

[This section of the System Boundary Document provides an overview of the system/project and includes the purpose and background for the project. Boilerplate text for this section is provided below.]

This document is a System Boundary Document for the <Project or System Name>. It provides information on the boundaries of the <Project or System Name> project. This document establishes a formal agreement between the <Project and System Name> Executive Sponsor, user community and the <Office of Information Technology (OIT) or other office> in order to communicate the high level requirements for this project.

This document will be used to communicate to the OIT (OCIO) the business functions, goals and objectives that the <Project or System Name> project will satisfy. It also states critical success factors, assumptions and constraints for the project as well as performance measures that provide criteria to judge whether the <Project or System Name> project satisfies the business goals and objectives.

1.1 Purpose

[This subsection of the System Boundary Document describes the purpose of the system/project and the reason for the system/project. State whether the purpose of this project is to consolidate systems and adopt a single integrated process. If not, explain why this is not the case.]

1.2 Background

[This subsection of the System Boundary Document provides background information that will help understand the need for the system/project and reach consensus on what the Executive Sponsor intends to achieve by pursuing the system/project.. Provide information in this section on previous decisions or previous projects that are relevant to understanding the current project.]

2.0 MISSION

[This section of the System Boundary Document refers to Center, FDA, and HHS strategic planning documents and provides an overview of the system’s/project’s mission and its relationship to the FDA’s mission, the project’s objectives and critical success factors.]

2.1 System/Project Mission

[This subsection of the System Boundary Document describes the mission statement for the system/project. It should convey information on why the project is important and relate the system/project mission to the Center and/or FDA mission. The system/project mission will note how it will address any relevant business opportunities and deficiencies.]

2.2 Objectives

[This subsection of the System Boundary Document defines the business and organizational objectives to be achieved by the project. The objectives cover multiple long-term desired project results. State how the project is aligned & with the goals defined in the FDA Strategic Plan (See EA artifacts folder at: http://eroom.fda.gov/eRoom/OCIO/FDA-ITPMOPAL/0_8a2b7] State performance improvements and gaps associated with the project. Also state whether the development of the IT system complies with all mandatory and other applicable legislations, policies, standards and guidelines].

2.3 Goals

[This subsection of the System Boundary Document states any quantifiable targets that should be achieved, and the time frames for reaching the targets. Goals should support one or more system/project objectives.

2.4 Critical Success Factors

[This subsection of the System Boundary Document defines the conditions that must exist or must be overcome for the system/project to be considered successful in reaching its goals.]

2.5 Performance Measures

[This subsection of the System Boundary Document describes how progress on the achievement of the system/project objectives, goals, and critical success factors will be measured and reported. Boilerplate text for this section is provided below.] In order to determine if the <Project or System Name> project will successfully perform as expected the following criteria will be evaluated:

· <Performance criteria>

· <Performance criteria>

· <Performance criteria>

· <Performance criteria>

· <Performance criteria>

3.0 REQUIREMENTS STATEMENT

[This section of the System Boundary Document provides the preliminary documentation of functional and informational requirements for the project.

3.1 Existing Methods and Procedures

[This subsection of the System Boundary Document describes the current methods, procedures or information systems that are used by the organization to satisfy existing information requirements. It should summarize the conclusions of any analysis that was performed on the ability of the existing system to satisfy mission, objectives, goals, and critical success factors described above. Describe all of the products and services delivered to current customers

3.2 Required Capabilities

[This subsection of the System Boundary Document describes the new and/or existing capabilities to be delivered by the project.]

3.2.1 FUNCTIONAL NEEDS

[This subsection of the System Boundary Document describes the user requirements in functional terms; it should include information on any business functions that will be changed, replaced and/or added as a result of the system/project. State the capabilities that this system/project should provide. Refer to IT Strategic Plan document for the details of Capability Areas and Capability characteristics. (See EA artifacts folder at: http://eroom.fda.gov/eRoom/OCIO/FDA-ITPMOPAL/0_8a2b7)] [Show how the IT system or project is aligned to the FDA Business Process Hierarchy. Refer to the FDA Business Process Hierarchy document (See EA artifacts folder at: http://eroom.fda.gov/eRoom/OCIO/FDA-ITPMOPAL/0_8a2b7]

[Graphical representations may be used to express the requirements and their interrelationships. When a requirement is the improvement of existing methods and procedures, state the extent of anticipated improvement and the relationship to previously stated opportunities and deficiencies.]

3.2.2 INFORMATIONAL NEEDS

[This subsection of the System Boundary Document describes the user requirements for information (input and output) needed to perform their functions. Distinguish what business information will be changed, replaced and/or added to the system/project. Specify data steward(s) (a.k.a. who has ownership and responsibility for the data) and what information source(s) will be the system(s) of Record (a.k.a. “Gold Standard” data source.]

3.2.3 SECURITY/PRIVACY OF INFORMATION

[This subsection of the System Boundary Document describes the level of sensitivity assigned to the information that will be changed, replaced and/or added by the system/project. Sensitive information must be protected in accordance with the Computer Security Act of 1987 (Public Law 100-25) and the Privacy Provisions of the e-Government Act of 2002.]

3.2.4 VOLUME ESTIMATES

[This subsection of the System Boundary Document provides an estimate of the number of users, projected volumes and types of data to be exchanged and the frequency of the data exchange.]

3.2.5 CONCEPTUAL INTERFACE REQUIREMENTS

[This subsection of the System Boundary Document describes the potential future relationships with existing and other planned systems.

Include a System Context diagram that graphically depicts, at a high level, how the system/project would conduct its primary mission and what relationships are envisioned with other existing or planned systems/projects and organizations. Typically, a system context is a single picture that captures the essence of participants in the operating scenario.

Treating the proposed system/project as a “black box”, include information about any significant potential external interfaces, being sure to specify the following for each information flow in the diagram where available:

· Interface Name – Name of interface (e.g. “Clinical Trials Data-feed”)

· Description - Brief description of the information exchanged.

· Status – Current status of interface (e.g. “Current” or “Planned”) and date of any known changes to status.

· Standards – Any FDA, national, or international Data Standards that apply, including data vocabulary (e.g., MEDRA) and/or messaging standards (e.g., HL7).

· Interface Type - Type of data transferred (e.g. “Document”, “Files” or “Both”).

· Manual Interface (Yes/No) – Is data manually entered at the keyboard, or assembled / transmitted using mostly human capital (e.g., manually integrating Spreadsheets, sending or receiving a data disk to a recipient)?

· Volume – A rough order of magnitude estimate of how much information would be transferred (e.g. “approximately 10,000 reports/year”).

When addressing this section, coordinate with the Enterprise Architecture Team for any clarification needed. The Enterprise Architecture Team can be contacted at <OIM EA TEAM>. Example of System Context Diagram is available at: http://eroom.fda.gov/eRoom/OCIO/FDA-ITPMOPAL/0_8a2ba ]

3.2.6. DATA INTERFACE STANDARDS

[This subsection describes the intended use of data standards, including FDA, government, industry, national, and/or international vocabulary / terminology and data messaging standards that will be utilized by the system. Indicate for each vocabulary standard (e.g., MEDRA, LOINC, etc.) the type of data that will use that standard. Similarly, indicate the planned use of data messaging standards (e.g., HL7 ICSR).Link to Data Standards Can be found at http://www.fda.gov/ForIndustry/DataStandards/default.htm]

4.0 BUSINESS ASSUMPTIONS AND CONSTRAINTS

[This section of the System Boundary Document describes the stakeholders associated with the system/project, the business, system, and program management assumptions on which the project is based, and the business constraints on project factors such as the organization, legal, security and facilities.]

4.1 Business and User Stakeholders

[This subsection of the System Boundary Document lists the business stakeholders for this system/project’s sponsor and user community. Identify the target users and other beneficiaries of the project.]

The stakeholders for this <Project or System Name> include:

· <individual and/or organization>

· <individual and/or organization>

· <individual and/or organization>

4.2 Conceptual Organizational Structure and Impacts

[This subsection of the System Boundary Document identifies the potential impacts on the existing organizational structure. Define all constraints that the organizational structure may impose on the system/project. List any user communities involved in the system/project and any external organizations impacted by the system/project. Include any organizational charts deemed necessary. Boilerplate text for this section is provided below.] Figure 1 provides an organizational chart for <Center and/or organization>.

<Place organizational chart here>

Figure 1 - Organizational Chart

Primary users for the <Project or System Name> project include:

· <role and/or organization>

· <role and/or organization>

· <role and/or organization>

· <role and/or organization>

These users will need training on

Potential secondary users for the <Project or System Name> project include:

· <role and/or organization>

· <role and/or organization>

· <role and/or organization>

· <role and/or organization>

These users will need training on

Table 1 - Organizational Impact and Constraints, displays the types of impacts and constraints, and the potentially affected organizations.

[Some impacts types include: automation, acquisition, legal, security, access to technology and information, facilities, work conditions, job duties, standard operating procedures, performance measurements, reporting, etc. Boilerplate text for this section is provided below. Identify the impacted organizations and processes

<organizational title>

<organizational title>

<organizational title>

<organizational title>

<organizational title>

<organizational title>

<organizational title>

<organizational title>

Table 1 - Organizational Impact and Constraints

4.3 Conceptual Organizational Support

[This subsection of the System Boundary Document identifies what business and user community organizations will provide support to this project and what support the organizations will provide. Note any assumptions and constraints about the level of support to be provided within and external to the project team in executing the project.

Reference charters, memorandums of understanding, or other agreements between these participants. Boilerplate text for this section is provided below.] Table 2 - Organizational Support, displays the organizations that will provide support to and/or detract from the project and what type(s) of support and/or detraction the organizations will provide.

<type of support>

<type of support>

<type of support>

<type of support>

<type of support>

<type of support>

<type of support>

<type of support>

Table 2 - Organizational Support

4.4 Business and User Community Assumptions And Constraints

[This subsection of the System Boundary Document describes the assumptions on which the system/project is based and the constraints on project factors such as the schedule, budget, resources, organizational support, organizational structure, acquisition, software to be reused, software to be incorporated, technology to be employed, and product interfaces to other products.

Boilerplate text for this section is provided below.] Currently known assumptions and constraints related to this project include the following:

· <assumption or constraint>

· <assumption or constraint>

· <assumption or constraint>

5.0 PROJECT RISKS

[This section of the System Boundary Document lists the risks and mitigation strategies for the system/project. Boilerplate text for this section is provided below.] In order to complete the <Project or System Name> project development process within planned boundaries, risks on the project should be well understood, mitigated and align with the OMB Exhibit 300 risk categories. Table 5 – Risks and Mitigation Strategies, lists the risks and mitigation strategies for the <Project or System Name> project.

· <mitigation strategy>

· <mitigation strategy>

· <mitigation strategy>

· <mitigation strategy>

· <mitigation strategy>

* Note: At a minimum, the business and user community should address business, strategic and privacy risks.

Table 5 – Risks and Mitigation Strategies

6.0 RETURN ON INVESTMENT

[This section of the System Boundary Document provides a statement about the perceived return on investment that will be provided by the system/project. Indicate what quantitative and qualitative measures of valuation were used to determine the return on investment.]

7.0 REFERENCES <optional section>

[This section of the System Boundary Document provides a complete list of all documents and other sources of information referenced in the System Boundary Document. Each document should be identified by title, report number, date, author, path/name for electronic access, and publishing organization. Other sources of information, such as electronic files, should be identified using unique identifiers such as date and version number. Any deviations from referenced standards or policies should be identified and justifications should be provided.]

8.0 DEFINITIONS <optional section>

[This section of the System Boundary Document defines, or provides references to, documents containing the definition of all terms and acronyms required to properly understand the System Boundary Document.]

9.0 INDEX <optional section>

[An index to the key terms and acronyms used throughout the System Boundary Document is optional, but recommended to improve the usability of the System Boundary Document.]

APPENDIX A: BOUNDARY DOCUMENT APPROVAL

The undersigned acknowledge that they have reviewed the <Project Name> Boundary Document and agree with the information presented within this document. Changes to this Boundary Document will be coordinated with, and approved by, the undersigned, or their designated representatives.

Signature:

Date:

Print Name:

Title:

APPENDIX B: REFERENCES

[Insert the name, version number, description, and physical location of any documents referenced in this document. Add rows to the table as necessary.]

The following table summarizes the documents referenced in this document.

APPENDIX C: KEY TERMS

The following table provides definitions and explanations for terms and acronyms relevant to the content presented within this document.

Template version 3.0 (Last Modified on Jan 18, 2011)

PAGE