衆所周知，Design從來就是一個很見仁見智的東西，Design沒有對與錯，只有好與壞之分，那麼，如何把自己的Design體現出來給Leader（PM？IPS？EA？）知道或者Review呢，通常我們習慣的做法都是Document下來生成一份SDD，以便指導後續的Designer或者Developer進行實際的開發。
那麼通常一份好的SDD裏面應該包含些什麼要素呢？我個人認爲，至少需要包含以下的這些要素（個人見解）
1. Executive Summary（可選）
主要介紹這個Design是爲了什麼目的的，可以簡單說一下這個Project的Background和Purpose。
2. Introduction（可選）
說明這份Document的性質，裏面描述的是些什麼東東。
3. Architecture Representation（必選）
簡單描述整個Design的Architecture的表現，例如，通常我們會採用4＋1 View的Model來組織整個Design的Architecture，包括
- Requirement View －－重點，描述software requirements，這裏會包括functional和non-functional的。
- Logical View －－重點中的重點，包括Design中的Object Model，System的分層或者Subsystem的劃分及其之間的依賴關係。
- Process View －－一般描述Design中的同步與併發的情況。
- Implementation View －－重點，主要描述在整個開發環境中software的靜態組織。
- Deployment View －－重點，主要描述開發完後的software如何和真正的hardware對應起來，顧名思義，就是發佈的結構描述。
- Date View －－一般描述software中的Database的Design，如果有用到DB的話。
這些View Model至關重要的原因就是在一個開發團隊中，有不同的角色，他們可以根據這份SDD，在整個架構中有針對性的去查找到自己角色所負責的那個Model，各司其職。例如，System engineers可以僅僅關注logical view，process view和deployment view。Database adminstrators可以僅僅關注data view。Software Configuration Managers可以僅僅關注implementation view。而Project Manager也可以僅僅關注requirement view。
4. 各個View Model的展開（必選）
如果說上面Point 3是一個概要描述性的話，現在提到的這一點就是整個Design的命脈所在。這麼說吧，Point 3和Point 4就是一個概要和具體的關係。
總而言之，Design雖然沒有對與錯之分，但是SDD是對整個Design的描述，可以用來指導整個後續開發的進行，如果說SDD是high level design的話，它就是用來指導PS（program specification）這個low level design的開展的。