Connecting the Dots: How SysML Links Requirements to Real Designs

by

You wouldn’t build a house without blueprints, so why develop a system without mapping how each piece fulfills its purpose? In SysML, Satisfy and Derive relationships are the glue that binds requirements to actual system components—ensuring nothing gets lost in translation.

Let’s cut through the jargon and explore how these relationships work in practice, using relatable examples (no theoretical washing machines here).

1. Requirements: More Than Just a Wishlist

SysML treats requirements as active model elements—not static text. Each requirement has:

  • A unique tag (e.g., SAF-101)
  • A clear statement (e.g., “The drone must avoid obstacles within 5 meters”)
  • Metadata (priority, owner, verification status).

Why this matters: Ever seen a requirement like “The system shall be secure” with no clue how to implement it? SysML forces specificity.

2. The “Satisfy” Relationship: Proving Your Design Delivers

What it does: Links a requirement to the exact component or function that makes it happen.

Real-world analogy:

  • Requirement: “The coffee machine must brew in under 30 seconds.”
  • Satisfied by: The High-Pressure Pump block in your design.

Visualized in SysML:

[Requirement: FAST_BREW] — (satisfied by) –> [Block: Pump_Assembly] 

Key benefits:

  • No ghost requirements: If no block satisfies a requirement, it’s a red flag.
  • Change impact analysis: Modify the pump? The model instantly shows which requirements are affected.

Industry example:

In a medical ventilator, the requirement “Deliver 600 mL tidal volume” must be satisfied by both the Airflow Controller (hardware) and the Volume Calibration algorithm (software). The Satisfy relationship ensures neither team misses their role.

3. The “Derive” Relationship: Breaking Down Big Problems

What it solves: Vague, high-level requirements like “The car shall be safe” are useless to engineers. Derive relationships split these into actionable specs.

How it works:

  1. Start with a parent requirement:
    • “The smartwatch shall monitor health vitals.”
  2. Derive child requirements:
    • “Heart rate accuracy: ±2 BPM”
    • “SpO2 alerts if <90% for 5 minutes”

Visualized:

[HEALTH_MONITOR] → [HR_ACCURACY] | [SPO2_ALERTS]

Why engineers love this:

  • Prevents scope creep: If a derived requirement (like “Track sleep phases”) isn’t traced back to the parent, it doesn’t belong.
  • Simplifies validation: Test teams verify each derived requirement individually.

Case study:
An electric bike system starts with “Range: 100 km per charge.” Derived requirements might include:

  • “Battery capacity ≥750 Wh”
  • “Regenerative braking recovers ≥15% energy”
    Each sub-requirement ties to specific components (battery pack, motor controller).

4. Combining Both Relationships: Traceability in Action

The power move: Use Derive to split requirements, then Satisfy to link them to design elements.

Example for a food delivery robot:

  1. Top-level requirement:
    • “Maintain food at ≥60°C during transport.”
  2. Derived requirements:
    • *”Insulated compartment with 0.5°C/min heat loss max”*
    • “Heater reaches 60°C within 3 minutes of activation”
  3. Satisfied by:
    • Insulation material (block: Thermal_Liner)
    • Heating coil (block: Ceramic_Heater)

Result: Full traceability from customer need → engineering specs → physical parts.

5. Pro Tips for Effective Modeling

  1. Use tool shortcuts:
    • In Cameo or MagicDraw, right-click a requirement → “Show Related Elements” to instantly see all Satisfy/Derive links.
  2. Validate as you go:
    • Run a traceability report weekly. Any requirement without Satisfy links is either:
      • Not yet designed (schedule risk)
      • Unnecessary (scope creep)
  3. Handle changes gracefully:
    • If a derived requirement changes (e.g., “SpO2 alerts if <92%”), the model highlights all affected tests and components.

When These Relationships Save Projects

  • Aerospace: Deriving “Withstand 5G forces” into specific wing and fuselage specs.
  • IoT: Proving a *”10-year battery life”* requirement is satisfied by the power management IC.
  • Medical: Tracing “Sterile operation” requirements down to autoclave-resistant materials.

Final Thought

SysML’s Satisfy and Derive relationships turn requirements from a compliance checkbox into a dynamic design compass. They answer two critical questions:

  1. “How does this bolt/sensor/algorithm contribute to the big picture?”
  2. “Can we prove it?”

Try this today: Pick one high-level requirement in your project. Can you:

  • Derive at least three sub-requirements?
  • Name the components that satisfy each?

Leave a Comment