System Definition-Concept Of Operations (ConOps)

1 Concept of Operations, Checklist June 13, 2003 Technical Content Recommendations & Review Criteria Purpose and Scope. This Checklist provides recommended technical content for concept of operations documentation. This document is not a mandatory life cycle document. However, it is useful during project initiation as a place to capture/document pre-project initiation, pre-vendor selection and pre-COTS (computer-off-the-shelf) selection data pending project approval by the appropriate authority. The concept of operations document can be viewed as a convenient place to accumulate pre-requirements project data and can be used to obtain consensus among the user and developer (and other stakeholders).

Depending on its use, this document may focus on communicating the user’s needs to the developer or the developer’s ideas to the user and other interested parties. (Reference 2)

1. “The operational concepts are plain-language descriptions of days in the life of your product.”

2. “Operational concepts are a simple, cost-effective way to build a consensus among all [project] stakeholders and to discover missing requirements.”

3. “Operational concepts are…scripts describing how the product will be used…routine ‘everyday’ use of the product.”

4. “Operational concepts facilitate complete and consistent requirements…identify user interface issues early…offer inexpensive opportunities for early validation…form a foundation for testing scenarios in product verification…have a high return on investment.”

5. Use cases; operational plans; operational sequences; operational scenarios; user requirements; user needs and intended uses; use case diagram

References: 1. IEEE Std 1362-1998, IEEE Guide for Information Technology – System Definition – Concept of Operations (ConOPs) Document. 2. Customer Centered Products, Hooks & Farry, AMACON, 2001, 3. Operational Concept Document, Data Item Description, DI-IPSC-81430, US Government/DOD 4. Understanding, Designing, and Testing Use Cases, Harinath V. Pudipeddi, Dec 9, 2002 5. Use Case Modeling, Kurt Bittner/Ian Spence, Addison Wesley, 2002 Concept of Operations Documentation Content Summary. The components described in this section are recommended to be included in this document. These components may have different names, groupings, or sequences in different projects and it may be necessary to determine if there is an equivalent or suitable substitute. Additional information may be added as required.

This data is generally expanded upon and included in other life cycle documentation such as the project management plan and the system requirements documentation. Scope Referenced Documents Current System or Situation Justification for and Nature of Changes Concept for a New or Modified System Operational Scenarios Summary of Impacts Analysis of the Proposed System Assumptions, Constraints, Pre-requisites, Authority, Responsibilities Signatures & Approvals Notes Annexes Concept of Operations Documentation Detailed Content (For those items in the summary above that are not self-explanatory, the following detailed information is provided.) Scope Identification.

This shall contain a full identification of the system to which this document applies, including, as applicable, identification number(s), title(s), abbreviations), version number(s), and release number(s). System Overview. This shall briefly state the purpose of the system to which this document applies. It shall describe the general nature of the system; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and maintenance organizations; identify current and planned operating sites; and list other relevant documents. Document Overview. This shall summarize the purpose and contents of this document and shall describe any security or privacy protection considerations associated with its use. Regulatory or Operational Policies and Constraints.

2 Concept of Operations, Checklist June 13, 2003 Technical Content Recommendations & Review Criteria Current System or Situation This should describe the system or situation as it currently exists. Background, Objectives, and Scope. This shall describe the background, mission or objectives, and scope of the current system or situation. Operational Policies and Constraints. This shall describe any operational policies and constraints that apply to the current system or situation. Description/Purpose. Describes the product/system in terms of the user needs it will fulfill, its relationship to existing systems or procedures, and the ways it will be used.

Description of Current System or Situation. This shall provide a description of the current system or situation, identifying differences associated with different states or modes of operation (for example, regular, maintenance, training, degraded, emergency, alternative-site, wartime, peacetime). The distinction between states and modes is arbitrary. A system may be described in terms of states only, modes only, states within modes, modes within states, or any other scheme that is useful. If the system operates without states or modes, this shall so state, without the need to create artificial distinctions. The description shall include, as applicable:

1. The operational environment and its characteristics

2. Major system components and the interconnections among these components

3. Interfaces to external systems or procedures

4. Capabilities/functions of the current system

5. Charts and accompanying descriptions depicting input, output, data flow, and manual and automated processes sufficient to understand the current system or situation from the user’s point of view

6. Performance characteristics, such as speed, throughput, volume, frequency

7. Quality attributes, such as reliability, maintainability, availability, flexibility, portability, usability, efficiency 8. Provisions for safety, security, privacy protection, and continuity of operations in emergencies Users or Involved Personnel.

This shall describe the types of users of the system, or personnel involved in the current situation, including, as applicable, organizational structures, training/skills, responsibilities, activities, and interactions with one another. Support strategy. This shall provide an overview of the support strategy for the current system, including, as applicable to this document, maintenance organizations; facilities; equipment; maintenance software; repair/replacement criteria; maintenance levels and cycles; and storage, distribution, and supply methods. Justification for and Nature of Changes Justification for Change. This, shall:

1. Describe new or modified aspects of user needs, threats, missions, objectives, environments, interfaces, personnel or other factors that require a new or modified system.

2. Summarize deficiencies or limitations in the current system or situation that make it unable to respond to these factors Description of Needed Changes.

This shall summarize new or modified capabilities/functions, processes, interfaces, or other changes needed to respond to the factors identified above. Priorities Among the Changes. This shall identify priorities among the needed changes. It shall, for example, identify each change as essential, desirable, or optional, and prioritize the desirable and optional changes. Changes Considered but Not Included. This shall identify changes considered but not included in 4.2, and rationale for not including them. Assumptions, Dependencies, and Constraints. This shall identify any assumptions, dependencies on other factors/projects/organizations/systems and constraints applicable to the changes identified in this clause. Concept for a New or Modified System Background, Objectives, and Scope.

This shall describe the background, mission or objectives, and scope of the new or modified system. Operational Policies and Constraints. This shall describe any operational policies and constraints that apply to the new or modified system. Description of the new or modified system. This shall provide a description of the new or modified system, identifying differences associated with different states or modes of operation (for example, regular, maintenance, training, degraded, emergency, alternative-site, wartime, peacetime). The distinction between states and modes is arbitrary. A system may be described in terms of states only, modes only, states within modes, modes within states, or any other scheme that is useful. If the system operates without states or modes, this shall so state, without the need to create artificial distinctions.