How Do You Scope a System Architecture Review Without a Completed Design?

Here is the tension every systems engineer on a program eventually faces: the program schedule calls for a System Requirements Review or Preliminary Design Review, the customer or review board wants to see the system architecture, and the architecture is not done. It may not even be close to done. You have allocations on whiteboards, trade studies in progress, and interface definitions that change every two weeks.

So what are you actually reviewing?

This is not a rhetorical question. The answer determines what artifacts you prepare, what exit criteria you set, and whether the review is a productive risk-reduction activity or a theater exercise where everyone agrees the design looks fine and nothing useful happens.

The Purpose of an Early Architecture Review Is Not Design Completion

The single most damaging assumption teams bring into SRR and PDR is that the goal is to demonstrate a finished architecture. It is not. If your architecture is fully defined at PDR, one of two things is true: either the problem was simple enough that you probably didn’t need a formal review, or you locked decisions before you had the analysis to support them.

Early milestone reviews serve a different set of purposes:

Feasibility assessment. Can the proposed architecture actually satisfy the driving requirements? This does not require a complete design. It requires demonstrating that there is no known physical, logical, or resource constraint that makes the requirements unachievable with the chosen approach. “We haven’t identified a showstopper” is a legitimate and honest finding.

Risk identification. What are the key unknowns, and do they have mitigation plans? A good PDR architecture review makes the risks visible. A bad one hides them behind slides that look more complete than the underlying work.

Key trade identification. Which architecture-level decisions are still open, and what is the plan to close them? Trades that are still open at PDR are not necessarily a failure — they are often correct, because the analysis may legitimately still be underway. But reviewers need to see what trades exist, what data is needed to close them, and when they will close.

Driving requirements allocation. The most load-bearing question a reviewer can ask at SRR or PDR is: “Which requirements are driving the architecture, and how are they allocated to functional or physical elements?” If the team cannot answer that question, the review has no foundation. If they can, the review has substance — even if many design details remain unresolved.

What Architecture Artifacts Should Exist at Each Milestone

The artifact expectations should match the review purpose. Here is a working framework:

At SRR

  • A system context diagram that defines external interfaces and system boundary
  • A functional decomposition at Level 1 (the system) and Level 2 (major functions or subsystems)
  • Allocation of driving stakeholder requirements to top-level functions
  • Identification of system-level performance parameters and their derivation from stakeholder needs
  • A documented assumptions list — not a gap list dressed up as completed work

What should not be expected at SRR: subsystem-level design, interface control documents, component selection, or resource budgets with high confidence.

At PDR

  • Functional architecture through Level 3 or Level 4, depending on system complexity
  • Physical architecture showing major configuration items and their relationships
  • Requirement allocation from system to configuration item or subsystem level
  • Key interface definitions (not necessarily fully specified, but identified and owned)
  • Resource budgets with margin tracking (mass, power, link budget, timing — whichever are driving)
  • Open trade studies listed with closure plans
  • Technical risk register with current assessment and mitigation status

What should not be expected at PDR: detailed part selection, manufacturing process definition, fully specified ICDs, or software architecture at the module level for complex software-intensive systems.

The pattern here is deliberate: each milestone should demonstrate that the team has made the architecture decisions appropriate to that phase and deferred the design decisions appropriately. The review is scoped to the horizon of knowledge, not to a fiction of completeness.

Architecture Decisions vs. Design Decisions

This distinction is harder to apply in practice than it looks in a table, but it is the key intellectual tool for scoping a review honestly.

An architecture decision defines structure. It determines how requirements are partitioned across the system, what the major functional or physical elements are, how they interact, and where the key performance margins live. Architecture decisions are typically hard or expensive to change. Getting them wrong has broad consequences.

Examples:

  • Federated versus integrated avionics architecture
  • Centralized versus distributed data processing
  • Single-fault-tolerant versus dual-redundant fault management strategy
  • RF versus optical for the inter-subsystem link

A design decision populates structure. It determines the specific implementation of an architectural element: which processor, what memory size, which specific FPGA fabric, how a particular protocol is implemented within a defined interface.

Examples:

  • Which radiation-hardened processor implements the flight computer function
  • Specific clock frequency for the bus
  • FPGA gate utilization
  • Software partitioning below the subsystem boundary

