A Guide to Aerospace Requirements Management

Aerospace requirements management is the practice of capturing, controlling, tracing, and verifying requirements across the lifecycle of an aircraft, spacecraft, or defense system, in a form a certification authority can inspect on demand. What separates it from controlling and verifying requirements elsewhere is that the evidence is part of the product. A team must build the system correctly, then show on request which requirement each line of code and each test result answers to.

A single interface requirement between two subsystems shows why that matters. If a propulsion requirement specifies thrust command units and the engine control software assumes different units, nothing in either document reveals the conflict, and it surfaces at integration. A trace link between the two makes it findable earlier, which is why unlinked requirements count as safety-critical failure modes rather than paperwork errors.

Four Pressures That Make Aerospace Requirements Harder to Trace

Four pressures apply at once on an aerospace program, and each makes trace links harder to keep accurate:

• Certification rigor: What a team must prove scales with what happens if the system fails. At the highest assurance levels, engineers trace each requirement through design to code and test evidence, and show that testing exercised every decision branch.
• Hardware and software together: Authorities assess airborne software as part of the whole aircraft system, so software requirements must stay connected to the same requirement tree the hardware team works from.
• Multi-tier supplier flow-down: A requirement written by the prime contractor must pass down intact through every supplier and sub-tier contract beneath it, and the evidence must come back up the same way.
• Systems-of-systems scale: One mission can span several projects, sites, and contractors. Top-level objectives break down into the specifications each team builds to, and every level must stay connected to the one above.

Word and Excel handle any one of these pressures. All four at once is where they break down, and the standards below decide how the evidence is judged.

The Standards That Govern Aerospace Requirements Management

Three documents carry most of the traceability obligations on an airborne program. ARP4754B governs aircraft and system development, and added Model-Based Safety Analysis in its December 2023 revision. DO-178C covers airborne software, and its obligations run in both directions along a single requirement chain. DO-254 covers airborne electronic hardware, which matters on any program building complex custom devices.

Feeding all three is ARP4761A, published the same day as ARP4754B, which carries the system safety assessment process that sets the assurance levels the others work to.

Which revision applies matters more than usual, because the system-level and software-level documents are on different clocks.

DO-178C sets the traceability obligation most programs plan around. It asks for links running in both directions along one chain, from system requirements through high-level and low-level software requirements into source code, then on to the test cases and results that verify them. Read forward, the links show every requirement was built and tested. Read backward, they show every line of code answers to a requirement, which keeps dead and extraneous code out of certified builds.

A standard carries no weight until a certification authority accepts it as a way to show compliance. The Federal Aviation Administration (FAA) did that through Advisory Circular AC 20-115D. The European Union Aviation Safety Agency published a matching AMC 20-115D in 2017. Authorities accept new revisions slowly, so a team picking up ARP4754B mid-certification should confirm which one its authority accepts before writing the plans.

What Requirements Failures Cost, and Where Traceability Breaks

Changing requirements after development starts is expensive enough to show up in program-level cost data. Research, development, test, and evaluation costs ran 11 percent above initial estimates on major defense weapon programs that changed no requirements once development began. On programs that did change requirements, the same costs ran 72 percent above estimate, according to a 2008 review of 46 surveyed weapon programs.

Cost data shows the size of the problem, and audit findings show how it happens. Auditors reviewing a Department of Defense readiness reporting program in 2009 tried three separate times to trace system requirements up and down that chain, and found no traceability on any attempt. The program had never built a traceability matrix, never baselined its requirements, and had another 530 requirements collected but never evaluated, according to Government Accountability Office (GAO) reviewers.

That program built a readiness reporting system, not an aircraft, so the details don’t transfer, but the way it failed does. Three patterns account for most of the drift that reaches an audit:

• Supplier tooling mismatch: An integration contractor working outside the program’s requirements management platform leaves its work unlinked until someone reconciles it by hand.
• Unmeasured requirements growth: Teams that stop counting requirements cannot tell whether a slipping schedule came from churn or slow execution.
• Stale documentation: Documentation that stops being updated after delivery cannot show that what shipped matches what was approved.

All three are upkeep problems rather than knowledge problems, which is why the practices that hold up under audit are the ones that keep trace links current.

Three Practices That Keep Requirements Ready for Audit

Three practices decide whether a program can produce trace evidence on demand, and none involves knowing the standards better. The readiness program above had no shortage of requirements, with 530 waiting and no baseline to absorb them into.

Write Every Requirement to the Same Rule Set

Requirements that hold up in an audit are written to a rule set rather than to taste. Nine characteristics define a usable requirement, unambiguous and verifiable among them. Meeting them is spelled out in 42 numbered rules in the International Council on Systems Engineering (INCOSE) Guide to Writing Requirements. The Easy Approach to Requirements Syntax (EARS) supplies the sentence shape, using keywords that mark continuous states, one-off events, unwanted behavior, and optional features.

A requirement covering two conditions stacks two keywords. One might read that while the aircraft is above 10,000 feet, if cabin altitude exceeds 14,000 feet, the environmental control system shall deploy the passenger oxygen masks. Written that way, it states its trigger and expected response plainly enough that a test engineer can write a test without asking what was meant.

