Software Design Descriptions : A How to Guide for Project Staff

Between the requirements document and the first line of production code, there is a critical moment of translation. Someone — an architect, a senior developer, a designer — must take the abstract statement of what a system must do and convert it into a precise, structured description of how it will actually work. That document is the Software Design Description. And without a rigorous guide to writing one, the translation can go badly wrong.

Software Design Descriptions: A How-To Guide for Project Staff is that guide. Grounded in IEEE Standard 1016, the internationally recognised practice for software design documentation, it provides a clear, practical pathway from design concept to complete, code-ready documentation — the kind that a programmer can pick up, follow without ambiguity, and implement with confidence.

The book opens by establishing what a Software Design Description — an SDD — actually is and why it exists. It is, at its core, the primary reference for code development. As Tuffley makes clear from the outset, the SDD must contain all the information required by a programmer to write code. Nothing more and nothing less. That deceptively simple standard turns out to demand considerable intellectual discipline, and this book provides the framework to meet it.

Before reaching the document structure itself, the book does something that more prescriptive guides often skip: it defines what makes a design description good. A dedicated section on quality criteria examines the design virtues that separate professional software documentation from the kind that causes maintenance headaches for years to come. Traceability ensures every design entity maps to a specific requirement. Completeness demands that no input goes unaccounted for and no output is left without a value. Modularity is explored in depth — the discipline of breaking a complex problem into sub-problems small enough that a reviewer can understand a module on a first reading with only limited knowledge of the complete system.

The treatment of cohesion and coupling is particularly lucid. Poor cohesion — a module that detects messages, runs scheduled tasks, monitors communications links, and attempts error recovery all at once — is shown in stark contrast to the clean, single-purpose module that does one thing well. The four levels of coupling, from acceptable data coupling through the deeply problematic territory of content coupling, give designers a practical compass for evaluating their own work.

The bulk of the book walks through the SDD document structure section by section. Module detailed design descriptions receive the most thorough treatment: purpose, function, subordinates, dependencies, interfaces, resources, internal data, and processing logic are each given precise definitions and requirements. The unit test strategy section — embedded within the module design itself, not treated as an afterthought — reflects a mature understanding of how good design and good testing are inseparable disciplines.

Interface design descriptions, database design, global memory management, and the full message architecture round out the document structure, followed by an appendix on Structured English — the pseudo-code methodology that gives processing descriptions a precise, unambiguous form that bridges human readability and code logic.

For architects, designers, senior developers, and the project managers who must evaluate their work, this book establishes the standard. Design is, as the author himself writes, a plan for arranging elements in the best way to achieve a purpose. This book shows exactly how to document that plan.