Waterfall: Securing Requirements with Phase-Gated Development
A phase-gated approach to software development based on Royce's 1970 model, emphasizing sequential stages, documentation, and early risk reduction.
Waterfall is one of the earliest formalized approaches to software development. Often linked to Winston W. Royce’s 1970 paper “MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS”, Waterfall draws from traditional engineering disciplines where predictability, documentation, and phase gates mitigate risk in large, capital‑intensive initiatives (defense, aerospace, infrastructure) with clear goals and clear timelines.
Most of the time it is described as a rigid process of five sequential stages: Requirements, Design, Development, Testing, and Deployment, where each stage must be completed before the next stage can be started. This is true for the initial process Royce presented as a common but fundamentally flawed model, which is risky and invites failure due to its inability to address issues early. This is the diagram that was later named the “Waterfall Model”.
In comparison with the Lean methodology, the Waterfall process is focused on securing the requirements and documenting as much as possible at the cost of increasing the development time and resources, and introducing steps that do not bring value to the customer.
Core Principles
For the rest of the paper, Royce actually advocates introducing an iterative approach to this model, with the preceding and succeeding stages cooperating to provide early feedback. It includes the famous feedback arrows going back from each step to the previous ones, collecting and clarifying requirements to streamline further design and development, and the crucial step of building a “Preliminary Program Design” with substantial documentation before full-scale development.
It is often assumed that requirements can be collected and clarified once, in a dedicated phase, to streamline subsequent design and development. After the requirements are finalized, the team designs the target system before proceeding to coding. Design and development may include building prototypes to validate concepts at a smaller scale, challenge assumptions with fewer resources, and gather early feedback from stakeholders and end users. Prototyping also enables management to assess whether the allocated resources and schedule are sufficient to deliver the project within defined constraints. At this stage, the overall system is designed, and key decisions are made about technologies, algorithms, and data sources.
The intent is to uncover and resolve problems as early as possible by thoroughly inspecting and planning the software before any coding begins. Ignoring these practices pushes defect discovery to later stages and forces costly backtracking to earlier stages such as requirements and design. The resulting design changes can be so dramatic that the original requirements are violated, causing significant losses of time and resources.
Key Practices
In Royce’s model, “Waterfall” is a phase‑gated process with constant feedback between neighboring stages and reinforced by risk‑reduction practices.
Feedback loops between stages: Each stage (requirements, design, implementation, verification, operations) reviews outputs from the next and can send work back for correction. Teams and departments are supposed to collaborate to surface errors and correct them early at lower cost.
Preliminary program design: Produce a high‑level architecture, module decomposition, interfaces, data flow, and performance budgets before completing full analysis to validate feasibility and guide detailed work. The point is to establish preliminary constraints and challenge them during analysis, which precedes the next phase.
Document the design: Maintain specification‑driven artifacts like software requirements, software architecture, service‑to‑service contracts, test plans, and schedules. Produce thorough documentation that ultimately becomes the project’s specification and design. These artifacts enable development and quality assurance teams to understand every aspect of the system and collaborate effectively in later stages.
“Do it twice”: Build a pilot/prototype/simulation to validate architecture, technology choices, throughput/latency, and critical algorithms before committing to a full‑scale build. Today, we would call it a proof of concept implementing the primary features and key selling points as a prototype first and cancel the project if it doesn’t find an audience. This saves resources by avoiding projects that are unrealistic or not actually valuable to customers.
Plan, control, and monitor testing: Start involving testing early, ideally by planning the test process alongside the design phase. Such an approach helps to ensure that every logic path in the software is tested at least once by specialists who could do it properly. Organizing autonomous test groups may help in defining whether the documentation is prepared well enough to follow and to properly test the working software against the collected requirements.
Involve the customer: Make sure the customer is involved in the process at every key phase. The involvement can be formalized through a series of formal reviews during the design stage and requirements gathering, as well as prototype demos and the final acceptance review. This is intended to reduce ambiguity, avoid misunderstandings in requirements, and control scope with recorded approvals.
Strengths and Benefits
Based on the improvement suggestions by the author of the original paper, the Waterfall methodology offers several key advantages:
Separate Responsibility: Clear separation of responsibilities into stages makes it easier to follow the process. Separate departments can focus on their responsibilities and provide detailed feedback on work done by preceding stages. This way, developers can provide detailed feedback on design decisions, and quality assurance can challenge the software implementation against detailed requirements.
Iterative Feedback: Each stage provides feedback on the outcome of the previous stage, allowing multiple teams to collaborate effectively, receive early feedback, and address issues at earlier stages.
Comprehensive Documentation: Each stage contributes to documentation; cumulatively, these artifacts share knowledge about the system across departments and specialists and reduce the bus factor — the risk that only one person understands how the system actually works.
Customer Involvement: The end customer is involved from the requirements‑gathering stage through final software acceptance. Such deep involvement helps reduce misunderstandings in requirements and adds an additional layer of review across the software development life cycle.
Challenges and Considerations
These challenges and drawbacks are based on suggestions from the author of the enhanced Waterfall methodology:
Rigid Processes: In spite of all the efforts to improve the original multistage process, it remains rigid, and any severe changes in design or requirements at later stages will significantly increase the effort and resources needed to complete the project.
Locked‑In Requirements: The process and suggested improvements are targeted to secure requirements early and foresee issues at early stages. Such an approach does not have the agility to incorporate constantly changing customer needs and adapt accordingly.
Monolithic Solutions: The process suggests employing modeling and prototyping, but it still treats the program as a single, complete release cycle — from requirements gathering to final delivery to the customer.
Late Testing: Feedback from quality assurance is provided at later stages and validates only the complete system over previously secured requirements. Significant issues in system design, user experience, or infrastructure may not be discovered until this point. It is extremely challenging to foresee all problems early, and even harder to adapt to changing customer expectations at that stage.
Slow Delivery: Suggested improvements help to fix the initial Waterfall model, but eventually slow down the project and cement all next stages from breaking down the process without bringing any significant value to the customer. The giant amount of documentation requires everyone to contribute to it, write it on almost every step, and support it to make sure the current version aligns with the secured requirements.
Conclusion
Waterfall methodology represents a structured, phase-gated approach to software development that emphasizes thorough planning, comprehensive documentation, and staged progress. While Royce’s original paper advocated for more iteration and feedback than the commonly understood “pure waterfall” model, the methodology remains best suited for projects with stable requirements and predictable outcomes. Understanding both its strengths in providing structure and its challenges in adapting to change is essential for determining when Waterfall is the right choice for your project.
Useful Links
- Managing the Development of Large Software Systems (Royce 1970): The original paper that defined the Waterfall model.
- Waterfall by Steven Zeil: Academic perspective on Waterfall methodology.
- Waterfall Methodology Guide: Modern overview of Waterfall methodology and its applications.