EPLC_Systems Concept of Operations

Concept of Operations

Food and Drug Administration

<Project Name & Release Version #> Enterprise Performance LifeCycle

CONCEPT OF OPERATIONS

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

[This document is a template of a Concept of Operations 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.

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

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

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

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

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

7. 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 Interface Control 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 51.0 Introduction

51.1 Intended Audience

52.0 Referenced Documents

53.0 Current System

53.1 Background, Objectives, and Scope

53.2 Operational Policies and Constraints

53.3 Description of Current System or Situation

63.4 Current Modes of Operation

63.5 Current Users and Stakeholders

73.6 Current Support Environment

74.0 Justification and Description of Changes

74.1 Justification for Changes

74.2 Description of the Desired Changes

84.3 Priorities among Changes

84.4 Changes Considered But Not Included

85.0 Proposed System or Situation

85.1 Background, Objectives, and Scope

85.2 Operational Policies and Constraints

85.3 Description of the Proposed System or Situation

95.4 Modes of Operation

95.5 Anticipated Users and Stakeholders

95.6 Proposed Support Environment

96.0 Operational Scenarios

97.0 Summary of Impacts

107.1 Operational Impacts

107.2 Organizational Impacts

107.3 Development Impacts

108.0 Analysis of the Proposed System

108.1 Summary of Improvements

118.2 Disadvantages and Limitations

118.3 Alternatives and Trade-Offs Considered

119.0 Appendices

1110.0 Glossary

1.0 Introduction

[Summarize the purpose of the document, the scope of activities that resulted in its development, its relationship to other relevant documents (e.g., the corresponding Business Case Analysis (BCA)), the intended audience for the document, and expected evolution of the document. Also describe any security or privacy considerations associated with use of the ConOps.] The Purpose of this Concept of Operations for <System Name> is to bridge the gap between the user’s needs and vision and the technical specifications needed to develop the software that will support them, i.e. it is the first step in moving from what needs to be done to how it will be accomplished.

It describes the objectives of the <System Name>, how it will replace or improve the business process(es) it is intended to support, its impact on related business processes and systems, the proposed technical environment, and the approach to implementation.

1.1 Intended Audience

Identify the intended audience for this document.

The expected audience for this document includes the Offices of <Audience 1>, <Audience 2>,….,<Audience n>, who are the business sponsors and primary users of the system; the Integrated Project team, and its Critical Partners.

2.0 Referenced Documents

[Provide identifying information for all documents referenced within the ConOps document (e.g., legislation, feasibility studies, documents concerning related projects, relevant technical documentation, etc.]

3.0 Current System

Describe the system or situation (either automated or manual) as it currently exists. If there is no current system on which to base changes, then describe the situation that motivates development of the proposed system.]

3.1 Background, Objectives, and Scope

[Provide an overview of the current system or situation, including as applicable, background, mission, goals, objectives, scope, business drivers, and motivation for the current system.]

3.2 Operational Policies and Constraints

[Describe the operational policies and constraints affecting the operations of the current system. Operational policies are predetermined management decisions regarding the operations of the current system, normally in the form of general statements or understandings that guide or limit decision-making activities, but do allow for some discretion. Operational constraints are limitations placed on the operations of the current system (e.g., available hours of system operation, available number of personnel to operate the system, computer hardware and operational facilities constraints).]

3.3 Description of Current System or Situation

[Provide a description of the current system or situation that is simple and clear enough that all intended readers of the document can fully understand it. Provide a graphical overview of the current system or situation, such as in the form of a context diagram, a high-level diagram that depicts the system and its relationships to the rest of the environment. The description should include the following as appropriate:

a) The operational environment and its characteristics (e.g., facilities, equipment, computing hardware, software, communications links, personnel, and operational procedures used to operate the existing system);

b) Major system components and the interconnection among those components;

c) Interfaces to external systems or procedures;

d) Capabilities, functions, and features of the current system, including types of transactions processed;

