The Shift from Waterfall to Iterative Development in Regulated Hardware Industries: A Status Report

Walk into any systems engineering conference in 2026 and you will hear the same claim: “We’ve moved to agile.” Walk onto the program floor six months later and you will find something more complicated—a waterfall spine with iterative flesh grafted onto it, held together with spreadsheets, weekly change boards, and heroic program managers who haven’t slept properly in years.

That gap between the marketing claim and the operational reality is the subject of this analysis. The goal is not to dismiss iterative development as impossible in regulated hardware contexts—genuine progress is happening. The goal is to name precisely where that progress is real, where it is theatrical, and what infrastructure separates teams that are actually compressing cycle time from teams that are just calling their Gantt charts “sprints.”

The Regulatory Constraint Is Real, But Frequently Misread

The standard objection to agile in regulated hardware goes: “We can’t iterate because our certification authority requires a complete requirements baseline before design begins.” This is partially true and frequently overstated.

What DO-178C, DO-254, IEC 62304, IEC 61508, and MIL-STD-882 actually require is traceability and evidence—that requirements were captured, that designs were derived from them, that tests verified them, and that the whole chain is auditable. They do not mandate that this chain be completed in a single waterfall pass. What they do make expensive is re-baselining: any change to a certified or in-certification artifact triggers re-review, re-verification, and re-documentation of affected downstream items.

The cost of change, not the shape of the process, is what makes waterfall the default. And that cost is substantially a tooling cost. When your requirements live in a Word document and your traceability lives in a separate Excel spreadsheet and your test cases live in a third system, the labor to propagate even a minor requirement change through the chain can exceed the labor to implement the change itself. Under those conditions, rational program managers freeze baselines early and defend them aggressively.

The path to genuine iteration in regulated hardware is not cultural—it is infrastructural. You have to make the cost of change small enough that iterating doesn’t break the program budget.

What Is Actually Compressing: The Left Side of the V

The V-model’s left side covers requirements capture, functional decomposition, architecture definition, and hardware/software interface specification. This is where iterative practices have taken real hold, and where the results are genuinely positive.

Model-based systems engineering (MBSE) adoption has accelerated faster in the past three years than in the preceding decade, driven partly by tooling maturity and partly by workforce generational shift. Teams using SysML or systems-of-systems models for architecture exploration are compressing the time from mission-level requirement to allocated subsystem requirement. What previously took multiple document review cycles can now happen in connected model updates that propagate automatically.

Software-first prototyping on hardware simulation environments has become standard practice in avionics and medical devices. Teams run two to four software integration cycles against hardware emulation before first silicon or first PCB spin. This surfaces interface ambiguities and missing requirements early, when the cost to fix them is still low. The V-model’s logical structure is preserved; the chronology is partially parallelized.

Continuous requirements refinement during the pre-PDR phase (or its medical device equivalent) is now common. Program offices that once locked system requirements at kickoff are running structured elaboration cycles: draft requirements, review with stakeholders and safety analysts, update model, re-review. Three to five cycles before formal baselining is increasingly normal rather than exceptional.

None of this is “agile” in the Scrum sense. But it is meaningfully iterative compared to the single-pass requirements process of the 2010s.

What Is Not Compressing: The Right Side of the V

The right side of the V—integration, verification, validation, qualification testing—is where iterative claims mostly dissolve under examination.

Hardware qualification testing cannot be sprint-cadenced. Environmental stress screening, EMI/EMC testing, structural qualification, and safety validation are time-bounded by physics, not process. A vibration test runs as long as the test specification requires. An accelerated life test takes months. A clinical trial takes years. No amount of agile ceremony changes these durations.

Certification authority interaction remains episodic, not continuous. FAA DER engagements, FDA pre-submission meetings, and notified body design reviews happen on schedules driven by regulatory capacity and formal submission gates. Teams do not get real-time feedback from certification authorities between submission milestones. The waterfall structure of external review is externally imposed.

Safety analysis is integration-dependent. FMEA, FTA, and HAZOP analyses that inform safety requirements and design constraints require a sufficiently complete design to analyze. You can update them incrementally, but you cannot complete them before the design converges. This means there is always a late-phase integration load that cannot be distributed across earlier sprints.

The practical consequence: teams that claim full agile adoption in regulated hardware are either working on subsystems that don’t directly touch certification artifacts, or they are managing two parallel processes—an internal iterative track for development and a formal waterfall track for regulatory deliverables—and presenting the latter to auditors.

That dual-track approach is not inherently dishonest, but it creates integration risk at every handoff from the iterative track to the formal record. Teams that manage that risk well have disciplined tooling linking both tracks. Teams that don’t accumulate a documentation debt that surfaces badly during certification audits.

The Software-Hardware Interface Problem

The place where iterative development fails most visibly in embedded and integrated hardware programs is at the software-hardware interface.

