Theory
The documents that describe a project
A software project is described by a set of technical documents, each capturing a different part of its story. Knowing what each one is, and producing them clearly, is a professional skill and directly shapes your project report.
This lesson lists the core technical documents: the problem statement and requirements (what and why), design diagrams like UML and ER (how it is structured), and testing and deployment documentation (that it works, and how to run it). You created most of these for your project; here we name them as a coherent set. Together, they document a project fully and professionally.
At a glance
| Document | What it captures |
|---|---|
| Problem statement and requirements | What problem is solved and what the system must do (functional and non-functional) |
| Design diagrams (UML, ER) | How the system is structured: UML (class, use-case, sequence), ER (database), architecture, DFD |
| Testing documentation | Test plans, test cases, and test results/reports (evidence it works) |
| Deployment documentation | How the system is deployed, installed, and run (plus user docs) |
Theory
Requirements, design diagrams, testing, deployment
The problem statement and requirements open the story: what problem the project solves and, in the SRS, exactly what the system must do (functional and non-functional). This is the what and why.
Design diagrams show the how. UML diagrams model software structure and behaviour, a class diagram shows the classes and their relationships, a use-case diagram shows what users can do, a sequence diagram shows how objects interact over time. ER diagrams model the database. Architecture and DFDs complete the picture.
Testing documentation (test plans, cases, and result reports) provides evidence the system works, what was tested and the outcomes. Deployment documentation explains how to deploy and run the system, plus user instructions. Each document covers one dimension; together they describe the whole project.
Quiz
Which technical documents show how a project's system is structured?
- The test result reports
- Design diagrams such as UML (class, use-case, sequence) and ER diagrams, plus architecture and DFDs
- The deployment guide only
- The problem statement alone
Show the answer
Design diagrams such as UML (class, use-case, sequence) and ER diagrams, plus architecture and DFDs
Design diagrams, UML diagrams (class, use-case, sequence), ER diagrams (database), plus architecture diagrams and DFDs, are what show how a system is STRUCTURED (its design). Option A, test result reports, provides evidence that the system WORKS (testing), not how it is structured. Option C, the deployment guide, explains how to deploy and run the system, a different concern. Option D, the problem statement, says WHAT problem is solved and why, not how the system is built. Each document covers one dimension: requirements (what/why), design diagrams (how it is structured), testing (that it works), deployment (how to run it).
Think first
Why produce several different documents instead of one big description?
Why split the project's documentation into separate documents (requirements, design, testing, deployment) rather than one? Then tap.
Show the answer
Because each document serves a DIFFERENT PURPOSE and AUDIENCE, and separating them keeps each focused, findable, and maintainable, whereas cramming everything into one giant description would be confusing, hard to navigate, and hard to keep up to date. Consider who needs what. Someone verifying WHAT the system should do (a client, a tester, an evaluator checking requirements were met) needs the requirements/SRS, and they should be able to find it without wading through design internals or deployment steps. A developer needing to understand or extend the STRUCTURE needs the design diagrams (UML, ER), and wants them together and clear, not buried among test cases. Someone checking the system WORKS needs the testing documentation (plans, cases, results). Someone tasked with running or installing it needs the deployment documentation. Each of these readers has a distinct question, and dedicated documents let each find and use exactly the relevant part quickly. Separation also aids MAINTENANCE: when the design changes, you update the design document; when tests change, the test docs; without disturbing unrelated content, so each stays accurate. A single mega-document, by contrast, mixes all concerns together, so readers must hunt for the piece they need, related information is scattered, and updating one aspect risks tangling with others, making the whole thing quickly stale and unwieldy. This mirrors the separation-of-concerns principle you have met throughout engineering: keep distinct things distinct so each is clear and manageable. For your project report, these documents also map to the report's SECTIONS (requirements, design, testing, deployment), so producing them separately means your report practically writes itself. So multiple focused documents are not extra bureaucracy; they are how you keep documentation clear, navigable, and maintainable, each answering one kind of question for one kind of reader. Distinct documents for distinct concerns beat one tangled description.
Summary
Key takeaways
- A project is described by a set of technical documents, each capturing a different part of its story.
- The problem statement and requirements (SRS) say what problem is solved and what the system must do (the what and why).
- Design diagrams show the structure: UML (class, use-case, sequence diagrams), ER diagrams (database), plus architecture and DFDs.
- Testing documentation (test plans, cases, and result reports) provides evidence the system works.
- Deployment documentation explains how to deploy, install, and run the system, plus user instructions.
- Separate, focused documents each serve a different purpose and audience, staying clear, findable, and maintainable, and they map to your report's sections.
- Memory hook: requirements (what/why), design diagrams UML/ER (how structured), testing (that it works), deployment (how to run).