What is it?

Forward traceability links each higher-level safety requirement to corresponding lower-level requirements and further lifecycle artifacts (design, implementation, and verification). The aim is to ensure that no requirement is lost or ignored when the system is decomposed into subsystems, hardware, or software. While this KB focuses mainly on software safety requirements, the same principle applies equally to hardware safety requirements.

How it supports functional safety

Forward traceability directly addresses systematic failures by enforcing consistency across lifecycle stages. If a top-level safety requirement is missed in lower-level specifications, the system may behave unpredictably even if components function correctly. Traceability ensures that each requirement is implemented and tested, preventing silent erosion of safety intent.

#SIL #ASIL #61508

When to use

• When deriving low-level requirements from top-level safety requirements.
  Example: When software safety requirements are derived from system-level safety requirements.
• During hardware or software design phases to ensure downstream alignment.
• Before verification and validation planning, to guarantee test coverage of every requirement.

Inputs & Outputs

Procedure

1. Collect and review higher-level safety requirements.
2. Decompose them into lower-level hardware or software safety requirements.
3. Establish and document trace links in a matrix or dedicated tool.
4. Extend links into design elements, implementation artifacts, and test specifications.
5. Review trace links during change control and lifecycle reviews.

Worked Example

High-level

A train control system has a top-level safety requirement: “The train shall stop within 500 m after an emergency brake command.” This requirement is decomposed into:

• Software requirement: “Emergency braking logic shall command maximum braking if remaining distance < 500 m.”
• Test requirement: “Emergency braking tests shall demonstrate stopping distance ≤ 500 m in simulations.”

In Excel or a requirements management tool (e.g., DOORS, Polarion, Jama), traceability is captured as:

Code-level

/* Implements Requirement R-1003
   Derived from System Requirement R-312 (Spec ABC)
   SAFE REACTION: apply maximum braking */

Result: The traceability link shows exactly how the high-level requirement is implemented, tested, and maintained.

Quality criteria

• Every high-level requirement has at least one lower-level requirement linked.
• No floating requirements (requirements without a parent).
• Links are kept current as requirements evolve.
• Verification evidence demonstrates complete coverage.

Common pitfalls

• Pitfall: Trace links created mechanically without reviewing meaning.
  Mitigation: Regularly review the rationale for each link.
• Pitfall: Requirements without parents or without children (orphans/floating).
  Mitigation: Use traceability reports to detect and resolve gaps.

Related techniques

• Backward traceability — ensures each design or test element is justified by a higher-level requirement.
• Impact analysis — uses trace links to assess the effect of requirement changes.

References

• IEC 61508-7:2010, Annex C.2.11 Traceability
• Hull, Jackson, Dick. Requirements Engineering, Springer, 2005
• ISO 26262-8:2018, Clause 6 — Bi-directional traceability

FAQ