SpaceX requirements management appears to work by putting technical ownership close to the hardware, treating many internal requirements as challengeable design criteria, and connecting those criteria to frequent testing. Public accounts describe a development system in which responsible engineers negotiate interfaces directly, systems specialists protect the wider mission, and verification evidence arrives throughout development instead of at the end.
That is the short answer. The more useful answer is that SpaceX does not seem to have abolished systems engineering. It has redistributed much of the work. Requirements ownership, interface negotiation and verification are treated as part of engineering rather than as a separate document service.
We should be careful with the claim. SpaceX has not published a complete internal requirements-management manual, and this article is not endorsed by the company. It brings together public descriptions from Flow Engineering, established NASA systems-engineering guidance and the practical lessons that other space teams can apply without pretending to copy a private operating system.
How does SpaceX manage requirements?
The public picture is less about one special tool and more about a clear ownership model. The engineer responsible for a component or subsystem also owns the reasoning behind it. That person is expected to understand the requirements that constrain the design, challenge them when a better system trade exists, coordinate with neighbouring teams and show evidence that the resulting hardware works.
Flow Engineering describes these people as responsible engineers, or REs. Its account of SpaceX systems engineering argues that design owners must also be able to own and question lower-level requirements. This matters because a requirement that looks sensible within one subsystem can make the complete vehicle heavier, slower or harder to verify.
NASA uses different language, but its public guidance reinforces the importance of iteration. The NASA Systems Engineering Handbook describes system design processes as interdependent, highly iterative and recursive. The contrast is not simply SpaceX equals agile and NASA equals waterfall. Both recognise iteration. The difference is how quickly information, authority and evidence move through the organisation.
What is the Bill of Design?
Flow describes an internal concept called the Bill of Design, or BOD. A traditional bill of materials tells a team what physical items make up a product. A Bill of Design is presented as a record of why those items exist, who owns them, which design criteria apply and how compliance will be demonstrated.
That shift from parts to intent is important. A part number is naturally sticky. Once it exists in procurement, CAD and manufacturing systems, people begin to protect it. A design unit defined by an objective is easier to reconsider. If the team finds a simpler way to meet the same objective, the old part can disappear without losing the engineering reason it served.
The public Bill of Design account connects design units, responsible engineers and automated verification. That is a useful model for requirements management because it places the requirement beside the owner and the evidence, rather than leaving those facts in separate systems.
For another space company, the lesson is not to rename a bill of materials. It is to create a connected record that answers four questions: what outcome is required, why is it required, who can make the trade, and what evidence will prove the result?
Why call some requirements design criteria?
Words shape behaviour. The word requirement often sounds permanent, especially when it arrives in a spreadsheet with an identifier and a shall statement. Some constraints really are hard. Customer obligations, safety limits, regulatory commitments and mission-level performance targets need formal control and verification.
Lower-level constraints are different. They are frequently design decisions that have been decomposed into requirement-shaped statements. Treating every one of them as equally fixed can stop engineers from proposing a better trade.
Public descriptions of the SpaceX approach use the term design criteria for many internal constraints. A criterion still guides the work, but the language invites challenge. If increasing one subsystem limit produces a much better vehicle-level result, the responsible engineers can discuss the change with the affected owners rather than treating the original number as untouchable.
This does not mean casual change. A criterion needs version history, rationale, affected relationships and review status. The psychological flexibility only helps when the programme can see the consequences. Otherwise, challengeable requirements become untracked decisions.
What does a responsible engineer actually own?
Ownership is more than having a name in a spreadsheet column. The responsible engineer needs authority to make local decisions and a duty to protect the complete system. That includes understanding incoming constraints, defining outgoing interfaces, coordinating verification and escalating trades that cross subsystem boundaries.
In Flow’s discussion of agile systems engineering, former Anduril chief engineer Adam Thurn describes the need for “fast, aligned movement in a changing environment.” That is a good description of what requirements management should enable. A controlled baseline matters, but it should not force every decision through a central queue that lacks the local technical context.
The model also changes the role of a systems team. Systems engineers do not vanish. They focus on mission coherence, interfaces, second-order effects, risk and the health of the requirements process. They help responsible engineers see across the network and intervene where a local optimisation harms the whole vehicle.
A practical ownership record therefore needs more than an assignee. It should show review authority, collaborators, affected interfaces, verification responsibility and the current maturity of the requirement. Ownership becomes visible behaviour, not a directory field.
How can direct engineer-to-engineer communication stay controlled?
Direct communication is faster than routing every question through a central function, but speed can create a new problem. Two engineers can agree on a change while other affected teams remain unaware. The programme then has a quick decision and a slow surprise.
The answer is a networked model with a shared record. Engineers should be able to negotiate directly, while the requirement, rationale, proposed change and affected relationships remain visible to the programme. Reviews then focus on the actual diff and its impact instead of reconstructing what was said in a meeting.
This is where requirements software earns its place. It should not replace the conversation. It should preserve the result, identify downstream effects and make the decision reviewable. A useful workflow gives engineers a safe branch for a proposed change, shows which requirements and tests are connected, records comments in context and merges an approved update into the baseline.
The distinction matters. Centralised communication makes the systems team a switchboard. Networked communication without traceability creates chaos. Networked communication with a connected programme model creates speed with memory.
How does verification support speed?
Fast development only compounds when each iteration produces trustworthy information. If a team builds quickly but cannot connect the result to the criterion it tested, the next iteration starts with an argument about evidence.
The Bill of Design account describes clear verification paths and readable go or no-go status. The exact SpaceX implementation is private, but the principle is familiar: define how a criterion will be verified while the design is still moving, then keep test cases, results and evidence attached to that criterion.
NASA guidance similarly distinguishes verification from validation. Verification asks whether the product meets its specified requirements. Validation asks whether the resulting system fulfils the intended use. A fast team needs both. Frequent component tests can show that the design meets local criteria, while integrated tests reveal whether those criteria were the right ones.
Continuous verification does not mean every early prototype needs certification-grade evidence. Evidence maturity should match product maturity. Early work may use analysis, simulation and rough tests to retire uncertainty. Later baselines need controlled procedures, calibrated equipment, review records and traceable closure. The connection should remain intact as the evidence becomes more rigorous.
Does this approach remove formal reviews?
No. It changes what the team brings to them. A programme that keeps requirements, decisions and evidence current does not need to rebuild its status immediately before PDR or CDR. The review becomes a decision point over a living record, not a recovery project for stale spreadsheets.
Stage gates still create valuable boundaries. They help a programme decide which changes belong in the current iteration, which risks are acceptable and which evidence must be complete before proceeding. The goal is not to eliminate control. It is to avoid using the gate as the only moment when cross-functional alignment happens.
What can another space team adopt?
A team does not need SpaceX’s organisation, budget or risk posture to improve its requirements process. It can start by moving ownership and evidence closer to the engineering work.
- Separate hard external obligations from internal design criteria that can be challenged through review.
- Give every important requirement a responsible engineer, rationale, affected relationships and verification method.
- Let engineers propose changes directly while preserving the diff, discussion and approval in a shared system.
- Trace tests and evidence to requirements from the first useful prototype, then increase rigour as the design matures.
- Use systems engineers to protect interfaces, mission outcomes and cross-programme impact rather than to manually relay every update.
Start with one subsystem and one active change. Import its requirements, identify the real owners, link the current verification evidence and map the immediate upstream and downstream relationships. Then run the next change through the connected workflow. The value should be visible in the quality and speed of that decision.
Where does Arc fit?
Arc is built around this connected model of engineering work. Requirements, architecture, systems, tests and evidence live in one structured workspace. Engineers can propose changes in branches, compare diffs, review the impact and merge approved work into the programme baseline.
Agents can help draft requirements, identify traceability gaps, assess change impact and monitor verification coverage. Engineers still own the meaningful decisions and approvals. The aim is not autonomous engineering. It is to remove the manual coordination that prevents responsible engineers from working responsibly.
If your team is trying to move beyond requirement spreadsheets without adopting a rigid schema, explore Arc’s requirements workspace or book a working session.
Related reading
For the broader foundation, read what requirements management means for space teams. For the wider operating model, read Agile vs Waterfall for Hardware. For the information problem behind distributed ownership, see why requirements break across Excel, Word and teams.
Frequently asked questions
Does SpaceX use requirements management?
Public descriptions indicate that SpaceX manages mission constraints, design criteria, ownership and verification, although its complete internal process and toolset are not public. The distinctive feature appears to be how much ownership sits with responsible engineers.
What is the difference between a requirement and a design criterion?
A hard requirement represents an obligation that needs formal control and verification. A design criterion guides an internal solution and can be challenged when a better system-level trade is available. Both still need rationale, ownership and change history.
Is the Bill of Design the same as a bill of materials?
No. A bill of materials records the physical items in a product. Public accounts describe the Bill of Design as a structure around design intent, criteria, ownership and verification.
Can agile systems engineering work in a safety-critical programme?
Yes, if iteration is controlled and evidence maturity grows with product maturity. Frequent learning does not remove formal verification, configuration management or review obligations.
What is the first practice a smaller team should copy?
Give each important requirement a real owner and connect it to its rationale, relationships and verification evidence. That single change exposes gaps that a spreadsheet often hides.
Evaluate Arc
Try Arc on a representative engineering workflow
Start with one requirement set and test traceability, change control, review and verification in a private Arc workspace.