Link roles define how work items in the Aerospace Safety Solution connect to form traceability chains across requirements, safety analysis, design, testing, and change management.
Requirements traceability links form the backbone of the V-Model, connecting customer specifications through system and design levels to verification test cases.
Creates same-type hierarchy within a requirement level
Valid Source Types
customerRequirement, sysReq, desReq, heading
Valid Target Types
customerRequirement, sysReq, desReq, heading
Cardinality
One parent, many children
Use Case
Organize requirements into outline structure (e.g., parent requirement with sub-requirements)
Notes: The parent role enforces same-type hierarchy. A customerRequirement can only have a customerRequirement parent (or heading for organizational structure). This differs from the refines role, which crosses requirement levels.
Decomposes a requirement into a lower-level requirement
Valid Source Types
sysReq, desReq, characteristic
Valid Target Types
desReq, sysReq, customerRequirement
Cardinality
Many children refining one parent
Bidirectional
Yes — both forward (sysReq refines into desReq) and reverse (characteristic refines sysReq)
Notes: The refines role is the primary decomposition link across requirement levels. A system requirement refines a customer requirement. A design requirement refines a system requirement. A characteristic refines a design requirement. This creates the 4-level decomposition chain: customerRequirement → sysReq → desReq → characteristic.Example: System Requirement SR-001 “System shall provide real-time monitoring” refines Customer Requirement CR-001 “Monitoring system shall meet user expectations.”
Links a design/implementation item to the requirement it fulfills
Valid Source Types
task, riskControl
Valid Target Types
sysReq, desReq, riskControl
Cardinality
Multiple implementations per requirement
Common Pattern
Task or Risk Control → Design Requirement
Notes: Use implements to show how a mitigation task or risk control addresses a safety or design requirement. This is distinct from refines — implements represents actual design/code artifacts, while refines represents requirement-level decomposition.
Notes: Test cases verify technical requirements (system, design) and validate customer requirements. The verifies link is essential for traceability matrix reports showing which tests cover which requirements. A single test case may verify multiple requirements; conversely, a single requirement may be verified by multiple test cases.Example: Test Case TC-DES-001 “Verify real-time update latency < 100ms” verifies Design Requirement DR-001 “Real-time monitoring shall update at least every 100ms.”
Safety assessment links connect failure analysis (FHA, FMEA) to system elements, functions, and risk controls, forming the foundation of ARP 4761 hazard analysis.
Notes: The assesses link is the most versatile in the system, enabling failure modes, failure conditions, and security threats to be analyzed against both functions (for functional analysis) and system elements (for component analysis). This supports both SFMEA (system-level) and DFMEA (component-level) workflows.Example: Failure Mode FM-001 “Sensor processing timeout” assesses Function F-001 “Acquire sensor data.”
Links a failure mode to the failure condition it contributes to
Valid Source Types
failureMode
Valid Target Types
failureCondition
Cardinality
Multiple failure modes contribute to one failure condition
Cross-Analysis Bridge
Connects FMEA (bottom-up) to FHA (top-down)
Notes: The causeOf link bridges FMEA and FHA analysis. A failure mode is the root cause of a failure condition. Multiple failure modes may contribute to a single failure condition (e.g., three different component failures leading to the same safety condition). This link is critical for traceability between top-down hazard analysis and bottom-up fault tree analysis.Example: Failure Mode FM-001 “Power supply voltage drops” is causeOf Failure Condition FC-001 “Loss of primary power.”
Links a risk control to the failure or risk record it mitigates
Valid Source Types
riskControl, task
Valid Target Types
riskRecord, failureMode
Cardinality
Multiple controls per risk; multiple risks per control
Post-Mitigation
Connected items contribute to residual risk (post-mitigation RPN)
Notes: Every failure mode or risk record should be addressed by at least one mitigation control. The mitigates link is used to calculate post-mitigation RPN values. Risk controls include Inherent Safety improvements, Protective Devices, and Information for Safety measures (per DO-178C).Example: Risk Control RC-001 “Redundant power supply monitor” mitigates Failure Mode FM-001 “Power supply voltage drops.”
Links a failure mode to downstream failure modes in the FMEA hierarchy
Valid Source Types
failureMode
Valid Target Types
failureMode
Cardinality
One failure mode may cause multiple downstream modes
Direction
Upstream FMEA → Downstream FMEA
Notes: The causes link enables vertical traceability in FMEA workflows. A failure mode in a system-level SFMEA may cause failure modes in a subsystem SFMEA, which in turn cause component-level DFMEA failure modes. This creates a failure propagation chain essential for understanding how component failures escalate to system-level failures.Example: System-level Failure Mode FM-SYS-001 “Processing unit failure” causes Subsystem Failure Mode FM-SUB-001 “Data validation error,” which causes Component Failure Mode FM-COMP-001 “Memory corruption.”
One change request may track multiple affected items
Broadest Coverage
Highest-cardinality single link role in the system
Notes: The tracks link is the primary change impact traceability mechanism. When a design change is proposed, link it to all affected requirements, risk items, and tasks. This enables impact analysis reports showing which work items would be affected by a proposed change. A single change request typically tracks 5–10+ work items.Example: Change Request CHG-001 “Increase sensor update frequency” tracks System Requirement SR-002, Design Requirement DR-005, Failure Mode FM-010, and Task TSK-023.
Links a follow-up task to the defect, issue, or previous task it addresses
Valid Source Types
task
Valid Target Types
defect, task, changeRequest
Cardinality
One task may follow up on multiple items
Workflow Pattern
Defect resolution and action item tracking
Notes: Use followsUp to create chains of related tasks and defects. For example, a defect detected during testing may generate a follow-up task to implement a fix, which may in turn be tracked by a follow-up code review task. This creates an audit trail of resolution activities.
Enables defect-detection-rate analysis per test case
Notes: The detectedBy link creates traceability from discovered defects back to the test activities that uncovered them. This metric is useful for evaluating test effectiveness and planning test expansion. It also supports DO-178C §6.4.1 (test coverage evaluation) and DO-254 §8.3.1 (design verification).
Assigns a function, failure mode, or requirement to a specific system element
Valid Source Types
function, failureMode, riskRecord, processStep
Valid Target Types
systemElement
Cardinality
Multiple items per system element; typically one allocation per item
System Decomposition
Critical for per-component analysis views and reports
Notes: The allocatedTo link is essential for system decomposition views. By allocating functions, failure modes, and requirements to specific system elements (subsystems, components, LRUs), you enable filtering and analysis at any level of the system hierarchy. The Risksheet DFMEA template uses this link to organize failure modes by component.Example: Function F-001 “Acquire sensor data” allocatedTo System Element SE-001 “Sensor Module”; Failure Mode FM-001 “Sensor timeout” allocatedTo System Element SE-001.
Unidirectional (test case to customer requirement)
Purpose
Links a validation test case to the customer requirement it validates
Valid Source Types
testCase
Valid Target Types
customerRequirement
Cardinality
Multiple test cases may validate one requirement
V-Model Right Side
Validation arm of the V-Model (customer satisfaction)
Notes: The validates link differs from verifies — validation test cases confirm that the system meets customer expectations (customer requirements), while verification test cases confirm that the system meets technical specifications (system and design requirements). This distinction is important for traceability matrix reports and DAL allocation decisions.Example: Validation Test Case VTC-001 “User acceptance test: monitoring dashboard displays real-time data” validates Customer Requirement CR-001 “System shall provide real-time visibility.”
The Aerospace Safety Solution provides automated traceability coverage reports that measure:
Requirements Decomposition Coverage: What % of customer requirements decompose to system requirements? What % of system requirements decompose to design requirements?
Verification Coverage: What % of design requirements are verified by test cases?
Allocation Coverage: What % of requirements are allocated to system elements?
Mitigation Coverage: What % of failure modes have associated risk controls?
These reports use the link roles (refines, verifies, allocatedTo, mitigates) to count forward and backward link coverage. A requirement with no forward links (no verification) or no backward links (not traced to higher level) indicates a gap.
