这几天主要研究了一下设计文档，因为最近客户要求一个《概要设计》，这是个问题，到底什么是概要设计，我们到底需要给客户提供什么文档才合适？
首先解释一下概要设计：DB+模块+流程图。
其实概要设计是一个遗留问题，因为我们我们知道早期面向流程开发的时候，客户需要的只是流程和数据库，这一点，对日项目保持的非常完好，描述详细的流程，每个流程和那些数据库相关联云云。
但是现在的问题是我们已经进入到到了面向对象的时代了，我们思考的过程是需求->对象识别分析（OOA）->面向对象设计（OOD）->面向对象开发（OOP）。所以此时再看概要设计怎看都觉得很简陋而且不丰满的东西，根本无法体现出面向对象的设计模式。
我认为，现代的开发其实需要提供的文档如下：
1.需求文档
从用户的角度讲清楚几件事情：功能点，场景（故事），输入（来源，数据），输出（目的地，数据），处理。还有一点就是页面原型，需求文档的目的就是和客户确认他们的意思（需求）已经被我们理解，并且我们宏观的设计了处理方式，来满足他们的需求。
2.设计文档
从开发的角度讲清楚几件事情：架构怎么样，模块划分，每个模块都下属哪些类，页面（本身也被看成是特殊类，一种用户可以直接打交道的类）都是怎样和这些类交互，类和类之间又是怎样交互的。
3.数据库文档
这里我要说一下，关于数据库的意义和含义，其实数据库在面向对象的设计开发中他的价值在于支持顶层设计。这里有一个顺序的问题，一定是先有识别对象和实际对象间交互，然后才有数据库设计。所谓的“一定”是符合设计逻辑的，这样的一个思路其实是保证了你的数据库的设计是建立在对于系统的理解之上的，而不是生硬的设计。
“其实我们做IT的接触开发这方面的东西很定是要比咱们客户机会要多，我们也在不断的总结如何能够快速的高质量的交付产品，所以开发理念以及成果物的提交也是在不断的演变，我们作为开发方十分希望能够把这些比较新的，而且证明了更优秀工作方式介绍给客户。
我们也是参看了IBM，微软以及华为的开发流程，现在经过验证了的开发方式就是将书写详细设计文档的时间放在项目沟通和开发测试上面，我们现在的开发流程中内部是有一套机制来保证开发人员能够比较确切的理解业务和开发方式的。而且最关键的是高质量的代码作为详细设计其实是比书写详细设计文档更有意义，因为我们作为开发知道，作为一个维护的项目是没有人看详细设计文档的，我们会看需求规格说明书以及概要设计文档。
其实作为甲方之所以要设计开发方面的文档主要的目的还是能够通过监管文档这种方式来让乙方证明设计充分，从而降低风险，我们之所以认为提供这三分文档已经足够了就是因为我们现在开发的思路和方式就是这样的，这种方式提供的文档对我们而言是一种开发方式的体现，我们的文档书写压力最小，因为这都是真实的设计流程；对于甲方而言是获知我们真实工作的载体。”