Theory
Software has a life cycle
Software is not built in one leap; it moves through a life cycle of phases, from understanding the need to maintaining the finished system. This is the Software Development Life Cycle (SDLC), and at each phase, documentation captures what was decided and done.
You lived this in your project. This lesson frames it explicitly, and adds an important distinction: how much you document depends on the model you follow. Traditional models document heavily up front; Agile documents lightly and continuously. Understanding the SDLC and these models matters for your report and for professional life, where you will work within one of these approaches.
At a glance
| Phase | Documentation produced |
|---|---|
| Requirements | SRS (what the system must do) |
| Design | Design documents and diagrams (architecture, UML, ER, DFD) |
| Implementation | The code, with comments and inline docs |
| Testing | Test plans, test cases, and test reports |
| Deployment / maintenance | Deployment guides and user documentation |
Theory
Documentation at each phase
Each SDLC phase leaves a documentation trail that records its decisions.
Requirements produce the SRS (what the system must do). Design produces design documents and diagrams (architecture, UML, ER, DFD). Implementation produces the code with helpful comments. Testing produces test plans, cases, and reports (what was tested and the results). Deployment and maintenance produce deployment guides and user documentation.
This documentation matters because it lets others (and your future self) understand and maintain the system, and it feeds directly into your project report. Each phase's docs are the memory of why and how things were done, so nothing important is lost when the phase ends.
Theory
Traditional vs Agile documentation
How much you document depends on the development model.
Traditional models (like Waterfall) are sequential: each phase is completed, with heavy, detailed documentation, before the next begins. You document requirements thoroughly, then design thoroughly, and so on. This suits projects with stable, well-understood requirements.
Agile is iterative: work proceeds in short cycles (sprints), delivering working software frequently and adapting to change, with lighter, just-enough documentation produced continuously rather than exhaustively up front. Agile values working software and responsiveness over heavy paperwork.
Neither is simply 'better'; they suit different situations. But knowing the difference tells you what level of documentation your context expects, exhaustive and up front, or lean and continuous.
Quiz
How does documentation differ between traditional (Waterfall) and Agile models?
- Agile requires much heavier up-front documentation than Waterfall
- Traditional/Waterfall documents heavily up front in sequence, while Agile uses lighter, just-enough documentation produced continuously and adapts to change
- Neither model uses any documentation
- They document in exactly the same way
Show the answer
Traditional/Waterfall documents heavily up front in sequence, while Agile uses lighter, just-enough documentation produced continuously and adapts to change
Traditional/Waterfall models are sequential and document heavily and thoroughly UP FRONT before moving to the next phase, while Agile is iterative and uses LIGHTER, just-enough documentation produced continuously, favouring working software and adapting to change. Option A reverses them: it is Waterfall, not Agile, that emphasises heavy up-front documentation. Option C is wrong: both models use documentation, they differ in how much and when, not whether. Option D is wrong: they document quite differently (heavy-and-up-front vs lean-and-continuous). Knowing the difference tells you what documentation your project or workplace expects.
Think first
Why does Agile favour lighter documentation, and is that a good thing?
Documentation is valuable, so why does Agile deliberately produce less of it? Then tap.
Show the answer
Because Agile prioritises RESPONDING TO CHANGE and delivering WORKING SOFTWARE, and heavy up-front documentation can become a costly burden that goes out of date the moment requirements change, so Agile keeps documentation LEAN and CONTINUOUS, enough to be useful but not so much that it slows adaptation, which is a good fit for projects where requirements evolve. The reasoning starts from a real problem with heavy up-front documentation: in many projects, especially modern software, requirements are NOT fully known or stable at the start; they change as users give feedback, as the market shifts, and as the team learns. If you invest heavily in exhaustive documentation up front (as strict Waterfall does), then when requirements change, much of that documentation becomes outdated or wrong, and keeping it perfectly current consumes effort that could go into building the actual software. Agile responds to this by valuing 'working software over comprehensive documentation' and 'responding to change over following a plan' (from the Agile principles): it produces just ENOUGH documentation to communicate and coordinate effectively, created continuously as the work proceeds, and it relies more on close collaboration, conversation, and the working software itself to convey understanding. This lets the team stay flexible and fast, adapting to change without dragging a mountain of paperwork behind them. Is that a good thing? It depends on the context, which is the honest answer. For projects with EVOLVING requirements and a need for speed and adaptability (common in modern software and startups), Agile's lean documentation is a strength. For projects with STABLE, well-understood requirements, or where regulation, safety, or large teams demand thorough records (aerospace, medical, big enterprise systems), heavier documentation is genuinely valuable and Waterfall-style thoroughness makes sense. So Agile's lighter documentation is not laziness or a rejection of documentation's value; it is a deliberate trade-off that prioritises adaptability and working software, appropriate where change is expected, while acknowledging that other contexts need more. The professional skill is knowing which approach fits your situation, and documenting at the right level for it, rather than assuming more (or less) documentation is always better. Right amount of documentation for the context, not maximum or minimum, is the goal.
Summary
Key takeaways
- Software is built through the Software Development Life Cycle (SDLC): requirements, design, implementation, testing, deployment, and maintenance.
- Each phase produces documentation: requirements -> SRS; design -> design docs/diagrams; implementation -> code+comments; testing -> test plans/reports; deployment -> deployment/user docs.
- This documentation records decisions so the system can be understood and maintained, and it feeds your project report.
- Traditional/Waterfall models are sequential with heavy, detailed documentation done up front.
- Agile is iterative (sprints) with lighter, just-enough documentation produced continuously, favouring working software and adapting to change.
- Agile documents lightly to stay flexible when requirements evolve; heavier documentation suits stable requirements or regulated/large projects.
- Memory hook: SDLC phases each leave documentation; Waterfall documents heavy-and-up-front, Agile lean-and-continuous, right amount for the context.