Page 1 of 1

The Waterfall Model for Software Development Describes the Waterfall Model

#1 Martyn.Rae   User is offline

  • The programming dinosaur
  • member icon

Reputation: 547
  • View blog
  • Posts: 1,420
  • Joined: 22-August 09

Posted 15 March 2010 - 08:55 AM

The Waterfall Model for Software Development


Wikipedia describes the Waterfall Model as follows:


The waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.

Most companies feel that there is no place for the Waterfall Model in a throw-away society, where everything has to be here and now and where technological advancements make the system you are in the process of producing out-of-date before you have actually delivered it. Indeed I have presented this model to various companies in recent years only to be laughed at. Yet the ad-hoc methodologies they employ to develop solutions, especially for very large systems simply do not work. In the United Kingdom, we have had two or three very large (multimillion pound) systems simply rejected by the customer because the system they commissioned, simply did not do the job it was supposed to do.

In this tutorial, I would like to describe to you a version of the waterfall model that has been proven to work and that is still as relevant today as it was some twenty years ago. I will endeavor to use real-world examples to illustrate the important steps necessary for implementing a project using this method.

So what is this Waterfall Model?

The waterfall model consists of five phases namely,

  • Requirements Phase
  • Design Phase
  • Implementation Phase
  • Testing Phase
  • Installation Phase

Each phase is completed and 'signed off'. It is permitted of course, to move back a phase or two, to correct things, cascading the changes forwards to the point where the project currently stands under strict change control. This is the general understanding of the Waterfall method, but it actually lacks finesse.

The model which I used extensively in the seventies and eighties, looks considerably different from the vague list given above. The key to the success of any software development project is documentation.

The Requirements Phase

Business Requirements Document

The business requirements phase is the production of a document called the business requirements document. This is often produced by a customer, and normally forms the basis for a 'request for proposal' from a external consulting houses.

Business requirements are often vague, a wish list if you like. Written by a team of people who know the business well, but are not versed in computer techno-jargon. For software being produced internally by a company, the Business Requirements Document is probably going to be a wish list based upon consultations with major stakeholders within the organization.

Proposal Document

The proposal document is the response to the Business Requirements document. It addresses all the points in the Business Requirements Document discussing how each of the requirements is to be met, the risks involved, design strategies and outcomes etc. This aspect of the requirements phase was often referred to as the feasibility study. I have been in a few situations where during the production of a proposal, it has become clear that the Business Requirements could not be met within the requested timescale, and so we have withdrawn our interest. In one case, that so intrigued the customer, they requested our assistance in reworking the Business Requirements then awarded us the contract!

If the Business Requirements Document was not going to be outsourced, but processed internally, a proposal document would not be needed.


Requirements Document

The translation of the business requirements document into a set of well formed requirements is not something to be taken lightly. Now, I am about to make a very profound statement.

A requirement is only a requirement it it is a measurable.

If the requirement cannot be measured (i.e tested), then the ability to determine if the requirement has been met becomes a possible point of contention. Let's take an example and say you commission an architect to design a new house for you. Your brief is that the front of the house must have four windows and a front door. Now, this is not an unreasonable request. This is the drawing of the front of the house, the architect produces for you.

Posted Image

What was the problem? We were quite specific with our requirements wern't we? Well, obviously not. These are the requirements that we should have provided:

  • The house shall have two floors.
  • There shall be four windows in the house.
  • There shall be an front door to the ground floor of the house.
  • The front door shall be placed in the middle of the width of the house.
  • Each window shall be rectangular in shape.
  • Each window shall be the same size.
  • There shall be two windows on the ground floor of the house.
  • There shall be two windows on the first floor of the house.
  • Each of the four windows shall be placed in the following positions:-

    • A window shall be placed on the ground floor to the left of the front door position.
    • A window shall be placed on the ground floor to the right of the front door position.
    • A window shall be placed on the first floor to the left of the front door position.
    • A window shall be placed on the first floor to the right of the front door position.
    • The ground and upper floor windows will be vertically aligned

Notice, each requirement is exact, unambiguous and is clearly a list we can use to formulate a test plan.

Test Plan

