A waterfall-style process organizes work into phases such as requirements, design, implementation, testing, and operation. Each phase produces information that the next phase depends on.
Why Use Phases?
Explicit deliverables and review points help teams agree on scope, responsibilities, and acceptance criteria. This is useful when work must be coordinated across several groups or external commitments.
The Main Risk
If important assumptions are tested only near the end, a failure can require changes to earlier requirements and design. A completed document is not proof that the software will satisfy timing, integration, or user needs.
Royce’s 1970 paper is often associated with waterfall, but it warns against a simple one-pass implementation and discusses iteration, early design work, testing, and customer involvement. Avoid treating “waterfall” as a claim that feedback or revision is forbidden.
Choosing an Approach
Ask how stable the requirements are and how soon the riskiest assumptions can be tested. Keep clear review criteria without delaying all practical feedback until final testing.
