A CONOPS should define any critical, top-level, performance requirements or objectives stated either qualitatively or quantitatively (including system rationale for these objectives). 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.Ī 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. Post-fielding life cycle costs often dwarf those of the development effort.
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).
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 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. 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.
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. 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.
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. The user, developer, or both may write CONOPS, often with help from MITRE systems engineers. The purpose of a CONOPS is to describe the operational needs, desires, visions, and expectations of the user without being overly technical or formal. In addition, they should test operational concepts (concept validation) and user utility as described in the CONOPS. They should also be able to develop test requirements that are traceable to system requirements and user needs. MITRE SEs should be able to apply systems engineering methods to map user (operational) needs to system requirements, functions, and conceptual system designs. In some cases MITRE systems engineers may be asked to support the development of a CONOPS. 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. Keywords: concepts, CONOPS, operational concept description, operational concepts, operational scenarios, system concepts, use cases, user needs, user/system roles, viewpoints 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. 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. "Ī 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. 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.
Definition: A Concept of Operations (CONOPS) is a user-oriented document that "describes systems characteristics for a proposed system from a user's perspective.