e) Diagrams and accompanying descriptions depicting inputs, outputs, data flows, control flows, and manual and automated processes sufficient to understand the current system or situation from the user’s point of view (e.g., business process models, data flow diagrams);

f) Cost of system operations;

g) Operational risk factors;

h) Performance characteristics, such as speed, throughput, volume, frequency;

i) Quality attributes, such as: availability, correctness, efficiency, expandability, flexibility, interoperability, maintainability, portability, reliability, reusability, supportability, survivability, and usability;

j) Provisions for safety, security, privacy, integrity, and continuity of operations in emergencies that exert influence on the operation or operational environment of the current system.] The diagram below represents the current inputs, outputs, data flows, control flows, and manual and automated processes (e.g., business process models, data flow diagrams) associated with <System Name>;

Major components and the interconnection among those components of the current <System Name>;

Major <System Name> Interfaces to external systems or procedures;

[Diagram Here]

3.4 Current Modes of Operation

[Describe the various modes of operation for the current system or situation (e.g.,normal, degraded, exception handling, maintenance, training, backup, emergency, alternate-site, active, and idle modes). All of the modes that apply to all classes of users should be included, and especially the modes that involve different sites and equipment that have significant impacts on the operational aspects of the system or situation. System processes, procedures, and capabilities or functions should be related to each mode, as appropriate, perhaps using a cross-reference matrix.]

3.5 Current Users and Stakeholders

[A user class is distinguished by the ways in which users interact with the present system or situation. Factors that distinguish a user class include common responsibilities, skill levels, work activities, and modes of interaction with the system. In this context, a user is anyone who interacts with the existing system, including operational users, data entry personnel, system operators, operational support personnel, system maintainers, and trainers. Subordinate sections might provide existing organizational structure(s) of the various user groups and user classes that are involved with the current system or situation; profiles of user classes; interactions among user classes; and identification of other involved personnel who do not directly interact with the system, but who have an influence on it or are influenced by the existing system or situation.)]

3.6 Current Support Environment

[Describe the support concepts and support environment for the current system or situation, including the support organization; facilities; equipment; support software; repair or replacement criteria; maintenance levels and cycles; and storage, distribution, and supply methods.]

4.0 Justification and Description of Changes

[Briefly describe the shortcomings of the current system or situation that motivate development of a new system or modification of an existing system. If there is no current system on which to base changes, then so indicate and provide justification for the features of the new system.]

4.1 Justification for Changes

[Briefly summarize new or modified aspects of the user needs, missions, objectives, environments, interfaces, personnel, or other factors that require a new or modified system. Summarize the deficiencies or limitations of the current system or situation that make it unable to respond to new or changed factors. Provide justification for a new or modified system (e.g., legislative drivers, new opportunities, improvements, new functional capabilities).]

4.2 Description of the Desired Changes

[Summarize the new or modified capabilities, functions, processes, interfaces, and other changes needed to respond to the factors identified in 4.1. Changes should be based on the current system described in section 3 of the document. If there is no existing system on which to base changes, then summarize the capabilities to be provided by a new system. This description should include the following, as appropriate:

a) Capability changes

b) System processing changes

c) Interface changes

d) Personnel changes

e) Environment changes

f) Operational changes

g) Support changes

h) Other changes] Include at diagrams with desired changes to <System Name>;

The diagram represents proposed changes to <System Name> inputs, outputs, data flows, control flows and manual and automated processes. (e.g., business process models, data flow diagrams);

Major changes to the <System Name> components and the interconnection among those components;

Major changes to the <System Name> interfaces to external systems or procedures;

[Diagram Here]

4.3 Priorities among Changes

[Identify priorities among the desired changes and new features. Each change should be classified as essential, desirable, or optional and a reason provided for the classification.]

4.4 Changes Considered But Not Included

[Identify desired changes and new features considered but not included in section 4.2, and the rationale for not including them.]

5.0 Proposed System or Situation

[Describe the concepts for the proposed system or situation that results from the desired changes specified in section 4 above. The description should be at a high-level, indicating the operational features that are to be provided without specifying design details. The description should be of sufficient detail to fully explain how the proposed system is envisioned to operate in fulfilling users’ needs and the business requirements. The ConOps may contain some examples of typical design strategies, for the purpose of clarifying operational details of the proposed system, but should not contain design specifications.]