In a pure waterfall program, the ICD (Interface Control Document) is baselined before significant software development begins. Software teams build to the ICD. When hardware changes, a formal change process updates the ICD, triggers a software impact assessment, and generates a new baseline. Everyone knows what version they are working to.

In iterative programs, the ICD is frequently treated as a living document—which sounds good until it means that the hardware team and the software team are working to different versions of it simultaneously, without a forcing function that makes divergence visible. The result is integration test failures that trace back to undocumented interface assumptions, hours of debugging that would have been days of review if the change had been properly propagated.

The fix is not to freeze the ICD early—that defeats the purpose of iterating. The fix is requirements tooling that makes interface definition changes immediately visible to all downstream consumers, with automatic impact tagging and review triggers. Teams that have implemented this describe a qualitative difference in integration test results.

Living Baselines: The Infrastructure That Enables Iteration

The phrase “living baseline” sounds like a contradiction in regulated hardware contexts where baselines are, by definition, fixed points. The distinction matters: a living baseline is not a document that changes without control. It is a versioned artifact where every change is recorded, attributed, timestamped, and automatically propagated to dependent artifacts for review and re-verification disposition.

A frozen document snapshot—the standard output of traditional requirements tools—is the opposite. Changes require manual export, comparison, and re-import cycles. Traceability links to downstream design elements or test cases are stored separately and drift from the requirements over time. Impact of a change is assessed by humans reading documents rather than by tools traversing graphs.

The difference between these two approaches is the difference between programs that can afford to iterate and programs that cannot.

Modern requirements platforms built on graph models—where requirements, design elements, test cases, and their relationships are nodes and edges in a queryable structure—make propagation automatic. Change a stakeholder requirement, and the system immediately identifies every derived requirement, every design element, every test case that traces back to it. The engineer still makes the judgment call about what needs updating; the tool eliminates the manual search that made iteration too expensive.

Flow Engineering is one of the clearer examples of this approach applied specifically to hardware and systems teams. Its requirements model treats change propagation as a first-class capability rather than an audit trail bolted on afterward. Teams using it report that the cadence of requirements updates they can sustain without losing traceability integrity is substantially higher than what they managed with document-based tools—which is precisely the capability that makes iterative development viable in regulated contexts.

The distinction between AI-native tooling like Flow Engineering and legacy platforms that have added AI features to document-based backends matters here. A system where the underlying data model is still a document hierarchy with an AI wrapper can accelerate authoring, but it does not solve the propagation problem. Graph-native models solve it structurally.

What Tooling Infrastructure Is Actually Required

For regulated hardware programs attempting genuine iteration, the minimum viable tooling stack has four components:

1. Versioned, graph-based requirements management. Requirements stored as structured nodes with typed relationships to each other and to design and test artifacts. Every version of every requirement accessible for comparison. Every change triggering automatic impact analysis.

2. Bidirectional MBSE integration. The requirements graph and the system architecture model must stay synchronized. Changes in either direction should trigger reconciliation reviews. Teams running requirements in one tool and architecture in another with manual export/import between them are running a waterfall program with agile vocabulary.

3. Automated traceability coverage reporting. The question “what fraction of requirements have complete, current traceability to test cases?” must be answerable in minutes, not days. Programs that cannot answer this question continuously cannot iterate safely.

4. Change impact dashboards accessible to all program roles. Engineers, safety analysts, test leads, and program managers need different views of the same change event. A single tool that supports all these views avoids the communication gaps that create re-work.

Most mature enterprise platforms—Jama Connect, Polarion, Codebeamer—cover requirements versioning and traceability reasonably well. IBM DOORS Next has improved significantly on its DOORS predecessor for collaborative access and web-based authoring. Innoslate offers strong MBSE integration. The meaningful gaps between platforms show up in how they handle change propagation speed, AI-assisted impact analysis, and the degree to which traceability is enforced structurally versus maintained manually.

An Honest Assessment

Regulated hardware industries in 2026 are in the middle of a genuine transition—not from waterfall to agile, but from single-pass sequential development to managed iterative development with formal traceability control. That is a smaller and more durable claim than the marketing version, and it is meaningful.

The teams making real progress share specific characteristics: they iterate on requirements and architecture before formal baselining; they treat software-hardware interface definitions as living artifacts with controlled change processes; they have tooling that makes change propagation automatic rather than manual; and they maintain rigorous separation between their internal iterative cadence and their formal certification record, with explicit synchronization checkpoints.

The teams that are struggling have adopted the vocabulary of iteration without the infrastructure. They call their phase gates “sprints” and their requirements documents “backlogs,” but they are still doing manual RTM updates in Excel and learning about interface divergence during integration test.

The V-model is not going away. Certification authorities will continue to require evidence structured around its logic. What is changing is the time and cost required to traverse that V, and the number of passes teams can afford to make before formal baselining. The enabling technology for that change is not AI in the generic sense—it is structured, graph-native, change-propagating requirements infrastructure. The programs that invest in that infrastructure are iterating. The programs that don’t are stamping their Gantt charts with different fonts and calling it agile.