Applying the Waterfall Model
Career Paths
How to interpret this table?
You may choose this advanced topic if you like doing the things listed under “they usually do”, and you are fine with not doing the things listed under “they usually do not do”.
Alternatively, you may choose it if you are interested in applying for the listed job roles and want to practice work that is close to those roles.
| Job title | They usually do | They usually do NOT do | Real-life examples |
|---|---|---|---|
| Software Engineer (process-focused) | Apply selected SDLC principles consciously, document process decisions, align implementation with chosen model aspects | Follow a process blindly, mix models without understanding, or retrofit explanations after the fact | Contract-driven development, regulated software projects |
| Technical Lead | Decide which Waterfall aspects to apply, enforce phase discipline where chosen, explain trade-offs to the team | Pretend to follow Waterfall while working ad-hoc | Fixed-scope internal tools, specification-driven systems |
Affected SDLC Phases
If a team chooses this advanced topic, the planning, feasibility analysis, and system design phases are most strongly affected. Implementation and testing still happen within the semester constraints, but teams must consciously apply and justify selected Waterfall principles. Some bending of the model is acceptable if explicitly acknowledged and explained. Any changes in the model must be presented to the tutor before applying, and only acceptable if the tutor acknowledge it.
Affected Tasks
Features are defined
Minimum Viable Product (MVP)
By the end of this task, your team has defined features with a higher-than-usual level of upfront detail, reflecting a Waterfall-style emphasis on early specification. The team must explicitly state which Waterfall aspects they apply (1–2 only) and how these affect feature definition.
Technical Details
Before defining features, the team must select 1–2 key Waterfall aspects and document them in README.md.
Acceptable Waterfall aspects include (examples):
- Heavily detailed upfront requirements
- Formal approval or “freeze” of feature definitions
- Clear separation between requirements and design
- Limited or no feature changes after planning
Each feature must include precise descriptions, assumptions, constraints, and acceptance criteria. Features must aim to minimize later reinterpretation.
Quality
High-quality work shows consciously chosen Waterfall aspects applied consistently. Feature definitions are precise, unambiguous, and stable. The team clearly explains what was fixed early and why.
Features are sorted by priority
Minimum Viable Product (MVP)
Your team sorts features by priority assuming limited change after planning, reflecting a Waterfall mindset.
Technical Details
Prioritization must assume that later changes are costly. The team must document which features are considered mandatory vs optional and why.
Quality
High-quality prioritization reflects realistic upfront decision-making and avoids relying on late iteration to fix poor choices.
Features' cost and price are estimated
Minimum Viable Product (MVP)
Your team produces cost and price estimates based on the assumption that requirements are mostly fixed.
Technical Details
Estimates must be based on the detailed feature definitions and must state underlying assumptions clearly. Re-estimation later is allowed only if explicitly justified as a deviation from Waterfall.
Quality
High-quality estimates are internally consistent and clearly tied to early specifications, not adjusted opportunistically later.
System is working
Minimum Viable Product (MVP)
By the end of this task, your team demonstrates a working system that implements the earlier defined features without major scope changes.
Technical Details
The demo must show that the implemented system matches the original specifications. Any deviation must be explicitly documented as a conscious bend of the Waterfall model.
Quality
High-quality work shows strong alignment between early plans and final implementation, with minimal surprises.
Bug fixing
Minimum Viable Product (MVP)
During development, your team reports and fixes one bug following a Waterfall-style approach: clear defect report, analysis, fix, and verification.
Technical Details
The bug report must include formal description, expected vs actual behavior, and impact. Fixing should not introduce scope changes.
Quality
High-quality bug fixing reflects discipline and traceability rather than rapid trial-and-error.
User documentation
Minimum Viable Product (MVP)
User documentation is written assuming stable functionality and minimal change.
Technical Details
Documentation should closely match the original specifications and final system behavior.
Quality
High-quality documentation benefits from early clarity and requires little rework.
Developer documentation
Minimum Viable Product (MVP)
Developer documentation reflects a clear separation between requirements, design, and implementation.
Technical Details
Documents should reference earlier planning and design decisions explicitly.
Quality
High-quality documentation makes the Waterfall structure visible and understandable.