Waterfall Model

Definition: The Waterfall Model is a sequential software process in which the project moves through a fixed series of phases — requirements, design, implementation, verification, maintenance — with each phase completed and formally approved before the next begins. Its defining characteristics are the stage gate (work does not advance without sign-off) and the document as the unit of handoff between specialist teams. It optimizes for predictability, auditability, and contractual clarity, and it pays for those properties with a structural inability to absorb change discovered after a gate has closed.

How It Works

Waterfall is not merely “do things in order.” Every real implementation has three machineries working together: a phase sequence that defines what work happens, a gate mechanism that defines when work is allowed to advance, and a document set that defines how knowledge crosses the boundary between phases. Remove any one and the model stops functioning as designed.

The Phase Sequence

The canonical phases, in the order almost every textbook and standard presents them:

Phase	Primary question answered	Principal output	Typical owner
Requirements	What must the system do?	Requirements specification (SRS)	Business analysts, customer
System design	How is the system decomposed?	Architecture and interface specs	System architects
Detailed design	How does each component work internally?	Module design documents	Designers, senior engineers
Implementation	Build it	Source code, unit tests	Developers
Integration and verification	Does it match the spec?	Test reports, defect logs	QA and test engineering
Deployment	Put it in production	Release package, installation guide	Operations
Maintenance	Keep it correct over its life	Patches, change requests	Sustaining engineering

The sequence is not arbitrary. Each phase consumes the output of the one before it as its authoritative input. Detailed design does not consult the customer; it consults the architecture document. Implementation does not consult the architecture; it consults the module design. This is the model’s core efficiency claim: once a phase is signed off, everyone downstream can treat that artifact as settled truth and stop re-litigating it. It is also the model’s core fragility, because any error baked into an early document propagates silently through every downstream phase until testing exposes it.

Stage Gates and Sign-Offs

The gate is what distinguishes Waterfall from “we happened to do design before coding.” A gate is a scheduled decision point with three properties:

Entry criteria. Defined deliverables must exist and be complete before the review can be held.
A review body. Not the author. Typically a cross-functional board that includes the customer or a customer proxy, QA, and the engineering lead.
A binary outcome with authority. Pass, pass-with-actions, or fail. A failed gate means the phase repeats; it does not mean the next phase starts “at risk.”

Common gate names in formal environments: System Requirements Review (SRR), Preliminary Design Review (PDR), Critical Design Review (CDR), Test Readiness Review (TRR), Production Readiness Review (PRR). These come from aerospace and defense practice and predate software; Waterfall inherited them wholesale from systems engineering, which is exactly where the model came from.

Sign-off is the legal and organizational meaning of the gate. When a customer signs the requirements specification, two things become true at once: engineering gains permission to spend, and the customer loses the free right to change their mind. Everything after that point flows through a change control board (CCB), which prices each change request and decides whether the schedule and budget absorb it. In fixed-price contracting this is the entire commercial mechanism — the specification defines what was bought, and change requests are how additional work gets paid for.

Documentation as the Transfer Medium

In Waterfall, knowledge moves between phases as written artifacts, not conversations. This is a deliberate design choice with real trade-offs.

What it buys you: a specialist team can be swapped out entirely between phases; an auditor two years later can reconstruct why a decision was made; a supplier in another country can implement to spec without daily contact; a certification body can review the design without reading the code. Traceability matrices link each requirement to the design elements that satisfy it and the test cases that verify it, so coverage becomes a computable property rather than a feeling.

What it costs you: documents are lossy. The gap between what a specification says and what its author meant is where a large fraction of Waterfall defects are born. Documents also age badly — the design document that was true at CDR diverges from the code within weeks of implementation starting, and maintaining that synchronization is unglamorous work that gets deprioritized under schedule pressure. The result is the familiar failure mode where the documentation set is simultaneously enormous and untrustworthy.

Feedback, Where It Exists

