Skip to main content

​
The Core Idea: Two Sides of One V

The V-model gets its name from its shape. The left side descends through decomposition: customer needs break down into system requirements, which decompose into subsystem requirements, then into design requirements. The right side ascends through verification: test cases confirm each requirement was correctly implemented. The bottom of the V is where design meets reality. What makes aerospace V-model traceability distinct from a simple requirement hierarchy is the bidirectional obligation: every requirement must trace down to something more specific, and every requirement must trace up to something that proves it was met. A requirement with no test case is a gap. A test case with no requirement is an orphan. Both are compliance findings. diagram

​
The Four Decomposition Levels

Customer Requirements sit at the top. These capture what the aircraft operator or certification authority needs — in ARP 4754A terms, they represent the aircraft-level functions and safety objectives. They carry SC/CC (Safety Critical / Critical Characteristic) classification inherited from FHA failure condition severity. Customer requirements are validated by test cases: validation answers the question “did we build the right thing?” System Requirements refine customer requirements via the refines link role. This is where engineering decisions are made explicit — a single customer requirement typically decomposes into several system requirements that specify how the system will satisfy the need. System requirements are verified by test cases at the system level. Subsystem Requirements add a third decomposition tier, reflecting the reality that avionics systems contain subsystems (processing units, sensor arrays, power management modules) that have their own specifications. Internally, subsystem requirements share the sysReq work item type with system requirements but are constrained to subsystemRequirementsSpecification document types — the document context is what determines the level. Design Requirements are the leaf nodes of the decomposition. They carry a subType field (system, software, or hardware) that enables DO-178C versus DO-254 filtering — the same requirement type serves both software and hardware design assurance disciplines. Design requirements are refined further into Characteristics, which are the measurable implementation properties that test cases directly verify.

​
Verification vs. Validation: A Critical Distinction

“Verification” and “validation” are not interchangeable in this context. Using the wrong link role (verifies vs validates) produces incorrect coverage metrics in dashboards and may create compliance gaps in certification submissions.
Validation (validates link) applies to Customer Requirements. It answers: does this system satisfy the user’s actual needs? Validation test cases are executed against the complete system. Verification (verifies link) applies to System, Subsystem, and Design Requirements. It answers: does this implementation conform to the specified requirement? Verification may be performed at each level independently. The distinction matters for DO-178C Table A-7 compliance: the Software Verification Matrix must demonstrate bidirectional traceability between system-level requirements and design-level requirements with test cases at both levels.

​
SC/CC Classification Flows Down — and Must Stay Consistent

Safety Critical (SC) and Critical Characteristic (CC) classifications assigned at the Customer Requirement level must propagate through every level of decomposition. The ARP 4754A compliance rule is strict: an SC customer requirement cannot decompose into a non-SC system requirement. The Classification Consistency Report exists specifically to detect this type of drift. This constraint exists because DAL allocation depends on it. If a failure condition classified as Hazardous at the FHA level flows down through customer and system requirements, every derived design requirement must carry the same criticality — otherwise the DAL allocated to the implementing software or hardware component will be lower than the safety objective demands.

​
How the RTM PowerSheet Unifies the Chain

The Whole RTM PowerSheet is the primary tool for visualising the full chain in context. Its four color-coded column groups (green for Customer, purple for System, teal for Subsystem, blue for Design) correspond directly to the four decomposition levels. The hierarchical expand chain — chapter → system requirements → subsystem requirements → design requirements, each with associated test cases — reflects the same refines link structure described above. The nxLinkCoverage() macro powering the Requirements Traceability Summary dashboard computes decomposition and verification percentages for each level: what fraction of customer requirements have been refined into system requirements, what fraction of design requirements have associated test cases. These are the gaps that certification auditors examine.
The RTM “Summary” view strips detail columns to provide a dashboard-like overview. Use it for program reviews. Use the full view when investigating specific gaps or preparing for audit.

​
The Safety Chain Intersects the Requirements Chain

The traceability chain does not exist in isolation from safety analysis. Risk Controls (SFMEA, DFMEA outputs) link to requirements via implements — a risk control that mandates a protective measure should be traceable to the design requirement that implements it. Failure Modes are allocated to System Elements via allocatedTo, and System Elements anchor the entire requirements hierarchy to a physical architecture. This intersection is why the System Decomposition Report shows requirement, function, characteristic, failure mode, risk control, and test case counts per element: every element in the physical architecture is a node where multiple traceability chains converge. For deeper background on the safety analysis entities that feed into this chain, see Failure Condition and Failure Mode Hierarchy and System Element Hierarchy. For the broader data model that defines all work item types, see Data Model and Work Item Types.
Code: .polarion/nextedy/sheet-configurations/Whole RTM Config.yaml (0.66) · .polarion/pages/spaces/_default/Requirements Traceability Summary/page.xml, Verification Validation Summary/page.xml, Risk Control Effectiveness Report/page.xml, System Decomposition Report/page.xml, FMEA Coverage Report/page.xml, Classification Consistency Report/page.xml, System FMEA Report/page.xml, System Structure Navigator/page.xml (0.61) · .polarion/nextedy/models/rtm.yaml (0.59) · .polarion/tracker/fields/workitem-link-role-enum.xml (0.58) · .polarion/nextedy/sheet-configurations/DO-178C Software Verification Matrix.yaml (0.57) · datasets/sol-aero-ui-walkthrough/summary.md, navigation.md, dashboards/home-dashboard.md, dashboards/role-dashboards.md, dashboards/standards-compliance.md, risksheet-views/risksheet-views.md, work-item-types/data-model.md (0.57) · .polarion/nextedy/sheet-configurations/DO-326A Security Requirements Traceability.yaml (0.56) · modules/RiskTemplates/PSSATemplate/attachments/risksheet.json (0.55) · .polarion/pages/spaces/_default/Data Model/attachments/diagram_1771111587_documents.mxg.svg, diagram_1771111587_risk.mxg.svg, diagram_1771111587_traceability.mxg.svg, modules/Requirements/SYSTEM-ELEMENTS/attachments/diagram_20260215-0024.44000.mxg.svg (0.54) · .polarion/pages/spaces/_default/Data Model/page.xml (0.51)