What's Wrong with Waterfall Design
The most traditional of formal software design processes tend to
be of a type known as waterfall. This is because a project goes in
distinct stages where each stage overlaps only with the stage
immediately before and after. As work progresses on a stage, it
generates feedback to the prior stage -- and then later it receives
feedback from the next stage. Thus, there is a stepped cascade
from the beginning to the end.
Common opinion among software experts is that the waterfall model is
flawed and outdated. Nevertheless, I have seen it adhered to in major
companies. Below I give a fairly balanced overview of the waterfall
process, after which I describe the flaws in it.
- Requirements analysis and definition.
Software requirements are a document which outlines the desired
product features based on an analysis of the end user's needs
and goals. Good requirements describe only what the user sees
and does, not what happens in the computer. Thus, any
discussion of algorithms or data structures belongs in a later
stage, not in the requirements document. Ideally, the
requirements should completely and unambiguously describe how
the product will look from the end user's point of view.
- Design and Specification
Based on the requirements, the developers create an in-depth
design plan, or architecture. Work on the plan provides
feedback to the requirements. Based on the design plan,
priority is assigned to each requirement by weighing its gain
against the estimated cost in time and money devoted to
When the requirements are locked down, coding begins.
Experience in the early phases of coding may provide feedback
to the design plan, which may be altered to account for
- Coding and Module Testing
This is the stage of actually writing the program or programs.
It may be that as methods are coded, the programmers may see
problems in the design plan. This provides feedback to the
design plan, but note that in a strict waterfall model the
requirements are not changed based on coding.
When the code is functionally complete, the planning is over
and testing begins. Based on feedback from system testing,
bugs are tracked down and re-coded to fix them.
- Integration and System Testing
This usually means user-level testing by Quality Assurance
(QA) personnel rather than by programmers. They test the whole
from the viewpoint of a user, and provide feedback to the
- Requirements are imprecise:
- An imprecise set of requirements is interpreted differently by
different groups, causing errors in coordination. For example,
Quality Engineering's test plan may fail to test a feature
because it was not clearly communicated, and thus an untested
feature is shipped to customers. On the other hand, other
works in development might assume a feature exists and
mistakenly point customers to the product's feature.
- Requirements are too specific:
- A requirements document with too many details of a particular
solution locks developers into an implementation and prevents
them from find a different solution that is easier, cheaper, or
- Requirements are too complex:
- Complex requirements fail to separate the product's pieces and
describe them in simple and concise terms. As a result,
developers devote more energy on less important features while
failing to add simple features.
Good requirements have three main sets of qualities.
- They are understandable from an end-user point of view:
- Good requirements describe only what the user sees and does,
not what happens in the computer. A useful rule of thumb is
that any discussion of algorithms or data structures belongs in
the design document, not in the requirements document. Focus
on the end user's needs, not the computer's.
- They are an unambiguous and describe the problem to be solved:
- Identify everything that the end user sees or does. For GUI
applications, include a full set of screen mockups to provide
the necessary level of detail and completeness. For non-GUI
applications, include to a set of standard system interface
definitions and data exchange formats.
- They are a concise list of identifiable features:
- All requirements must be broken apart into distinct items so
their priority may be moved up or down, if necessary. Each
requirement should be assigned a number so item can be referred
to in other documents and be tracked between different versions
of the requirements document. Features should always be
distinct, although some features can depend on others. For
example, if there are two features, "A" and "B," B can depend
on A, but A must be tested separately.
John H. Kim <firstname.lastname@example.org>
Last modified: Thu Jun 20 09:40:53 2002