The Operational Analysis described is the previous article, MBSE with Arcadia method step-by-step: Operational Analysis [1], involves defining and creating a domain model, independently of the future system to be realized. The principle is to create a level of abstraction from the system under study in order to focus on the needs of the different stakeholders. The System Analysis level, on the other hand, is where the System-of-Interest (SoI) to be defined emerges. The following questions for the system definition needs to be answered: • What must the system do? • What are the external interfaces to the system? In order to answer the first question, the expected behaviour is modelled as Functions.

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

2. Contents
1. Introduction ....................................................................................................................................3
2. System analysis (SA)........................................................................................................................3
2.1. System Analysis concepts .......................................................................................................3
3. System Analysis artefacts and activities matrix..............................................................................4
3.1. Define Context System Actors ................................................................................................5
3.2. Define Missions and System Capabilities................................................................................5
3.3. Define System Functions.........................................................................................................6
3.4. Define Functional Exchanges ..................................................................................................7
3.5. Allocate System Functions to System Component and Actors...............................................8
3.6. Describe System Capabilities with Functional Chains.............................................................9
3.7. Describe System Capability with Functional Scenarios.........................................................10
3.8. Describe System Capability with Entity Scenarios................................................................11
3.9. Describe Capability Realizations with Functional Chains and Scenarios ..............................11
3.10. System Analysis traceability flow......................................................................................12
Conclusion.............................................................................................................................................14
Bibliography ..........................................................................................................................................15
Figures
Figure 2.1: System Analysis main concepts ............................................................................................4
Figure 3.1: [CSA] Context System Actors ................................................................................................5
Figure 3.2: [MCB] Mission and Capabilities Blank ..................................................................................6
Figure 3.3:[SFBD] System Functions Breakdown diagram......................................................................7
Figure 3.4: [SDFB] System Data Flow Blank ............................................................................................8
Figure 3.5: [SAB] System Architecture Blank diagram - right .................................................................9
Figure 3.6: [SFCD] System Functional Chain Description diagram - right.............................................10
Figure 3.7: [FS] Functional Chain diagram ............................................................................................10
Figure 3.8: [ES] Entity Scenario.............................................................................................................11
Figure 3.9: System Capability described by Functional Chains and Scenarios .....................................12
Figure 3.10: System Analysis model elements and diagrams traceability flow....................................13
Table
Table 3.1: System analysis activities and artefacts.................................................................................5

3. 3
1. Introduction
The Operational Analysis described is the previous article, MBSE with Arcadia method step-by-step:
Operational Analysis [1], involves defining and creating a domain model, independently of the future
system to be realized. The principle is to create a level of abstraction from the system under study in
order to focus on the needs of the different stakeholders.
The System Analysis level, on the other hand, is where the System-of-Interest (SoI) to be defined
emerges. The following questions for the system definition needs to be answered:
• What must the system do?
• What are the external interfaces to the system?
In order to answer the first question, the expected behaviour is modelled as Functions.
Textual requirements if captured at Operational Analysis level, should be derived, and formalized at
this level.
Below is listed the main activities expected for the System Analysis layer.
Main activities:
• Formalize and consolidate requirements.
• Identify system boundaries, external interfaces, and actors.
• Perform a functional and non-functional analysis.
• Identify functions of system and actors.
• Identify interfaces of the system (i.e., component ports).
• Identify information used in function and exchanges (classes data model can be defined).
• Perform a capability trade-off analysis.
• Identify system and actors’ capabilities.
• Identify and define functional chains and behavioural scenarios.
• Define System Modes and States.
2. System analysis (SA)
“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. System Analysis concepts
Hereafter, it will be described the main Operational Analysis concepts:

4. 4
Figure 2.1: System Analysis main concepts
3. System Analysis artefacts and activities matrix
The activities and artefacts matrix was defined in the MBSE with Arcadia: Operational Analysis, the
System Analysis will consider and reference the same matrix.
As mentioned before, Arcadia or this document do not impose any sequence to define the System
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.

