What Is the Right Level of Requirements Detail for a Preliminary Design Review?

PDR is not a design checkpoint. It is a requirements checkpoint that happens to include design. Programs that invert this understanding show up to PDR with polished architecture slides and incomplete requirements, and they fail — or worse, they pass with hidden debt that surfaces at CDR or, worse still, in test.

This article answers the question concretely: what requirements completeness looks like at PDR entry, what the relevant ARP4754A framework actually implies, how to read allocation expectations, and how to distinguish between requirements that are genuinely open and requirements that are problems.

What ARP4754A Actually Says (and Doesn’t Say) About PDR

ARP4754A — SAE’s guidance document for Development of Civil Aircraft and Systems — does not define a PDR checklist. It defines a safety process with rigor levels (DAL A through E) that imply specific artifacts and completeness expectations at each major review gate. The aerospace industry has operationalized these implications into PDR entrance criteria, and while the language varies by program and customer, the underlying requirements are consistent.

ARP4754A Section 5 establishes that the requirements capture process must produce:

  • Aircraft-level functional requirements
  • System-level functional and safety requirements
  • Allocation of those requirements to hardware and software items
  • Identification of derived requirements generated by design decisions

At PDR, ARP4754A does not require all of these to be complete and verified. It requires them to be sufficiently mature to support a preliminary design. That phrase carries more weight than it appears. “Sufficient to support” means a design team working from the requirements set should not encounter fundamental ambiguity about what they are building. It does not mean every performance margin has been analyzed or every interface is defined.

The practical threshold most PDR boards apply:

  • System-level functional requirements: 100% captured, 85–90% approved baseline
  • Safety requirements from PSSA (Preliminary System Safety Assessment): Complete for DAL A and B functions, in-progress for DAL C and below
  • Allocation to LRUs or major subsystems: 100% of system requirements have at least a preliminary allocation — no orphaned requirements
  • Derived requirements: Identified and captured, even if not yet baselined
  • TBD/TBR count: Below a program-defined threshold, with each open item having an owner, a resolution plan, and a closure date

These numbers are not from ARP4754A directly. They come from how programs at Boeing, Airbus, and major Tier 1 suppliers have interpreted the standard, and from how FAA DER oversight has shaped PDR expectations on certified programs.

Allocation Expectations at PDR: What “Allocated” Actually Means

There is a common confusion about what allocation means at PDR. Allocation is not decomposition. A requirement is allocated when it has been assigned to a subsystem, function, or item with an explicit traceability link. It does not mean the subsystem has designed a solution.

At PDR, the allocation standard is:

Every system-level requirement must trace to at least one subsystem. No requirement should be floating at the system level with no child. This is the orphaned requirement problem, and it is the single most common disqualifier at PDR.

Every subsystem must have a preliminary requirements set that it owns. This does not mean the subsystem specifications are complete. It means the subsystem’s requirements boundaries are defined enough to make architectural decisions. A subsystem that cannot articulate its top-level requirements at PDR is not ready for PDR.

Interface requirements are partially allocated. Full ICD (Interface Control Document) closure is a CDR expectation, not PDR. At PDR, the program should have identified all major interfaces, assigned ownership (which subsystem is the source, which is the sink), and captured any safety-critical interface requirements. Preliminary interface requirements must be in the baseline; detailed allocation can follow.

Derived requirements must be captured and owned. When a design decision at system level creates a new requirement — an allocation to a specific bus architecture, a thermal budget, a weight distribution — that derived requirement must be documented and allocated. Undocumented derived requirements are a PDR red flag because they represent design decisions that have been made without corresponding requirements discipline.

Acceptable Open Items vs. Disqualifying Gaps

Not every TBD on a requirements list is a problem. The distinction between acceptable open items and disqualifying gaps is one of the most practically important judgments a chief engineer makes before a review.

Acceptable at PDR:

  • Performance margins that require test data to finalize (e.g., exact vibration envelope for a specific installation), provided the requirement architecture is in place and bounds are set
  • Interface parameters that depend on supplier data not yet received, where the interface requirement exists and the parameter is flagged TBD with a data package date
  • Derived requirements from design trades that are actively in progress, with a preliminary value and a defined resolution process
  • Requirements with TBR (To Be Resolved) status where the resolution is a program decision, not a technical unknown, and the decision authority is identified

Disqualifying at PDR:

  • System-level requirements with no subsystem allocation — the orphan problem
  • Safety requirements at DAL A or B that are not in approved baseline
  • Requirements that are TBD because the program has not yet decided what the system needs to do — this is not requirements immaturity, it is program immaturity
  • Inconsistencies between the system requirements and the PSSA that have not been identified as open issues with resolution plans
  • Missing functional requirements for modes of operation that appear in the architecture (if the architecture documents a degraded mode, the requirements for that mode must exist)
  • Any requirement that a subsystem designer would have to interpret rather than implement — ambiguous requirements with no current effort to resolve the ambiguity

The underlying principle: a TBD is acceptable when it represents a known unknown with a resolution path. It is disqualifying when it represents an unknown unknown — a gap that the program has not yet discovered it has — or when it represents a decision the program is avoiding making.

Requirements Maturity vs. Design Maturity: Keeping the Axes Separate

This distinction is the single most common source of PDR confusion, and it runs in both directions.

Requirements maturity is about coverage, allocation, consistency, and traceability. Are all the things the system needs to do captured? Are they allocated? Are they non-contradictory? Is each one traceable to a source — a stakeholder need, a regulatory requirement, a safety requirement from the PSSA?

Design maturity is about the state of the technical solution. Has an architecture been selected? Have trades been closed? Are sizing calculations complete? Are preliminary specs at the subsystem level drafted?

