• What modelling activities and artefacts content should be produced?
• What are the artefacts relationships and traceability?
• What are the stakeholder roles involved for the modelling effort?
• What is the flow between processes?
• What should be the scope of the model?

The simple process for architecture development has been defined to architect and deliver by managing stakeholder expectations, and described on this article.

This process was inspired by the process modelling content within ‘SysML for Systems Engineering’ book, the MBSE with Arcadia step-by-step guide and the MagicGrid framework.

Capturing process development and definition goals

• Address stakeholder understanding and expectations; capture and define roles, activities, and artefacts.
• Ease of use; ensure ease of use, in terms of speed of understanding, adoption and complexity.
• Clear communication; clearly communicate modelling efforts and manage stakeholder expectations
• Level of abstraction; capture appropriate level of information
• Consistency; ensure consistency with modelling framework adopted

Process in one page

The process starts with the set of stakeholder needs captured by the requirements engineer in a specification captured either on an external Requirements Management Tool (RMT), step 1. Needs and requirements can be captured directly in the MBSE modelling tool. If needs/requirements are captured in an external tool, there is the need to import them into the modelling tool and feed the start of the conceptual architecture analysis..

The conceptual architecture analysis follows the MagicGrid framework steps and is executed by the system architect and normally supported by a Subject Matter Expert (SME), to capture domain knowledge. This process is flexible enough to work with any other MBSE framework or method, for example the Arcadia method. It is strongly advised to discuss, agree and clarify the modelling effort with all stakeholder involved to promote communication and manage modelling expectations. When the system architect completes the conceptual architecture, it can be exported from the modelling tool (step 2) containing the agreed set of diagrams and description.

The requirements engineer at the system level receives as input both the needs and the model document supporting and enhancing the SPP textual requirements captured at the system level (step 3).
The model provides the analytical reasoning linking requirements (design view) to needs (stakeholder view) and incorporating SME domain knowledge not present in the needs. The process is repeated for the solution and subsystem capture.

Next sections it will be described in detail each session of the process definition in one page.

Simple Process for Architecture Development with MagicGrid

This document contains:

• Simple Process for Architecture Development with MagicGrid focused on the solution architecture.
• References to content and resources

Download SPAD with MagicGrid432 Downloads

Roles definition

Roles involved in the modelling process were identified and defined. This allowed the identification of new roles and associated training needs within the organisation. There is not a 1:1 mapping between role and person for the following reasons:

• Requirements engineer; responsible to capture stakeholder needs and requirements.
• System architect; captures the system architecture for a system-of-interest. A system is normally decomposed in several layers of abstraction; hence, it is expected system architects to work in a collaborative environment.
• Subject Matter Expert; subject matter expert responsible for a product development, e.g., fuel cycle. He is also responsible to review the model content.

Artefacts relationship

This section identifies and captures artefacts, and relationship.

Capturing process artefacts guides and supports stakeholders involved in understanding the relationship and traceability in the model-based approach. The list of artefacts currently captured:

• Stakeholder needs. Captures the initial textual stakeholder needs.
• System and subsystem requirements. Captures system textual requirements at the different levels.
• Conceptual, system and subsystem architecture model. Model tool file containing the architecture.

It is, very important to understand the artefacts relationship and structure. The below figure is used to show and describe to all stakeholders what different types of traceability are expected, that is, between textual needs and between the needs and requirements and the architecture.

The “derive” traceability between textual needs and requirements are captured, reviewed and managed in the RMT, and not part of the system architecture process, hence, not described.

The “refine” and “satisfy” traceability relationship are captured in the MBSE modelling tool.

Activities and modelling artefacts content

Within each process step shown in figure MBSE process above there are a number of activities executed by the system architect to produce artefacts. A visual representation facilitates understanding with stakeholders and assists in the discussion and agreement of scope. Artefacts are a combination of SysML diagrams and additional tool diagrams, tables, and matrices. Maturity of both process tasks and artefacts is captured to assist with both capability and artefact development. The activities produce a set of artefacts are shown in figure below as example for the conceptual architecture:

Steps and artefact flow between processes

The “steps and artefact flow between processes” captures the interaction between cross-disciplinary processes, that is, system requirements definition process, step 1, 3 and step 5 and the system architecture definition process steps 2, 4, 6 and 7. It also shows the high-level artefacts produced and consumed by each of the process:

