SDD

Motivation

An SDD makes the intended software design reviewable before implementation details become expensive to change. It records how the system is decomposed, how components collaborate, and which quality attributes shape the design.

Typical contents

• System context and design goals
• High-level architecture
• Component or module responsibilities
• Interfaces and integration boundaries
• Data models and data flows
• Security, reliability, performance, and scalability considerations
• Deployment assumptions
• Important trade-offs and unresolved risks
• References to architectural decision records

Level of detail

An SDD should be detailed enough for reviewers to evaluate the design, but it does not need to prescribe every class, function, endpoint field, or deployment command. Those details commonly belong in a TSD or implementation-specific specification.

Common mistakes

• Producing diagrams without explaining responsibilities and trade-offs.
• Copying the final implementation after the fact rather than guiding decisions.
• Ignoring operational and security qualities.
• Allowing the document to drift without identifying its owner or status.