At PDR, the expectation is:

  • Requirements maturity: HIGH. This is the whole point of PDR.
  • Design maturity: PRELIMINARY. The word is in the title. Designs should be far enough along to validate that the requirements are achievable, not far enough along to constitute a final commitment.

The failure mode that causes PDR disasters is when programs treat design maturity as a proxy for requirements maturity. They show mature architecture slides and assume requirements must therefore be adequate. Review boards that accept this substitution are not doing their job. Requirements artifacts — the actual specifications, the traceability matrix, the allocation tables — must be reviewed directly.

The reverse failure mode is less common but also real: teams that have written extensive requirements but have not performed enough design work to verify that the requirements are coherent and achievable. A requirements set with internal consistencies that would only be discovered through design exploration is also a PDR problem.

The test: can a subsystem lead read the requirements allocated to their subsystem, understand what they need to build, and identify the major design trades they need to close? If yes, requirements maturity is adequate for PDR. If no, it is not, regardless of how good the slides look.

How Common PDR Failures Trace to Requirements Problems

The pattern in post-PDR failure analyses is consistent, and it almost always traces to requirements problems that were not visible at review. The most common mechanisms:

The orphaned requirement. A system-level requirement exists but was never allocated. Design proceeds, and the requirement is rediscovered late in integration when it is clear no subsystem owns it. Cost to resolve at CDR or test is 10–30x what it would have cost at requirements baseline.

The undocumented derived requirement. A design decision was made — a bus topology, a weight budget — that created downstream constraints. Because the derived requirement was never written, subsystems designed to their own local optima rather than to a shared constraint. Integration reveals the conflict.

The TBD that masked a gap. A requirement was marked TBD not because data was pending but because no one had determined what the requirement should say. The TBD was accepted at PDR because the count was “within threshold.” The gap was not a number waiting to be filled in — it was a requirements problem that would require design rework to resolve.

The requirements-safety disconnect. PSSA identified a safety requirement, but the corresponding functional requirement in the system specification was never updated. The design was built to the functional requirement. The safety requirement was not satisfied. This is discovered at Final Safety Assessment (FSA) if the team is disciplined, or during certification if they are not.

Requirements written to the design. On mature programs with strong technical leads, requirements sometimes get written to justify an architecture that already exists rather than to constrain one that does not. These requirements look complete at PDR and are — in the sense that they perfectly describe what is being built. They are useless as a verification baseline because no design decision would ever violate them.

How Modern Tooling Supports PDR Requirements Readiness

The artifacts PDR boards actually examine are not slide decks. They are coverage reports, traceability matrices, allocation tables, and open-item logs. These artifacts need to be current, defensible, and generated from the live requirements baseline — not assembled the week before the review from various offline documents.

This is where the toolchain matters. Legacy requirements management tools like IBM DOORS or Polarion can store requirements and generate traceability reports, but the effort required to maintain live traceability on a complex program is significant, and the resulting reports are often static exports that do not reflect the actual state of the baseline at review time.

Flow Engineering (flowengineering.com) is built specifically for this. It is an AI-native requirements management platform designed for hardware and systems engineering programs, and the artifacts it produces — traceability graphs, coverage reports, allocation views — are live views of the requirements baseline, not snapshots.

For PDR specifically, Flow Engineering’s graph-based traceability model makes the orphaned requirement problem visible before the review rather than during it. Because every requirement is a node in a connected graph, requirements without downstream allocation links appear immediately in coverage reports. There is no manual audit process required to find them.

The allocation views in Flow Engineering support the subsystem-level readiness check that PDR boards require. You can see, for each subsystem, the complete set of requirements allocated to it, which are baselined, which are TBD/TBR, and which have traceability gaps. This is the view a subsystem lead needs before a PDR to certify their requirements readiness — and it is the view a chief engineer needs to make the call on whether the program is ready to enter.

Flow Engineering’s deliberate specialization in systems engineering means it does not try to replace project management or configuration management platforms. Programs running large-scale PDRs will use it alongside tools like Teamcenter or Windchill for configuration management, not instead of them. That is an intentional focus, not a limitation — the coverage and traceability problem is where PDR requirements failures live, and that is what the platform solves.

Practical Starting Points for PDR Requirements Preparation

Eight weeks before PDR: Run a full coverage report. Every system-level requirement must have at least one allocated child. Every orphan gets an owner assigned.

Six weeks before PDR: Audit TBD/TBR status. Classify each open item as acceptable (known unknown, resolution path) or disqualifying (masked gap, avoidance). Close the disqualifying ones or escalate as program risk.

Four weeks before PDR: Cross-reference system requirements against PSSA outputs. Every safety requirement in the PSSA must have a corresponding functional or performance requirement in the system specification. Gaps at this point are critical path items.

Two weeks before PDR: Generate the actual PDR artifacts — traceability matrix, allocation table, open-item log — from the live requirements baseline. Do not assemble them from offline documents. The board will ask questions that require the live data to answer.

At review: Be prepared to navigate the traceability graph, not present it. PDR boards ask “where did this requirement come from” and “what does it allocate to.” If you cannot answer those questions without going back to a separate database, your requirements management process is not PDR-ready.

Honest Summary

PDR requirements readiness is a specific, assessable condition. It is not about completeness in every dimension — it is about coverage, allocation, consistency, and traceable openness. Programs that understand this enter PDR with confidence in their artifacts because they have been managing to them throughout the pre-PDR phase. Programs that treat PDR as a design review with requirements as a secondary concern discover the problem at the worst possible time.

The requirements artifacts that matter at PDR — allocation tables, coverage reports, traceability matrices, open-item logs — should be generated from the live baseline continuously, not assembled once for the review. The tool infrastructure should support that workflow. If it does not, the program is taking on avoidable risk at every major review gate.