5.1 Background, Objectives, and Scope

[Provide an overview of the proposed system or situation, including as applicable, background, mission, goals, objectives, scope, business drivers, and motivation for the proposed system.]

5.2 Operational Policies and Constraints

[Describe the operational policies and constraints affecting the operations of the proposed system. Operational policies are predetermined management decisions regarding the operations of the proposed system, normally in the form of general statements or understandings that guide or limit decision-making activities, but do allow for some discretion. Operational constraints are limitations placed on the operations of the proposed system (e.g., available hours of system operation, available number of personnel to operate the system, computer hardware and operational facilities constraints).]

5.3 Description of the Proposed System or Situation

[Provide a description of the proposed system or situation that is simple and clear enough that all intended readers of the document can fully understand it. Also include a graphical view of the proposed system or situation, such as in the form of a high-level flow chart, system context diagram (which can, by reference, incorporate the diagram from the Boundary Document) or other graphical illustration that depicts the system and its environment from a users’ perspective.

The description should also address the following, as appropriate:

a) The operational environment and its characteristics (e.g., facilities, equipment, computing hardware, software, communications links, personnel, and operational procedures used to operate the proposed system);

b) Major system components and the interconnection among those components;

c) Interfaces to external systems or procedures;

d) Capabilities, functions, and features of the current system, including types of transactions processed;

e) Charts and accompanying descriptions depicting inputs, outputs, data flows, control flows, and manual and automated processes sufficient to understand the current system or situation from the user’s point of view (e.g., business process models, data flow diagrams);

f) Cost of system operations;

g) Operational risk factors;

h) Performance characteristics, such as speed, throughput, volume, frequency;

i) Quality attributes, such as: availability, correctness, efficiency, expandability, flexibility, interoperability, maintainability, portability, reliability, reusability, supportability, survivability, and usability; and

j) Provisions for safety, security, privacy, integrity, and continuity of operations in emergencies that exert influence on the operation or operational environment of the proposed system.]

5.4 Modes of Operation

[Describe the various modes of operation for the proposed system or situation (e.g., normal, degraded, exception handling, maintenance, training, backup, emergency, alternate-site, active, and idle modes). All of the modes that apply to all classes of users should be included, and especially the modes that involve different sites and equipment that have significant impacts on the operational aspects of the system or situation. System processes, procedures, and capabilities or functions should be related to each mode, as appropriate, perhaps using a cross-reference matrix.]

5.5 Anticipated Users and Stakeholders

[A user class is distinguished by the ways in which users interact with the proposed system or situation. Factors that distinguish a user class include common responsibilities, skill levels, work activities, and modes of interaction with the system. In this context, a user is anyone who interacts with the proposed system, including operational users, data entry personnel, system operators, operational support personnel, system maintainers, and trainers. Subordinate sections might provide existing organizational structure(s) of the various user groups and user classes that are involved with the proposed system or situation; profiles of user classes; interactions among user classes; and identification of other involved personnel who do not directly interact with the system, but who have an influence on it or are influenced by the proposed system or situation.)]

5.6 Proposed Support Environment

[Describe the support concepts and support environment for the proposed system or situation, including the support organization; facilities; equipment; support software; repair or replacement criteria; maintenance levels and cycles; and storage, distribution, and supply methods.]

6.0 Operational Scenarios

[Provide step-by-step descriptions of how the proposed system should operate and interact with its users and its external interfaces under a given set of circumstances. The scenarios should be described in a manner that will allow readers to walk through them and gain an understanding of how all the various parts of the proposed system function and interact. The scenarios tie together all parts of the system, the users, and other entities by describing how they interact, and may also be used to describe what the system should not do. Operational scenarios should be described for all operational modes and all classes of users identified for the proposed system. Each scenario should include events, actions, stimuli, information, and interactions as appropriate to provide a comprehensive understanding of the operational aspects of the proposed system. The scenarios can be presented in several different ways: 1) for each major processing function of the proposed system, or 2) thread-based, where each scenario follows one type of transaction type through the proposed system, or 3) following the information flow through the system for each user capability, following the control flows, or focusing on the objects and events in the system. The number of scenarios and level of detail specified will be proportional to the perceived risk and the criticality of the project. The scenarios developed for the ConOps can serve as the basis for the subsequent Requirements Document, Test Case Specification, and Users Manual.]

