MBSE with Arcadia method step-by-step: Operational Analysis

This article follows the MBSE Arcadia method ontology elements traceability, where it was provided an introduction to the method, the different architecture layers, a simplified metamodel and model elements traceability.

In the following, it will be explored the Arcadia Operational Analysis layer to capture stakeholder (e.g., users, environment, other systems) and business needs, a reasoned step-by-step activities and artefacts (i.e., diagrams) that can be produced to help during the stakeholders elicitation process helping to explore needs and identify gaps in the analysis; the full MBSE with Arcadia step-by-step is not described in this article, but it has extended to all Arcadia layers (i.e., System Analysis, Logical and Physical Architecture) and it can be used in projects for defining and guiding in the initial project activities and artefacts to be produced from the model.

The Operational Analysis as mentioned in the previous article, aims at capturing what the user of the system needs to accomplish, hence, the Operational Analysis normally starts by identifying who the users (i.e., Operational Entities and/or Operational Actors) of the future system are, and any containment relationship between them. Below is captured main tasks normally performed when defining the Operational Analysis:

Main objectives:

• Identify and capture stakeholders of the system.
• Define Operational Capabilities.
• Perform an operational needs analysis.
• Identify and capture Operational Activities for each stakeholder (i.e., Operational Entities and Actors).
• Define interactions between activities and actors.
• Define information used in activities and interactions.
• Identify and define Operational Processes and scenarios.
• Define Operational Modes and States.

Stakeholder textual requirements, should be an input to the Operational Analysis layer. Textual requirements can be formalised and analysed in more detail when Operational Processes and Scenarios are defined. When defining Operational Processes and Scenarios it should be considered to analyse and define situations that describes "what if" scenarios. That is, explore situations where the behaviour occurs as expected under normal operation and others where it is exploited and considered a different execution path, for example an error as occurred.

This is a powerful MBSE capability and Arcadia does implement it to analyse and describe in detail Operational Capabilities. During the scenarios process definition, it is recommended to involve the stakeholders and users. From this detailed analysis with the different stakeholders, it is often the case to identify new textual requirements.

Textual requirements can be captured in the Capella tool as described in the Model-Based System Engineering and textual requirements traceability, however, if there is the need for a requirements management and create textual requirements baselines, it might be a better approach to capture textual requirements in a requirements management database tool (e.g., IBM Doors) and then import them to Capella.

Operational analysis (OA)

“What system users must achieve”.

This perspective analyses the issue of operational users, by identifying actors that have to interact with the system, their goals, activities, constraints, and the interaction conditions between them.

This perspective allows to model the required high-level operational capabilities and perform an operational needs analysis without even defining the system-of-interest, in fact the system is not even mentioned at this layer.

Operational analysis concepts

Hereafter, it will be described the main Operational Analysis concepts:

Arcadia process and defining project work activities

When starting a new project for capturing a product Architecture, it is recommended to define and agree what is the Work Breakdown Scope (WBS) and priorities for each project. That is, it is not mandatory to define all layers and all model elements from the start; it can be analysed, captured, and developed the Architecture in a phased approach, for example, capture initially what is defined under columns: requirements, capability, capability description, functional and structure as captured in the table “Arcadia matrix activities”. The other areas will emerge and defined later.

Several artefacts can be produced and exported, if needed, from the model. Arcadia does provide several diagrams as captured in the table “Arcadia diagrams” that ideally needs to be understood what the expectation for each of them is and how they can support the project and the different stakeholder expectations. This will be explained in detail in the hereafter sections.

The below table shows the several Arcadia diagrams (not exhaustive list) of what diagrams can be produced for each layer and focus area of development:

Operational Analysis artefacts and activities matrix

As mentioned before, Arcadia or this document do not impose any sequence to define the Operational Analysis activities and artefacts. The following table captures a reasoned and possible step-by-step and artefacts (i.e., diagrams) produced from each step. A mapping to the Arcadia matrix activities defined above is also captured.

Capture Operational Entities and Actors

The Operational Entity Breakdown diagram (OEBD) is expected to be one of the first diagrams to be defined, as it exercises to think and capture what are the Operational Entities and Actors that do have an interest in the future system or service.

Below is captured the main activities undertaken to define this diagram.

Activities:

• Identify and capture Operational Entities and Actors that will interact with the future system.
• Identify Operational Entities and Actors containment (hierarchy).

Capture Operational Capabilities

Following the capture of Operational Entities and Actors, the next step will be to capture motivations, expectations, goals, objectives, intentions, etc., in a form of Operational Capabilities (OC).

The below figure shows the Operational Capabilities captured for the example In-flight entertainment. For each of them it has been identified and defined involvements between the different OCs and Entities and Actors.

An involvement shows all the Entities and Actors that do express an interest on the Operational Capability.

Business needs can also be identified and captured as Operational Capabilities. An example is the Airline Company Operational Entity and the Operational Capability “Implement a Commercial Strategy”.

A way of reading the below diagram can be:

“Entertain During Flight” OC:

• The Passenger goal/motivation is to be Entertained During Flight AND
• The Cabin Crew goal is to Entertain During Flight.

“Perform Flight On-board Announcements” OC:

• The Cabin Crew needs to Perform Flight On-board Announcements AND
• The Pilot needs to Perform Flight On-board Announcements.

