Development assurance
Systems-development evidence review under ARP4754B
A systems-development evidence review checks whether an article's ARP4754B development-assurance data holds together: that the item definition, the system requirements, the architecture, and the validation evidence are consistent with the development assurance level assigned to each function. It is for avionics and equipment suppliers building or recovering a system-level data set. The review reads the development plans, the item and interface definitions, the requirement set, the validation evidence, and the requirement allocation to software and hardware, then checks them against the development assurance the level demands. You receive a status against the development-assurance objectives and a list of weak or missing links.
When this review is needed
- A system is integrating software and hardware and the system-level data needs a read before it drives those programs.
- The architecture changed and the requirement allocation to items may no longer reflect the design.
- A development assurance level was revised and the validation evidence has to match the new expectation.
- Software or hardware reviews keep tracing requirements up to a system definition that is incomplete.
The problem
ARP4754B sits above the software and hardware standards and sets the requirements they implement, yet the system-level data is often the thinnest part of a package. The item definition lags the design, requirements are captured without validation that they are correct and complete, and the allocation to software and hardware is informal. The lower-level programs then build to requirements that were never validated, and the rework cascades downward.
What gets reviewed
- The development plans and how the system process follows them
- The item definition and the interface definitions between items
- The system requirement set and its capture and validation
- The architecture and how requirements allocate to software and hardware
- The validation evidence that requirements are correct and complete
- Development assurance level assignment and the rigor it drives
What gets validated
- Each function carries a development assurance level and the data rigor matches it
- System requirements are validated for correctness and completeness, not only captured
- Requirements allocate cleanly to software and hardware with no orphaned items
- The item and interface definitions are current with the architecture
- Derived requirements at the system level are identified and assessed
- Validation evidence exists for the requirements that drive the lower-level programs
- Configuration of the system data is controlled across requirement changes
Evidence normally required
- The development plans and the item definition
- The system requirement set and any validation records
- The architecture description and interface definitions
- The requirement allocation to software and hardware items
- Development assurance level assignments and their rationale
Common discrepancies
- System requirements captured but never validated for correctness or completeness
- An item definition that lags the current architecture
- Requirements with no clean allocation to a software or hardware item
- Development assurance level assigned without the data rigor to match
- Derived system requirements not assessed against the architecture
- Interface definitions that the integrating items do not agree on
What is at stake
An unvalidated system requirement that proves wrong forces change across every item that implemented it, multiplying the cost the further the program has run. A missing item definition leaves the software and hardware teams interpreting scope, which surfaces as integration findings. When the development assurance level and the evidence diverge, the system data has to be rebuilt while the lower levels wait.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Frame the system
Confirm the item definition, interfaces, and the development assurance level assigned to each function.
Test validation
Check that system requirements are validated for correctness and completeness, not only captured.
Check allocation
Follow the allocation of requirements to software and hardware and find orphaned or unowned items.
Report the gaps
Produce a development-assurance status and a closure list ordered by downstream-rework risk.
What the buyer receives
- A status against the ARP4754B development-assurance objectives
- A validation-gap view across the system requirement set
- An allocation view flagging orphaned or unallocated requirements
- A prioritized closure list ordered by downstream-rework risk
Who uses the output
- Certification leads building the system-level data set
- Systems engineering teams closing validation and allocation gaps
- Program management coordinating the software and hardware programs the system drives
How the work fits into the transaction or program
The review sits at the top of the development chain and frames the software and hardware lifecycle reviews. It supplies the validated requirements those programs implement and feeds the safety assessment that sets the assurance levels.
Start with a single asset
Confirm requirements trace through verification.
Regulatory limits
Endeavor Elements reviews the applicant's development-assurance data for consistency against ARP4754B. It does not assign development assurance levels on an authority's behalf, make compliance findings, or guarantee acceptance of the system data.
What this review does not cover
- Making compliance findings or issuing any approval
- Setting the development assurance level in place of the applicant's analysis
- Producing the missing requirements or validation evidence
Specific to this review
- ARP4754B separates validation, that a requirement is correct and complete, from verification, that the implementation meets it, so a system data set can be heavily verified yet thin on validation.
- The development assurance level for a function drives how much rigor the system data carries, so the same requirement set can be adequate for one level and short for a higher one.
- System requirements feed the software and hardware programs that implement them, so an unvalidated requirement propagates its error into every item that builds to it.
- Requirement allocation is where the system meets its items, and a requirement with no allocated owner is a structural gap rather than a wording problem.
Sources
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
SAE International. Safety assessment methods (FHA, PSSA, SSA, FTA, FMEA) supporting development assurance level assignment.
Frequently asked questions
How is this different from the software and hardware reviews?
This review works at the system level above them. It checks the requirements and validation that the software and hardware programs implement, where those reviews check the lifecycle data within each discipline.
Relevant glossary terms
Related pages
Where this fits
Talk to an engineer who has done this work
We will walk through your current state, the records or evidence involved, and a scoped first engagement.
Walk through your situation with an engineer who has done this work.