Check Each Level of Decomposition Before Starting the Next

Reviewing derived requirements against their parents, before work starts on the level below, is the cheapest place to catch the two defects auditors find most often. A requirement never allocated downward leaves a capability nobody builds, and a lower-level requirement with no parent adds work nobody asked for. Both stay invisible in a document workflow until integration or an audit surfaces them.

Worth saying plainly, this is harder than the process diagrams suggest. On a program carrying thousands of requirements and a schedule that rewards moving on, a review that finds nothing reads as lost time, and the reviews that get skipped are on the subsystems nobody was worried about.

Keep Trace Links Current Between Baselines

A baseline only means something if changes to it get recorded the same way the original approval was. When a requirement changes mid-program, someone has to walk the chain and find every affected design element, test case, and risk item. One missed link becomes an audit finding later. Change management that sends every revision back through the same approval path as the original keeps the record and the program in step.

The evidence trail matters as much as the change. A record of what changed, why, who authorized it, and what it affected answers an auditor in an afternoon. Capturing only the final state turns the same question into weeks of reconstructing intent from old email. Keeping that record by hand works on a small program, and stops working once the data crosses a supply chain.

What Digital Engineering Changes About Traceability

On defense programs the requirements and their trace links are becoming the deliverable, taking over from the documents that used to carry them. A model is only as reliable as the relationships recorded inside it, so the links now carry the weight. Department of Defense Instruction 5000.97, effective December 2023, directs programs to communicate system information through digital models and their underlying data rather than document deliverables.

Requirements analysis is usually one of the first places a program applies a unified model, where each requirement gets a fixed place and a defined set of relationships. A Traceability Information Model (TIM) records which relationships a program expects between requirements, models, code, tests, and verification results, then flags a missing one before a supplier exchange. What none of that removes is the need to notice when a change has made a link wrong.

How Jama Connect Supports Aerospace Requirements Management

Before anyone can review a change, the program has to know which trace links that change put in doubt. Jama Connect®, a web-based requirements management and traceability platform for complex, regulated product development, records the trace relationships a program is required to have and compares them against what the project contains. Live Trace Explorer™ reports coverage against that pattern and marks downstream items as suspect when an upstream requirement changes. The engineer who owns each marked item decides whether to update it or clear the mark, so broken links surface before an auditor does.

Airborne programs don’t have to build the certification framework themselves. Jama Connect for Airborne Systems ships frameworks aligned to ARP4754B, ARP4761A, DO-178C, DO-254, and DO-326A, with Code of Federal Regulations (CFR) Parts 21 through 59 already imported. Jama Connect Advisor™, available on Jama Connect Cloud only, scores requirement text against the same INCOSE rules and EARS patterns while an engineer is writing it, and drafts test cases from a selected requirement using aerospace and defense context. The engineer reviews those drafts and can regenerate them with more direction, and each test case and its trace link back to the source requirement are created at the moment the engineer accepts one. Programs with hosting constraints have aerospace and defense deployment options, including Amazon Web Services (AWS) GovCloud (US) for International Traffic in Arms Regulations (ITAR) requirements and self-hosted for air-gapped installations.

Correcting Trace Drift Before the Next Certification Review

Three of the standards in this guide are newly revised or under revision now. None of that changes what actually costs programs, which is how far the trace record has drifted from the program since its last baseline. A team that corrects it continuously has less to do when a revision lands.

If your program spends more time rebuilding traceability ahead of a certification review than maintaining it during development, Jama Connect supports that upkeep as part of the working day, not a separate exercise. You can start a free 30-day trial against your own requirements data.

Frequently Asked Questions About Aerospace Requirements Management

What is the difference between requirements validation and verification in aerospace?

Validation asks whether the requirements are the right ones, checking a derived set against its parents and against what the engineering and program teams intended. Verification asks whether the built system meets each requirement, shown through inspection, analysis, test, or service experience. Auditors treat the two as separate evidence chains, and merging them leaves both chains incomplete. Structured verification and validation reviews with recorded approvals keep them distinct.

How does traceability depth change with design assurance level under DO-178C?

Testing obligations tighten as the assurance level rises. Statement coverage applies at the three highest levels, decision coverage at the two highest, and modified condition and decision coverage at the highest only. Separately, at the highest level, a program has to find any object code the compiler produced that has no direct link back to source, and verify that code on its own. Those two obligations get treated as one more often than they should, and they answer different questions about DO-178C and ED-12C.

When do certification authorities examine traceability evidence?

Authorities look at trace data across the lifecycle, not at a single gate. The four-stage review model most programs plan around is convention drawn from a 2003 FAA order, replaced in 2018 by risk-based involvement levels scaled to software level and product novelty. Requirements-based and structural coverage are examined at the software verification review, while the final review concentrates on the accomplishment summary and conformity evidence. Bidirectional traceability held current through development is what makes those reviews a reading exercise rather than a reconstruction.

This article was authored by Mario Maldari and published on August 20, 2026.