7.0 Summary of Impacts

[Describe the anticipated operational and organizational impacts of the proposed system on the users, system developers, and the support and maintenance organizations. Also describe the temporary impacts on the users, system developers, and the support and maintenance organizations during the period of time when the new system is being developed, installed, or training is being provided. This information will allow all affected organizations to prepare for the changes that will be brought about by the new system and to plan for the impacts during development and transition to the new system.]

7.1 Operational Impacts

[Describe the operational impacts of the proposed system on the users, system developers, and the support and maintenance organizations. The impacts to consider include the following:

a) Interfaces with primary or alternate computer operating centers;

b) Changes in procedures;

c) Use of new data sources;

d) Changes in quantity, type, and timing of data to be input into the system;

e) Changes in data retention requirements;

f) New modes of operation based on emergency, disaster, or accident conditions;

g) New methods for providing input data if the required data are not readily available;

h) Changes in operational budget;

i) Changes in operational risks]

7.2 Organizational Impacts

[Describe the anticipated organizational impacts of the proposed system on the user, development, and support or maintenance organizations during operation of the proposed system. The impacts to consider include the following:

a) Modification of responsibilities;

b) Addition or elimination of job positions;

c) Training or retraining users;

d) Changes in numbers, skill levels, position identifiers, or locations of personnel; and

e) Numbers and skill levels of personnel needed for contingency operation at one or more alternate sites following an emergency, disaster, or accident.]

7.3 Development Impacts

[Describe the anticipated impacts on the user, development, and support or maintenance organizations during the development project for the proposed system. The impacts to consider include the following:

a) Involvement in studies, meetings, and discussions prior to award of the contract;

b) User and support involvement in reviews and demonstrations, evaluation of initial operating capabilities, and evolving versions of the system, development or modification of databases, and required training;

c) Parallel operation of the new and existing systems; and

d) Operational impacts during system testing of the proposed system.]

8.0 Analysis of the Proposed System

[Provide an analysis of the benefits, limitations, advantages, disadvantages, and alternatives and trade-offs considered for the proposed system. Improvements to the system should be documented. This includes a qualitative and quantitative summary of the benefits to be provided by the proposed system, and can include new capabilities, enhanced capabilities, deleted capabilities and improved performance. In addition, ant disadvantages and limitations should be provided.]

8.1 Summary of Improvements

[Provide a qualitative (and to the extent possible, quantitative) summary of the benefits to be provided by the proposed system. The summary should include benefits realized from new capabilities, enhanced capabilities, deleted capabilities, and improved performance. The benefits should be related to deficiencies identified in section 4.1.]

8.2 Disadvantages and Limitations

[Provide a qualitative (and to the extent possible, quantitative) summary of the disadvantages and/or limitations of the proposed system. Disadvantages might include the need to retrain personnel or change to a new style of user interface. Limitations might include features desired by users but not included or greater-than desired response time due to hardware constraints.]

8.3 Alternatives and Trade-Offs Considered

[Describe major alternatives considered, the trade-offs among them, and rationale for the decisions reached. In the context of the ConOps, alternatives are operational alternatives, not design alternatives, except to the extent that design alternatives may be limited by the operational capabilities desired in the new system.]

9.0 Appendices

[Utilize appendices to facilitate ease of use and maintenance of the ConOps document. Each appendix should be referenced in the main body of the document where that information would normally have been provided.]

10.0 Glossary

[Provide clear and concise definitions for terms used in the ConOps that may be unfamiliar to readers of the document.]

Version 1.0, 11/4/2010