Designing for Reusability: How Launch Vehicle Companies Are Rethinking Requirements

When SpaceX landed the first Falcon 9 first stage in December 2015, most of the aerospace industry treated it as a demonstration. Impressive, yes. But production-viable? That argument took another three years and dozens of reflights to settle. By 2019, the question was no longer whether a rocket booster could be reused. The question was how to build the next generation of vehicles so that reuse was not a retrofit capability bolted onto a performance-optimized design, but a primary requirement from day one.

That shift — from reusability as a demonstration to reusability as a design driver — turns out to be a significant systems engineering problem. Rocket Lab’s Neutron, Blue Origin’s New Glenn, and a growing list of next-generation medium and heavy launch vehicles are being designed with explicit reusability goals. And the engineering teams working those programs are discovering that designing for reuse changes requirements in ways that ripple through nearly every subsystem.

The Falcon 9 Baseline: What SpaceX Actually Proved

Before getting into what the industry is now trying to do, it is worth being precise about what SpaceX demonstrated.

Falcon 9’s Block 5 variant was the first version explicitly designed for high-flight-rate reuse. Earlier blocks were designed to be reusable, but required significant refurbishment between flights. Block 5 targeted a 24-hour turnaround with minimal work and ten flights with no planned refurbishment. In practice, SpaceX has flown boosters into the twenties and beyond.

What SpaceX showed is that structural life, thermal protection, propulsion re-certification, and inspection can all be managed at cadence — but only if the entire vehicle architecture, manufacturing approach, and ground operations workflow is designed around that assumption from the outset. Block 5 required substantial redesign from Block 3/4. The lesson for the next generation of vehicles is that late-stage reusability retrofits are expensive. Requirements have to be set correctly before the architecture freezes.

How Reusability Changes the Requirements Hierarchy

On a traditional expendable launch vehicle, performance margins dominate the requirements hierarchy. Structural margins are set to survive the mission envelope. Propulsion requirements are set to deliver the specified performance. Thermal protection requirements are set to survive ascent or reentry — whichever is relevant. All of these are verified once: the vehicle flies, and if it survives, the requirements are met.

Reusable vehicles need a fundamentally different set of top-level requirements. Several categories become primary design drivers that have little to no analog in expendable design.

Refurbishment time and cost requirements. A vehicle that requires 90 days of depot-level work between flights cannot support a competitive mission rate. This means that refurbishment time must be specified as a system requirement — not a program goal — and it must be allocated to subsystems just like mass or power. If the thermal protection system requires 30 technician-hours of inspection and replacement per flight, that is a requirement derivation problem: the TPS design does not close against the refurbishment budget.

Structural life requirements. Expendable structures are designed for one load cycle. Reusable structures must be designed for N load cycles, where N is specified at the system level and allocated to structural components as fatigue life requirements. This is not a new engineering discipline — aerospace has done fatigue-life design for aircraft for decades — but it is new to launch vehicles, and the load profiles are more severe. The structure experiences launch acoustics and vibration, max-Q aerodynamic loads, engine cutoff transients, reentry heating, and landing loads. Each flight is a complete load cycle across all of those environments. Requirements that specify structural life in terms of flight cycles must be allocated and verified against accumulated damage models, not just single-event test data.

Propulsion re-certification requirements. An engine that flies once is verified by analysis, component test, and acceptance testing. An engine that flies twenty times needs a re-certification rationale that accounts for accumulated wear, thermal cycling, and any anomalies observed during flight. This requires that re-certification criteria be specified as requirements — what inspection gates must be passed, what parameters must fall within what limits, what constitutes a mandatory depot-level teardown — and that those requirements are traceable to the engine design.

Landing system availability requirements. For vehicles that land propulsively or with a recovery system, the landing system must be treated as a reliability-driven subsystem with availability requirements. This is distinct from performance requirements. The landing system does not just have to work; it has to work with high reliability across the full range of booster return conditions. If landing system availability is 98.5% per flight, that drives system-level mission availability and economic modeling. Specifying availability rather than just performance is a requirements authoring discipline that many launch vehicle teams are still developing.

Inspection and anomaly resolution requirements. Reusable vehicles accumulate a maintenance history. Requirements for inspection capability — what must be inspectable, how, and at what turnaround interval — must be written at the system level and allocated to design. If a structural weld is inaccessible without removing a major component, that is a requirements traceability problem: the inspectability requirement was not properly allocated to the structural design.

Verification Is Iterative by Definition

On an expendable vehicle, verification has a clear terminal state. You build the vehicle, test the components, run acceptance tests, verify the analysis, and fly. Verification closes.

For a reusable vehicle, verification never fully closes. Each flight is a data point in an ongoing verification campaign. The structural life model that was used to set fatigue requirements gets updated as flight data accumulates. The propulsion re-certification criteria that were set based on pre-flight analysis get refined as inspection results from real flights come in. The landing system availability estimate that was set during design gets corrected as the fleet grows.

