11.3 Refine, Trace & Containment Hierarchies

11.3 Refine, Trace & Containment Hierarchies

Quick Reference: While «deriveReqt», «satisfy», and «verify» form the core requirements-to-design backbone, SysML provides three additional mechanisms for structuring and contextualizing specifications: «refine» (where a behavioral model element elaborates what a requirement means), «trace» (a general-purpose, semantically unconstrained audit tracking link), and Containment (composite parent-child ownership rendered via a circle-plus (+) symbol or physical nesting).

---

1. The «refine» Relationship: Behavioral Clarification

Natural language requirements—no matter how meticulously drafted—suffer from inherent semantic ambiguity. A requirement stating "The automated teller machine shall authenticate customer credentials securely" does not describe the chronological exchange of PIN digits, biometric encryption tokens, or retry limit lockouts.

To eliminate ambiguity, systems engineers construct formal behavioral models (Use Cases, Activities, State Machines, or Sequence Diagrams). SysML connects these descriptive models to requirements using the «refine» dependency.

Metamodel Semantics and Visual Syntax

• Client (Tail): The refining model element (most commonly a Use Case, Activity, State Machine, Interaction, or SysML Model View).
• Supplier (Head): The requirement being refined.
• Arrowhead: A dashed line with an open arrowhead pointing from the refining model element to the requirement.

UseCase / Activity - - - «refine» - - - > Requirement

SysML 1.2 also permits the reverse use, where a text requirement refines a less detailed model element. Before reading a «refine» arrow, check which end is the requirement.

+---------------------------+                 +---------------------------+
|         «useCase»         |                 |       «requirement»       |
|    AuthenticateOperator   |-----«refine»--->|     OperatorSecurity      |
|                           |                 | id = "REQ-SEC-001"        |
+---------------------------+                 +---------------------------+

The Critical Distinction: «refine» vs. «satisfy»

Candidates frequently confuse «refine» and «satisfy». While both point from a model element to a requirement, their engineering purposes are fundamentally different:

• «refine» (Clarifying WHAT the requirement means): Connects a descriptive model (e.g., a Use Case, Activity flow, or State Machine) that elaborates, disambiguates, or formalizes the requirement's operational intent.
• «satisfy» (Asserting HOW the design realizes it): Connects a concrete architectural component (e.g., a physical Block, software module, or hardware part) that implements the requirement in the final system architecture.

---

2. The «trace» Relationship: General-Purpose Audit Tracking

A «trace» relationship is a standard, general-purpose dependency used to record a historical, auditable, or tracking connection between two model elements, at least one of which is typically a requirement.

Characteristics of «trace»

1. Weakest Semantic Relationship: «trace» imposes no behavioral constraints, no mathematical bindings, and no design realization obligations. It merely asserts: "An auditable relationship exists between these two model elements for tracking, history, or compliance auditing."
2. Client and Supplier: Drawn as a dashed line with an open arrowhead pointing from client to supplier (ElementA ----«trace»----> ElementB).
3. Broad Applicability: Used to link model requirements back to external regulatory documents, customer request-for-proposal (RFP) paragraphs, legacy specifications, or hazard analyses where a more specific relationship (such as «satisfy» or «deriveReqt») does not apply.

Exam Warning: Modeler candidates should not use «trace» as a lazy substitute when a semantically richer relationship is applicable. If a Block fulfills a requirement, use «satisfy». If a test validates a requirement, use «verify». If one requirement is deduced from another, use «deriveReqt». Reserve «trace» strictly for general historical or cross-reference auditing. SysML 1.2 itself recommends that trace "not be used in conjunction with the other requirements relationships."

---

3. Requirement Containment Hierarchies: Namespace Decomposition

Complex engineering systems frequently involve massive, multi-tiered compound requirements. For example, a high-level requirement EnvironmentalControl encompasses cabin temperature, cabin pressurization, oxygen replenishment, and humidity control.

SysML supports this compositional decomposition through Requirement Containment.

Ownership Semantics of Containment

Requirement containment is not a dependency relationship. It is a strict namespace ownership relationship governed by standard UML package/namespace containment rules:

• Single Owner: Every contained sub-requirement is owned by exactly one parent requirement namespace.
• Cascading Lifecycle: If the parent requirement is deleted from the model repository, all of its contained sub-requirements are automatically deleted with it.
• Namespace Qualified Name: Contained requirements reside inside the parent requirement's namespace path (e.g., SpacecraftReqs::EnvironmentalControl::CabinPressure).

Graphical Notations for Containment

SysML provides two alternative visual representations for requirement containment on a Requirement Diagram (req):

1. Circle-Plus Connector Notation

A solid line links the parent requirement to the child sub-requirement. At the end touching the parent (container) requirement, the line terminates in a circle enclosing a plus sign ((+)). No arrowhead is used.

+-----------------------+                 +-----------------------+
|     «requirement»     |                 |     «requirement»     |
| EnvironmentalControl  |(+)--------------|     CabinPressure     |
| id = "REQ-ENV-001"    |                 | id = "REQ-ENV-002"    |
+-----------------------+                 +-----------------------+

Exam Trap: The circle-plus (+) symbol must always touch the parent (enclosing) requirement. Placing the circle-plus at the child end is a syntactic violation frequently used as an incorrect answer choice on certification exams.

2. Physical Nesting (Box-in-Box Notation)

The child requirement box is drawn physically inside the boundary of the parent requirement box. This notation visually illustrates encapsulation without connecting lines, though it is practical only for small hierarchies.

+-------------------------------------------------------------+
|                        «requirement»                        |
|                    EnvironmentalControl                     |
| id = "REQ-ENV-001"                                          |
+-------------------------------------------------------------+
| +---------------------------------------------------------+ |
| |                      «requirement»                      | |
| |                      CabinPressure                      | |
| | id = "REQ-ENV-002"                                      | |
| +---------------------------------------------------------+ |
+-------------------------------------------------------------+

---

Containment vs. «deriveReqt»: The Crucial Distinction

A central topic on the OCSMP Model User exam is distinguishing between Containment and «deriveReqt»:

---

The Complete 6-Way Requirement Relationship Comparison Matrix

---

Worked Example: Comprehensive Requirements Model

Consider an automated baggage handling airport system:

1. «requirement» BaggageHandlingSystem (Top-Level Container)
   • Contains via (+): BagRouting and BagTracking.
2. «requirement» BagRouting
   • Refined by («refine»): Use Case RouteLuggageToFlight.
   • Derived to («deriveReqt»): ConveyorMotorSpeed (Subsystem Requirement).
3. «requirement» ConveyorMotorSpeed
   • Satisfied by («satisfy»): Block ElectricRollerConveyor.
   • Verified by («verify»): Activity ConveyorTachometerTest stereotyped as «testCase».
4. «requirement» BaggageHandlingSystem
   • Traced to («trace»): External document FAA-Airport-Safety-Standard-402.

This integrated scenario demonstrates the clean separation of concerns among all six requirement relationships.

---

Exam Pitfalls & Misconceptions