混在IT-（12）夹板下的详细设计报告

2块木板一夹，在四处乱跑的东西都要老实很多，如果是3木块板呢，我想它会被固定住。

对MIS类的详细设计报告而言：

第一块木板：需求规格说明书功能列表和分册，列表里面有功能点、分册里面有界面，那么这块木板就把详细设计报告的目录和实现的样子给确定了。专业点就是说面子已经固定下来，就是要长成这摸样，不要试图去韩国美容。

第二块木板：概要设计报告，概要设计在我的理解，它就是约定，也就是说一个业务的实现必须需要遵守的规则。这个就不是面子问题了，是强制，就是要这么走路，这么坐姿，这么吃饭，这么说话，这么这么什么的，这决定了是贵族还是平民的问题。

第三块木板：数据库设计报告（这个我们后面章节谈），决定了存储，就是掌控了锅碗瓢盆，掌握着吃饭的问题，要吃饭，可以，遵守我定的规则。

三块木板这么一夹，我们是不是觉得写详细设计报告就很清晰了，在我看来这种情况，就是边界的魅力，我们从需求开始一直在控制，一直在收敛。团队规模越大，意味着沟通会成为最重要的障碍，如果边界定的越不清晰，合作起来越痛苦，越多的扯皮。当然团队规模越小，边界越模糊，每个人都可能客串很多角色，只要沟通好，没歧义也行。

谈了这么多，我们找个例子来分享一下详细设计报告吧。

这个例子是《混在IT-（7）需求规则说明书案例分享》文章的延续，有人问，上章概要设计的时候为什么不用这个案例？呵呵，那是因为项目很小，成员也没几个，概要设计当时就是在会议室做了个约定，还做了现在都不知道跑到哪里去的会议纪要，因为有了需求规格说明书，本来还想详细设计不做了，后来想想还是做吧，不然与程序员沟通怎么和数据库实在交换太累了，这个可是比沟通什么架构复杂多了，也无趣。

开始贴图：
项目是使用.NET做的，数据库是SQL SERVER。通过10张图来展现。

[u]1、分册[/u]
详细设计报告可以根据分工不同或分类做成不同分册

[align=center][img]http://dl.iteye.com/upload/attachment/342079/7efe188a-1d75-3688-8dbf-3fd6c0132a69.jpg[/img][/align]

[u]2、分册中公共部分的目录[/u]
主要是定义输入输出

[align=center][img]http://dl.iteye.com/upload/attachment/342082/02726e53-35d6-3246-a881-cf71096e6202.jpg[/img][/align]

[u]3、实体类说明描述[/u]

[align=center][img]http://dl.iteye.com/upload/attachment/342085/3981aff6-462d-3f3e-9e7a-90a587469bf2.jpg[/img][/align]

[u]4、功能模块设计目录[/u]

[align=center][img]http://dl.iteye.com/upload/attachment/342087/a725be75-4d43-3c17-9ffb-f83c05aa7eae.jpg[/img][/align]

[u]5、目录内概述和分层列表[/u]

[align=center][img]http://dl.iteye.com/upload/attachment/342089/84375d09-84c6-30d9-ad3e-82e538026a70.jpg[/img][/align]

[u]6、目录内某一个业务逻辑的描述[/u]

[align=center][img]http://dl.iteye.com/upload/attachment/342091/f2764baa-6e7e-36ef-be25-d9c16bc83fce.jpg[/img][/align]

[u]7、目录内页面处理的文件名定义[/u]

[align=center][img]http://dl.iteye.com/upload/attachment/342093/56b28bed-78b4-32cd-9679-b1e688c096f3.jpg[/img][/align]

[u]8、目录内的用户界面和元素说明[/u]
是不是很熟悉，这个界面可是从需求规格说明书分册中复制过来的。

[align=center][img]http://dl.iteye.com/upload/attachment/342095/d813bec4-3ac8-37a7-8eec-04b91a33dd02.jpg[/img][/align]

[u]9、界面逻辑描述[/u]

[align=center][img]http://dl.iteye.com/upload/attachment/342097/a6e3f7c6-726e-3cc8-8ec3-d17ce8d13a1e.jpg[/img][/align]

[u]10、界面处理的事件[/u]

[align=center][img]http://dl.iteye.com/upload/attachment/342099/0687ff42-d1e3-352d-b2ca-004045de4f5d.jpg[/img][/align]


大家有仔细看哦，这里有几个重要的东西要重复一下
[b]实现功能和需求规格说明书功能列表的编号一致，在第5张图上
分层列表和文件列表和概要设计的约定一致，在第5和第7图上
界面和需求规格说明书分册的界面一致，在第8张图[/b]


我们从需求、概要、详设一起走过来，不知道大家是否有个感觉，我们只是解决了面上的问题，即有界面可以体现的需求，但是在实际项目中我们还会碰到很多没有界面的需求，这些需求也是要填进需求规格说明书，也要在概要中约定，也要在详设中设计。如外部接口、客户要求的算法等等。我们将在下一章专题讨论这些没有面子的需求该如何处理，看看我们是怎样套用前面讨论的思路。