Pure Waterfall — no backflow at all — is a teaching abstraction, not a practice. Real projects allow feedback to the immediately preceding phase, which is what the classic “cascade with return arrows” diagram depicts. The critical constraint is that feedback is local: verification can send defects back to implementation, and implementation can raise design change requests, but a discovery in verification that invalidates a requirement has to climb back up through every intervening gate, re-opening signed documents at each level. That climb is expensive, politically difficult, and the reason teams under pressure quietly patch around problems in code rather than admit that a requirement was wrong.

The solid arrows are the intended flow. The dotted arrows are the ones that cost money, and the higher up the diagram a dotted arrow reaches, the more it costs.

Why It Matters

It is the default mental model of software in most large organizations. Finance, procurement, legal, and executive reporting all assume a plan with phases, dates, and a fixed deliverable. Even organizations running Scrum at the team level frequently sit inside a Waterfall-shaped funding and governance wrapper. Understanding the model is a prerequisite for negotiating with the people who control budgets.
It defines the vocabulary that every later methodology reacted against. The Agile Manifesto, Iterative and Incremental Development, the Spiral Model, and Extreme Programming (XP) are all legible primarily as answers to specific Waterfall failures. You cannot understand why Agile emphasizes working software over comprehensive documentation without understanding what comprehensive documentation was supposed to accomplish.
It remains legally and commercially embedded. Fixed-price contracts, government procurement rules, and regulated-industry compliance frameworks encode Waterfall assumptions directly. Changing methodology inside those constraints is a contractual problem before it is an engineering one.
It makes progress measurable in a way iterative methods struggle to match. “Design is 80 percent complete” is a defensible statement against a document outline. Iterative methods deliberately refuse that metric, which is more honest but far harder to report upward.
It surfaces the cost-of-change curve more starkly than any other model, which makes it the best teaching vehicle for why feedback latency is the central economic variable in software process design.
It is genuinely correct for some problem classes. Where the specification is externally fixed, where deployment is physically irreversible, or where a certification authority must approve a design before build, Waterfall is not a compromise — it is the appropriate structure.
Its documentation artifacts have real downstream value. Traceability matrices, interface control documents, and formal test plans are how safety cases get built. Teams that abandoned Waterfall wholesale sometimes rediscover these artifacts painfully when they enter a regulated market.
Misunderstanding its history produces bad arguments. The version of Waterfall most practitioners attack is a strawman that its supposed originator also attacked, in the very paper cited as its origin. Getting this right improves the quality of methodology debates considerably.

The Royce Paper: What Actually Happened in 1970

This is the part of the story that almost every introductory treatment gets wrong, and it is worth getting right.

In 1970, Winston W. Royce published “Managing the Development of Large Software Systems” in the proceedings of IEEE WESCON. Early in the paper he presents a diagram: a cascade of boxes labeled system requirements, software requirements, analysis, program design, coding, testing, operations, each flowing into the next. That diagram is the one reproduced in thousands of textbooks as the Waterfall Model.

What those textbooks omit is Royce’s own commentary on it. He introduces the sequential scheme, and then states plainly that the implementation described is risky and invites failure. His argument is specific: testing is the first phase in which timing, storage behavior, and real input/output performance are actually observed, and these are precisely the properties least amenable to analysis on paper. When testing reveals that the design cannot meet them, the required fix is not a code change — it is a design change, sometimes a requirements change. That rework arrives at the point of maximum schedule commitment and minimum remaining budget. The sequential model, in Royce’s framing, guarantees that the most expensive discoveries happen last.

The remainder of the paper — the majority of it — is a set of five recommendations intended to fix this. Paraphrased:

