- Operational Analysis step-by-step
- System Analysis step-by-step
- Logical Architecture step-by-step
- Physical Architecture step-by-step
- Data modelling
- Arcadia architecture layers and activities
- Identifying and capture user needs
- Arcadia diagrams matrix
A new project within a small or big company, may start with some level of planning to understand and define what activities should be needed and undertaken for developing a given system.
That is, defining and agree what is process, organisation capabilities, tools needed and the Work Breakdown Scope (WBS) priorities for each project.
The Model-Based System Engineering (MBSE) with Arcadia, uses a guided step-by-step method divided by abstraction layers to help and assist all stakeholders internal and external to develop a system, as described in the understanding what is the MBSE Arcadia method. Any development order can be followed or considered. The guide will describe each layer considering a reasoned order of activities execution as captured hereafter.
Understand “What the Stakeholders need from the future system”, common activities can be to identify and capture stakeholders with an interest on the system and what they need to achieve from the future system to be developed. It might be a good approach to start working at the Operational Analysis.
Capture “What the system must do for the users”, by capturing functions, interfaces and interactions between the System-of-Interest (SoI). The System Analysis is the most appropriate layer to fulfil this need.
Define “How the System should work” independently of any solution and by capturing high-level functionality and an initial trade-off architecture. The Logical Architecture allows to refine any functions captured at System Analysis and the logical structure.
Finally, but this could be the first layer to be defined if taking a bottom-up approach of the system, the Physical Architecture layer allows to define “How the system will be made off”.
An important part of system engineering involves ensuring consistency, correctness and completeness between the data managed in the system and the data exchanged with external actors, and components.
The table “Arcadia matrix activities”, captures what is expected at each level, but again there is no mandatory development path to follow or need to cover all areas of the matrix.
Several artefacts can be produced and exported, if needed, from the model. Arcadia does provide several diagrams as captured in the table below “Needs and Arcadia capabilities” 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.
To define the WBS some needs may need to be captured from the different stakeholders/users of the model. Not intended to be a thorough list, but below some of the user needs and mapping to model and tool capabilities listed:
Identifying and capture user needs
Below it is captured a list of diagrams that can be captured (not extensive list):
Arcadia diagrams matrix