The waterfall model is a way to run a software project in fixed phases, where each phase is finished and signed off before the next one begins. It is also called the waterfall methodology, and it is one of the oldest ways to organize software work. This guide explains how it works and gives a simple test for when it fits a custom software development project.
How the waterfall model works in software engineering
In software engineering, the waterfall model is a sequence of phases that each run once, in order. Requirements come first, then design, development, testing, deployment, and maintenance, and work moves back only when something goes wrong.
The model is a way of sequencing the software development life cycle, not a different process. The waterfall SDLC model keeps the same phases as any other approach and runs each of them one time.
Teams still choose it when the scope is fixed, and a mistake is expensive. In our judgment, that is why it survives in regulated and contract-driven projects.
Where the waterfall model came from
The waterfall model is usually traced to Winston Royce’s 1970 paper, and Royce did not recommend the single-pass version of the approach. His paper, Managing the Development of Large Software Systems, never uses the word waterfall.
Royce described a sequence that ran from requirements through design and coding to testing and operations. He called it risky for large systems, because testing came last and a failure found that late usually forced a major redesign.
He still called the basic approach fundamentally sound, and he proposed five safeguards: design first, document the design, build a pilot, plan the testing, and involve the customer. Later descriptions often kept the sequence and dropped the safeguards, which is TekRevol’s reading of how the model is usually taught.
Phases of the waterfall SDLC
Waterfall delivery runs through six phases, and each one ends with a sign-off before the next begins. In TekRevol’s reading of common guides, the stage count runs between five and eight, depending on whether they split out planning or retirement. We use six and fold planning into requirements.
| Phase | Main output | Usually owned by | Sign-off test |
| Requirements | Signed requirements document | Business analyst and client | Can every requirement be tested? |
| Design | Architecture and interface specification | Architects and designers | Can a developer build from this without asking questions? |
| Development | Working code | Engineers | Does the code match the specification? |
| Testing | Test report and defect log | QA team | Does every requirement have a passing test? |
| Deployment | Live release and handover | Engineering and operations | Is the software running in production and accepted? |
| Maintenance | Fixes and updates | Engineering and support | Are issues resolved within the agreed support terms? |
The owners and sign-off tests are TekRevol’s reading of common practice, because projects name them differently. The gate is what makes the model waterfall: if the test fails, the phase is not finished, and the next phase does not start.
A waterfall example: an invoicing portal and one late change
TekRevol’s illustration: a distribution company asks for an invoicing portal and signs a requirements document that says every invoice needs one approval from finance. The rest of the project is built on that document.
In the testing phase, the finance team says large invoices need a second approval. That is a change to a signed requirement, so it goes through change control.
Change control in a waterfall project is a formal request that states what changes and what it costs. Here, the request reopens the requirements, the design of the approval screens, the code already built, and the tests already passed, and the team quotes a new price and date before work resumes.
The same change in the requirements phase would have cost a conversation. Found in testing, it costs rework in four places, and in TekRevol’s judgment, that gap is why waterfall projects spend so long on requirements.
Advantages of the waterfall model
The main advantage of the waterfall delivery model is predictability: the scope and the price are agreed before the build starts. Every benefit below depends on the requirements staying put:
- Fixed scope and price. A fixed-price contract needs an agreed scope, and the model produces one up front.
- Clear documentation. Each phase leaves a written output, which helps with audits and handovers.
- Easy progress tracking. Phases and sign-offs give managers clear milestones to report against.
- Light demands on the client mid-build. The client’s time goes into requirements and acceptance.
Disadvantages of waterfall model
The advantages and disadvantages of the waterfall model mirror each other: the same fixed plan that makes the approach predictable also makes it hard to change. The biggest disadvantage is late feedback, because working software appears near the end and wrong assumptions surface when they cost the most to fix.
- Late testing. Defects and gaps appear only after the build, which is the problem Royce raised in 1970.
- Costly change. Every change needs a formal request, new pricing, and rework across SDLC phases.
- Assumed requirements. The client signs a document before seeing any software, so a requirement can be wrong while everyone follows the plan.
- No early product. Users cannot try anything until deployment.
- Uneven client effort. The client works hard at the start and at acceptance, with long gaps in between.
When to use waterfall delivery
Use waterfall delivery when requirements are stable, and the contract fixes scope and price. It also fits when an auditor needs every requirement traced to a test.
The TekRevol Waterfall Fit Test turns that into five questions. The test is TekRevol’s judgment.
| Question | Points toward waterfall | Points away from waterfall |
| How stable are the requirements? | Fixed and agreed by all stakeholders | Likely to change once users see the product |
| What does the contract say? | Fixed scope and fixed price | Capacity-based or open scope |
| Does an auditor need traceability? | Yes, each requirement must trace to a test | No formal audit trail is needed |
| Can the client decide quickly during the build? | No, the client can only review at set points | Yes, a named owner can decide every week |
| How familiar is the problem and the technology? | A known system or a rebuild | A new product or unproven technology |
Four or five answers in the middle column point to waterfall, and four or five in the last column point to an iterative approach. Anything in between suggests a hybrid. Avoid waterfall when the problem is new or users cannot say what they need until they see something.
Waterfall variants and hybrid approaches
The iterative waterfall variant adds feedback loops between adjacent phases, so a team can return to the previous phase to fix a problem, which is the fix Royce himself drew. In TekRevol’s judgment, the V-model pairs each design phase with a matching test level, so requirements are checked by acceptance tests.
A hybrid keeps waterfall’s upfront architecture and sign-off gates, then builds the features in short sprints. Our guide to software development models compares these approaches with the other models.
Is waterfall the same as the SDLC?
No. The SDLC is the set of phases every software project goes through, and waterfall delivery is one way to sequence them. Agile is another, and our agile vs waterfall comparison covers when each one fits.
Not sure whether your project fits waterfall delivery?
If you are weighing waterfall software development against an iterative approach and the TekRevol Waterfall Fit Test gives mixed answers, bring your requirements and your contract type to a conversation before you choose.
TekRevol is a software development company that usually delivers in agile iterations inside a capped budget. It scopes fixed-price work honestly when a project needs it, and proposes a more sequential engagement when a client cannot commit to a decision timeline.
Choose the model after you test the requirements. Start with a 30-minute Free Consultation.
