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.

Overview

Description

1. 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.
2. 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 development.
   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 unanticipated problems.
3. 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.
4. 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 programmers.

Analysis

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 better.

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.

Qualities of Requirements

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.