Last year, I wrote that one of the most important characteristics of a strong systems engineering organization is knowing the operational setting in which the system-under-development will be placed. (See: 9 Characteristics of Good Systems Engineering.) Whether you are an organization contemplating a new system initiative or product development, or a contractor developing an approach for system development in response to a system acquisition, an effective understanding of operations is a critical part of the systems engineering process.
How do we learn about operations? The operations aspect of the system is typically studied early in the system lifecycle during an exploratory or conceptual design stage where stakeholder needs are identified. Operational analysis—the term for this study—may be conducted (implicitly or explicitly) by systems engineers, marketing professionals, or even entrepreneurs. I’ll use the term operational analysis to refer to the process of understanding user needs and translating them into stakeholder requirements.
But what exactly does operational analysis consist of? What artifacts does it produce, and how can MBSE help? The systems metamodel offered by Vitech and implemented in CORE™ and GENESYS™ creates the foundation for operational analysis. In the following paragraphs, we will discuss a list of steps in that process.
Operational Objectives
The way to begin an operational analysis is to determine the objectives, or purpose of the system of interest. These objectives might be unprecedented or they might result from a need to correct deficiencies in an existing system or systems. The understanding of user needs will be refined throughout the operational analysis process, but to get started we need some general idea of what the new system, or systems, of interest will do.
For example, the automobile was envisioned as a means to replace the horse and carriage. The fundamental needs of potential users were the same: transportation of people and cargo. The innovative idea offered by the automobile was elimination of the use of horses as the motive power for transportation and, along with it, the requisite infrastructure needed to care and feed them.
We can use the systems metamodel framework from MBSE to model operational objectives as Capabilities much like we do any requirements hierarchy, as depicted in the figure below.
Figure 1. Operational Objectives for an Automobile
Operational Scenarios
Having a good understanding of operations also means having a set of scenarios in mind that describe how external systems interact with a system of interest. These operational scenarios can also be referred to as use cases, borrowing from the discipline of software engineering. In addition to describing how a system of interest interacts with external parties, an operational scenario further describes interactions among the external parties conducted to achieve the goals of a broader mission.
To borrow an example used by Russell Ackoff, we learn why a car should have four doors not by deconstructing the car, but by looking at how the car is used operationally. We then learn that a car should have four doors to accommodate a driver and passengers entering and exiting the car. Furthermore, we learn why passengers need to access the car by examining the daily tasks of potential users. If we are designing a car with families in mind, we can build a sedan with four doors so everyone can drive together. If we also want to maximize cargo space, we can build a van to create more vertical space and a fifth door to accommodate loading and unloading.
The systems metamodel can assist with documenting operational scenarios by using the Operational Activity class to identify behavior of external parties as they interact with the system of interest and how they interact amongst each other. Operational Activities are a behavioral class and can be described just as we would system functions, by depicting a flow of activities and an exchange of information or resources, as depicted in the following scenarios for driving and occupying a car.
Based on the understanding and insight we gain through the operational use of the system, we can update and refine the operational objectives for the system of interest that we identified earlier.
Figure 2. Operational Scenario: Drive Car
Figure 3. Operational Scenario: Enter Car
The Operational Context
While analyzing operations, we should also give thought to the system boundary. Of all the stakeholders that interoperate to perform a mission, how do we combine or partition the set to identify a system for implementation? We can form a boundary physically by identifying which of the external parties interface to the system of interest, and which will be considered part of the system of interest.
We can identify the operational boundary physically using the Operational Node class (aliased now to Performer) and Needlines from the systems metamodel to effectively depict an operational context, as shown below visualizing how a Driver and Passengers interact as external parties with the automobile.
Figure 4. Operational Context for Automobile
We can also identify the operational boundary behaviorally using a new set of Operational Activities and Operational Items (mutually exclusive of those used to define the operational scenarios) to model operational behavior intended for the system of interest. A notional behavior model for the automobile is depicted below showing how the external parties interact with the automobile to occupy and drive the vehicle. We use these system-related activities to motivate the creation of operational requirements.
Figure 5. Operational Activities for an Automobile
Operational Requirements
The product of an operational analysis is a set of operational requirements. Operational requirements represent the required improvements to operations, or outcomes, envisioned with the introduction of the new system. They are first captured by the identification of operational outcomes, but are ultimately defined by the activities implied for the systems as discovered via the operational scenarios.
You can track operational requirements within the descriptions of the operational activities defined for the system in the previous step. Alternatively, you can track operational requirements as updates or refinements to the operational objectives continuing to use the Capability class from the systems metamodel, and the “refined by” relationship (depicted in the hierarchy below).
Figure 6. Refinement of Operational Objectives into Operational Requirements
Tying it altogether
MBSE and the systems metamodel support the operational analysis process. MBSE provides the method, and the systems metamodel forms the framework. As specified in the metamodel below, Capabilities are the “basis of” Operational Activities, which are “performed by” Performers. Additionally, Capabilities specify Performers in the form of constraints. Operational Activities exchange Operational Items over Needlines.
Figure 7. Key Classes and Relationships from the Systems Metamodel for Operational Analysis
The MBSE methodology can be leveraged as the systems design continues, so that engineers can view how elements of an eventual system design trace back to the operational objectives of the systems and ultimately to the needs of the users. Organizations that can capture this knowledge will be better positioned to develop products that will be successful operationally.
