What Is the Right Level of Requirements Detail at System PDR?

How detailed do your requirements need to be before you can call PDR?

It is one of the most argued questions in systems engineering, and it produces real program damage on both sides of the mistake. Teams that hold PDR too early—with requirements that are vague, incomplete, or untraceable—burn review cycles answering basic coverage questions that should have been settled weeks before. Teams that wait until every subsystem requirement is fully specified before calling PDR have often already made irreversible design decisions without formal scrutiny, which defeats the purpose of the review.

The correct answer is not a page count or a requirement count. It is a function of hierarchy level, allocation completeness, and the specific evidence your authority—whether that is the FAA, ESA, a DoD program office, or an internal chief engineer—expects to see. Here is what each of those looks like in practice.

What PDR Is Actually Reviewing

Preliminary Design Review is a system-level event. Its purpose is to confirm that the proposed design approach—your architecture, your major trade decisions, your allocation of performance and interface responsibilities to subsystems—is credible given the requirements it must satisfy.

That sentence contains the answer to the question: requirements at PDR must be detailed enough to make your design approach credible, but they do not need to be detailed enough to build to. Build-to requirements belong at CDR and below.

The practical consequence: at PDR, your system-level requirements should be frozen, and your allocated subsystem-level requirements should be defined well enough that the review board can evaluate whether the architecture can plausibly satisfy them. Third-level requirements—detailed design specifications, interface control document line items, component-level performance margins—are not PDR artifacts. They are CDR artifacts.

This distinction is not a shortcut. It is the intended structure of the milestone review sequence.

What Certification Authorities Actually Expect

FAA (Airborne Systems and Avionics)

The FAA does not mandate a PDR in its own right for all programs, but it engages during Preliminary Design via the certification plan and means of compliance submitted under 14 CFR Part 21 and the relevant design approval basis. For systems developed under DO-178C, DO-254, or ARP4754A, the FAA’s expectation at the equivalent of PDR is this:

  • The system functional requirements are defined, reviewed, and baselined.
  • The allocated requirements to hardware and software items are defined to a level that allows the Safety Assessment process to confirm failure condition classifications.
  • Requirements are linked—either explicitly in a tool or demonstrably through a traceability matrix—from the certification basis down through the system safety objectives to the item-level requirements.

What the FAA does not expect at this stage: low-level hardware requirements, software architecture specifications, or component derating criteria. Those belong in later design reviews and Stage of Involvement (SOI) audits.

The critical phrase in ARP4754A is “allocated requirements”: requirements that have been assigned to an item, that carry their parent rationale with them, and that are complete enough to bound the item’s design space. Not necessarily complete enough to fill it.

ESA (Space Systems)

ESA follows ECSS-E-ST-10C and the associated review standard ECSS-M-ST-10-01C. ESA is explicit about what the Preliminary Design Review (PDR) gates. The System Requirements Review (SRR) must close before PDR opens, and SRR is specifically where top-level functional and performance requirements are confirmed as complete and stable.

By PDR under ECSS, the review board expects:

  • Functional requirements at system level: complete and stable.
  • Performance, interface, and environmental requirements allocated to subsystems: defined with enough specificity to enable analysis.
  • Preliminary Interface Control Documents (ICDs): baseline-worthy, though not yet fully detailed.
  • A preliminary verification matrix demonstrating that each system-level requirement maps to at least one planned verification method and level.

ESA’s language is instructive here. The verification matrix does not need to show completed verification at PDR—it needs to show planned verification. The requirement is credible coverage, not proof.

DoD Programs (MIL-STD-1521B / ANSI/EIA-632 lineage and DoDI 5000 series)

DoD acquisition programs generally operate under the guidelines in DAG (Defense Acquisition Guidebook) and program-specific SEPs (Systems Engineering Plans). For ACAT I and II programs, PDR is a formal Milestone Decision Authority event. The technical expectations are codified in MIL-HDBK-502A and the program’s Systems Engineering Plan:

  • System-level technical requirements: allocated, baselined, and in a controlled requirements baseline (typically in an DOORS or equivalent database).
  • Functional architecture to at least Level 2 decomposition, with requirements allocated to each function and element.
  • Key Performance Parameters (KPPs) and Key System Attributes (KSAs): fully allocated and bounded.
  • Draft SCD (System/Subsystem Specification): complete enough for the review board to evaluate whether the design approach closes against it.

DoD program offices often also request a Derived Requirements Summary—a document or artifact showing which requirements were derived from design decisions rather than flowed down from parent requirements, and why each is justified. This is frequently the source of PDR review actions on programs that have not tracked derived requirements systematically.

The Difference Between Allocated Requirements and Detailed Design Requirements

These two terms are often conflated, and that confusion produces most of the PDR timing mistakes.

Allocated requirements establish what an element must do and what constraints it must satisfy. They flow from a parent requirement, carry a rationale, and define the boundary of the design problem. A good allocated requirement at PDR looks like this:

The propulsion subsystem shall deliver a minimum of 450 N of thrust at sea-level standard conditions with a thrust-to-weight ratio no less than 8.2:1 under all defined operating modes.

