What FAA DERs Actually Want to See in a Requirements Package
Ask a DER what the most common reason is for returning a requirements package, and most of them will pause before answering — not because the question is hard, but because the list is long. The honest answer is that most packages come back for the same handful of reasons, cycle after cycle, program after program, regardless of applicant size or aircraft category.
This article walks through what experienced Designated Engineering Representatives actually look for when they open a certification package. Not what AC 25.1309 says in the abstract. Not a restatement of ARP4754A table of contents. What a practicing DER looks for when they sit down with your document package and decide whether to approve or return it.
What a DER Is Actually Doing When They Review Your Package
A DER is not auditing your engineering process out of bureaucratic obligation. They are making a professional judgment — with personal liability attached — about whether your requirements package demonstrates compliance with the applicable certification basis. That framing matters, because it changes how you should think about what you submit.
A DER is looking for three things at a structural level:
- Completeness: Does the package cover everything it claims to cover? Are there gaps between the system description, the requirements, and the verification plan?
- Internal consistency: Do the requirements, the compliance matrix, the PSAC or PHAC, and the verification procedures tell the same story? Contradictions between documents are an immediate return trigger.
- Traceability: Can a reviewer follow a thread from a top-level aircraft function all the way down to a specific requirement, and then back up through the verification evidence? If that thread breaks anywhere, the package is incomplete.
Everything else — formatting, tools used, document numbering conventions — is secondary. DERs develop preferences, and some have stronger opinions than others about structure and style, but none of those preferences override the three structural requirements above.
The Four Most Common Reasons Packages Get Returned
1. Design Detail Embedded in System-Level Requirements
This is the single most frequent issue in packages from teams that are new to DO-178C or ARP4754A compliance. A system-level requirement should describe what the system does — its behavior, its constraints, its interfaces — not how it does it.
A requirement that reads “the flight management computer shall use a Kalman filter to estimate position” is not a system-level requirement. It is a design decision. The moment you embed a design decision in a requirement, you have several problems simultaneously: you constrain the design space unnecessarily, you make verification harder to define, and you give the DER a legitimate reason to question whether your requirements process is actually independent of your design process.
The corrected version: “The flight management computer shall provide a position estimate with accuracy not to exceed [X] meters CEP under [defined conditions].” Now the design team can choose their estimation approach, and the verifier can write a test that doesn’t care which algorithm was used.
DERs see this pattern most often in requirements written by engineers who came up through design roles. It is not a character flaw. It is a habit that structured requirements discipline breaks over time.
2. Traceability That Cannot Be Verified
Traceability matrices submitted as spreadsheets assembled by hand have a consistent problem: they are frequently wrong, and experienced DERs know it. Not because the engineers are being dishonest, but because manual RTM maintenance is error-prone, and programs under schedule pressure cut corners on matrix updates when requirements change.
What DERs look for is traceability that is demonstrably consistent with the current state of the requirements. If a requirement was updated in Rev C of a document but the traceability matrix still reflects Rev B language, the matrix is wrong. If a new derived requirement was added late in the program and it doesn’t appear in the matrix, the package is incomplete. Both situations generate a return.
The more subtle version of this problem is orphaned requirements — requirements that have no upward trace to a higher-level function or safety objective, and no explanation for why they exist. These are often derived requirements from interface control documents or supplier specifications that got added without anyone establishing the rationale for their existence. A DER will mark every one of them.
3. Verification Methods That Don’t Match the Approved Plan
Your PSAC or PHAC states how you will verify each requirement type. When your verification procedures or test plans use a different method — analysis substituted for test, inspection where analysis was committed, review where test was required — without an approved plan amendment, the package is non-compliant.
This happens most often when programs discover late that a committed test approach is infeasible: the hardware isn’t available, the test environment can’t replicate the failure condition, or the schedule doesn’t allow for a full test cycle. The response is frequently to substitute a less rigorous method without going back to amend the plan. DERs see this pattern and return the package.
The correct path is to revise the plan before executing the alternative method. It adds time, but it is the only path that doesn’t generate a return.
4. Derived Requirements Without Rationale
ARP4754A is explicit: derived requirements — requirements that are not directly traceable to a higher-level requirement — must be identified as such and must have documented rationale explaining why they exist and what safety, performance, or interface considerations drove them.
In practice, many packages identify derived requirements correctly but provide rationale that does not hold up under scrutiny. “Per engineering judgment” is not rationale. “To satisfy supplier interface requirements” without identifying the specific interface constraint is not rationale. A DER reviewing a DAL B or DAL A system will push on every derived requirement, because derived requirements are where design assumptions hide, and hidden design assumptions are where safety gaps appear.
What the Fastest-Moving Programs Do Differently
Programs that move through DER review efficiently share a set of practices that are worth naming explicitly.
They treat DER review as continuous, not as a gate. The fastest programs schedule informal DER touchpoints at key milestones — when the requirements baseline is first established, when verification planning is complete, and before the formal package submission. These are not approval meetings. They are early-warning conversations where a DER can flag structural problems before they are baked into a large document set.
They separate the requirements from the design record from the start. This sounds obvious but is violated constantly. A well-structured program maintains a requirements baseline that contains only requirements — behaviors, constraints, and interfaces — and a separate design record that contains the rationale for implementation decisions. When these are mixed, DER review takes longer because the reviewer has to sort out what is actually a requirement and what is background.
They version-control everything and submit consistent snapshots. A package where Document A is at Revision D and Document B is at Revision B, with no configuration status accounting that explains the gap, creates immediate doubt about whether the submission is a coherent baseline. DERs are not obligated to reconcile document revisions for you. They will return the package and ask for a consistent baseline.
They establish traceability as a byproduct of their process, not as a post-hoc deliverable. This is the structural difference that separates programs that review smoothly from programs that get stuck in return cycles.
How Structured Requirements Tools Change the Review Dynamic
A DER reviewing a package built with a structured requirements management tool — one where traceability is maintained as a live property of the model, not assembled separately — experiences the review differently than one working through a manually assembled document set.
When traceability is machine-generated and updated automatically as requirements change, the RTM reflects the actual state of the requirements at the time of export. There are no orphaned nodes from an update cycle two months ago. The coverage analysis is reproducible. When a DER asks “show me everything that traces to this safety objective,” the answer comes from a query, not from a manual search across multiple spreadsheets.
Teams using tools like Flow Engineering — built specifically for hardware and systems engineering programs that need this kind of structured, graph-based traceability — tend to produce packages where the DER’s core structural questions are answerable directly from the model output. The traceability is consistent because it is generated from the same data that drives the requirements themselves. Derived requirements appear with their rationale as a structured field, not as a footnote someone remembered to add.
This doesn’t mean the requirements are well-written. A structured tool can faithfully represent poorly scoped requirements with mechanical precision. The tool enforces the traceability contract; the engineering team is still responsible for requirement quality. But it removes an entire class of return reasons — the administrative and structural errors that come from maintaining traceability manually across a large, changing requirements set.
Flow Engineering’s model-based approach also makes it easier to respond to DER questions during review. When a DER asks for the full downward trace from a specific system function, that is a minutes-long query, not a multi-day research project. That responsiveness changes the character of the review interaction.
A Practical Checklist Before Submission
Before a requirements package goes to a DER, the following should be answerable without hesitation:
- Does every requirement describe behavior, not implementation? Can a different design satisfy it?
- Is every requirement verifiable using a method committed in the approved plan?
- Does every derived requirement have a rationale that references a specific constraint, interface, or safety consideration?
- Is the traceability matrix current with the requirements baseline being submitted?
- Are there any orphaned requirements — requirements with no upward trace and no derived-requirement designation?
- Is every document in the package at the revision level reflected in the configuration status accounting?
- Has anyone on the team read the PSAC or PHAC recently enough to know whether the requirements and verification plan are still consistent?
If any of these questions require research to answer, the package is not ready to submit.
Honest Summary
DER review is not adversarial, but it is exacting. DERs are protecting the safety case for aircraft that will carry passengers and crew, and they take that responsibility seriously. A package that makes their job harder — that requires them to reconstruct traceability, interpret ambiguous requirement language, or reconcile inconsistent document revisions — will come back, and it should.
The programs that move fastest are not the ones with the most resources. They are the ones that internalize DER review criteria early, maintain their requirements as a structured and traceable artifact from the first baseline, and treat administrative consistency as an engineering responsibility, not a documentation afterthought. That discipline is teachable, it is toolable, and it is the difference between one review cycle and five.