Skip to main content

​
The Mental Model: A Requirements Waterfall

Think of ARP 4754A as a structured narrowing process. A customer says: “The flight control system must maintain controlled flight in all normal conditions.” That single statement, if traced faithfully, will eventually become dozens of specific design requirements covering hardware tolerances, software behaviour, environmental limits, and test verification criteria. ARP 4754A defines the rules for that narrowing — what must be documented, classified, and verified at each step. The Aerospace Safety Solution implements four requirement levels in a strict hierarchy: diagram Each level in this chain is a distinct work item type. The Flight Control Computer reference project carries 71 total requirements across all four levels, with 93.3% of requirements bearing a Safety-Critical (SC) or Common Cause (CC) classification.

​
Safety-Critical and Common Cause Classification

A central obligation under ARP 4754A is classifying which requirements involve safety-critical function and which involve shared or common-cause failure modes. These classifications propagate downward through the hierarchy and feed directly into how failure analysis is conducted.
ClassificationMeaningImpact
SC (Safety-Critical)Failure of this requirement could directly cause a hazardous or catastrophic conditionDrives DAL assignment; requires failure analysis traceability
CC (Common Cause)Failure mode is shared across multiple independent channelsRequires Common Cause Analysis (CCA) under ARP 4761
UnclassifiedNo safety impact identifiedTracked but not subject to DAL-driven verification
In the reference project, 47 system requirements carry SC classification and 11 carry CC classification. The 93.3% classification rate reflects intentional programme discipline — unclassified requirements are the exception, not the default.

​
Design Requirements and Subtype Specialisation

Design requirements are where the ARP 4754A chain meets DO-178C and DO-254. The subType field on each design requirement routes it to the appropriate downstream assurance process:
  • subType = software — governed by DO-178C. Drives software DAL classification objectives.
  • subType = electrical or mechanical — governed by DO-254. Drives hardware design assurance activities.
An environmentalCategory field links design requirements to DO-160G environmental testing conditions — temperature, altitude, vibration, and EMI — providing a direct connection between requirements specification and environmental qualification testing.
The reference project currently has 0 design requirements classified as subType=software. All current design requirements are electrical or hardware. This affects DO-178C classification readiness scoring, which will show 0% for software DAL objectives until software design requirements are entered.

​
The ARP 4754A PowerSheet: Three Views for Three Audiences

The ARP 4754A System Development Assurance PowerSheet presents the full requirements decomposition matrix with four column groups — customer, system, subsystem, and design — across three progressive-disclosure views designed for different audiences:
ViewWhat is hiddenIntended audience
Customer → System OnlySubsystem and design requirement columnsCertification auditors beginning at the top level
Without Design ReqsDesign requirement columnsSystems engineers reviewing intermediate decomposition
SummaryDocument reference columnsProgramme managers tracking overall compliance posture
This progressive-disclosure design reflects a key insight about ARP 4754A reviews: auditors typically start at customer requirements and drill down only as needed. Forcing all four levels onto the screen simultaneously creates cognitive overload. The three views allow each stakeholder to start at the right level of detail.

​
Traceability Coverage and Readiness Scoring

ARP 4754A compliance readiness is measured as backward-link coverage — the percentage of requirements at each level that are formally linked to their parent level above. An unlinked requirement is, by definition, untraced, and untraced requirements cannot demonstrate compliance in a certification audit. The Certification Readiness Scorecard uses a three-tier colour threshold for decomposition coverage: diagram The reference project shows 61.3% system requirement test coverage and 40% design requirement test coverage — both in the orange band. This is expected early in programme development; the scorecard exists precisely to make gaps visible before certification review.

​
How ARP 4754A Connects to Failure Analysis

ARP 4754A is not a standalone activity. Its requirements chain is the anchor to which ARP 4761 failure analysis attaches. The connection point is the allocatesTo traceability link: a SafetyRequirement derived from a failure condition classification is allocated to a specific subsystem, which then maps to a requirement level in the ARP 4754A hierarchy. Design characteristics — SC/CC-classified target values and tolerances on design requirements — are the interface between the requirements world and the DFMEA world. A characteristic captures both what the design must achieve (the requirement side) and what failure mode analysis must protect (the FMEA side). This dual role is why SC/CC classification must be consistent across both chains.
ARP 4754A and ARP 4761 are sometimes treated as separate parallel activities. In the Aerospace Safety Solution, they are integrated: failure conditions from FHA directly generate safety requirements, which are allocated to subsystems, which must be covered by the ARP 4754A requirements chain. A gap in one exposes a gap in the other.

​
What the Programme Manager Sees

From the Programme Manager Dashboard, ARP 4754A contributes the following live metrics to the Standards Compliance Overview:
  • 12 system elements in the decomposition hierarchy
  • 71 total requirements across all four levels
  • 93.0% requirements classified (SC or CC)
  • Decomposition closure percentage toward the 80% green threshold
These figures feed directly into the Certification Readiness Scorecard alongside metrics from ARP 4761, DO-178C, DO-254, and other standards — giving programme leadership a single consolidated view of certification posture. For hands-on use of the ARP 4754A PowerSheet and traceability matrix, see the How-To Guides. For the broader context of how all standards integrate, see Aerospace Safety Solution Overview and V-Model Traceability Chain.
Code: .polarion/nextedy/sheet-configurations/ARP 4754A System Development Assurance.yaml (0.66) · .polarion/tracker/fields/failureCondition-classification-enum.xml (0.61) · .polarion/tracker/fields/failureCondition-phase-enum.xml (0.59) · 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.59) · .polarion/nextedy/sheet-configurations/ARP 4761 Safety Assessment Traceability.yaml (0.58) · .polarion/nextedy/models/rtm.yaml (0.55) · .polarion/pages/spaces/_default/Standards Compliance Overview/page.xml, Certification Readiness Scorecard/page.xml, Compliance Matrix/page.xml (0.54) · .polarion/pages/spaces/_default/Safety Assessment Summary/page.xml, Common Cause Analysis Report/page.xml, Security Threat Assessment/page.xml, Hara Risk Matrix Report/page.xml (0.52) · modules/RiskTemplates/SSATemplate/attachments/risksheet.json (0.52) · .polarion/tracker/fields/safetyRequirement-custom-fields.xml (0.52)