Technical Requirements and Traceability: Connecting the Dots Across the V-Model

Introduction: Beyond writing good requirements

Technical requirements form the foundation of successful system development, no matter the industry. The rules are well known – a good requirement should be clear, unambiguous, necessary, feasible, and verifiable. Ideally, it expresses one specific obligation, defines measurable acceptance criteria, and has a unique identifier.

However, even a perfectly written requirement has limited value if its origin, implementation, and verification cannot be established. This is where traceability becomes essential.

Within the V-Model, traceability connects stakeholder needs to system requirements, design decisions, implementation, and verification evidence. It ensures that requirements are not merely documented, but systematically carried through the development lifecycle. In safety-related engineering processes, this connection is particularly important: confidence in a system depends not only on its design, but also on whether its intended functions and safety objectives can be demonstrated. Without traceability, engineers may demonstrate that individual components work without proving that the overall system fulfils the original operational need.

Table 1: Requirements traceability in the V-model.

Source: Created by Lorit Consultancy with the assistance of AI.

Parent and child requirements: How many are appropriate?

A central aspect of traceability is the relationship between parent and child requirements. A parent requirement expresses an obligation at a higher level; its children define more detailed obligations that contribute to fulfilling it.

Neither the V-Model nor the general principles of requirements engineering impose a fixed one-to-one relationship. The appropriate number of parent or child requirements depends on system complexity, architecture, functional boundaries, and the need for independent verification.

Common parent-child requirement structures

A requirement can have:

• One parent: A common and straightforward arrangement when the requirement clearly belongs to a single higher-level objective.

• Multiple parents: Appropriate when a requirement genuinely contributes to several higher-level requirements. Each relationship must be justified, and potential duplication or conflicting obligations should be assessed.

• No parent: Acceptable for top-level stakeholder or system requirements, and sometimes for independently imposed constraints, provided their origin and rationale are documented.

• No children: Acceptable for a requirement that is already sufficiently detailed, belongs at the lowest relevant specification level, or does not need further decomposition.

Quality Over Quantity in Requirement Decomposition

The number itself is not a quality criterion. What matters is whether the children collectively address the parent’s intent without introducing unnecessary detail, gaps, or contradictions. Decomposition should stop when further splitting no longer improves clarity, allocation, or verification. Collectively, the children should cover the required behaviour, interfaces, constraints, and relevant operating conditions, preserving the parent’s intent. A set of individually verifiable children can still be incomplete if an important aspect of the parent has been omitted.

Table 2: Parent and child requirements

Source: Created by Lorit Consultancy with the assistance of AI.

Decomposed requirements versus derived requirements

In practice, organizations should define these terms in their requirements management process, because terminology can vary between industries and standards.

What are decomposed requirements?

Decomposed requirements result from breaking down a higher-level requirement into more detailed requirements. They explain how the original obligation is distributed across functions, subsystems, or components.

What are derived requirements?

Derived requirements are unavoidable in complex systems. Stakeholders describe what they need from a system, but they cannot specify every technical constraint, internal interface, failure response, or implementation condition necessary to achieve it. Engineers must identify these additional obligations through engineering analysis, architecture decisions, interface analysis, safety analysis, consideration of the operating environment etc., as the architecture and design develop. That is how the derived requirements are created.

A derived requirement can itself have child requirements, i.e. be decomposed.

Table 3: Examples of decomposed and derived requirements.

Source: Created by Lorit Consultancy with the assistance of AI.

Every derived requirement needs a documented technical rationale. Engineers should identify the analysis, assumption, constraint, or design decision that led to it and assess whether it is necessary, consistent with higher-level objectives, and compatible with other requirements.

Where appropriate, derived requirements should also be reviewed with the relevant system stakeholders and safety or design authorities, as to not silently weaken an existing safety obligation or introduce an unassessed failure mode. They can affect cost, complexity, certification scope, system behaviour, and the allocation of responsibilities between suppliers.

Table 3: Examples of decomposed and derived requirements.

Source: Created by Lorit Consultancy with the assistance of AI.