5. 5
Step Matrix Diagram Output Step description
Step 1 SA4 CSA Capture Context System Actors
Step 2 SA1 MCB Define Missions and System Capabilities
Step 3 SA2 SFBD Define System Functions Breakdown Structure (FBS)
Step 4 SA3 SDFB Define Functional Exchanges
Step 5 SA4 SAB
Allocate System Functions to System Component
and Actors
Step 6
SA2
SFCD Describe System Capabilities with Functional Chains
Step 7 FS
Describe System Capability with Functional
Scenarios
Step 8 ES Describe System Capability with Entity Scenarios
Table 3.1: System analysis activities and artefacts
3.1. Define Context System Actors
One of the first diagrams that can be produced when realising the System Analysis (SA), is the Context
System Actors [CSA], this diagram captures the System-of-Interest (SoI) and the actors, that is, all the
Operational Entities and Actors previously identified and captured at Operational Analysis (OA) should
be transitioned to SA; System Actors will be contextually created from Operational Entities and Actors
defined at Operational Analysis.
This diagram is synchronised and automatically updated by the Capella tool with new actors. For
example, new System Actors are identified and added during the System Architecture Blank [SAB]
diagram elaboration.
Activities:
• Identify and capture new System Actors (e.g., operators, other external systems).
Modelling tips:
• Perform a transition of the Operational Entities and Actors.
Figure 3.1: [CSA] Context System Actors
3.2. Define Missions and System Capabilities
Follow the capture of the Context System Actors diagram, the next diagram that can be produced is
the Missions and System Capabilities (MCB). To produce this diagram, it is recommended to transition
the Operational Capabilities (OC), from the OA. When done the transition OC can be decomposed
further in Capabilities (C).

6. 6
During the System Missions and Capabilities capture, asking the following questions may help to
elaborate Missions and Capabilities:
• Mission: What is the purpose of the System?
• Capabilities: What service(s) shall the System provide?
Activities:
• Identify and define System Missions (i.e., system goals) and new System Capabilities for each
System Capability.
• Identify involved Actors against each Capability.
Modelling tips:
• Perform a transition of the Operational Capabilities and translate Operational Capabilities into
System Capabilities.
Figure 3.2: [MCB] Mission and Capabilities Blank
3.3. Define System Functions
The Operational Activities identified during the Operational Analysis (OA) can be transitioned and
refined into System Functions. The System Functions can then be allocated to a System Actor and/or
a System Component.
It is important to note that the emergence of the functions is not merely a simple refinement of
operational activities: the object is a different analysis, in which, for example, several operational
activities can result in the same system function, and system needs functions may appear without
necessarily corresponding to an operational activity (self-tests or reconfigurations, for example).
Operational Activities refined and identified new System Functions can be allocated to System Actors
and/or System Component. More details will be provided in the chapter System Functions allocation.
Recall that only needs-related considerations should be included in this perspective dedicated to the
expression of the system needs as required by users or clients, excluding any choice of design or
refinements not requested by the client, in order to preserve the largest flexibility possible of design

7. 7
further on. Therefore, certain choices delegated to the provider are not addressed here but will have
to be considered in the perspectives dedicated to the solution.
Activities:
• Analyse and decompose Operational Activities to new System Functions and/or System
Actors.
• Identify high-level System Functions containment relationship.
Modelling tips:
• Transition Operational Activities and refine Operational Activities in new System Functions.
• Define a root function where all functions will be decomposed from.
• Good practice involves manually changing the colour of the parent functions transitioned from
Operational Analysis to white.
Figure 3.3:[SFBD] System Functions Breakdown diagram
3.4. Define Functional Exchanges
When functions are captured, functions interactions be defined, in a form of System Functional
Exchanges.
Arcadia rule:
• As soon as a function is broken down into subfunctions, there is the need to work on the
assignment of Functional Exchanges to the sub-functions of the parent Function. Only leaf
Functions (those that are not broken down) can have input/output Ports.
Activities:
• Identify and define System Functional Exchanges.
Modelling tips:
• Work on the assignment of Functional Exchanges to the sub-functions of the parent Function
• Remember that the Functions in light blue are those that have been allocated to Actors.

8. 8
Figure 3.4: [SDFB] System Data Flow Blank
3.5. Allocate System Functions to System Component and Actors
When System Functions are identified, captured, and refined there will be the need to ask whether
each Operational Activity will be realized by the system in its entirety, partially, or not at all. The result
at the System Analysis level can be formalized as follows:
• Entirely: the activity becomes a function of the same name, allocated to the system.
• Partially: the activity must be broken down into several functions, some of which are allocated
to the system and others to at least one actor.
• Not at all: the activity becomes a function of the same name, allocated to an actor.
Arcadia rule:
• At every level of Arcadia, a Functional Exchange between two Functions allocated to two
Behavioural Components must be allocated to a single Component Exchange between these
two Components. This Component Exchange references all the Functional Exchanges that it
implements. In general, a Component Exchange is made up of a synthesis of several Functional
Exchanges that it implements and gathers together. The direction of the Component Exchange
is purely conventional, but the general rule is that the direction of the Exchange is from the
provider toward the user of the main data exchanged.
• Arcadia demands that Functional Exchanges be unidirectional. A Function Port is either an
input or an output, and this property cannot be modified in Capella. On the other hand, a
Component Exchange can be uni- or bi-directional. In fact, it is the Component Ports whose
direction property can be edited: in, out, in out.
• A Function can only be allocated once. Similarly, a Functional Exchange can only be allocated
to one Component Exchange.
Activities:
• Allocate functions to System Component and Actors.
• Allocate Function Ports to Component Ports.

