The Satellite Constellation Era’s Systems Engineering Bottleneck
How high-volume space manufacturing breaks traditional requirements processes — and what constellation operators are doing about it
There is a number somewhere between satellite 10 and satellite 100 where every traditional aerospace systems engineering process quietly breaks.
It breaks not because the engineers are less capable or the standards less rigorous. It breaks because the entire institutional infrastructure of space systems engineering — the document-centric requirement, the milestone-gated review, the manually maintained requirements traceability matrix — was architected around the assumption that you are building one spacecraft, or maybe three, over a decade. When you are building 30 satellites a month, that infrastructure does not slow you down incrementally. It collapses.
SpaceX has launched over 7,000 Starlink satellites. Amazon’s Kuiper program is in active production toward an initial deployment of 3,236 spacecraft. Telesat’s Lightspeed constellation, though smaller at 198 satellites, is being manufactured at a cadence that would have been unrecognizable to the teams that built its predecessor geostationary assets. These programs represent not just a scaling of space hardware production, but a forced reinvention of how systems requirements are created, maintained, and verified across a living, evolving fleet.
This article examines what is actually breaking, what these operators are doing about it, which standards apply and where they fall short, and what the broader systems engineering community can extract from constellation manufacturing as a stress test of the discipline itself.
What Traditional Requirements Processes Were Built For
The canonical aerospace requirements process descends from a lineage optimized for high-cost, low-volume, long-cycle programs. A geostationary communication satellite program that started in 2010 might have had a System Requirements Review in 2012, a Preliminary Design Review in 2014, and a Critical Design Review in 2016. Requirements matured over years. Traceability was maintained in DOORS or a comparable tool, audited at each review gate, and considered stable by the time manufacturing began.
This model has genuine virtues. It forces discipline in requirement decomposition. It creates clear accountability through traceability. It supports certification by providing auditable evidence that what was verified maps to what was required.
Its fundamental assumption, though, is that the requirement set converges — that at some defined point, requirements stop changing and manufacturing begins executing against a stable baseline. That assumption dies the moment you begin constellation manufacturing.
Three Ways Volume Manufacturing Breaks Requirements
1. Variant Management at Scale
No two production lots of a high-volume satellite are identical. Component obsolescence forces hardware substitutions. Supply chain constraints require alternative suppliers for radiation-tolerant components. Antenna designs are iterated based on on-orbit performance data. Software versions diverge across lots as new features are developed.
In a traditional program, a single design change triggers a formal Engineering Change Proposal, a requirements impact assessment, a re-verification event. That process, executed on a 6-week cycle, is incompatible with a production line turning out 30 satellites per month where a component might be substituted in 48 hours to avoid a line stoppage.
What constellation operators need — and what traditional tools do not provide — is a requirements architecture that natively supports variants. Not branches of a document. Not separate requirement sets that engineers manually keep synchronized. A single model in which requirements are structured as a graph, with variant nodes that capture which version of a requirement applies to which configuration of which production lot, with full traceability preserved through every variant without manual reconciliation.
2. Production Lot Acceptance Requirements
A one-off spacecraft has a verification matrix. Every requirement has a verification method — analysis, inspection, demonstration, or test — and a verification closure event. By CDR, that matrix is defined. By delivery, every cell is filled.
A production lot of 60 satellites does not get verified the same way. Statistical lot acceptance replaces 100% verification for a large class of requirements. Environmental stress screening replaces full thermal-vacuum testing for every unit. Software qualification testing is performed once against a software build, with regression suites run on subsequent lots.
This means the requirements themselves must carry different attributes in a production context. A requirement that was verified by test on the engineering model must now specify: verified by test on qualification unit, accepted on production units by lot acceptance test, accepted on subsequent lots by regression. The traceability structure is not linear. It is a web of requirement, verification event, statistical confidence level, lot identifier, and unit serial number.
No spreadsheet manages this. No document-centric tool manages this. Very few requirements management platforms were designed with this data model in mind.
3. On-Orbit Software Delta Requirements
Constellation satellites are not delivered and forgotten. They receive software updates throughout their operational lives — sometimes minor patches, sometimes major capability expansions. Starlink satellites have received software-defined radio configuration updates, orbital maneuvering algorithm updates, and new link protocol implementations via on-orbit software uploads.
Each of those updates is, from a systems engineering standpoint, a requirements event. The software update changes what the satellite does. That change must trace back to a requirement. That requirement must trace forward to the verification that the update was tested before deployment, that the update is compatible with the on-orbit hardware configuration of the units receiving it, and that the update does not violate any higher-level system requirement.
When you are doing this across a fleet of 7,000 satellites with multiple hardware variants and multiple software versions, the traceability problem is not a documentation exercise. It is a data engineering problem. Requirements must be stored and queried as structured data, not retrieved from PDF exports of a DOORS database.
What the Standards Say — and Where They Stop
ECSS-E-ST-10-06C, the European Cooperation for Space Standardization standard on technical requirements, provides a solid framework for requirement quality. ECSS-M-ST-80C covers configuration management, which is directly relevant to variant management. NASA-STD-1006A and NPR 7120.5 address program formulation and systems engineering management.
These standards are not wrong. They correctly identify the need for traceability, configuration control, and verification closure. Their limitation for constellation programs is that they were written with a single-configuration, milestone-driven program model as the implicit context. They do not specify how to manage a requirement that applies to 47 of your 60 production units because 13 units in that lot used a different FPGA due to a spot shortage. They do not address how to version requirements across on-orbit software deltas while maintaining traceability to the original system-level performance specifications.
Industry bodies have recognized this gap. AIAA has convened working groups on model-based systems engineering for constellations. The Space ISAC has touched on configuration management for fleet software. But there is no published standard today that provides specific normative guidance for requirements management in high-volume space manufacturing. Constellation operators are making their own rules.
What the Operators Are Actually Doing
SpaceX does not publish its systems engineering methodology. What can be inferred from public statements, hiring patterns, and former employee accounts is that Starlink operates with an internally developed toolchain that is deeply software-driven, with requirements living in structured data systems rather than traditional requirements management tools. The cadence of Starlink hardware iteration — with multiple hardware generations in production and deployment simultaneously — requires exactly the kind of variant-aware, machine-queryable requirements architecture described above.
Amazon Kuiper has been more public about its approach. Kuiper’s engineering leadership has emphasized model-based systems engineering as a core methodology, with requirements integrated directly into digital engineering environments alongside CAD models, simulations, and test data. Kuiper is building at a cadence that required building its own factory in Kirkland, Washington, and the systems engineering infrastructure is designed to match that cadence.
Telesat Lightspeed, built by MDA and Thales Alenia Space, operates within a more traditional European aerospace supply chain but has publicly committed to digital continuity across design, manufacturing, and operations — meaning requirements must flow through the production and acceptance process as live data, not as milestone documents.
The common thread is not a shared tool or a shared standard. It is a shared architectural principle: requirements are data, not documents. They must be queryable, versionable, branachable, and connectable to test results and configuration records in real time.
What the Broader Industry Can Learn
The constellation programs are stress-testing systems engineering in a way that no other sector currently is. The lessons are transferable — to automotive OEMs managing software-defined vehicle variants, to defense electronics manufacturers building large quantities of a common platform with customer-specific configurations, to any organization where the assumption of a single converging requirement baseline no longer holds.
Four transferable lessons stand out.
Requirements must carry configuration context natively. A requirement is not a statement in isolation. It is a statement that applies to a specific configuration, a specific lot, a specific software version. If your requirements management tool cannot express that context as structured data, you will manage it in spreadsheets, and the spreadsheets will drift.
Verification closure is a continuous process, not a milestone event. Lot acceptance, regression testing, and on-orbit anomaly investigation all generate verification evidence continuously. That evidence must connect to requirements automatically. A manual RTM updated quarterly is not verification closure — it is a compliance artifact that does not reflect the actual verification state of the fleet.
Variant branching is a first-class systems engineering operation. When a hardware substitution or a software update creates a new configuration, that is not a documentation event. It is a requirements event. The tooling must make it possible to branch requirements, preserve traceability through the branch, and reconcile variants without manual copy-and-paste.
AI-assisted change impact analysis is becoming a practical necessity, not a luxury. When a requirement changes in a 5,000-requirement database with 200 production variants, manually identifying all downstream impacts is not a realistic activity. Tools that can analyze change impact across a connected requirements graph — identifying which variants are affected, which test cases are invalidated, which verification events must be re-executed — compress what would otherwise be weeks of engineering labor into hours.
This is where modern requirements tooling is starting to show meaningful differentiation. Platforms like Flow Engineering have been built around exactly this kind of graph-structured, AI-assisted requirements model — designed for teams that need to manage complex variants and trace requirements across large connected systems without losing traceability to the underlying engineering intent. That architectural approach aligns directly with what constellation operators are independently converging on, even if the space production scale is extreme.
An Honest Assessment
The satellite constellation era has exposed a genuine and significant gap between the requirements management practices the aerospace industry has institutionalized and the requirements management practices that high-volume space manufacturing actually needs.
The standards bodies are behind. The legacy tooling is behind. The training and cultural practices of aerospace systems engineering — which still orient around document-driven milestones — are behind.
The operators building these constellations are not waiting. They are building internal toolchains, developing internal process frameworks, and hiring systems engineers who understand that a requirement is a data structure, not a sentence in a Word document.
The broader lesson for the systems engineering community is uncomfortable but important: the processes and tools that earned their credibility on Apollo, on the Space Station, on decades of successful geostationary programs are necessary but not sufficient for the manufacturing cadences that the next decade of space — and defense electronics, and automotive, and other high-volume complex systems — will demand.
The engineers who understand both the domain depth of traditional aerospace systems engineering and the data architecture of modern requirements management are the ones who will define what systems engineering looks like in the constellation era. There are not enough of them yet. Building more of them, and building the tools that make their work tractable at scale, is one of the more important problems in the industry right now.