LEO Mega-Constellations Are Breaking Traditional Satellite Requirements Management
When you launch 60 satellites a month, document-based requirements processes collapse — here’s what replaces them
There is a specific moment when satellite programs outgrow their requirements management processes. For single-satellite programs — a GEO comms bird, a science mission, a classified reconnaissance asset — that moment rarely comes. The program is long, the team is stable, and IBM DOORS or a well-maintained spreadsheet hierarchy can carry you from Phase A through decommissioning.
For LEO mega-constellation programs, that moment arrives sometime around the third or fourth production batch. SpaceX’s Starlink, Amazon’s Kuiper, and OneWeb’s reconstituted constellation have each, in different ways, hit the same wall: the requirements infrastructure built to manage one satellite configuration becomes a liability when you are managing thousands of related-but-diverging configurations simultaneously, across a launch cadence measured in weeks, not years.
This is not a process problem that better discipline solves. It is an architectural problem. The tools and workflows that the aerospace industry developed over four decades are built on assumptions that LEO mega-constellations violate structurally.
What Makes Constellation Programs Fundamentally Different
The standard framing — “it’s just more satellites” — misses what actually changes at scale.
Common heritage, continuous differentiation. Every satellite in a Starlink Gen2 batch shares a baseline architecture. But batches diverge. New phased array designs, upgraded inter-satellite link hardware, modified power systems, revised attitude control software — each production run incorporates incremental changes driven by supply chain realities, on-orbit anomaly data, and deliberate capability upgrades. The result is not one configuration; it is dozens of coexisting, related configurations, each with its own requirements delta from a shared parent.
In traditional satellite programs, configuration differentiation is exceptional. An engineering change proposal (ECP) is a significant event requiring review boards, formal documentation, and deliberate baseline control. In constellation programs, differentiation across batches is continuous and expected. Managing it as a series of exceptional events creates a process that is always behind.
Traceability must span hardware and software simultaneously. A GEO satellite might fly the same software baseline for a decade. Constellation satellites receive over-the-air software updates that change functional behavior without changing hardware. Requirements traceability must now follow threads across hardware configuration items, software versions, and the intersection of both — for each satellite, in each batch, against the on-orbit operational baseline.
Test records and anomaly data are requirements inputs, not just outputs. When you have 3,000 satellites on orbit, anomaly data from the fleet informs requirements for the next production batch in near-real-time. A thermal management issue on Batch 7 becomes a requirements change for Batch 9. In traditional programs, requirements drive test; in constellation programs, test results at scale drive requirements revision. The causal arrow runs in both directions.
Launch cadence is the forcing function. SpaceX has sustained Starlink launch rates that would have seemed implausible for any satellite program five years ago. Amazon’s Kuiper is ramping toward similar cadences. When you are launching every few weeks, the time available to close requirements for a production batch is measured in weeks, not the months or quarters that traditional ECO processes assume. Any requirements management process that cannot operate at that clock speed becomes a program risk.
Where Traditional Tools Break Down
IBM DOORS and DOORS Next are the industry standard for a reason. They handle complex hierarchical requirements, bidirectional traceability, and multi-discipline change management well. For a single-satellite program with a stable team and a multi-year development schedule, they remain defensible choices.
They break at constellation scale for specific, structural reasons.
The data model is document-centric, not variant-centric. DOORS represents requirements as a hierarchical document structure. Managing variant configurations — Batch 7 satellites with the Gen2 ISL hardware versus Batch 7 satellites with the legacy ISL hardware — requires either maintaining parallel document hierarchies (which immediately diverge and become inconsistent) or implementing complex attribute-based variant management that the tool’s architecture was not designed for. Teams end up with sprawling module structures that no single engineer fully understands.
Change management assumes exceptional events. The ECP workflow in most aerospace RM tools assumes that changing a requirement is a significant, carefully controlled event. In constellation production, requirements changes are frequent, incremental, and often driven by information arriving from multiple directions simultaneously — supply chain, anomaly review boards, software releases, regulatory updates. Treating each change as an exceptional event creates process bottlenecks that compress the already-tight window between batch definition and launch.
There is no native concept of “fleet state.” A constellation program needs to answer questions like: “Which satellites on orbit have the Batch 5 attitude control requirements?” or “What is the requirements delta between Batch 8 and Batch 11 for thermal subsystem?” Traditional RM tools can answer these questions only if someone has meticulously maintained the right attribute structure and kept it current. In practice, that maintenance is the first casualty of schedule pressure.
Traceability RTMs become unmanageable. A single-satellite program might have a requirements traceability matrix with thousands of rows. A constellation program with continuous batch differentiation, software variant management, and fleet-level test records needs a traceability model that scales to millions of relationships. Spreadsheet-based RTMs fail completely. Even DOORS-based RTMs become performance problems and, more critically, comprehension problems — no engineer can reason effectively about a traceability structure of that complexity in a document-centric view.
What Sophisticated Operators Are Actually Doing
The most advanced constellation programs are not waiting for tool vendors to solve this. They are assembling practices, some novel and some borrowed from adjacent disciplines, that address the structural gaps.
Treating requirements as a graph, not a document hierarchy. The relationships between a system requirement, its derived subsystem allocations, the hardware configurations it applies to, the test records that verify it, and the on-orbit telemetry that monitors it are inherently graph-structured. Leading programs are moving toward requirements models that are represented as connected graphs — where queries like “show me all requirements affected by this anomaly” or “which batches share this verification record” become natural operations rather than manual cross-referencing exercises.
Borrowing software version control concepts. The closest analogy to constellation batch differentiation is software branching. Batch N is a fork from Batch N-1, with a defined delta. Sophisticated operators are applying branching-model concepts to requirements: a shared trunk for constellation-wide requirements, batch-specific branches for production deltas, and formal merge/synchronization processes when anomaly data from one batch drives requirements changes that propagate back to the common baseline. This is fundamentally different from the traditional ECP model, which assumes a single authoritative baseline rather than a tree of related baselines.
Closing the loop between on-orbit data and requirements. The most mature programs are building direct traceability from fleet telemetry anomaly reports back to the requirements that govern the affected subsystem. When an anomaly is classified as requirements-relevant — it implies a gap or ambiguity in the stated requirement — that linkage is captured formally, and the affected requirement is flagged for batch review. This turns the fleet itself into a continuous requirements validation engine, which is the appropriate use of 3,000 orbiting data points.
Separating heritage management from change management. Rather than trying to manage heritage and change in the same workflow, advanced programs maintain a stable, explicitly versioned common heritage baseline and treat batch differentiation as a first-class object — not a deviation from the baseline, but a managed child of it. This separation allows engineers working on Batch N+2 to operate against a clean baseline while Batch N anomaly-driven changes are being incorporated through a separate process.
The Tooling Direction: Graph-Based, AI-Native, Connected
The requirements tooling that constellation programs need does not look like a better version of DOORS. It looks more like a connected engineering knowledge graph with requirements as one layer of a richer model.
Several characteristics define what this generation of tooling needs to do:
Native variant and configuration management. Not attribute-based workarounds in a document model, but first-class support for parent-child relationships between requirement baselines, with queryable deltas and propagation-aware change management.
Bidirectional traceability at fleet scale. The ability to trace from a system requirement down through batch-specific allocations, to hardware configuration items, software baselines, test records, and on-orbit telemetry monitoring parameters — and to traverse that graph in any direction, at query time, without manual RTM maintenance.
AI-assisted impact analysis. When a Batch 7 anomaly suggests a requirements change, the tool should be able to surface — automatically — which other requirements are potentially affected, which batches share the affected configuration, and what verification records might need to be revisited. Doing this manually at constellation scale is not feasible.
Integration with manufacturing and operational systems. Constellation requirements do not live in isolation from the factory and the NOC. The requirements tooling needs to connect to production tracking, test data management, and operations systems so that fleet state is continuously reflected in the requirements model.
Flow Engineering has built its platform explicitly around the graph-based model that constellation-scale requirements management demands. Its representation of requirements as connected nodes in a queryable graph — rather than rows in a document hierarchy — directly addresses the fleet-state query problem that defeats document-centric tools. Its AI-assisted impact analysis reduces the manual cross-referencing burden that constellation batch differentiation creates. For programs operating at the intersection of frequent configuration changes, multi-batch coexistence, and real-time anomaly integration, Flow Engineering’s deliberate architectural choices align with the problem structure in ways that legacy tools, however mature, do not.
The caveat worth stating plainly: Flow Engineering’s depth in traditional aerospace process compliance — DO-178C traceability, formal ECP workflows, legacy DOORS migration — is less extensive than what DOORS Next or Jama Connect offer for programs where that compliance infrastructure is a hard requirement. For a Kuiper-scale program that needs to satisfy both FAR Part 25 analog rigor and a monthly launch cadence, the tooling answer is likely a combination, not a single platform.
The Honest Assessment
The aerospace industry’s requirements management practices were built for programs measured in years, with stable teams, single configurations, and document-based review cultures. Those practices work well in that context. They are structurally mismatched with the problem of managing requirements across a fleet of 6,000 satellites that grows by 60 per month, differentiates continuously across production batches, and receives its most important requirements inputs from anomaly data generated on orbit.
The programs that are managing this best are not doing so because they found a perfect tool. They are doing so because they made explicit architectural decisions about how to represent their requirements — as graphs, not documents; as versioned branches, not single baselines; as living models connected to operational data, not static artifacts reviewed quarterly.
The tools are catching up. But the conceptual shift — from requirements as documents to requirements as a connected model of engineering intent — has to happen first, and it has to happen inside the program, not just in the software. The launch schedule will not wait for the process.