Concept of Operations

6.3.1.2 Life Cycle Concept of Operations - The context diagram defines what the system interacts with in the external world. However, this is a static view. A dynamic view of the system is also necessary to understand how the system interacts with the external world. This dynamic view is provided with the concept of operations (Con-Ops) description.  Although the emphasis is on scenarios describing normal operation of the system sometimes scenarios describing operations in unique conditions or non-operational conditions should be included. Examples might be if the system has unique operations during testing, maintenance or at end of life that add to the system requirements.

The concept of operations includes a number of scenarios that in total convey an overall understanding of the system behavior. It does not include an exhaustive list of every operating mode of the system, but provides a broad view that the systems engineer uses as the basis for defining the details necessary in the design requirements. Each scenario provides a single thread of sequential events that starts at a typical predefined state, and completes when a primary set of operations is complete.  Scenarios are success oriented, providing a linear flow for operation of the processes of interest, and do not include alternate processing in the flow. Following the completion of the scenario, faults can be described as an alternate flow describing how the system may react should a fault occur. During the scenario, the flow may describe interactions with the operator. The flow assumes a particular input from the user thus providing the singular linear flow. Should alternate inputs provide important understanding of the system, they need to be described in separate scenarios. If there are many variations of processes that all start with a common flow then it may be convenient to describe the initial common portion as one scenario, and the multiple variations as independent flows. 

Scenarios need to include assumptions about what may have occurred prior to the start of the description, and describe the state of the system at the completion of the description. Environmental conditions need to be defined if they affect the operation of the system.

Use cases, to be described in a later chapter, are an excellent standard tool used to develop scenarios.

Typical operating scenarios include:

            Initialization – The initialization flow starts with the system unpowered and completes when the system is ready to perform its primary function. There may be multiple initialization scenarios. For example, when a computer boots, the computer may prompt the operator for input as to whether to perform a standard boot, or to perform a maintenance ‘safe’ boot. These two scenarios are described separately, both starting the same way with the application of power, but deviating based on the input from the operator.

Operation – Starts at the completion of initialization and completes when a process of the system is complete. The process may be scheduled, initiated by an operator, or the result of some other event detected by the system. An operational scenario may include a number of processes but should be short enough to be easily grasped by someone not familiar with the system. Multiple operational scenarios may be necessary in order to cover all primary processes.

Maintenance – Starts in a normal operating state and completes when the system is returned to the operating state. Assumptions of events leading up to the maintenance action are a particularly important part of these scenarios.

Repair - Starts in a fault condition and completes when the system is returned to the operating state. It is not possible to include scenarios which address every possible fault. The key is to remember is the intent is to provide the systems engineer with the broad understanding of how ‘typical’ faults are handled. This should provide enough understanding to extrapolate the operation of faults not explicitly described.

The content of the concept of operations must be developed with support of the user. This document captures the user expectations for how the system behaves. Additionally, this is the opportunity to guide the user to alternate operation if the behavior can be simplified. In the end, a user review is critical to receiving formal agreement with the final document. This document forms the basis for the system requirements for behavior. Additionally, it is the primary input to any user’s manual.

---