“Implement a Commercial Strategy” OC:

• The Airline Company intends to Implement a Commercial Strategy.

Activities:

• Identify Operational Capabilities expected from the Operational Entities and Actors.
• Identify entities and actors associated against each Operational Capability.

Define Operational Activities

Operational Activities can be identified initially, from the Stakeholder requirements, if available.

Activities to identify and capture new Operational Activities, can be done with the different stakeholders for a better understanding of the needs. Operational Activities can be grouped by similar functionalities. A reference for grouping Operational Activities can be the Miller’s law. From Miller study, it is recommended to refine a parent Operational Activities into 7 ± 2 children Operational Activities. This rule can be followed for all the behavioural and structural breakdown activities.

Activities:

• Identify Operational Activities to be performed by the Operational Entities and Actors.
• Identify high-level Operational Activities containment relationship.

Define Operational Activities Interactions

When identified and captured Operational Activities, Operational Interactions can be identified and defined. Operational Interactions defines interactions between different Activities and provides a description of what it flows.

The diagram below can capture any number (i.e., all or a sub-set) of Operational Activities that are considered relevant for the analysis by the different stakeholders or focus on Operational Activities that can be involved to describe an Operational Capability.

Activities:

• Identify Operational Activities performed by the Operational Entities and Actors.
• Identify high-level Operational Activities containment relationship.

Allocate Operational Activities

Operational Activities are performed by either an Operational Entity or Actor. Hence, Operational Activities should be allocated to each and responsible entity or actor that will perform it; this is called Operational Activities allocation to entities and actors.

During the allocation task, it can be shown Operational Process that has been defined, as per section above, and identified and defined new Operational Processes and interactions in context with the different Operational Entities and Actors.

Activities:

• Identify and allocate Operational Activities performed by each Operational Entity and Actors.
• Identify in context new Operational Interaction between Operational Entities and Actors.
• Identify in context new Operational Processes for each Operational Capability.

Describe Operational Capability with Operational Process and Scenarios

Let’s recall that Operational Capabilities captures high-level goals, motivations, expectations and/or needs. The process that describes what Operational Activities should be involved to fulfil, describe, and verify an Operational Capability, can be captured with Operational Process. Operational Process involves (i.e., references) Operational Activities that are identified to describes an Operational Capability. A number of Operational Processes can be defined to describe one single Operational Capability.

It is inherent to each Operational Process definition, to identify what Operational Activities make the start and end of the Operational Process.

Activities:

• Identify Operational Activities and Operational Interactions that describe an Operational Capability.

An Operational Capability can be described by Operational Processes as described above. Operational Entity and Activity Scenarios, provides with the means to describe an Operational Process in more detail. Operational Scenarios describe the sequence of interactions in time.

In an Operational Scenario it can be shown (i.e., referenced) all the following:

• Operational Activities interactions.
• Operational Activities allocated to each Operational Entity. Related to Operational Entity Scenarios.
• Modes and States.
• Fragments (e.g., decisions, loops) to enhance scenarios.

Activities:

• Identify Operational Entities and Operational Actors involved for an Operational Capability description.
• Identify the interactions sequence in time.
• Show Operational Activities and Fragments to enrich scenario.
• Show Modes and States associated to each Operational Entity and Actor.

Define Operational Modes and State

Modes and States can be captured, and all the triggering and guard conditions defined. Modes and States need to be allocated to Operational Activities.

Activities:

• Identify and capture modes and states relevant to the system Life Cycle, phases.

Operational Analysis model elements traceability

Arcadia method defines an ontology as mentioned, the ontology captures, model elements concepts and the relationship between them.

The figure below shows some of the Arcadia model elements traceability that are related to each other. This also allows model elements to be reused and referenced in several diagrams, but also a major difference to other tools (e.g., office tools) and languages (e.g., natural languages), where little or no traceability is maintained and performed, hence, artefacts are produced more as pictures that are unlikely to be consistent with each other.

Operational Analysis traceability flow

Finally, it is captured in the figure below the model elements and diagrams traceability flow and relationship.

From the figure it can be read that:

• An Operational Capability (i.e., stakeholder motivations, expectations, goals, objectives, intentions) can be described by a number of Operational Process and/or Scenarios.
• An Operational Process and Operational Scenarios involve Operational Activities.
• Operational Activities are allocated to Operational Entities and Operational Actors.

It is also shown what diagrams can be used to capture the different model elements and relationship.

Conclusion

The above guided step-by-step method to capture stakeholder needs, activities and explore different scenarios can be of great value for a project or organisation to understand what is expected from initial stakeholder needs and what is needed and intended to be developed for the future system (product or service). MBSE with Arcadia provides a rich ontology and diagrams that enables and promotes consistency, reuse of concepts and a visual and common language that can be used to explore with different stakeholders during the needs capture.

Further reading:

Part 2: MBSE with Arcadia method step-by-step: System Analysis

Part 3: MBSE with Arcadia method step-by-step: Logical Architecture

Part 4: MBSE with Arcadia method step-by-step: Physical Architecture

PDF file

Below it can be found a FREE PDF of this article, the three following MBSE with Arcadia method step-by-step articles, and the article what "What is MBSE".

#MBSE #systemarchitecture #Arcadia #digitaltwin #engineering