optional · CSS study notes
Software Documentation (2016)
CSS CS Optional — Paper-I, Section-B, Topic V.
🔑 What It Is
- Written material describing a system: requirements, design, code, usage, maintenance.
- Produced alongside development, not bolted on after.
📌 Two Broad Categories
- Process documentation — plans, schedules, meeting minutes, standards, test plans. For dev team/PMs.
- Product documentation:
- System documentation — spec, design docs, code comments, test docs → for developers/maintainers.
- User documentation — manuals, install guides, help systems → for end users.
📌 Why It Matters for Maintenance
- Maintenance = 60–80% of lifetime cost (see System Delivery and Maintenance page).
- Good docs = maintainer can understand & safely change system they didn't build.
- Poor docs = direct cause of "lost context" problem.
⚠️ MCQ Trap
- A user manual = product/user documentation, NOT process documentation — even though written during the process. Category = what it describes, not when written.
📜 Past-Paper Questions & MCQs (CSS 2016–2026)
2016 · Paper-I · Q7(d) · 5 marks
Q. What is the difference between an SRS document and a design document? What contents should each contain?
Ans.
| Basis | SRS (Software Requirements Specification) | Design document (SDD) |
|---|---|---|
| Purpose | States what the system must do | Describes how the system will be built |
| Audience | Customers, users, analysts, testers | Developers and architects |
| Phase | Requirements analysis | Design |
- SRS contents: introduction (purpose, scope, definitions), overall description, functional requirements, non-functional requirements (performance, security, usability), external interface requirements, constraints and assumptions.
- Design document contents: system architecture, module and component design, data design (database schema, ER diagram), interface and screen design, algorithms, class and sequence diagrams, and traceability back to the SRS.