The test plan more or less becomes a rewording of the requirements. So, taking the first two requirements would give us:

  • Does the house have two floors?
  • Are there four windows in the house?

The first two lines of our test plan. So, to test if the architect has met the requirements we provided, we run through our test plan and apply each question in turn to the drawing that has been returned. This is the only way we can ensure that we get what we requested. If all the boxes are ticked, then we have what we asked for!

Installation Document

This document provides information pertaining to the installation of the system when it is delivered. It will detail how the system will be handed over to the end-users, special notice to out-of-hours access to PC's, etc. It may provide details on parallel running with an existing system, disruption to end users, risks, backup procedures for existing data etc.

The Design Phase

Preliminary Design Document

The preliminary design document, transposes the requirements into high-level pseudo-code. Each requirement is tested against the pseudo-code to ensure that no requirement is missed. User interaction (windows, etc) would be identified during this stage. Notes to the programmer would be given.

User Specification Document

The User Specification Document would also be produced during this phase, showing work flows, for example, how to create a customer - select such an item from the menu bar, then select such an item and a dialog box will appear that looks like figure 1 and so on. This again, tends to be a rework of the requirements document, in a form that end users can understand.

System Integration Test Specification Document

The System Integration Test Specification Document is aimed at ensuring the system is tested in it's entirety. All integrated components are tested, all responses and outputs are checked, load tests are specified etc. The document is a rework of the user specification. For example the tests that would be performed for the creation of a customer,

  • Select the 'Customer' item from the menu bar and a drop-down menu shall appear.
  • Select the 'Create Customer' item from the drop-down menu and it shall be replaced by a dialog window as shown below.
  • Blah blah blah


Detailed Design Document

The detail design document, takes the preliminary design document and moves it forward, expanding the detail, identifying work units (blocks of functionality that can be programmed by different developers), the classes involved, their interfaces etc).

Detailed Test Specification Document

The detailed test specification document provides lists of tests that need to be performed in order to ensure that a successful component has been produced.

Unit Test Documents

The unit test document that lists the tests a software developer needs to perform before the unit can be accepted as completed. Expected results will be specified here, and the developer will report results to prove that unit tests have been exhaustively performed.

User Manual

During the Detailed Design and Detailed Test Specification document production, the user manual is written. This is completed before coding is commenced.

The Implementation Phase


The coding would be the last phase of the project. Code is tested against the unit test document to ensure the code is correct.


Normally, there are reviews after the Requirements, Preliminary Design, Detailed Design and Test phases. There are also code reviews performed during the Implementation phase. These reviews are intended to ensure that no functionality has been lost during the previous phase and all requirements are still being addressed. Also, documentation standards are checked, to ensure consistency, and code is checked against to ensure it is adhering to company standards.


As you can see, there is a lot of documentation produced. The phase being undertaken dictates the documentation produced, and the documentation is produced earlier rather than later. It is a very rewarding way to work, as you are 99% certain that the work you are performing, whether it be documentation or coding, is not in vain. Changes are made under change control, and not ad-hoc. Reviews ensure that everybody knows you are moving in the right direction. The only pitfall with the Waterfall method, is that the code is not produced until very late in the life cycle of the project.

I noticed that KYA had produced a tutorial on iterative design found here. In his tutorial, he states:

KYA said:

Those are the bare-bones basics of modeling programs. We shall now look at two different development methods: waterfall and iterative development (emphasis on the latter). While both strive to achieve the same goal (software completion) they go about different ways of doing it. For example, the waterfall approach looks something like this:

Posted Image

The client tells the designer what they want. The clients then sign off on it. The designer hands it off to the programmer and then the programmer hands the "finished" product to QA testers who then give the product to the client. This is not necessarily the best method and can lead to disastrous results. Note the direct linearity of this system. It is difficult to go "back" once you reach the next step and this illustrates some of the drawbacks of using this approach.

To a degree this is true, but the iterative approach he describes is no different to the waterfall method I have described above, which is also iterative in that changes can be made at any point during the life-cycle, but the further back they are to the start (say a requirement change), the more costly it is to incorporate the change. It is also possible to use prototype models quickly to assist with user feedback, even during the requirements phase.

Is This A Good Question/Topic? 1
  • +

Page 1 of 1