Concept of Operations – Why Bother?

Many projects begin development with a specification document, a list of the requirements needed for the project to be successful or for the project’s product to be realised. When the subject of a Concept of Operations (ConOps) is broached, the reaction can often be negative; in effect:

“Why bother? We’re already past that point in the lifecycle, we have a requirements document.!”

The ConOps is valuable because it gives the designer a perspective not available from the requirements alone. It provides a view of the practical applications of the product in which to couch the design approach, helping to ensure the designer’s interpretation of the requirements is meaningful to the customer’s anticipated use of the product.

The ConOps puts the operation of the product into a world view perspective by stating:

• Which operations need to be performed by the product and in what order?
• What the operator will be providing as inputs?
• When those inputs will become available in the operations timeline?
• What he/she is expecting as output?
• When that output is needed?
• How it will be used?

Seeing the big picture helps the designer to judge which of the many potential design responses best fits the customer’s need.

The ConOps also specifies the operating conditions under which the most intense utilisation of the product or system will occur, when the system is being stressed as much as any operation is expected to stress it. The ConOps differentiates that state from those other conditions under which the most frequent utilisation of the product will occur, and should include the anticipated utilisation rates for each case.

This becomes the underlying rationale for many of the “ility” requirements (including such as availability, reliability, durability, supportability, sustainability and so on), and helps the test designers to bound the developmental and operational test conditions that are needed to demonstrate those parameters, to in turn provide confidence that test results are meaningful and representative of true product or system performance.

The ConOps information can be especially important in a spiral development context, if cost and time constraints in the development programme dictate that certain capabilities need to be delayed into future builds. For example:

• From the requirements document we know that the product must be able to travel overseas by air in an un-pressurised compartment
• From the ConOps we learn that the expectation of the user is that the product will be shipped overseas once in its lifetime, and then not until the year 2010 when the overseas contract goes into effect

Knowing when a specific capability will be needed for implementation by the user allows the program manager to identify which capabilities can be deferred and for how long. Knowing how often a capability will be called upon in a product’s life can help the program manager to gauge the risk associated with achieving or not achieving that capability.

The ConOps is not just a retelling of the requirements, but is instead an essential part of the customer requirements that defines how the product or system has to satisfy the requirements in its real world operating and support environments.

Representing the ConOps in Cradle Projects

A Concept of Operations (ConOps) is an important part of the specification of any large system or product. It is typically either:

• Part of the information supplied by the customer to the contractor
• Part of the information to be developed by the contractor on the customer’s behalf

In the first case, the ConOps can be handled as a source document and loaded into the Cradle database using Document Loader. The ConOps is typically loaded into a different set of items to the user requirements, and so a separate item type (such as CONOPS) would be created, and the ConOps document parsed into a hierarchy of these items.

In the second case, the ConOps will be a document published from Cradle using the Document Publisher tool. The information in the ConOps will be descriptions of the one or more operating modes or uses of the product or system. These descriptions can be created using a combination of one or more of:

• Operational concept descriptions, perhaps created as a hierarchy of CONOPS items
• Use case diagrams (UCDs) and associated use cases, each use case described with a main flow and one or more alternate flows, and each decomposed into alternative scenarios if the use case is complex
• Process flow diagrams (PFDs) and associated process descriptions, one PFD for each operating mode, use or scenario

Once the operating modes, uses or scenarios (whichever term is being used) have been defined or captured (so that the ConOps exists in the Cradle database), it can be used to assist the further development of the system by linking the ConOps descriptions to the:

• Operational and functional analysis models, used to derive the functional system requirements
• System requirements, both the functional system requirements and the non-functional “ility” requirements

This typically creates the following sets of cross references in the database:

• User requirements are linked to the ConOps
• ConOps are linked to the system requirements
• User requirements are linked to the system requirements