Agile requirements management keeps engineering intent controlled while allowing it to mature through short build-and-test loops. NewSpace teams separate hard mission, customer and regulatory obligations from lower-level assumptions and solution targets. Responsible engineers propose revisions 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?
The practice treats controlled intent as part of an iterative technical process. The team starts with enough clarity to make the next responsible decision, then refines, derives and verifies obligations as architecture and evidence mature. Every revision still has a reason, owner, affected context and review path.
The central control problem is that teams often give every statement the same apparent authority. A customer obligation, an internal mass target and an experiment hypothesis then travel through one workflow even though changing them has radically different consequences. A three-layer model makes that difference visible before the team chooses review speed.
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.
Separate constraints, design targets and experiment hypotheses
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 statements often behave differently. They may be allocations, derived constraints or implementation 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.
The three-layer control model 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.
| Control layer | Typical contents | Change authority | Evidence expected |
|---|---|---|---|
| Invariant constraints | Mission, safety, regulatory, contractual and external interface obligations | Named programme or external authority | Authoritative source, applicability and formal verification route |
| Design targets | Allocations, budgets, performance goals and coordination limits | Cross-functional technical owners | Trade rationale, margins, affected interfaces and planned proof |
| Experiment hypotheses | Assumptions to test, candidate thresholds and learning objectives | Iteration owner within an agreed risk envelope | Testable prediction, timebox and decision rule |
Lifecycle states still matter inside each layer
A layer describes the type of authority; a state describes how mature the statement is. Candidate, draft, reviewed, baselined, verified and superseded can still be useful states, but a baselined experiment hypothesis does not become a customer obligation. It means the team has agreed what it will test and how it will interpret the result.
Why one backlog is not enough
A single undifferentiated backlog encourages two opposite mistakes: teams either freeze learning items too early or quietly treat true obligations as negotiable. The layer, state and applicable configuration should travel together so an engineer can see both the statement's origin and the freedom available to change it.
Ownership follows the affected decision
Ownership should sit close to the technical work. A responsible engineer understands the obligation, the solution 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 controlled statement 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.
Set change cadence by consequence, not ceremony
A revision begins as a proposal against the current baseline. The owner records the proposed delta, 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 proposals need the relevant authorities. The programme should distinguish exploration from an approved update so engineers can learn without creating several competing truths.
Once approved, the revision propagates to connected records, architecture, work and verification. The old baseline remains reproducible. If the update invalidates evidence, closure reopens or carries an explicit limitation.
Use a dependency 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.
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.
A consequence-based operating cadence
The cadence should follow the consequence and reversibility of the decision, not a fixed software ceremony. A low-risk experiment threshold may change within a daily learning loop; a two-sided electrical interface needs both owners; a launch-provider constraint waits for the named external authority.
| Consequence class | Review cadence | Required record |
|---|---|---|
| Local and reversible | Named owner may review inside the iteration | Proposal, expected learning and rollback condition |
| Cross-domain | Review when affected owners can assess the shared trade | Dependency impact, options and accepted allocation |
| Safety, mission or contractual | Formal authority before implementation | Complete rationale, assurance impact and approval evidence |
| Unknown consequence | Pause approval while uncertainty is bounded | Investigation owner, deadline and decision needed |
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.
Arc can represent each control layer, maturity state and applicable configuration beside the connected architecture, interfaces, tests and evidence. Branches keep proposals separate from the accepted baseline so teams can compare the diff and assess consequences before merging a change.
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?
This approach manages technical intent through short, evidence-led learning cycles. External obligations stay controlled, while assumptions and lower-level constraints mature through reviewed revisions as the team learns from analysis, prototyping 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.
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.
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.