Do a preliminary program design before the requirements are finalized, so that the analysis phase is constrained by what is actually buildable rather than producing a specification that no design can satisfy.
Document the design thoroughly, which is the one recommendation the industry did adopt enthusiastically, arguably to excess.
Do it twice. Build a pilot version of the system first, treat it as a simulation to expose the high-risk areas, and then build the deliverable version informed by what the pilot taught you. In modern language: prototype, then iterate.
Plan, control, and monitor testing as a first-class engineering activity with dedicated specialists, rather than as a phase that absorbs whatever schedule the earlier phases left behind.
Involve the customer in a formal, structured way at multiple points, not only at requirements sign-off and final acceptance.

Read as a whole, recommendations 1, 3, and 5 are arguments for iteration, early risk reduction, and continuous customer feedback. Royce’s proposed process includes explicit feedback loops spanning multiple phases. He was describing something closer to the Spiral Model than to the rigid cascade that bears his diagram.

Two further points of accuracy. First, Royce never used the word “waterfall” — the term appears later, commonly attributed to a 1976 paper by Bell and Thayer, which cited Royce. Second, the model’s formalization into mandatory practice came through procurement standards, most notably the US Department of Defense standard DOD-STD-2167 (1985), which effectively required a document-driven sequential process for defense software contracts. Its successor, MIL-STD-498 (1994), explicitly permitted iterative and incremental strategies precisely because the sequential mandate had produced so many failed programs. So the institutionalization of strict Waterfall lasted roughly a decade in its most rigid legislated form, and the organization that mandated it was also among the first to formally walk it back.

The honest summary: the industry took Royce’s illustration of a problem and adopted it as a solution, discarding the argument that accompanied it. When someone says “Waterfall was never even proposed as a good idea by the person who invented it,” they are essentially correct, and it is one of the more instructive cases of citation drift in engineering history.

The Cost-of-Change Curve

The structural weakness of Waterfall is not sequence. It is feedback latency — the elapsed time between introducing a defect and detecting it. Sequence is merely the mechanism that maximizes that latency.

Barry Boehm’s data, gathered across TRW and IBM projects and published in Software Engineering Economics (1981), showed defect repair cost rising sharply with the phase distance between injection and detection. The frequently quoted figures — roughly 1x in requirements, 5x in design, 10x in coding, 20x or more in testing, and 100x or more in production — are order-of-magnitude illustrations rather than precise constants, and the steepness of the curve varies enormously by system type. But the shape is robust and has been reproduced repeatedly.

If we model cost as growing multiplicatively per phase crossed, a rough form is:

C(n) = C_0 \cdot k^{\,n}

where $C_0$ is the cost of fixing the defect in the phase it was introduced, $n$ is the number of phase boundaries between injection and detection, and $k$ is a per-phase amplification factor typically observed somewhere between 2 and 5 for large systems. With $k = 3$ and a requirements defect found during system test five phases later, $C(5) = 243 \cdot C_0$ .

Why the multiplication happens is more interesting than the arithmetic:

Cost component	Why it compounds
Artifact rework	Every downstream document derived from the wrong requirement must be revised, reviewed, and re-approved
Code rework	Implementation built on the wrong design must be rewritten, not patched
Test rework	Test cases derived from the incorrect specification are themselves wrong and must be re-authored and re-run
Regression risk	Late structural change touches code already verified, invalidating prior test evidence
Gate re-entry	Re-opening a signed document may require re-convening a review board and, in regulated settings, re-certification
Context loss	The engineers who wrote the original design have moved to other work or other employers

Waterfall’s phase structure places the single richest source of information — running the actual system under real conditions — at position five or six in the sequence. Every assumption made in phases one through four remains unvalidated until then. That is the whole critique, stated economically: the model defers learning until the point where learning is most expensive to act on.

The iterative response is not “planning is bad.” It is that shrinking $n$ matters more than improving the accuracy of any single phase. A two-week cycle that ships something real drives $n$ toward zero for the majority of defects, which is why practices like Test Pyramid and TDD and CI-CD Best Practices deliver outsized returns — both are, at heart, feedback-latency reduction machines rather than quality rituals.

