Back

SYSMOD Problem/Space Zigzagging with SysML v2

The SYSMOD methodology includes the Zigzag Pattern, which describes the zigzagging between the problem space (what is needed) and the solution space (how it will be realized).

The following illustrates a basic framework of the problem-solution zigzag across several abstraction levels using SysML v2. It is only a pattern and will typically be implemented in different varieties in practice.


Base Architecture: Level 0 – The Foundation

The model begins by defining a generic system context (level0_systemContext) containing the system of interest (mySystem) and an external actor (myActor1). This serves as a basic architecture that sets out the architectural and technical decisions that are already fixed at the start of a project (for example, should a surveillance system, a surveillance drone, or a surveillance robot be developed?).

part def MyProject {
    part level0_systemContext {
        part mySystem;
        part myActor1;
    };

Level 1 – Problem Space

The first level of the problem space specializes (:>) the base system context. The system and the actors can be modified. Here, as an example, another actor myActor2 is added.

    part level1_problem_systemContext :> level0_systemContext {
        part myActor2;
    }

The system of the problem space on level 1 is the subject of the system requirements.

    requirement level1_system_requirements {
        subject mySystem :> level1_problem_systemContext.mySystem;
    }

A use case describes how actors interact with the system. It’s a classic requirement analysis artifact. The system is again the subject, and the actors from the context are potential actors of the use cases.

    use case myUseCase {
        subject mySystem :> level1_problem_systemContext.mySystem;
        actor myActor1 :> level1_problem_systemContext.myActor1;
        actor myActor2 :> level1_problem_systemContext.myActor2;
    }

Level 1 – Solution Space

Here begins the solution space. It specializes the problem-level context and further redefines mySystem by adding and redefining the parts. Also, solution-specific actors can be added. Here, the two parts subsystem1 and subsystem2 are added.

    part level1_solution_systemContext :> level1_problem_systemContext {
        part :>> mySystem {
            part subsystem1;
            part subsystem2;
        }

A satisfy link the solution mySystem to the requirement specification.

        satisfy level1_system_requirements 
           by level1_solution_systemContext.mySystem;

To complete the engineering loop, a verification statement ensures that the solution is verified and aligned with the requirements.

    verification level1_solution_verification {
        subject mySystem :> level1_solution_systemContext.mySystem;
        objective {
            verify level1_system_requirements;
        }
    }

Level 2 – Zigzagging Down: Subsystem 1

Problem Space for Subsystem 1

At the next level of granularity, the model “zigzags” back into the problem space, here focusing on subsystem1. New requirements for subsystem1 are defined at this subsystem level. This is where the pattern starts to repeat itself. The system is a specialization of the next higher level and is set as the subject of the requirements.

    part level2_problem_subsystem1 :>    
           level1_solution_systemContext.mySystem.subsystem1;
    requirement level2_subsystem1_requirements {
        subject mySubsystem1 :> level2_problem_subsystem1;
    }

Solution Space for Subsystem 1

Again, the problem space element is further developed in the solution space, maintaining direct traceability to the problem formulation.

    part level2_solution_subsystem1 :> level2_problem_subsystem1;

Here’s the full example:

//
// SYSMOD Problem Solution Zigzagging Example
//
// Copyright 2025 MBSE4U
//
part def MyProject {
  // Base Architecture
  part level0_systemContext {
    part mySystem;
    part myActor1;
  }

  //------------------------------
  // Level 1 - Problem Space
  part level1_problem_systemContext :> level0_systemContext {
    part myActor2;
  }
  requirement level1_system_requirements {
    subject mySystem :> level1_problem_systemContext.mySystem;
  }
  use case myUseCase {
    subject mySystem :> level1_problem_systemContext.mySystem;
    actor myActor1 :> level1_problem_systemContext.myActor1;
    actor myActor2 :> level1_problem_systemContext.myActor2;
  }

  // Level 1 - Solution Space
  part level1_solution_systemContext :> level1_problem_systemContext {
    part :>> mySystem {
      part subsystem1;
      part subsystem2;
    }
    satisfy level1_system_requirements by level1_solution_systemContext.mySystem;
  }
  verification level1_solution_verification {
    subject mySystem :> level1_solution_systemContext.mySystem;
    objective {
      verify level1_system_requirements;
    }
  }

  //------------------------------
  // Level 2 - Problem Space - Subsystem 1
  part level2_problem_subsystem1 :>     
    level1_solution_systemContext.mySystem.subsystem1;
  requirement level2_subsystem1_requirements {
    subject mySubsystem1 :> level2_problem_subsystem1;
  }
  // Level 2 - Solution Space - Subsystem 1
  part level2_solution_subsystem1 :> level2_problem_subsystem1;
}

Tim is a member of the executive board of the German consulting company oose, an MBSE consultant and trainer, and an active member of the OMG and INCOSE communities. He is a co-author of the SysML v1 specification, was co-chair of the task forces responsible for the last SysML v1 versions, and is actively involved in the ongoing work on SysML v2. He was co-chair of the task force responsible for the final submission of SysML v2, and is now co-chair of the SysML v2.1 revision task force (RTF). Tim is involved in numerous MBSE activities, and you can meet him at several conferences focused on MBSE and related topics.

As a consultant, he has advised many companies in different domains. His insights into their challenges are one source of his experience that he shares in books and presentations.