11.2 Key Relationships: Derive, Satisfy & Verify

11.2 Key Relationships: Derive, Satisfy & Verify

Quick Reference: All SysML requirement relationships are specialized UML dependencies rendered as dashed lines with open arrowheads. Under the universal UML dependency convention, the arrow points from the Client (the dependent element) to the Supplier (the independent target). Therefore: «deriveReqt» points from Derived Requirement to Source Requirement; «satisfy» points from Design Element (Block/Action) to Requirement; and «verify» points from Verification Construct (TestCase) to Requirement.

---

The Dependency Foundation of Requirement Relationships

In SysML, traceability between requirements and other model elements is established using specialized forms of Dependencies. In the Unified Modeling Language (UML) metamodel upon which SysML is based, a Dependency represents a supplier-client relationship where the semantics or implementation of the client element depends upon or references the supplier element.

The Universal Dependency Notation Rule

Client [Source of Arrow] - - - «stereotype» - - - > Supplier [Target of Arrow]

• Client: The model element at the tail of the dashed arrow. This is the entity that derives, satisfies, verifies, or refines.
• Supplier: The model element at the arrowhead of the dashed arrow. This is the requirement being derived from, satisfied, verified, or refined.

The Golden Rule for SysML Requirement Arrows: When connecting a design element, test case, or derived requirement to an existing requirement, the arrowhead always points TO the requirement.

This rule is the single most heavily tested syntactic rule on the OCSMP Model User exam. In everyday informal conversation, engineers often say: "This requirement derives ten lower-level requirements" or "This requirement is satisfied by the hydraulic pump." However, in formal SysML graphical syntax, the arrow direction is the exact opposite of that colloquial phrasing: it always points towards the requirement being fulfilled or derived from.

---

1. The «deriveReqt» (Derive Requirement) Relationship

A «deriveReqt» (Derive Requirement) relationship represents a dependency between two requirements at different levels of architectural abstraction. It signifies that a lower-level requirement is derived from, deduced from, or necessitated by a higher-level requirement.

Directed Semantics and Metamodel Rules

• Client (Tail): The derived requirement (the more detailed, lower-level, or subsystem requirement).
• Supplier (Head): The source requirement (the higher-level, system-level, or stakeholder requirement).
• Arrowhead: Open arrowhead on a dashed line pointing from derived requirement to source requirement.

SubsystemRequirement - - - «deriveReqt» - - - > SystemRequirement

+---------------------------+                 +---------------------------+
|       «requirement»       |                 |       «requirement»       |
|     MotorCurrentDraw      |---«deriveReqt»->|      VehicleMaxRange      |
| id = "REQ-MTR-002"        |                 | id = "REQ-SYS-001"        |
+---------------------------+                 +---------------------------+

Why Derivation Occurs in Systems Engineering

Requirements do not emerge fully detailed from initial customer stakeholder requests. High-level customer needs (e.g., "The vehicle shall travel 400 km on a single charge") must be translated through systems engineering analysis into subsystem technical specifications. When engineers select an electric powertrain architecture, that architectural decision immediately creates new requirements for battery capacity, inverter switching efficiency, and motor current draw.

Because these subsystem requirements did not exist in the customer's original specification but are logically deduced through engineering synthesis, they are connected to the parent requirement via «deriveReqt».

---

2. The «satisfy» Relationship

A «satisfy» relationship is a directed dependency asserting that a structural or behavioral design element fulfills, realizes, or accomplishes the condition specified by a requirement.

Directed Semantics and Metamodel Rules

• Client (Tail): The design element fulfilling the requirement. This can be a structural Block, a Part Property, an Activity, an Action, or a State Machine.
• Supplier (Head): The requirement being satisfied.
• Arrowhead: Open arrowhead on a dashed line pointing from the design element to the requirement.

DesignBlock - - - «satisfy» - - - > Requirement

+---------------------------+                 +---------------------------+
|          «block»          |                 |       «requirement»       |
|       HydraulicPump       |----«satisfy»--->|      FluidFlowRate        |
|                           |                 | id = "REQ-HYD-005"        |
+---------------------------+                 +---------------------------+

What Model Elements Can Satisfy a Requirement?

1. Structural Blocks: A physical or logical component (e.g., HydraulicPump, FlightComputer) satisfies a requirement by providing the necessary physical capacity, power, or architecture.
2. Part Usages: A specific role or part property in an internal block diagram (e.g., primaryInverter: Inverter) satisfies a subsystem requirement.
3. Behavioral Elements: An Activity, Action, or State Machine satisfies a functional requirement by executing the required operational steps or event responses.