One important caveat, in fairness to Waterfall. The curve’s steepness depends heavily on how expensive it is to change the artifact. In a web service with automated deployment, changing production is minutes of work, so short cycles are nearly free and $k$ is small. In firmware burned to mask ROM, in a system whose safety case has been certified by a national regulator, or in software coupled to a physical product already in tooling, late change is not merely expensive but sometimes physically impossible. Where $k$ is enormous and cycle cost is enormous, front-loading analysis is the rational strategy. Waterfall is what you get when you take that reasoning to its conclusion.

When Waterfall Is the Right Choice

A fair hearing requires naming the conditions under which sequential development beats iterative development on its merits. Four hold up.

Fixed Scope Under Regulatory Constraint

When requirements originate from legislation, a standard, or a regulator rather than from users, they are genuinely stable — a tax calculation rule, an emissions reporting format, a payment protocol conformance profile. There is no product discovery to do because no amount of user feedback can change what the law requires. In these projects, iteration buys you very little, while the traceability artifacts Waterfall produces are exactly what the compliance auditor will demand. Building to a frozen specification with a formal verification phase is not a compromise here; it is the shape of the problem.

Safety-Critical Systems With Certification Requirements

Standards such as DO-178C (airborne software), IEC 62304 (medical device software), ISO 26262 (automotive functional safety), and EN 50128 (railway) all require that design and verification evidence be produced, reviewed, and traceable before a system may be certified for use. Requirements-to-design-to-test traceability is mandatory, independence between developer and verifier is mandatory at higher assurance levels, and the certification body reviews artifacts, not commit history. These standards have been updated to permit iterative development, and modern practice does iterate — but the artifact set and the gate structure remain fundamentally Waterfall-shaped because the assurance argument depends on them.

Hardware-Coupled Projects

If software ships in a device, the software schedule is subordinate to the hardware schedule, and hardware has real gates: tooling is cut, silicon is taped out, a production line is committed. A design change after tape-out costs millions and months. Under those conditions the software’s interfaces must be frozen when the hardware freezes, whether or not the software team feels ready. Interface control documents and formal design reviews are not bureaucracy; they are the only mechanism by which two teams with wildly asymmetric change costs can commit to each other.

Fixed-Price Contracts and Procurement

A fixed-price contract requires a definition of “done” specific enough that a court could adjudicate it. That definition is a specification, and a specification implies a requirements phase producing a signed artifact. Agile contracting models exist — time-and-materials, capped time-and-materials, incremental delivery contracts — but many public procurement regimes do not readily permit them. If your commercial structure requires a fixed deliverable at a fixed price, you have already chosen a Waterfall-shaped process; the remaining question is only how much iteration you can smuggle inside each phase.

A fifth, weaker case worth mentioning: short projects with well-understood domains. A four-week migration of a known system to a known target, done by a team that has done it before, gains almost nothing from iterative ceremony. The reason this case is weaker is that teams systematically overestimate how well they understand their own domain.

The Change Control Loop

Once requirements are signed, the change control board becomes the only legitimate path for altering scope. Understanding this loop is understanding how Waterfall actually behaves under pressure, because it is the mechanism that decides whether new information gets acted on or buried.

The rejected branch is where Waterfall projects accumulate their real damage. A rejected change request does not make the underlying problem disappear; it relocates it into the code as a workaround that satisfies the letter of the specification while diverging from its intent. Repeated across a program, these workarounds are the origin of the phenomenon where a system passes every test case and still fails to do what anyone wanted.

Three properties determine whether the loop is healthy:

Property	Healthy	Pathological
Turnaround time	Days	Weeks, so engineers route around it
Approval rate	Change is priced and often accepted	Near-zero, making the board a scope shield
Who may raise a request	Any engineer who finds a conflict	Only management, so field knowledge never reaches the board

A board that meets monthly and approves nothing is functionally equivalent to having no feedback path at all, which returns the project to the pure sequential model Royce warned about.

Variants and Hybrids