This creates a verification architecture problem. The traditional systems engineering approach — requirements, design, verify, close — does not accommodate a model where the requirement itself may be revised based on operational evidence. Programs need a verification strategy that distinguishes between requirements that close at qualification (single-event structural margins, for example) and requirements that remain open across the operational life of the vehicle (fatigue life, inspection criteria, re-certification thresholds).

Practically, this means that the requirements management infrastructure for a reusable vehicle program needs to support living baselines. Requirements that are conditioned on fleet data — “the vehicle shall complete N flights before mandatory depot inspection, where N is established based on accumulated fatigue analysis updated with flight data” — require a different traceability model than static performance requirements.

Fleet Data as a Systems Engineering Input

This is one of the least-discussed but most consequential shifts in how reusable launch vehicle programs must operate.

On expendable vehicles, flight data is used to validate analysis and improve future designs. It is an output of operations that feeds back into engineering. On reusable vehicles, flight data is an input to systems engineering decisions that are made between flights. The question “is this booster cleared to fly again?” is a systems engineering question, not just an operations question, and it requires integrating fleet data — across all prior flights of this vehicle and the broader fleet — into the requirement verification logic.

This means several things concretely:

Anomaly trending must be a formal process. A single off-nominal temperature reading on a turbopump is not necessarily a concern. A trend of increasing turbopump temperatures across the last three flights of a specific booster, in the context of similar trends across the fleet, may indicate a wear mechanism that violates the re-certification requirement. Detecting that requires that flight data be organized in a way that supports trend analysis against requirement thresholds, not just archival storage.

The requirement baseline must reference fleet data. This is a tooling and process problem. If refurbishment requirements specify that a booster must pass a defined set of inspections before each flight, and those inspection criteria are updated based on fleet findings, then the requirement baseline must track those updates and maintain traceability to the evidence that justified each revision.

Configuration management must distinguish between vehicle-level and fleet-level requirements. Some requirements apply to each vehicle as an individual (this specific booster has N fatigue cycles remaining). Some requirements apply to the fleet as a class (the landing system design must achieve availability above X%). Both need to be tracked, but they have different update cadences and different evidence bases.

How Modern Tooling Has to Support This

Traditional requirements management tools — IBM DOORS, Jama Connect, Polarion, and their contemporaries — were designed around the assumption that requirements are documents. You author a requirement, link it to verification evidence, and mark it closed. That model works reasonably well for programs with a defined endpoint, where requirements close at acceptance.

For reusable vehicle programs, that model is a poor fit. The requirements are not documents that get authored and closed. They are nodes in a model that connects design parameters, verification evidence, operational data, and updated analysis. The traceability is not a static RTM; it is a living graph that gets updated as flights accumulate and as the understanding of the vehicle’s behavior evolves.

This is an area where graph-based, AI-native tools have a genuine architectural advantage over document-based tools. Tools like Flow Engineering, which are built around connected traceability models rather than hierarchical document structures, are better suited to the update-in-place, data-fed requirements model that reusable vehicle programs need. When a fleet data finding updates a refurbishment threshold, that change needs to propagate through the requirements graph to all downstream verification items and design allocations. In a document-based system, that propagation is manual and error-prone. In a graph-based system, it is traceable and auditable.

Flow Engineering’s model-native approach also supports the kind of multi-condition requirement authoring that reusable programs need — requirements that are conditioned on flight count, fleet findings, or updated analysis — in a way that flat document structures cannot easily represent.

What the Next Generation Programs Are Actually Doing

Public information on Rocket Lab’s Neutron requirements architecture is limited, but the vehicle’s design choices are instructive. Neutron’s composite structure, re-lightable Archimedes engines, and landing leg system are all designed around a multi-flight assumption. Blue Origin’s New Glenn, which has begun flying, is similarly designed for reuse from the outset, with the first stage intended to fly multiple times per booster.

What distinguishes these programs from earlier reusability efforts is that the reuse requirements are not afterthoughts. Landing availability, turnaround time, and structural life requirements are reported to be primary design drivers that shaped architecture decisions early in the design process — before the major structural design reviews that lock in the approach.

The industry is also seeing increased investment in digital thread infrastructure that connects design models, requirements, test data, and flight data in a unified environment. This is not purely a tooling choice. It is a recognition that reusable vehicles generate a type of engineering feedback loop — flight experience updates the model, which updates the requirements, which updates the design — that cannot be managed with disconnected document repositories.

Honest Assessment

Designing for reusability from day one is the right approach, and the next generation of launch vehicles is taking it more seriously than any prior generation outside of SpaceX. But the requirements engineering discipline needed to support reusable systems is still maturing.

Most aerospace systems engineering processes were built for programs with clear terminal verification events. Adapting those processes to handle living requirements, fleet-fed verification, and iterative re-certification is a significant organizational and tooling challenge — one that does not have a fully worked-out industry consensus solution yet.

What is clear is that the teams that get this right early — that build requirements architectures that can accommodate flight data as a systems engineering input — will have a structural advantage in turnaround rate and operational cost over teams that treat requirements management as a compliance exercise rather than a living engineering tool.

The economics of reusability only work if the engineering infrastructure keeps up with the operational tempo. Requirements management is part of that infrastructure.