Which SysML Diagram Should You Start With? A Practical MBSE Workflow

One of the most common questions engineers ask when beginning a Model-Based Systems Engineering (MBSE) project is:

“Which SysML diagram should I create first?”

SysML includes multiple diagram types, and it can be overwhelming to decide where to begin when you join a project or start modeling a new system.

The key to choosing the right starting point is understanding where your system sits in the system lifecycle and whether you are modeling behavior, structure, or requirements.

In this guide, we walk through a practical workflow for deciding which SysML diagrams to create first, how they connect together, and how your model evolves as the project matures.

Watch the full video explanation here:

https://www.youtube.com/watch?v=FcpYAR0rYGI

---

Step 1: Determine the System Lifecycle Stage

Before creating any SysML diagrams, you should first understand what stage of development the system is in.

Common early-stage scenarios include:

• IRAD (Internal Research and Development)

• Concept exploration

• Early system architecture development

• Initial requirements discovery

At this stage, the goal is to understand what the system should do and who interacts with it.

---

Start with Use Case Diagrams and User Needs

If the system is still in its early concept phase, the first diagrams to create are typically:

• Use Case Diagrams

• User Needs / Requirement Diagrams

A use case diagram helps define:

• system actors

• external interactions

• system goals

• operational scenarios

This provides a clear understanding of what the system must accomplish from the user perspective.

Once the use cases are defined, you can begin deriving stakeholder requirements and modeling them using requirement diagrams.

These diagrams establish the foundation of the entire system model.

---

Step 2: Begin Structural or Behavioral Decomposition

After defining the system goals and requirements, the next step is to begin decomposing the system.

At this point, you must decide whether to begin with:

• Structural modeling

• Behavioral modeling

Your choice depends heavily on the type of system being developed.

---

When to Start with Activity Diagrams

If your system is primarily software, it often makes sense to start with the behavioral side of the model.

The best starting point in this case is typically an activity diagram.

Activity diagrams help describe:

• system workflows

• operational logic

• data flow

• user interactions

• algorithm behavior

For software-heavy systems, understanding how the system behaves is often easier than defining its structure first.

As a result, activity diagrams can quickly provide insight into how the software should operate.

---

When to Start with Block Definition Diagrams

If your system includes hardware or a mix of hardware and software, it is usually better to start with the structural architecture.

In these cases, the recommended starting point is the block definition diagram (BDD).

A BDD allows you to:

• define the system of interest

• break the system into subsystems

• identify components

• establish interfaces and item flows

For physical systems, engineers often find it easier to define the structure first, because the architecture usually drives the behavior.

---

Iterating Between Structure and Behavior

Once the initial structure and behavior have been modeled, the development process becomes iterative.

Engineers will repeatedly refine:

• structural decomposition

• behavioral workflows

• system interfaces

• operational scenarios

During this process, it becomes important to allocate behavior to structural elements.

---

Allocating Behavior Using Swimlanes

One common technique is to use swimlanes in activity diagrams.

Swimlanes allow you to assign actions to specific system components.

For example:

This helps connect behavioral models to system architecture, ensuring that each function is performed by a defined subsystem.

---

Creating the System State Machine

After structural and behavioral models mature, the next step is often to create a system-level state machine.

A state machine typically:

• refines the System of Interest block

• defines the major system states

• orchestrates lower-level behaviors

The state machine often invokes activity diagrams to execute specific operational behaviors.

This creates a layered behavioral model where:

• the state machine controls system states

• activity diagrams perform detailed operations

---

Connecting Requirements to System Properties

As the system architecture evolves, stakeholder requirements become more detailed and technical.

At this stage, engineers begin linking requirements to value properties within the model.

Examples of value properties include:

• mass

• power consumption

• speed

• temperature

• battery capacity

These properties are usually defined within block definition diagrams.

---

Introducing Parametric Diagrams

Once value properties exist in the model, engineers can introduce constraint equations and parametric diagrams.

Parametric diagrams enable analytical modeling such as:

• mass rollups

• power rollups

• thermal calculations

• performance analysis

• vehicle speed calculations

For example, a mass rollup might calculate the total mass of a vehicle from the mass of each subsystem.

The results of these calculations can then be compared against system requirements to determine whether the design satisfies them.

---

Verifying Requirements Through Simulation

One of the most powerful aspects of MBSE is the ability to connect simulation results directly to requirements.

For example:

• calculated system mass → requirement limit

• power consumption → power budget requirement

• speed calculation → top speed requirement

If the simulation value exceeds the requirement threshold, the requirement can automatically be marked as failed.

This provides early insight into potential design issues.

---

Modeling Time-Dependent Behavior with Sequence Diagrams

Some system properties depend on time-based interactions.

Examples include:

• communication delays

• command-response timing

• network interactions

• asynchronous subsystem behavior

In these cases, sequence diagrams can be used to model the interaction timeline between components.

Constraints can then be applied to verify whether timing requirements are satisfied.

---

The Role of Package Diagrams

While package diagrams exist within SysML, they play a different role.

Package diagrams are mainly used for:

• model organization

• navigation

• grouping model elements

They are less important for system architecture modeling and are primarily used to keep the model organized.

Many engineers rely on the containment tree instead for navigating the model.

---

The Two Most Important SysML Diagrams

Although SysML contains many diagram types, two diagrams are especially useful as starting points.

Activity Diagrams

Best for:

• software systems

• operational workflows

• behavioral analysis

Block Definition Diagrams

Best for:

• hardware systems

• architecture decomposition

• subsystem structure

If you ever feel stuck deciding where to begin, these two diagrams are the safest places to start.

---

Practical SysML Modeling Workflow

A simplified modeling workflow might look like this:

1️⃣ Use Case Diagram
2️⃣ Requirement Diagram
3️⃣ Block Definition Diagram
4️⃣ Activity Diagrams
5️⃣ Internal Block Diagrams
6️⃣ State Machines
7️⃣ Parametric Diagrams
8️⃣ Sequence Diagrams

Each diagram builds on the previous ones, gradually increasing the fidelity of the system model.