A review board that demands design-level answers at PDR is applying the wrong criteria. A review board that accepts architecture-level answers when design decisions should already be made is being too permissive. The scoping conversation has to happen explicitly, or both failure modes will occur on the same program.

A practical test: ask whether the decision in question constrains downstream decisions significantly. If changing it would require reworking multiple subsystems or revisiting multiple requirements allocations, it is an architecture decision and it should be settled at or before PDR. If changing it affects one component’s implementation without propagating, it is a design decision and later closure is acceptable.

Realistic Exit Criteria for Early Reviews

Exit criteria for architecture reviews are frequently written as binary completion gates (“all Level 3 requirements allocated”) when the honest version should be risk-conditioned (“driving Level 3 requirements allocated, with residual gaps documented and tracked”).

For SRR, realistic exit criteria include:

  • System boundary and context defined and agreed
  • Stakeholder requirements baselined or controlled
  • Top-level functional decomposition consistent with known driving requirements
  • Known technical risks identified and entered into risk tracking
  • Assumptions documented and reviewed for plausibility

For PDR, realistic exit criteria include:

  • Requirement allocation to configuration item or subsystem level complete for all driving requirements
  • Resource budgets established with explicit margin policy
  • Open trade studies enumerated with closure dates before CDR
  • Key interfaces identified, ownership assigned, and ICD development started
  • No unmitigated high-risk technical items that threaten the baseline architecture

Notice that neither set of criteria says “architecture complete.” They say “architecture understood well enough to identify what we know, what we don’t know, and what the plan is to close the gaps.” That is the honest purpose of the review, and the criteria should reflect it.

Showing Reviewers What Exists, Even When the Design Is Partial

The practical challenge for teams preparing for early reviews is not just knowing what to present — it is generating the review artifacts without spending three months in document production instead of engineering.

This is where the requirement-to-architecture allocation model becomes operationally important, and where tooling matters.

Teams using Flow Engineering have a specific capability that is directly relevant here. Flow Engineering maintains a live graph of requirements linked to functional and physical architecture elements. Because the model is built continuously as the team works — not assembled retrospectively for a review — the allocation state at any point in the program reflects actual engineering work, not a document written the week before the review.

For a PDR preparation cycle, this means a review package can show reviewers which Level 3 requirements are allocated to which configuration items, which requirements are currently unallocated or partially allocated, and where the allocation confidence is low because the underlying trade is still open. That is honest. It gives the review board genuine signal about the state of the architecture without pretending the work is further along than it is.

The graph structure also makes it easy to answer the question reviewers care about most at PDR: “What are your driving requirements, and how are they shaping the architecture?” In a traditional document-based approach, answering that question requires manually tracing from a requirements document through an allocation matrix into a design document — a process that is error-prone and often outdated by the time anyone reads it. In Flow Engineering’s model, the requirement-to-element relationships are the database, and the current state is always queryable.

This does not mean the architecture is complete. It means the partial state of the architecture is visible and honest, which is exactly what a good early review needs.

Flow Engineering’s focus on systems engineering specifics — rather than general-purpose project management — means it is less suited for teams that need heavy change management workflows or mature process compliance tooling out of the box. But for teams whose primary challenge is making early-phase architecture work legible to reviewers and to themselves, the allocation graph model addresses the core problem directly.

The Honest Summary

When a review board asks to see your system architecture at SRR or PDR, they are not asking you to be done. They are asking you to show that you understand what you know, what you don’t know, and why the approach you have chosen is credible given current information.

That means your preparation work should focus on four things: making the functional and physical decomposition explicit, connecting requirements to architectural elements as far as the allocation actually goes, documenting the open trades honestly with close-out plans, and setting exit criteria that match the knowledge horizon of the phase.

The teams that survive early architecture reviews with credibility are not the ones who hide incompleteness behind polished slides. They are the ones who can walk a reviewer through the current allocation state, name the decisions that are still open, and explain why those decisions are appropriately open rather than embarrassingly incomplete.

That is a different kind of preparation than document assembly. It requires a live model of the architecture, not a snapshot written for the review. The tooling you choose for requirements and architecture management either supports that working mode or it doesn’t.

Hardware AI Review covers tools, methods, and tradeoffs for hardware and systems engineering teams. We do not accept sponsored content.