9. 9
Modelling tips:
• Only leaf functions can have input/outputs ports.
• Traceability flow and consistency between different model elements is done via Arcadia
ontology elements. Traceability can be verified in the Capella “semantic browser”.
Figure 3.5: [SAB] System Architecture Blank diagram - right
3.6. Describe System Capabilities with Functional Chains
Functional data flow refers to all the dependencies that exist between Functions. A Functional Chain
represents a set path in this global data flow. It is particularly useful for describing the expected
behaviour of the system in each context, and therefore for piloting verification/validation tests.
Functional Chains are also often used to express non-functional constraints in functional paths, such
as latency, criticality, confidentiality, redundancy, etc.
System Functional Chains Description (SFCD) diagram is needed when a Functional Chain is already
created and needs to be updated, e.g., new System Functions were captured and Functional
Exchanges defined making the Functional Chain invalid (no continuity), hence, there is the need to
update the chain with the new updates.
The SFCD diagram is always synchronized with the current state of the chain’s definition in the model.
The model elements present in the diagram are not themselves Functions and Functional Exchanges,
but rather references to these elements, called Functional Chain Involvement.
Activities:
• Define Functional Chains, by identifying what functions are involved in a functional path.
Modelling tips:
• Transition Operational Processes from Operational Analysis, if defined.
• Invalid Functional Chains can be updated with the System Functional Chains Description
diagram.

10. 10
Figure 3.6: [SFCD] System Functional Chain Description diagram - right
3.7. Describe System Capability with Functional Scenarios
As described in the Arcadia method section, a scenario describes the behaviour of the System in a
context for a particular Capability.
Functional Scenarios (FS) describe a sequence in time of the interactions and lifelines are Functions.
Activities:
• Define the functions involved that describe a System Capability.
• Define the ordered sequence in time of the interactions.
• Consider including Modes & States and fragments to enrich the scenario.
Modelling tips:
• Capella automatically creates a Capability the first time a Scenario is created unless a
Capabilities already exist. In this case, Capella asks to choose one Capability to attach the new
Scenario.
• Functional Scenarios can be created from a Capella transition of the Functional Chain.
Figure 3.7: [FS] Functional Chain diagram

11. 11
3.8. Describe System Capability with Entity Scenarios
Similarly, to Functional Scenarios, Exchange Scenarios can be defined and where Exchange Scenarios
lifelines are Components/Actors, and sequence messages are Functional or Component Exchanges.
Activities:
• Create Entity Scenarios (ES) that describe a System Capability.
Modelling tips:
• Consider including Functions, Modes & States, and fragments to enrich the scenario.
• Entity Scenarios can be transitioned, if created, from a Capella transition of a Functional
Scenario.
Figure 3.8: [ES] Entity Scenario
3.9. Describe Capability Realizations with Functional Chains and Scenarios
System Capabilities can be described by Functional Chains and Scenarios as described above. Capella
does provide automated transitions that facilitates the creation of the different scenarios as described
above and captured again below:
• When a functional chain is defined, a Functional Chain can be transitioned and created a
Functional Scenario.
• When a Functional Scenario is created, it can be transitioned and created an Entity Scenario.

12. 12
Figure 3.9: System Capability described by Functional Chains and Scenarios
3.10. System 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.

13. 13
Figure 3.10: System Analysis model elements and diagrams traceability flow

14. 14
Conclusion
The above Arcadia System Analysis guided step-by-step method, describes a reasoned step-by-step
choice in terms of activities and diagrams. It can be seen in several of its diagram’s traceability that is
provided and inherent in the model. System Analysis defines the needs for the System-of-Interest
(SoI), what it must do for the actors (i.e., external entities to the system), and identify and define
interfaces.
It was provided some Capella tool modelling tips that should be followed to promote correctness of
the model and some transitions that help and accelerate the modelling effort.

15. 15
Bibliography
[1] H. Castro, “MBSE with Arcadia method step-by-step: Operational Analysis,” 2023. [Online].
Available: https://www.linkedin.com/pulse/mbse-arcadia-method-step-by-step-helder-
castro/?trackingId=P53d%2FO7w9kmURcPB5XxMOQ%3D%3D.