The article will explore 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.

1. MBSE with Arcadia method
step-by-step
Operational Analysis
Author: Hélder Castro
Contact: helder.r.castro@gmail.com
LinkedIn: www.linkedin.com/in/heldersilvacastro

2. Contents
1. Introduction ....................................................................................................................................1
2. Operational analysis (OA) ...............................................................................................................2
2.1. Operational analysis concepts ................................................................................................2
3. Arcadia process and defining project work activities .....................................................................3
3.1. Operational Analysis artefacts and activities matrix ..............................................................6
3.2. Capture Operational Entities and Actors................................................................................6
3.3. Capture Operational Capabilities............................................................................................6
3.4. Define Operational Activities..................................................................................................7
3.5. Define Operational Activities Interactions..............................................................................8
3.6. Allocate Operational Activities................................................................................................9
3.7. Describe Operational Capability with Operational Process and Scenarios ............................9
3.8. Define Operational Modes and State ...................................................................................11
3.9. Operational Analysis model elements traceability...............................................................12
3.10. Operational Analysis traceability flow ..............................................................................12
Bibliography ..........................................................................................................................................14
Figures
Figure 2.1: Operational analysis concept................................................................................................2
Figure 3.1: Arcadia matrix activities........................................................................................................4
Figure 3.2: Arcadia diagrams matrix:......................................................................................................5
Figure 3.3: [OEBD] Operational Entities Breakdown Diagram................................................................6
Figure 3.4: [OCB] Operational Capability Diagram .................................................................................7
Figure 3.5: [OABD] Operational Architecture Blank diagram .................................................................8
Figure 3.6: [OAIB] Operational Activities Interaction Blank Diagram.....................................................8
Figure 3.7: [OAB] Operational Architecture Blank..................................................................................9
Figure 3.8: [OPD] Operational Process Description..............................................................................10
Figure 3.9: [OES] Operational Entity Scenario ......................................................................................11
Figure 3.10: [M&S] Modes & States .....................................................................................................11
Figure 3.11: Operational Analysis model elements traceability...........................................................12
Figure 3.12: Operational Analysis model elements and diagrams traceability ....................................13
Table
Table 3.1: Operational analysis activities................................................................................................6

3. 1
1. Introduction
This article follows the MBSE Arcadia method ontology elements traceability [1], 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 [2], 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.

4. 2
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.
2. 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.
2.1. Operational analysis concepts
Hereafter, it will be described the main Operational Analysis concepts:
Figure 2.1: Operational analysis concept
Operational Capability
Capability of an organization to provide a high level service leading to an
operational objective being reached (for example Provide weather forecasts, etc.);
Operational Entity
Entity belonging to the real world (organization, existing system, etc.) whose role is
to interact with the system being studied or with its users (for example Crew, Ship,
etc.);
Operational Actor
Particular case of a (human) non-decomposable operational entity (for example
Pilot, etc.);
Operational Activity
Process step carried out in order to reach a precise objective by an operational
entity, which might need to use the future system in order to do so (for example
Detect a threat, Collect meteorological data, etc.);
Operational Interaction
Exchange of information or of unidirectional matter between operational activities
(for example meteorological data, etc.);
Operational Process
Series of activities and of interactions that contribute toward an operational
capability.
Operational Scenario
Scenario that describes the behavior of entities and and/or operational activities in
the context of an operational capability. It is commonly represented as a sequence
diagram, with the vertical axis representing time.

5. 3
3. 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.

6. 4
Figure 3.1: Arcadia matrix activities

7. 5
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:
Figure 3.2: Arcadia diagrams matrix:

8. 6
3.1. 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.
Step Matrix Diagram Output Step description
Step 1 OA4 OEBD Capture Operational Entities and Actors
Step 2 OA1 OCB Capture Operational Capabilities
Step 3
OA3
OABD Define Operational Activities
Step 4 OAIB Define Operational Activities Interactions
Step 5 OA4 OAB Allocate Operational Activities
Step 6 OA2
OPD
OAS
OES
Describe Operational Capability with Operational
Process and Scenarios
Step 7 M&S-OA5 M&S Define Operational Modes and State
Table 3.1: Operational analysis activities
3.2. 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).
Figure 3.3: [OEBD] Operational Entities Breakdown Diagram
3.3. 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).

9. 7
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:
o The Passenger goal/motivation is to be Entertained During Flight AND
o The Cabin Crew goal is to Entertain During Flight.
• “Perform Flight On-board Announcements” OC:
o The Cabin Crew needs to Perform Flight On-board Announcements AND
o The Pilot needs to Perform Flight On-board Announcements.
• “Implement a Commercial Strategy” OC:
o 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.
Figure 3.4: [OCB] Operational Capability Diagram
3.4. 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

10. 8
functionalities. A reference for grouping Operational Activities can be the Miller’s law [3]. 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.
Figure 3.5: [OABD] Operational Architecture Blank diagram
3.5. 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.
Figure 3.6: [OAIB] Operational Activities Interaction Blank Diagram

11. 9
3.6. 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.
Figure 3.7: [OAB] Operational Architecture Blank
3.7. 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.

12. 10
Figure 3.8: [OPD] Operational Process Description
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.

13. 11
Figure 3.9: [OES] Operational Entity Scenario
3.8. 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.
Figure 3.10: [M&S] Modes & States

14. 12
3.9. Operational Analysis model elements traceability
Arcadia method defines an ontology as described in a previous section. An ontology captures, model
elements 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, artifacts are produced more as pictures that
are unlikely to be consistent with each other.
Figure 3.11: Operational Analysis model elements traceability
3.10. Operational Analysis traceability flow
Finally, it is captured in the figure below the model elements and diagrams traceability and
relationship.
From the figure it can be read that:
• An Operational Capability 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.

15. 13
Figure 3.12: Operational Analysis model elements and diagrams traceability

16. 14
Bibliography
[1] H. Castro, “MBSE Arcadia method ontology elements traceability,” [Online]. Available:
https://www.linkedin.com/pulse/mbse-arcadia-method-ontology-elements-traceability-helder-
castro/.
[2] H. Castro, “Model-Based System Engineering and textual requirements traceability,” [Online].
Available: https://www.linkedin.com/pulse/model-based-system-engineering-textual-
requirements-helder-castro/.
[3] “The Magical Number Seven, Plus or Minus Two,” [Online]. Available:
https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two.