众所周知，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的开展的。