Almost nobody ships pure Waterfall. The named variants are attempts to keep the gate structure while recovering some feedback.

Modified (or feedback) Waterfall. Explicit backflow arrows to the immediately preceding phase are permitted without a formal change request. This is the practical baseline in most organizations and is what Royce’s diagram already showed.
Sashimi (overlapping phases). Named for the overlapping slices, this variant lets a phase begin before its predecessor formally closes — detailed design starts on the stable portions of the architecture while the contentious portions are still being argued. It shortens the schedule and recovers some feedback, at the cost of rework when the overlapped assumptions turn out wrong.
Incremental Waterfall. Requirements are gathered once for the whole system, then implementation and delivery are split into several sequential releases. Requirements risk is unchanged, but integration and delivery risk are broken into manageable pieces. This is the most common large-enterprise compromise.
Waterfall with prototyping. A throwaway prototype is built during or before requirements specifically to expose usability and performance unknowns, then discarded. This is Royce’s “do it twice,” and it is the single highest-leverage modification available to a sequential project.
V-Model. The verification activity for each specification level is planned concurrently with that specification rather than deferred to a test phase. Test design becomes a design review technique: writing the acceptance test for a requirement is one of the cheapest ways to discover that the requirement is ambiguous.
Water-Scrum-Fall. The observed reality in most large enterprises: a Waterfall requirements and funding phase at the front, Scrum in the middle for delivery, and a Waterfall release and governance phase at the back. It is widely mocked and widely practiced. Its honest defense is that the front and back segments are usually imposed by finance and compliance rather than chosen by engineering.

The pattern across all of these is the same trade: each variant buys back a measure of feedback by relaxing exactly one Waterfall constraint — gate strictness, phase disjointness, delivery atomicity, or the ban on building anything before design is final. Which constraint you can afford to relax is determined by the external forces on the project, not by preference. Techniques such as Feature Flags and disciplined Semantic Versioning extend the same logic into delivery, letting a nominally sequential program decouple “shipped” from “switched on.”

Comparison

Dimension	Waterfall	Iterative and Incremental Development	Scrum
Unit of delivery	The complete system, once	A growing increment per cycle	A potentially shippable increment per Sprint
Requirements handling	Frozen at sign-off, changed via CCB	Baselined per iteration, refined between	Living Product Backlog and Refinement, reordered continuously
Feedback latency	Months to years	Weeks to months	Days to weeks
Primary risk strategy	Analyze exhaustively up front	Attack highest-risk items in early iterations	Deliver value early, inspect and adapt
Documentation	Heavy, formal, gate-controlled	Moderate, maintained per increment	Light; working software is the primary measure
Change cost profile	Rises steeply with phase distance	Bounded roughly by iteration length	Bounded roughly by sprint length
Progress measure	Phase and document completion	Features accepted per increment	Velocity and Burndown Charts against Definition of Done
Team structure	Specialist teams handing off sequentially	Often cross-functional per increment	Cross-functional, self-managing, stable
Customer involvement	Requirements sign-off and acceptance	Per-increment review	Continuous; Product Owner embedded
Fits best when	Scope fixed externally, change costly	Scope broadly known, risks concentrated	Scope emergent, feedback cheap and fast
Fails worst when	Requirements are uncertain or evolving	Increments are not genuinely integrated	Organization funds and governs by fixed scope

Two adjacent models deserve separate mention. The V-Model is Waterfall folded at the midpoint so that each specification phase pairs with the verification activity that validates it — requirements with acceptance testing, architecture with integration testing, module design with unit testing. It does not remove the sequencing constraint; it makes test planning concurrent with design instead of an afterthought, which is a real improvement and the reason it dominates automotive and medical device practice. The Spiral Model is closer to what Royce actually argued for: repeated cycles of objective-setting, risk analysis, engineering, and evaluation, where risk magnitude rather than a fixed phase list determines what to do next.

Real-World Use Cases

