Concept of Operations
Definition: A Concept of Operations (CONOPS) is a user-oriented document that "describes systems characteristics for a proposed system from a user's perspective. A CONOPS also describes the user organization, mission, and objectives from an integrated systems point of view and is used to communicate overall quantitative and qualitative system characteristics to stakeholders ."
A CONOPS "describes the proposed system in terms of the user needs it will fulfill, its relationship to existing systems or procedures, and the ways it will be used. CONOPS can be tailored for many purposes, for example, to obtain consensus among the acquirer, developers, supporters, and user agencies on the operational concept of a proposed system. Additionally, a CONOPS may focus on communicating the user's needs to the developer or the developer's ideas to the user and other interested parties ."
Keywords: concepts, CONOPS, operational concept description, operational concepts, operational scenarios, system concepts, use cases, user needs, user/system roles, viewpoints
MITRE SE Roles & Expectations: MITRE systems engineers (SEs) are expected to understand and recommend the development and use of a CONOPS as a tool throughout the SE life cycle to communicate user needs and system characteristics to developers, integrators, sponsors, funding decision makers, and other stakeholders. In some cases MITRE systems engineers may be asked to support the development of a CONOPS.
MITRE SEs should be able to apply systems engineering methods to map user (operational) needs to system requirements, functions, and conceptual system designs. They should also be able to develop test requirements that are traceable to system requirements and user needs. In addition, they should test operational concepts (concept validation) and user utility as described in the CONOPS.
The purpose of a CONOPS is to describe the operational needs, desires, visions, and expectations of the user without being overly technical or formal. The user, developer, or both may write CONOPS, often with help from MITRE systems engineers. The CONOPS written by a user representative communicates the overall vision for the operational system to the organizations (e.g., buyer, developer) that have a role in the system acquisition and/or development effort. A CONOPS can also be written by the buyer, developer, or acquirer to communicate their understanding of the user needs and how a system will fulfill them. In both cases, the CONOPS is intended to facilitate a common understanding of ideas, challenges, and issues on possible solution strategies without addressing the technical solution or implementation; it is often a first step for developing system requirements. As systems continue to evolve in complexity, SEs and mission owners can utilize a CONOPS to develop and sustain a common vision of the system for all stakeholders over the system's life cycle. The original CONOPS written at the beginning of system acquisition should be updated after developmental and operational testing, to convey how the system being acquired will actually be used. This update is needed since many final systems include some additional capabilities not originally envisioned at program start, and may not include some capabilities that were omitted during trade-off analysis. The CONOPS should include the full range of factors that are needed to support the mission (i.e., doctrine, organization, training, leadership, materiel, personnel, facilities, and resources). Post-fielding life cycle costs often dwarf those of the development effort. Therefore, it is critical that the CONOPS provide sufficient information to determine long-term life cycle needs such as training, sustainment and support throughout capability fielding and use.
A CONOPS should contain a conceptual view of the system (i.e., a preliminary functional flow block diagram or operational architecture) that illustrates the top-level functional threads in the proposed system or situation. A CONOPS should define any critical, top-level, performance requirements or objectives stated either qualitatively or quantitatively (including system rationale for these objectives). The SE should consider the CONOPS as a functional concept definition and rationale from the user and customer perspectives.
Multiple CONOPS guidelines, models, and methodologies are available that can be tailored as needed for particular environments or situations. A MITRE SE should be able to determine which CONOPS format, model, or methodology is appropriate for the specific situation, and if (or how) it should be tailored for that system/environment. Johns Hopkins University's Whiting School of Engineering provides an approach to making this decision based on SE analysis of criteria:
- Program risks
- Customer desires, requirements
- Funding constraints
- Market considerations
- Technology considerations
- Nature of the system to be developed
The Institute of Electrical and Electronics Engineers (IEEE) Standard 1362-1998 (IEEE Std 1362-1998), IEEE Guide for Information Technology—System Definition—Concept of Operations (CONOPS), is an example of a well-developed and commonly used SE CONOPS guideline. Several SE organizations, including the International Council on Systems Engineering (INCOSE), currently use the IEEE CONOPS guidelines, which state:
This guide does not specify the exact techniques to be used in developing the CONOPS document, but it does provide approaches that might be used. Each organization that uses this guide should develop a set of practices and procedures to provide detailed guidance for preparing and updating CONOPS documents. These detailed practices and procedures should take into account the environmental, organizational, and political factors that influence application of the guide .
In the situation where the operational user has not developed a CONOPS, MITRE SEs should select or recommend a CONOPS guideline or model, and the objectives for developing a CONOPS. They should also consider any guidelines that have been put in place by the organization. The main objective of a CONOPS is to "communicate with the end user of the system during the early specification stages to assure the operational needs are clearly understood and incorporated into the design decisions for later inclusion in the system and segment specifications ."
Regardless of who develops the CONOPS, frequent interaction is needed among the end users, MITRE engineers, acquisition organizations, and development, test and security stakeholders. It may also be the case that the operational user does not understand or cannot envision how new capabilities will operate in their environment, particularly if it is a new type of system or operation. In these cases, experiments and prototypes can be of value in illuminating these issues. Additional CONOPS objectives include:
- Provide end-to-end traceability between operational needs and captured source requirements.
- Establish a high-level basis for requirements that supports the system over its life cycle.
- Establish a high-level basis for test planning and system-level test requirements.
- Support the generation of operational analysis models (use cases) to test the interfaces.
- Provide the basis for computation of system capacity.
- Validate and discover implicit requirements.
Critical CONOPS Components
When tailoring IEEE Standard 1362-1998 CONOPS for a specific purpose, non-critical components can be deleted or minimized. However, the document should always include critical components in any CONOPS. These are contained in IEEE Standard 1362-1998, discussed below:
- The existing system (manual or automated) the user wants to replace.
- Justification for a new or modified system (including restrictions on that system).
- A description of the proposed system.
- Scenarios highlighting use of the system in the user's environment including internal and external factors.
For a software-intensive capability, the CONOPS might have a greater emphasis on the information system perspective of the users' needs and developers' products concentrating on software feasibility and software requirements.
System Engineering Applications for a CONOPS
MITRE SEs should be able to use various iterations of a CONOPS as a tool throughout the SE life cycle to communicate user needs and system characteristics to developers, integrators, sponsors, funding decision makers, and stakeholders. IEEE Standard 1362-1998 guidance on the application of a CONOPS provides additional clarification. "The CONOPS approach provides an analysis activity and a document that bridges the gap between the user's needs and visions and the developer's technical specifications." In addition, the CONOPS document provides the following:
- A means of describing a user's operational needs without becoming bogged down in detailed technical issues that shall be addressed during the systems analysis activity.
- A mechanism for documenting a system's characteristics and the user's operational needs in a manner that can be verified by the user without requiring any technical knowledge beyond that required to perform normal job functions.
- A place for users to state their desires, visions, and expectations without requiring the provision of quantified, testable specifications. For example, the users could express their need for a "highly reliable" system, and their reasons for that need, without having to produce a testable reliability requirement. [In this case, the user's need for "high reliability" might be stated in quantitative terms by the buyer prior to issuing a request for proposal (RFP), or it might be quantified by the developer during requirements analysis. In any case, it is the job of the buyer and/or the developer to quantify users' needs.]
- A mechanism for users and buyer(s) to express thoughts and concerns on possible solution strategies. In some cases, design constraints dictate particular approaches. In other cases, there may be a variety of acceptable solution strategies. The CONOPS document allows users and buyer(s) to record design constraints, the rationale for those constraints, and to indicate the range of acceptable solution strategies .
- Use tools and/or techniques that best describe the proposed system from the user's perspective and how it should operate.
- Describe the system simply and clearly so that all intended readers can fully understand it.
- Write the CONOPS in the user's language. Avoid technical jargon. If user jargon is employed, provide a glossary that translates it for non-users.
- Use graphics and pictorial tools as much as possible, since a CONOPS should be understandable to different types of stakeholders. (Useful graphical tools include, but are not limited to, node-to-node charts, use cases, sequence or activity charts, functional flow block diagrams, structure charts, allocation charts, data flow diagrams, object diagrams, storyboards, and entity relationship diagrams.)
- Describe the operational environment in detail to give the readers an understanding of the assumptions, constraints, numbers, versions, capacity, etc., of the operational capability to be used.
- Describe those aspects of the physical environment, safety, security, and privacy that exert influence on the operation or operational environment of the proposed system.
- Include voluminous descriptions, such as a data dictionary, in an appendix, or incorporate them by reference.
References & Resources
- IEEE Computer Society, March 19, 1998, IEEE Guide for Information Technology—System Definition—Concept of Operations (ConOps) Document (IEEE Std 1362-1998).
- Office of Management and Budget, December 5, 1994, Operational Concept Description (OCD), Data Item Description DI-IPSC-81430.
Additional References & Resources
Fairley, R.E., R. H. Thayer, and P. Bjorke, April 18-22, 1994, Proceedings of the First International Conference on Requirements Engineering, pp. 40-47.