That is complete enough to evaluate whether a candidate design approach can plausibly satisfy it. It is not complete enough to design, analyze, and verify the nozzle geometry.

Detailed design requirements translate the allocated requirement into specifications that drive hardware or software design directly: dimensions, tolerances, material grades, timing budgets, software stack constraints. Those belong after PDR, when the design approach has been reviewed and approved.

The PDR question is: Can this architecture satisfy these allocated requirements? The CDR question is: Does this detailed design satisfy these detailed requirements?

If you are standing in a PDR presenting detailed design requirements, you have collapsed two review events into one. Your review board will either wave you through without proper scrutiny or reject the review as premature for a different reason—because the design is already too far committed.

What ‘Good Enough’ Looks Like at Each Level of the Hierarchy

Level 1 — Mission/System Requirements Must be complete, stable, and formally baselined before PDR is called. No open TBDs at this level. These are what the program was contracted to deliver. If these are still in flux at PDR, reschedule.

Level 2 — Subsystem/Segment Allocated Requirements Must be defined well enough to support architecture trade evaluation and failure mode analysis. TBDs are acceptable only if they are bounded (i.e., the analysis closes at the pessimistic bound) and carry a documented resolution plan. An unbounded TBD at Level 2 is a PDR risk flag.

Level 3 — Element/Component Requirements Should be substantially defined at PDR for safety-critical, performance-driving, or long-lead elements. For non-critical elements, it is acceptable to enter PDR with Level 3 requirements flagged as “to be developed post-PDR with CDR closure.” The review board should know which elements carry that status and why it does not threaten the top-level closure.

Interface Requirements At PDR, interface requirements need to define the nature, protocol, and performance bounds of each interface. They do not need to specify pin counts or signal timing tables—that is ICD Detail B territory and belongs at CDR. The architecture-level question the board is asking is: Are these interfaces feasible and consistent with both elements they bound?

The Two PDR Mistakes and What They Cost

Holding PDR Too Early

Signs: requirements are characterized as “X% complete,” multiple Level 1 TBDs remain open, the preliminary verification matrix covers fewer than 80% of requirements, no formal requirements baseline has been established.

Cost: review actions that amount to “finish your requirements and come back.” These are expensive actions—they require re-baselining, re-allocating, and often re-evaluating architecture decisions that were made against incomplete requirements. Programs lose 4–12 weeks and sometimes discover that allocation decisions made without complete Level 1 requirements were wrong.

Holding PDR Too Late

Signs: the team presents requirements that include material, process, and form-factor specifications; interface control documents are complete at the connector level; PDR slides include component-level analysis against detailed margins.

Cost: the design is effectively committed before formal scrutiny. The review board cannot exercise its oversight function because reverting decisions would require restarting design work. Safety-critical design choices that should have been challenged get locked in. This is how latent design errors enter programs and survive until integration.

How Teams Use Flow Engineering to Assess Requirements Completeness Before PDR

The traditional approach to PDR readiness is the compliance matrix—a spreadsheet that maps each requirement to an architecture element and a verification method. The compliance matrix is not wrong, but it is a point-in-time snapshot assembled manually. By the time it is reviewed, it is already stale, and it shows coverage only for the requirements the team remembered to include.

Teams using Flow Engineering approach this differently. Because requirements in Flow Engineering exist as nodes in a connected graph—linked to parent requirements, to architecture elements, to verification methods, and to risk items—coverage analysis is not a document you produce before a review. It is a live query you run against the current state of the baseline.

Before entering PDR, a program systems engineer can query the requirement graph to surface every allocated requirement with no downstream verification method assigned, every Level 2 requirement with an open TBD that has no resolution date, and every interface requirement that references an architecture element with no ICD counterpart. These are the conditions that generate PDR review actions—and identifying them three weeks before the review gives the team time to close them rather than defend them.

Flow Engineering’s coverage view also makes the distinction between “allocated and traceable” and “detailed and build-to” visible in the graph structure. A review team can see, at a glance, which requirement branches are complete to the level appropriate for PDR and which carry downstream detail that should not be in the PDR baseline at all.

The result is that teams arrive at PDR with evidence rather than assertions. Instead of claiming “our requirements are X% complete,” they can show the review board a filtered view of the requirement hierarchy demonstrating that every Level 1 requirement has at least one allocated child, every allocated child has a planned verification method, and the open items are bounded and tracked. That is a different kind of review conversation.

Honest Summary

The right level of requirements detail at PDR is not maximum detail—it is the right detail at the right level. System requirements must be frozen. Allocated requirements must be defined to the point where your architecture can be evaluated against them. Detailed design specifications should not be in the PDR baseline.

The agencies—FAA, ESA, DoD—each frame it differently, but the underlying demand is the same: show that every top-level requirement has been allocated to an element that can plausibly satisfy it, that the allocation is traceable, and that you have a credible plan to verify it. Evidence of that, not assertion of it.

If your team cannot run a query against your requirements baseline and answer “how many Level 2 requirements have no planned verification method?” before your PDR kickoff meeting, that is the first problem to solve.