Alternative Compartment Notation for «satisfy»

In complex architecture diagrams containing hundreds of blocks, drawing individual dashed arrows across the canvas can create severe visual clutter. SysML provides two equivalent shorthand notations:

1. satisfies Compartment in a Block: A Block box can display a dedicated compartment named satisfies, listing the names or IDs of the requirements it fulfills.
2. Callout Notation: A note attached to the satisfying block that reads Satisfies followed by «requirement» RequirementName; a note attached to the requirement can read SatisfiedBy and name the design element.

+---------------------------+
|          «block»          |
|       HydraulicPump       |
+---------------------------+
| satisfies                 |
|   REQ-HYD-005             |
|   REQ-HYD-012             |
+---------------------------+

Exam Trap: «satisfy» represents an engineering assertion, not proof of compliance! Asserting that HydraulicPump satisfies FluidFlowRate in an architecture diagram does not prove that the manufactured pump actually works. Proof of compliance belongs exclusively to the «verify» relationship.

---

3. The «verify» Relationship and the «testCase» Construct

A «verify» relationship is a directed dependency establishing that a specific verification construct proves, demonstrates, or validates that a requirement has been met.

Directed Semantics and Metamodel Rules

• Client (Tail): The verification construct, typically a model element stereotyped with «testCase»; SysML 1.2 allows a test case "or other named element."
• Supplier (Head): The requirement being verified.
• Arrowhead: Open arrowhead on a dashed line pointing from the verification construct to the requirement.

TestCase - - - «verify» - - - > Requirement

+---------------------------+                 +---------------------------+
|        «testCase»         |                 |       «requirement»       |
|     PumpPressureTest      |----«verify»---->|      FluidFlowRate        |
| verdict: VerdictKind      |                 | id = "REQ-HYD-005"        |
+---------------------------+                 +---------------------------+

The «testCase» Construct in SysML

In SysML, a Test Case is not merely a textual test procedure. A «testCase» is a formal behavioral classifier (most commonly an Activity, Interaction / Sequence Diagram, or State Machine) that specifies the exact algorithmic sequence of stimuli, assertions, and measurements used to evaluate system compliance.

SysML 1.2 applies the TestCase stereotype to a behavior or an operation and requires its return parameter to be of type VerdictKind, which has these values:

• pass: The observed system behavior met all acceptance criteria defined in the requirement.
• fail: The observed behavior violated one or more acceptance criteria.
• inconclusive: The test executed, but observations were insufficient to determine compliance.
• error: The test infrastructure or execution environment failed before completing the assessment.

The Four Canonical Verification Methods

The Annex C example profile records the planned method in a verifyMethod property. The four classic systems engineering methods are:

1. Test: Quantitative operational measurement using instrumented equipment under controlled environmental conditions (e.g., measuring pressure with calibrated transducers).
2. Demonstration: Qualitative operational observation of functional performance without precision instrumentation (e.g., observing that an emergency hatch opens when the handle is pulled).
3. Analysis: Mathematical modeling, simulation, trade studies, or physics calculations (e.g., finite element thermal stress analysis).
4. Inspection: Visual examination of physical artifacts, engineering drawings, code syntax, or certification records without operating the system.

---

Systematic Comparison: DeriveReqt vs. Satisfy vs. Verify

---

Worked Example: End-to-End Requirement Traceability Thread

Consider an aerospace satellite thermal control subsystem:

1. Top-Level Requirement: REQ-SYS-001 (MissionLife) — "The satellite shall operate in low-Earth orbit for at least 5 years."
2. Derived Requirement: REQ-THM-014 (BatteryTemp) — "Battery cell temperatures shall be maintained between 0°C and 25°C throughout eclipse phases."
   • Relationship: BatteryTemp ----«deriveReqt»----> MissionLife
3. Satisfying Architecture: Block ThermalRadiator with embedded resistive patch heaters.
   • Relationship: ThermalRadiator ----«satisfy»----> BatteryTemp
4. Verifying Behavior: Activity ThermalVacuumTest stereotyped with «testCase».
   • Relationship: ThermalVacuumTest ----«verify»----> BatteryTemp

This end-to-end thread demonstrates total bidirectional traceability from high-level stakeholder expectation to detailed subsystem requirement, physical design implementation, and formal laboratory qualification.

---

Exam Pitfalls & Misconceptions