• Requirements definition process produces stakeholder needs and requirements captured in a specification and the Requirements Management Tool (RMT) adopted, that is represented by the green icon next to the blue human.
• System architecture process consumes artefacts from requirements process and produces modelling artefacts, such as model files or report document captured in an office tools, blue icon and pink human. The artefact content for the system architecture was already described previously in the content view.

This view shows a “Zig-Zag” flow from top level stakeholder needs to lower-level and subsystem architecture development, proving its value to:

• Where to start modelling, a system architect capturing the architecture for a subsystem, step 6, shall start by looking at the requirements captured in step 5 and the model captured during step 4 activities.
• When planning activities or presenting to non-System Engineer, what is the modelling effort involved, roles and artefacts consumed and produced.

Process usage in a modelling tool

The process above has been used in real projects and for the MBSE Cameo modelling tool. The below image is an example for the conceptual architecture capture:

Presentations delivered in Cameo modelling tool

Using the simple process for architecture development templates tailored to a conceptual architecture, solution and configuration, presentations can be delivered directly in the tool. Below a template demo within the Cameo modelling tool:

A system architect can move forward and backwards in a Cameo content diagram similar to a office presentation. No longer the need to export diagrams and increased workload to keep diagrams and model synched.

Key takeaways

The process described above and being used in projects has proven its value to:

• Tackle early modelling lack of understanding.
• Supports identification of roles and associated training needs.
• Clearly communicate modelling efforts and manage stakeholder expectations.
• Shows and clarifies artefacts between processes relationship.
• Clear step-by-step guidance between processes and artefacts flow.
• Clarify and support scope architecture development and agreement.
• Enables modellers to architect by guiding and clarifying which artefacts are produced and consumed throughout development.
• Manage and deliver against stakeholder expectations.

This process was sponsored by UKAEA.

The post Simple Process for Architecture Development with MagicGrid first appeared on Hélder Castro.

The matrix is based on the Arcadia method and can be used when:

• Architects starting with the Arcadia method.
• Senior architects planning activities and deliverables an architecture.
• Lead architects need to communicate modelling effort to stakeholders at different levels and remove modelling lack-of-understanding and expectations.

MBSE Arcadia matrix

While Arcadia allows flexibility in development order, the guide presents a reasoned sequence of activities to support learning and practical application.

This guide introduces the Arcadia method through a structured, step-by-step explanation. It is intended as learning guidance for engineers discovering Arcadia and understanding how modelling activities unfold across architecture levels.

MBSE Arcadia Operational Analysis

The Operational Analysis, 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.

Guided step-by-step article capturing activities and expected artefacts describing capturing “What the user of the system needs to accomplish.”.

System Analysis

The System Analysis level, 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?

Guided step-by-step article capturing activities and expected artefacts and describing “What the system must do for the user.“

Logical Architecture

Logical Architecture starts to “opens the box” by implementing the big decisions of the solution, in terms of principles of construction, and ways to fulfil the expectations of stakeholders.

Guided step-by-step article capturing activities and expected artefacts and describing “What the system shall do.”

Physical Architecture

The previous Logical Architecture started by “opening the black box” in order to identify the structural elements called Logical Components, as well as their properties and relations. The important rule followed is to ensure that it was excluded all technological considerations or implementation choices on this level. This is exactly the objective of the Physical Architecture in defining the “real” concrete components that comprise the system.

Guided step-by-step article “How the system shall be built“, defining the “real” concrete components that comprise the system.

MBSE Arcadia data modelling

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.

In order to, unambiguously describe these exchanges, the data, information, matter flow, etc., must be formalized. 

An important engineering task involves avoiding multiple definitions for a single piece of data in different areas of the system. Hence, the need to declare that several exchanges should carry the same type of data, without having to redefine the shared data for each exchange. 

Read article.

For readers who want to apply this guidance in a project context, a lightweight roadmap is provided. It summarises activities and artefacts discussed in this guide and can be used as a reference when planning or preparing reviews.

MBSE Arcadia step-by-step quick guide

This document includes:

• MBSE Arcadia matrix in one slide
• MBSE with Arcadia steps and diagrams with description
• References to the MBSE with Arcadia step-by-step guide online

Download PDF873 Downloads

This MBSE with Arcadia step-by-step guide is cited by Capella.org as a supporting resource for the Arcadia method

Capella practical example

The MBSE with Arcadia step-by-step guide is complemented by a Capella practical example. This practical guide explores the use of the Capella modelling tool project explorer and other capabilities that intends to reduce time to capture an architecture and automate activities

The full practical example can be found here.

The post MBSE with Arcadia step-by-step guide and practical example first appeared on Hélder Castro.