Derived Requirements Need More Than a Parent Link

The parent requirement has not changed. The architecture has. Half your derived requirements may now be wrong, while the traceability report still looks healthy.

That is the trap: treating decomposition as a document exercise rather than an engineering argument.

Decomposition is not derivation

Decomposition breaks a higher-level obligation into requirements that can be allocated and verified. Derivation introduces requirements needed because of the chosen architecture, operating conditions, interfaces or analysis.

They often happen together. They are not interchangeable.

Suppose an aircraft function must detect a hazardous condition and command a response within a specified time. Decomposition allocates that response-time budget across sensing, processing and command transmission.

Choosing a shared data bus may then introduce requirements for message age, time synchronisation and behaviour following communication loss. Those are consequences of the design choice. Linking them to the response-time requirement does not explain why they exist.

Capture the argument, not just the link

For each derived requirement, record enough context for another engineer to challenge it:

• Source: the analysis, interface decision, hazard assessment or constraint that created it.
• Rationale: why the requirement is necessary and which assumptions support it.
• Allocation: who owns implementation and which interfaces are affected.
• Verification: how compliance will be demonstrated, including relevant conditions and tolerances.

Keep rationale separate from normative wording. A clear requirement should state the obligation; supporting records should explain its origin.

Where safety or certification processes require it, feed derived requirements back into the appropriate assessment and approval activities. A subsystem decision can create a system-level hazard or invalidate a safety-case assumption.

Check the set, not just each sentence

Individually testable requirements can still form an incomplete decomposition.

Check that allocated budgets close. Include transport delays, scheduling effects and margins. Confirm that interface responsibilities meet without gaps. Examine degraded modes and transitions, not just steady-state operation.

Then ask the harder question: if every child requirement passes its verification, what evidence shows that the parent is satisfied? Lower-level results may need integration testing and analysis before that claim holds.

When architecture changes, review the originating decisions and assumptions as well as parent–child links. Otherwise, obsolete requirements survive while newly necessary ones never appear. That is where change impact and V&V planning drift apart.

Engineer-approved AI in Kelvora can help surface missing rationale, suspect allocations and change-impact candidates for review.