Software Engineering basics - Classical Waterfall Model

Classical Waterfall Model in Software Engineering

The Classical Waterfall Model is one of the earliest and most straightforward software development life cycle (SDLC) models. It follows a linear, sequential flow, meaning each phase must be completed before moving to the next—like water flowing down a waterfall.

Definition:

The Waterfall Model is a structured software development approach where the process flows in a step-by-step manner from requirements to maintenance, with no overlap between phases.

Phases of the Classical Waterfall Model

  1. 1. Requirements Gathering & Analysis

    • Understand what the customer wants.

    • All functional and non-functional requirements are collected and documented.

    • Output: Software Requirement Specification (SRS)

  2. 2. System Design

    • Based on requirements, the overall system architecture and design are created.

    • Output: System Design Documents (architecture, data models)

  3. 3. Implementation (Coding)

    • Actual coding starts.

    • Developers write the code based on the system design.

    • Output: Working source code

  4. 4. Testing

    • Software is tested to ensure that it meets the specified requirements.

    • Bugs and defects are reported and fixed.

    • Output: Tested and verified product

  5. 5. Deployment

    • Software is deployed in the user’s environment.

    • May include installation, setup, and training.

  6. 6. Maintenance

    • Fixing bugs or issues that come up after deployment.

    • Includes updates and enhancements over time.

Visual Diagram of Waterfall Flow

Requirements → Design → Implementation → Testing → Deployment → Maintenance

Each phase flows downward to the next, with little to no feedback loop.

When to Use the Waterfall Model

Best suited for:

  • Projects with clearly defined requirements

  • Short-duration projects

  • Projects where no expected changes will occur during development

  • Government or military software projects (where strict documentation is needed)