1 Overview
Waterfall is a sequential approach to software delivery in which work moves through distinct phases: requirements, design, build, test, and release. Each phase is expected to finish before the next begins, and progress is measured against a plan with milestones or gates. In regulated environments, this structure is not merely a preference; it is often the shape that compliance, audit, and safety obligations take. The method produces documents that map directly to evidence: what was required, what was designed, what was built, how it was tested, and who approved each step. That traceability is the point.
Agile, Scrum, and Kanban are frequently presented as the default modern choices, and for many product teams they are. But regulated work introduces constraints that iterative methods must address explicitly rather than assume away. When a regulator or auditor asks for a defensible record of decisions, a sequential plan with formal gates can answer more directly than a backlog and a burn-down chart. This article examines when Waterfall fits regulated work better than iterations, while being honest about its costs. It does not argue that Waterfall is superior in general, only that it can be the more suitable fit when the dominant risk is compliance and fixed scope rather than market discovery.
2 The problem this method was built to solve
Waterfall emerged from large-scale engineering and construction projects where changes late in the process are extremely expensive and where safety, contractual, or regulatory accountability demands a documented chain of decisions. Software inherited this model because early software projects were often embedded in hardware, defense, aerospace, or enterprise systems where the software could not be released independently of a certified physical product. The problem it solves is coordination under fixed commitments: many specialists must contribute to a single deliverable, and the work must be planned, approved, and evidenced in a predictable order.
In regulated contexts, the problem is not only building the right thing but proving that the thing was built correctly and within approved boundaries. A change to a medical device, a financial calculation, or an aviation component may require revalidation, reapproval, or regulatory notification. Iterative methods handle change well, but they do not automatically produce the formal approval records that regulators expect. Waterfall addresses this by making approval a first-class step: each phase ends with a review, and work does not proceed until the gate is passed. That reduces the risk of discovering a compliance gap late, when rework is most expensive. The trade-off is that it also reduces the opportunity to learn early from working software.
3 How one cycle runs, from ready to done
A Waterfall cycle begins with requirements, where the team documents what the system must do, including regulatory, safety, and contractual constraints. These requirements are reviewed and baselined, meaning they become the approved reference for the rest of the project. Only after that baseline is accepted does design begin. Design translates requirements into architecture, interfaces, data models, and detailed specifications. A design review checks that the design satisfies the requirements and that risks are identified. Once approved, the build phase starts, and developers implement against the frozen design.
After build, the work moves to test, where the team verifies that the implementation meets the requirements and validates that it meets the intended use. Test results are recorded and traced back to requirements. Then comes release, where the product is deployed or delivered, often with documentation, training, and operational handover. Each transition is a gate: a formal checkpoint where named approvers confirm that the phase is complete and that the next phase may begin. Change requests that arise after a baseline are routed through a change-control board, which assesses impact and decides whether to approve, defer, or reject. The cycle ends when the release is accepted and the evidence package is complete. There is no fixed iteration length; the rhythm is defined by milestones and approvals rather than by a repeating sprint cadence.
4 Roles and how they divide the work
Waterfall divides work by phase and by specialty. A project manager typically owns the plan, the schedule, and the coordination across phases. Phase owners, such as a requirements lead, a design lead, a build lead, and a test lead, are accountable for the quality and completeness of their phase. Business analysts or subject-matter experts often support requirements, while architects and senior engineers support design. Testers and quality assurance specialists own verification and validation, and release or operations staff own deployment and handover. A change-control board, usually including representatives from engineering, quality, and compliance, governs changes to baselined artifacts.
This division is clear and auditable, which is a strength in regulated work. Each role has defined responsibilities and produces defined outputs, so accountability is easy to trace. The trade-off is that the boundaries can become walls. When requirements, design, build, and test are separate handoffs, feedback travels slowly, and defects found late may require rework across multiple phases. Communication depends heavily on documents rather than on daily collaboration. In practice, many regulated teams blend this structure with iterative practices, such as incremental builds within a phase or early test involvement, to reduce the handoff cost without abandoning the formal gates that compliance requires. The roles remain, but the interactions become less rigid.
5 Artifacts worth keeping
The artifacts of Waterfall are its memory and its evidence. A requirements specification records what the system must do and the constraints it must satisfy. A design specification records how the system will meet those requirements, including architecture, interfaces, and key decisions. A test plan and test reports record how the system was verified and validated, and a traceability matrix links requirements to design, code, and tests so that coverage can be demonstrated. Change requests and their approvals record how the baseline evolved. Gate approval records capture who approved each phase and when. Release documentation covers deployment, configuration, and operational procedures.
These artifacts are worth keeping because they answer questions that regulators, auditors, and future maintainers will ask. They also support continuity when team members change, which is common on long projects. The risk is treating artifacts as the goal rather than as a means. When documents are produced only to satisfy a process, they can drift from the actual system and lose their value. The healthier approach is to keep artifacts lean enough to be maintained and precise enough to be trusted. In regulated work, the traceability matrix and the approval records are often the most valuable, because they connect intent to evidence. Design and requirements documents matter most when they are updated alongside changes rather than frozen and forgotten.
6 Where this method breaks down
Waterfall breaks down when requirements are uncertain or when the market, technology, or user needs change faster than the phase gates can accommodate. Because feedback arrives late, teams may build the wrong thing correctly, and the cost of correction rises with each phase. In software, where change is often cheap and discovery is continuous, this mismatch can be severe. Regulated work is not immune: regulations evolve, interpretations shift, and new risks emerge. A purely sequential plan can turn those changes into expensive change requests rather than routine adaptation. The method also struggles when the work is exploratory, such as research-heavy features or novel user experiences, where the design cannot be fully specified in advance.
Another failure mode is the illusion of control. A detailed plan and a set of gates can create confidence that does not match reality, especially if the gates become paperwork exercises. When phases are staffed by different people with limited interaction, knowledge is lost at handoffs and defects accumulate. The method can also be slow to deliver value, because nothing reaches users until late in the cycle. For regulated work, the honest position is that Waterfall fits when scope is stable, compliance evidence is the dominant risk, and late change is genuinely expensive. It fits less well when the product must learn from users, when the regulatory environment is shifting, or when the organization can support iterative delivery with equivalent traceability. The choice is about which risk to optimize for, not which method is modern.
7 Frequently asked questions
Is Waterfall ever appropriate for software today? Yes, in contexts where scope is fixed, compliance evidence is mandatory, and the cost of late change is high. Regulated domains such as medical devices, aerospace, and some financial systems often require documented approvals and traceability that a sequential plan provides directly. The method is not obsolete; it is a fit for a particular risk profile.
Can Waterfall and iterative methods be combined? Yes. Many regulated teams use a sequential framework for governance and evidence while allowing iterative work within phases, such as incremental builds, early testing, and regular reviews. This hybrid approach keeps the formal gates that auditors expect while reducing the feedback delay that pure Waterfall imposes. The key is to be explicit about which parts are iterative and how traceability is maintained.
Does Waterfall guarantee compliance? No. Compliance depends on the quality of the evidence and the rigor of the process, not on the label. A poorly executed Waterfall project can produce incomplete or inaccurate documentation, just as a poorly executed Agile project can lack traceability. The method provides a structure; the organization must still do the work of verification, validation, and honest record-keeping. When that work is done well, Waterfall can be a strong fit for regulated delivery.