Theory
Write it down
A working project that nobody can understand, use, or maintain is only half finished. Professional software is documented, and your final-year project should be too. Documentation records what the system does, how it is built, and how to use it, so the project makes sense to your team, your evaluators, future maintainers, and its users.
Three documents matter most: the SRS (requirements), the design document (structure), and the user manual (how to use it). This lesson covers each. Much of it draws on artifacts you already created, requirements, ER diagrams, wireframes, now gathered into clear documents.
At a glance
| Document | What it records | For whom |
|---|---|---|
| SRS (Software Requirements Specification) | What the system must do: functional and non-functional requirements | Team, evaluators, stakeholders |
| Design document | How it is structured: HLD, LLD, ER diagram, DFD, architecture | Developers and maintainers |
| User manual | How to use the system: features, steps, screenshots | End users |
Theory
The three documents
The SRS (Software Requirements Specification) is the formal record of your requirements, the functional and non-functional requirements you analysed, written down and agreed. It defines what the system must do and is the reference everyone builds and tests against.
The design document records how the system is structured: your high-level and low-level design, the ER diagram, the data flow diagram, and the architecture. It captures the design decisions so anyone can understand, and later maintain, the system.
The user manual is for the end users: clear instructions on how to use the system, its features, the steps to do common tasks, often with screenshots. It ensures people can actually use what you built. Together, these three cover the what, the how, and the how-to-use of your project.
Formula
Document as you go, not all at the end
A practical warning: do not leave all documentation to the final week. Writing everything from memory at the end is painful, rushed, and often inaccurate (you forget why decisions were made).
Instead, document as you go: you already produced requirements and design artifacts during planning and design, so gather and refine them into the SRS and design document along the way, and note user steps as you build features. Documentation written alongside development is more accurate and far less stressful, and it means much of your report (next lesson) is already done. Treat documentation as part of building, not a chore bolted on at the end.
Quiz
Which project document records what the system must do, its functional and non-functional requirements?
- The user manual
- The SRS (Software Requirements Specification)
- The architecture diagram only
- There is no such document
Show the answer
The SRS (Software Requirements Specification)
The SRS (Software Requirements Specification) is the document that records what the system must do, its functional and non-functional requirements, agreed and written down as the reference for building and testing. Option A, the user manual, tells END USERS how to USE the system, not what it must do at the requirements level. Option C, the architecture diagram, is part of the DESIGN document (how the system is structured), not the requirements specification. Option D is wrong: the SRS is a standard, important document. Remember the three: SRS (what it must do), design document (how it is structured), user manual (how to use it).
Think first
Why does documentation matter for a project that already works?
If the system runs correctly, why spend effort documenting it? Then tap.
Show the answer
Because software that works today still needs to be UNDERSTOOD, USED, MAINTAINED, and ASSESSED, and documentation is what makes all of that possible; without it, a working system is a black box that only its original builders (briefly) understand. Consider each audience. For MAINTAINERS (including your future selves, or whoever takes the project further), code alone rarely reveals WHY things were done a certain way or how the pieces fit; the design document and SRS explain the intent and structure, so someone can fix bugs, add features, or adapt the system without reverse-engineering everything, and without documentation, even the original authors forget the details within weeks. For USERS, a working system they cannot figure out how to operate is useless to them; the user manual bridges that gap so people can actually get value from what you built. For your TEAM during development, shared documents (requirements, design) keep everyone aligned on what is being built and how, preventing the miscommunication that derails group projects. And for EVALUATORS, documentation is a major part of how your project is judged (indeed the evaluation scheme allocates marks to it): clear documents demonstrate that you understood the problem, designed thoughtfully, and can communicate your work professionally, which is exactly the competence a final-year project should show. There is also a professional-habit dimension: in industry, undocumented software is a liability, and the ability to produce clear documentation is a valued, expected skill. So documentation is not busywork tacked onto a finished system; it is what turns a running program into a comprehensible, usable, maintainable, and credible piece of engineering. A system that works but is undocumented is fragile and opaque; the same system with good documentation is trustworthy and lasting. That is why even a working project must be documented, and why doing it well is part of doing the project well. Documentation is what makes working software understandable and usable by everyone who needs it.
Summary
Key takeaways
- Documentation records what the system does, how it is built, and how to use it, making the project understandable, maintainable, and assessable.
- The SRS (Software Requirements Specification) records the requirements, functional and non-functional, that the system must meet.
- The design document records the structure: HLD, LLD, ER diagram, DFD, and architecture.
- The user manual gives end users clear instructions on how to use the system (features, steps, screenshots).
- Together they cover the what (SRS), the how (design), and the how-to-use (user manual).
- Document as you go, gathering and refining the artifacts you already produced, rather than writing it all from memory at the end.
- Memory hook: SRS for requirements, design document for structure, user manual for users, documented software is usable and maintainable.