Avionics software certified under DO-178C. Flight control and display software at Design Assurance Levels A and B is developed against frozen requirements with full bidirectional traceability, independent verification, and structural coverage analysis. The certification liaison process assumes reviewable artifacts at defined milestones.
Class III medical device firmware under IEC 62304. An infusion pump’s dosing software requires documented risk analysis, a design history file, and verification evidence submitted to a regulator before market clearance. Late redesign can invalidate an entire submission.
NASA flight software. Historically developed through formal SRR/PDR/CDR gates. The Space Shuttle’s primary avionics software, produced under this regime, achieved defect densities orders of magnitude below industry norms — at a cost per line that only a program of that criticality could justify.
Core banking and payment scheme conformance. Implementations of card scheme mandates or real-time payment rails work to externally published, versioned specifications with fixed compliance deadlines. The specification genuinely does not change in response to your feedback.
Government procurement programs. Large public-sector systems tendered on fixed-price contracts with statutory requirements. The UK’s post-2013 shift toward agile delivery in government digital services was explicitly a reaction to repeated failures of this model at scale — instructive in both directions.
Automotive ECU development under ISO 26262. Software for braking, steering, or powertrain control follows a V-Model derived from Waterfall, with the software release synchronized to vehicle program gates that are set by manufacturing, not engineering.
Industrial control and railway signalling under EN 50128. Systems where an operational failure is a safety event, deployment windows are measured in scheduled maintenance outages, and every change requires re-verification of the safety case.
Data center or ERP migrations with a hard cutover. A single scheduled switchover with a rehearsed rollback plan is sequential by nature: you cannot iterate a cutover, only rehearse it.
Construction-coupled building systems. Access control, HVAC control, and building management software installed during construction inherits the construction schedule, where phases are enforced by physics and by trade sequencing.

Common Pitfalls

Treating the Royce strawman as the real model. Arguing against a process nobody defends wins nothing. The serious defense of sequential development rests on external constraint and change cost, not on a belief that requirements can be perfectly known. Engage with that argument or you are shadowboxing.
Freezing requirements the customer could not have known. Sign-off transfers risk, it does not eliminate it. When a customer signs a specification for a system they have never seen operate, the signature documents an assumption rather than a decision. Prototypes and mockups before sign-off convert some of that assumption into knowledge at low cost.
Compressing the test phase to absorb upstream slippage. Because verification sits last, it is the only phase with a variable end date under a fixed deadline. Every phase overrun is silently paid for out of test time, which means the phase that discovers defects is systematically starved exactly when the project has accumulated the most of them.
Confusing document completeness with progress. A signed design document is evidence that a document exists, not that the design works. Phase-completion metrics report the production of artifacts and are blind to whether those artifacts are correct — which is why Waterfall projects so often sit at “90 percent complete” for half their duration.
Big-bang integration. Deferring all component integration to a single late phase concentrates the hardest, least predictable work into the window with the least remaining schedule. Continuous integration is the direct countermeasure; see CI-CD and CI-CD Best Practices.
Letting the change control board become a change prevention board. A CCB exists to price change and decide deliberately. When its practical function becomes rejecting everything to protect a date, requirements defects stop being reported and start being worked around in code, producing exactly the Code Refactoring and Technical Debt that the process was meant to avoid.
Adopting Waterfall’s ceremonies without its constraints. Some teams run sequential phases and heavy documentation in a context where requirements are genuinely volatile and deployment is cheap. This is the worst combination available: all of the rigidity, none of the assurance benefit, and no external constraint that justifies either.
Declaring “agile” while funding and governing by fixed scope. The mirror failure. Two-week sprints inside an annual budget cycle that committed to a fixed feature list on a fixed date produces sprint ceremonies wrapped around a Waterfall plan, and the team absorbs the contradiction as overtime. Methodology has to reach procurement and finance or it is theater.
Ignoring architectural feedback from implementation. Developers discover, early and cheaply, that a design element cannot work. If the only path for that knowledge is a formal change request against a signed document, the rational individual response is to implement something that technically conforms while quietly diverging from intent.
Assuming maintenance is a small tail phase. For long-lived systems, post-release maintenance routinely consumes more total effort than original development. A model that treats it as the last box in the diagram tends to under-resource it and to under-invest in the code qualities — see SOLID Principles and Design Patterns Overview — that make maintenance survivable.

SDLC (Software Development Life Cycle) — the umbrella concept; Waterfall is one arrangement of its phases
Requirements Engineering — the discipline Waterfall depends on most heavily and stresses most severely
V-Model — Waterfall folded so that each specification phase pairs with its verification activity
Spiral Model — Boehm’s risk-driven cycle, much closer to what Royce actually recommended
Iterative and Incremental Development — the direct structural alternative, and older than most people assume
Agile Manifesto — the 2001 statement of values written in explicit reaction to document-driven process
Scrum — the dominant modern framework at the opposite end of the feedback-latency spectrum
Test Pyramid and TDD — the practice that collapses the defect detection delay Waterfall maximizes

Example

A medical device manufacturer is building the control software for a new volumetric infusion pump. The device is Class III in the target market; the software is classified Safety Class C under IEC 62304, meaning a failure could cause death or serious injury. The dosing hardware — the pump mechanism, the sensor package, the display board — is being developed in parallel by a hardware team whose tooling commitment date is fourteen months out and immovable, because the injection molds for the enclosure take four months to cut and the production line slot was booked a year ago.

The team runs a Waterfall process, and it is the right call for reasons that have nothing to do with methodology preference. A hazard analysis produces a set of safety requirements that are not negotiable and not subject to user feedback: the pump must detect an occlusion within a bounded time, must fail to a safe state on any sensor disagreement, must not permit a dose rate outside the configured envelope. These flow into a requirements specification that is reviewed by engineering, quality, and regulatory affairs, and signed. Architecture follows, and the interface control document between software and hardware is frozen at PDR — after that date the hardware team is cutting metal against those pin assignments and timing budgets. A traceability matrix links every safety requirement to the design elements that implement it and the verification cases that will demonstrate it, because the regulator will read that matrix.

Then verification finds the problem the model is bad at. During system test, eleven months in, the team discovers that the occlusion-detection algorithm cannot meet its timing requirement across the full range of fluid viscosities the device is specified to handle, because the pressure sensor’s noise floor at low flow rates forces a longer averaging window than the requirement allows. This is not a coding defect. It is a requirements-level conflict between two signed documents, discovered five phases after it was introduced, and the fix touches sensing hardware that is already in tooling. The change control board convenes. Adding a second sensor is rejected — the board is committed. The team lands on a software-only mitigation: a two-stage detection scheme that declares a provisional alarm early on a coarse threshold and confirms it with a longer window, meeting the timing requirement for the alarm signal while accepting a specified false-positive rate that clinical affairs judges acceptable. It costs seven weeks of rework across the design document, the code, the verification suite, and the hazard analysis, and it consumes essentially all of the schedule margin.

The instructive part is the counterfactual. Under Scrum, the timing conflict would likely have surfaced in month three, when a bench prototype first ran the algorithm against real sensor data — and the hardware team could still have changed the sensor. That is the cost-of-change curve making its argument in a single concrete case. But the counterfactual is not free either: the regulatory submission still requires the full artifact set, the hardware freeze date still exists, and a team iterating on emergent requirements would have had to reconstruct the traceability evidence retroactively. The right lesson is narrower and more useful than “Waterfall bad.” It is Royce’s third recommendation, unchanged since 1970: build it twice. A throwaway pilot of the highest-risk subsystem, run against real hardware before the interface freeze, would have bought this project its seven weeks back — without giving up a single artifact the regulator required.

Referenced by

Dig deeper

Spot an error in this note?