Derived requirements missing from the trace and safety assessment

When this review is needed

• Implementation introduced behavior that no higher-level requirement asked for and it was never recorded as derived.
• There are derived requirements in design notes that never entered the controlled requirements set.
• The safety assessment was completed before late derived requirements appeared and was never revisited.
• The team wants every derived item identified, classified, and confirmed evaluated for safety effect.

The problem

Derived requirements arise from design and implementation rather than from a higher-level need, which is exactly why they slip the trace. They have no parent to hang from, so they get written into code, logic, or schematics and never captured as requirements in their own right. The standards expect derived requirements to be recorded and fed back to the safety assessment, because a requirement the safety process never saw is a behavior whose failure effect was never assessed. An untraced derived requirement is a decision the safety case does not know about.

What gets reviewed

• Design and implementation data examined for behavior with no parent requirement
• Whether each derived requirement is captured in the controlled requirements set
• Whether each captured derived requirement is explicitly flagged as derived
• Whether each derived requirement was provided to the safety assessment process
• Verification status of derived requirements once they are in the set
• Items introduced after the safety assessment was last run

What gets validated

• Behavior present in design with no parent is captured as a derived requirement
• Each derived requirement is recorded and labeled as derived in the controlled set
• Each derived requirement has been provided to the safety assessment for evaluation
• The safety assessment reflects derived requirements introduced after its last run
• Every derived requirement carries verification like any other requirement
• No design behavior exists that is neither a parent requirement nor a recorded derived one

Evidence normally required

• Design data: code, logic descriptions, schematics, and design notes
• The controlled requirements set and its trace
• The safety assessment and its inputs
• The change history that may have added derived items after the assessment

Common discrepancies

• Implemented behavior with no parent and no derived-requirement record
• A derived requirement captured but not flagged as derived
• A derived requirement in the set that the safety assessment never received
• Late derived items that postdate the last safety assessment run
• A derived requirement with no verification because it entered the set informally

What is at stake

A derived requirement outside the trace breaks two things at once: the verification cannot show it is met because it is not in the set, and the safety assessment cannot account for its failure effect because it never reached the process. When a reviewer finds derived behavior with no requirement and no safety treatment, the program reopens the trace and reruns part of the safety assessment late in the program.

How the work runs

What the buyer receives

• The list of derived requirements that sit outside the trace or the safety assessment
• For each, whether it needs capture, a derived flag, safety evaluation, or verification
• A note on design behavior that has no requirement of any kind behind it
• A closure order weighted by potential safety effect

Who uses the output

• Systems engineers capturing and classifying the derived requirements
• Safety engineers folding the missing items into the assessment
• Certification engineers restoring the trace and verification

How the work fits into the transaction or program

This pass targets the derived-requirement failure mode specifically. It connects to the wider trace and to the safety assessment, so it is often run alongside a verification-evidence check on the same requirements set.

Regulatory limits

Endeavor Elements checks whether the applicant's derived requirements are captured, traced, and fed to the safety process. It does not perform the safety assessment for the authority or guarantee acceptance of the resulting analysis.

What this review does not cover

• Conducting the safety assessment itself
• Authoring the derived requirements or their verification
• Issuing approvals or making official compliance findings

Specific to this review

• Derived requirements have no parent by definition, which is the structural reason they escape a trace built top-down from higher-level needs.
• An untraced derived requirement fails on two axes at once: it cannot be verified and its failure effect was never assessed.
• The feedback path to the safety assessment is the check most often missed, because capturing the requirement and evaluating its safety effect are separate steps.
• A safety assessment frozen before late design changes will not reflect derived requirements added afterward unless it is explicitly rerun.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits