What is it?

Backward traceability proves that every detailed requirement, design element, and test can be traced back to an approved higher-level safety requirement or to the underlying perceived safety need. It eliminates “orphans”—items that add complexity without contributing to safety goals. Together with forward traceability, it closes the loop from stakeholder needs to implementation and back.

How it supports functional safety

By ensuring every implemented element is justified by a valid parent, backward traceability prevents unintended features and configuration drift—typical sources of systematic failures. It also improves change impact analysis and strengthens the safety case by providing clear evidence that implementation and tests originate from accepted safety intent. (Tags: #SIL #ASIL #61508)

When to use

• When validating that detailed (software, hardware, or subsystem) requirements are justified by higher-level safety requirements or perceived safety needs.
• During design reviews to detect and remove unnecessary functions (“gold-plating”).
• When planning and executing verification, to ensure each test traces to a requirement and each requirement to a safety need.
• During change control, to confirm that proposed changes still trace back to approved needs.

Inputs & Outputs

Procedure

1. Inventory artifacts: List detailed requirements, design items, and test cases from all participating disciplines.
2. Identify parents: For each item, record the parent higher-level safety requirement or perceived safety need (with IDs).
3. Document links: Build a backward traceability matrix (spreadsheet or RM tool) capturing Item ID → Parent ID → Rationale.
4. Detect & resolve orphans: Report items without parents; either link them to a valid parent or remove/merge them.
5. Integrate with change control: Make the matrix a required input to reviews; re-run orphan reports after each change.

Worked Example

High-level

Perceived safety need: “Prevent overheating of the reactor core.”
System safety requirement (parent): “Core coolant temperature shall not exceed 200 °C.”

Backward traceability confirms that every derived item maps to the above intent. A simple matrix in Excel or a requirements tool (e.g., DOORS, Polarion, Jama) might look like this:

Code-level

# Backward-traceability annotation (comments only; not functional code)
# Item: Shutdown threshold requirement           ID: SW-88
# Parent: System safety requirement (coolant ≤200°C)   ID: SYS-10
# Originating perceived safety need: Prevent overheating

# SAFE REACTION: block change if SW-88 lacks a valid parent link (do not implement/or deploy)

Result: Every detailed item is justified; orphan items are detected and blocked until a valid parent link is established or the item is removed.

Quality criteria

• No floating requirements: every item has exactly one approved parent (or documented many-to-one with rationale).
• Unambiguous IDs: parent and child references use stable, unique identifiers.
• Reviewable rationale: each link includes a short justification tying intent to implementation/test.
• Freshness: trace links are updated promptly after changes; orphan reports show zero unresolved items.

Common pitfalls

• Vague parents (e.g., “general safety”). Mitigation: require explicit parent IDs and concise rationale.
• Matrix drift after changes. Mitigation: integrate orphan checks into CI/review gates; re-baseline after each change.
• Over-linking noise. Mitigation: prefer the minimal, sufficient parent; avoid redundant parallel links without justification.

Related techniques

• Forward traceability safety requirements — ensures each higher-level requirement is implemented downstream.
• Impact analysis — uses trace links to assess the effect of requirement changes.

References

• IEC 61508-7:2010, Annex C.2.11 — Traceability
• ISO 26262-8:2018 — Bi-directional traceability
• ISO/IEC/IEEE 29148:2018 — Requirements engineering

FAQ