Waterfall Software Engineering Life Cycle

The waterfall model is a classic, popular, linear approach to the software engineering life cycle. It defines a sequence of phases, each with clear goals. Like water flowing downhill, the strict model moves forward without reversing course.

The waterfall approach is strict and offers little scope for revision. Testing is treated as a separate phase rather than continuous work alongside development. As a result, the model does not allow defects to be detected early in development.

Open Full-Size Diagram ↗

Waterfall Software Engineering Life Cycle

The phases follow this sequence:

1. Requirements gathering: Capture the client’s requirements and prepare the necessary documentation.
2. System design: Use the requirements to define the architecture and the system’s hardware and software needs.
3. Implementation: Begin coding from the design. Divide the program into small, independent units, test each against its specifications, then integrate them into the complete system.
4. Integration testing: Combine the tested units and test the whole system for defects.
5. Deployment: Fix defects found during integration testing, then retest to verify that they are closed. The system is then ready for market release and deployment in the customer’s environment.
6. Maintenance: Release patches or new versions to resolve defects and issues found after delivery.

The phases cascade: a phase begins only after the previous one has been completed successfully.

Use waterfall when requirements are clear, the product is stable and each phase has enough resources. In practice, it should be used only for small, manageable projects. Avoid it when requirements carry moderate or high risk.

Requirements Specification and Analysis

Software development depends on one thing: how well requirements are captured and documented. Identifying and documenting them is called requirements specification and analysis.

The client, management team and technical support team discuss the requirements in detail. They analyze, review and document them until they are clear and complete.

Open Full-Size Diagram ↗

User Requirement Specification

Use the company’s required format, such as Word documents, flowcharts or drawings. The result is a detailed record of what the customer wants, helping the team understand those needs correctly. A defect is anything that does not meet the customer’s requirements. Capturing the wrong requirements starts the project on the wrong footing.

User Requirement Specification

This non-technical document describes the user’s expectations and business needs. End users write it, and its requirements are checked during user acceptance testing. It provides the foundation for the next requirements activities and system design.

Software Requirement Specification

The software requirements specification (SRS) defines how the user wants the software to function. It serves these purposes:

• Record the customer’s and supplier’s agreement on detailed software functionality.
• Provide the basis for software design.
• Simplify development and testing through clear requirements.
• Support activity scheduling and cost estimates.
• Provide a foundation for verification and validation.

Open Full-Size Diagram ↗

Software Requirement Specification

Software Design

Software design has two levels:

• High-Level Software Design
• Detailed Software Design

Open Full-Size Diagram ↗

Software Design

High Level Software Design

High-level design (HLD) describes the database design and functional architecture. It guides developers and answers questions about the design flow. A clear SRS is needed before the HLD can be prepared.

Detailed Software Level Design

Detailed design, or low-level design (LLD), breaks the HLD into smaller parts and records the logic that forms the program specification. It provides detailed system information and depends on the HLD being ready.

Software Design Processes

Design processes can follow either approach:

• Top-Down Design
• Bottom-Up Design

Top Down Design Approach

Top-down design starts with an outline of the system, leaving subsystem details for later. Work down through each subsystem, defining it in greater detail until you reach the base elements.

Bottom Up Design Approach

Bottom-up design starts with fully defined base elements. Link them into subsystems, then combine those subsystems until the whole system is formed. Think of planting a seed and gradually growing a tree.