Agile requirements management keeps engineering intent controlled while allowing it to mature through short design, build and test loops. NewSpace teams separate hard mission, customer and regulatory obligations from lower-level assumptions and design constraints. Responsible engineers propose changes as evidence arrives, and the programme preserves traceability, impact review, verification and approval instead of freezing uncertainty too early.
This is not software user-story management copied onto a launch vehicle. Hardware has physical inventory, supplier lead times, test facilities, safety responsibilities and configuration-specific evidence. Agility comes from reducing the time between learning and a controlled engineering response, not from pretending those constraints do not exist.
What are agile requirements?
Agile requirements are requirements managed as part of an iterative engineering process. The team starts with enough controlled intent to make the next responsible decision, then refines, derives and verifies requirements as architecture and evidence mature. Every change still has a reason, owner, affected context and review path.
Flow's article on agile requirements in NewSpace emphasises responsible-engineer ownership, cross-links, faster changes and continuous verification. Those are useful practices, but they become dependable only when the programme also defines authority, baseline meaning and the difference between a candidate constraint and an accepted obligation.
NASA's systems-engineering guidance describes its processes as iterative and recursive. That is a reminder that formal systems engineering is not inherently a one-pass waterfall. The real choice is whether the organisation lets new evidence update the connected technical baseline efficiently or forces engineers to work around a stale one.
Which requirements should remain hard?
Some requirements are external obligations. They come from the mission, customer, launch provider, regulator, safety case or contract. They may still change, but the team cannot change them through a local design decision. The applicable authority and downstream commercial or assurance process must be involved.
Lower-level requirements often behave differently. They may be allocations, derived constraints or design choices created to coordinate teams. A 100-kilogram subsystem limit might be a negotiated allocation rather than an immutable mission need. If a 10-kilogram increase produces a larger system-level saving, the programme should be able to assess the trade.
Agile requirements management makes this distinction visible. Hard does not mean unexplained, and flexible does not mean uncontrolled. Every important statement still needs source, rationale, owner and maturity.
What lifecycle states do iterative requirements need?
| State | Meaning | Permitted use |
|---|---|---|
| Candidate | Proposed intent or constraint under exploration | Trade studies and early design, clearly provisional |
| Draft | Owned statement with developing rationale and traceability | Cross-functional review and analysis |
| Reviewed | Technically assessed for the current maturity | Iteration planning and controlled implementation |
| Baselined | Approved obligation for a named configuration and baseline | Formal design and verification control |
| Verified | Accepted evidence shows conformity for the applicable configuration | Closure and release subject to change control |
| Retired or superseded | No longer active, with reason and replacement preserved | History and impact reference |
The exact names can differ. The key is that an engineer can see how much authority and evidence a requirement carries. Treating every early statement as baselined creates unnecessary resistance to learning. Treating every statement as a note prevents reliable coordination.
Who owns agile requirements?
Ownership should sit close to the engineering work. A responsible engineer understands the requirement, the design that must satisfy it and the evidence that will prove it. They can identify when a constraint is unrealistic and initiate a trade rather than silently working around it.
Ownership is not unilateral approval. A requirement can have a technical owner, source authority, interface collaborators, verification owner and formal approver. The programme should show those roles rather than hiding them behind one assignee field.
Systems engineers protect mission coherence, relationship semantics, interfaces and the quality of the process. They help local owners see second-order effects and escalate changes that need wider authority. This is more valuable than acting as a document switchboard between disciplines.
How should requirements change during an iteration?
A change begins as a proposal against the current baseline. The owner records what is changing, why new evidence supports it and which configuration or iteration it affects. The team then performs a proportional requirements change impact analysis.
Low-consequence edits can use lightweight review. Interface, safety, mission or contractual changes need the relevant authorities. The programme should distinguish a proposal from an approved update so engineers can explore without creating several competing truths.
Once approved, the change propagates to connected requirements, architecture, work and verification. The old baseline remains reproducible. If the change invalidates evidence, closure reopens or carries an explicit limitation.
Why do agile requirements need a network, not only a hierarchy?
Parent-child decomposition remains important. It shows how mission and system intent flows to lower levels. Complex hardware also needs cross-links. Thermal, power, software, structural and operational constraints interact across branches of the hierarchy.
Those lateral relationships are where many changes propagate. A payload data-rate increase can affect onboard compute, power, thermal rejection and ground operations even when those items do not share one immediate parent. Relationship types should explain whether one item derives from, allocates, satisfies, interfaces with or verifies another.
A dense graph is not automatically useful. Teams should create links that answer engineering questions and have ownership. Unlabelled similarity links add noise and make impact analysis harder.
How does verification stay agile?
Verification begins when the requirement is written, not after detailed design. The owner and verification team agree how the current statement could be shown to be true. Early evidence may come from analysis, simulation or a breadboard. Later evidence becomes configuration-controlled and formal enough for the applicable review or certification purpose.
Each iteration should have explicit learning and verification objectives. The team asks which assumptions must be retired, which interfaces need integrated evidence and which requirements are mature enough for formal closure. Read the continuous verification guide for the full evidence model.
Do stage gates still matter?
Yes. PDR, CDR and other gates create useful boundaries for commitments, risk and evidence. Agile requirements management reduces the amount of discovery deferred to the gate. Reviewers assess a living record that has been updated through the iteration rather than a document assembled from stale local copies.
A gate can also protect the team from uncontrolled scope. The programme decides which changes belong in the current baseline, which move to a later iteration and what evidence must be complete before proceeding. Agility without a boundary becomes permanent work in progress.
What does a practical operating cadence look like?
The cadence should follow the product, not a fixed software ceremony. A simulation loop may run daily, an electronics revision every few weeks and an integrated vehicle iteration every few months. Requirements review should be close enough to the learning that teams do not continue against known-wrong intent.
| Cadence | Requirements activity |
|---|---|
| Continuous | Owners comment, propose changes and attach new evidence |
| Iteration planning | Confirm learning goals, candidate scope and applicable baseline |
| Cross-functional review | Resolve interfaces, trades and high-impact proposals |
| Iteration close | Accept evidence, update maturity and carry unresolved risk |
| Formal gate | Approve the defined baseline and programme commitment |
What are the common failure modes?
- Everything stays flexible: contributors cannot tell which requirement is authoritative.
- Everything freezes early: engineers learn but the baseline does not respond.
- Ownership has no authority: assignees maintain text but cannot resolve the trade.
- Changes happen in chat: decisions are fast but the programme record remains stale.
- Verification trails behind: test cases and evidence continue to support old intent.
- Iterations optimise subsystems: local speed increases system-level integration risk.
How should a NewSpace team introduce agile requirements?
- Select one active subsystem or cross-domain interface with real change pressure.
- Separate external obligations from internal allocations, assumptions and design constraints.
- Define requirement states, relationship meanings, technical owners and approval roles.
- Connect the current requirements to architecture, interfaces and planned verification.
- Run one proposed change through a visible diff, impact review and approval.
- Close the iteration by updating evidence, maturity, decisions and unresolved risk.
- Expand when contributors trust the baseline and the review latency is improving.
How Arc supports agile requirements management
Arc gives engineers a connected workspace for requirements, architecture, systems, interfaces, tests and evidence. Configurable item types and states let the programme distinguish candidates from approved obligations. Technical ownership and relationships stay beside the engineering context.
Branches provide a safe place to propose work. Teams can compare the diff, assess affected items, discuss the trade and merge accepted changes into the baseline. Agents can help draft, find traceability gaps and monitor verification, while engineers retain decision authority.
Related reading
Compare the wider development methods in agile versus waterfall for hardware, and use the SpaceX requirements-management article for a public operating-model case study.
Frequently asked questions
What are agile requirements?
Agile requirements are requirements managed through short, evidence-led learning cycles. External obligations stay controlled, while assumptions and lower-level constraints can mature through reviewed changes as the team learns from design, analysis and test.
Can requirements change after PDR or CDR?
Yes, when the programme follows its change-control and configuration rules. The change should state the reason, affected baseline, impact, required reverification and approval authority.
Who owns a requirement on an agile hardware team?
The responsible engineer closest to the implementation should usually own its technical meaning and evidence, while systems, safety, programme or customer authorities retain the reviews and approvals appropriate to the requirement.
Does agile requirements management remove documentation?
No. It keeps documentation and structured records current in smaller increments. The aim is useful, traceable information rather than large periodic reconstruction exercises.
How do agile requirements work with certification?
The team preserves applicable obligations and evidence while allowing controlled learning within them. Formality, independence and verification rigour increase as the product and certification baseline mature.