2块木板一夹，在四处乱跑的东西都要老实很多，如果是3木块板呢，我想它会被固定住。
对MIS类的详细设计报告而言：
第一块木板：需求规格说明书功能列表和分册，列表里面有功能点、分册里面有界面，那么这块木板就把详细设计报告的目录和实现的样子给确定了。专业点就是说面子已经固定下来，就是要长成这摸样，不要试图去韩国美容。
第二块木板：概要设计报告，概要设计在我的理解，它就是约定，也就是说一个业务的实现必须需要遵守的规则。这个就不是面子问题了，是强制，就是要这么走路，这么坐姿，这么吃饭，这么说话，这么这么什么的，这决定了是贵族还是平民的问题。
第三块木板：数据库设计报告（这个我们后面章节谈），决定了存储，就是掌控了锅碗瓢盆，掌握着吃饭的问题，要吃饭，可以，遵守我定的规则。
三块木板这么一夹，我们是不是觉得写详细设计报告就很清晰了，在我看来这种情况，就是边界的魅力，我们从需求开始一直在控制，一直在收敛。团队规模越大，意味着沟通会成为最重要的障碍，如果边界定的越不清晰，合作起来越痛苦，越多的扯皮。当然团队规模越小，边界越模糊，每个人都可能客串很多角色，只要沟通好，没歧义也行。
谈了这么多，我们找个例子来分享一下详细设计报告吧。
这个例子是《混在IT-（7）需求规则说明书案例分享》文章的延续，有人问，上章概要设计的时候为什么不用这个案例？呵呵，那是因为项目很小，成员也没几个，概要设计当时就是在会议室做了个约定，还做了现在都不知道跑到哪里去的会议纪要，因为有了需求规格说明书，本来还想详细设计不做了，后来想想还是做吧，不然与程序员沟通怎么和数据库实在交换太累了，这个可是比沟通什么架构复杂多了，也无趣。
开始贴图：
项目是使用.NET做的，数据库是SQL SERVER。通过10张图来展现。
1、 分册：
详细设计报告可以根据分工不同或分类做成不同分册
2、分册中公共部分的目录：
主要是定义输入输出
3、实体类说明描述
4、功能模块设计目录
5、目录内概述和分层列表
6、目录内某一个业务逻辑的描述
7、目录内页面处理的文件名定义
8、目录内的用户界面和元素说明
是不是很熟悉，这个界面可是从需求规格说明书分册中复制过来的。
9、界面逻辑描述
10、界面处理的事件
大家有仔细看哦，这里有几个重要的东西要重复一下
实现功能和需求规格说明书功能列表的编号一致，在第5张图上
分层列表和文件列表和概要设计的约定一致，在第5和第7图上
界面和需求规格说明书分册的界面一致，在第8张图
我们从需求、概要、详设一起走过来，不知道大家是否有个感觉，我们只是解决了面上的问题，即有界面可以体现的需求，但是在实际项目中我们还会碰到很多没有界面的需求，这些需求也是要填进需求规格说明书，也要在概要中约定，也要在详设中设计。如外部接口、客户要求的算法等等。我们将在下一章专题讨论这些没有面子的需求该如何处理，看看我们是怎样套用前面讨论的思路。
