混在IT-（7）需求规格说明书案例分享

    给各位朋友分享的需求规格说明书是在2008年底编写的，当时我带的是一个全新团队，接了一个小单子来磨合项目组，目的是让项目组有个初步的规范化标准作业意识，所以文字看起来不够优美，比较粗糙。另外在这里先申明一下，文档不能全文贴出，因为那个是公司的财产，贴出就违规了。所以只是截取文档部分片段图片，还好，在我们这里不是提供一个标准或模板，而是提供一种思路给大家，那就是三分定天下方法，请各位赏析。

    需求规格说明书在我看来最重要的内容就是区分边界，好吧，我们开始看十大美女图，啊，错了，是十大贴图，清晰无码图，第1-5图是总论，第6图是功能列表，第7-10图是分册。

看图说话：

第1张图是文档列表，因为功能点非常的少，所以分册只有一份，如果功能点多的话，大家可以按自己感觉最好的分类来定义分册文件名，并把它拆分成多个分册文件。

第2张图是总论的目录，采用的是公司CMMI模板，模板意味着你要在规定的位置填空指定的内容。

第3张图是总论中一个很重要也是很神奇的约定说明，说白了其实就是给功能编号，这个号码会贯穿到需求规格说明书的功能列表、分册，详细设计、任务单、测试等等环节上，在我看来它更像是控制点的约定。

第4张图是总论的项目概述，文笔好的朋友可以大写特写，其实大家都知道，我们在写需求的什么经常会碰到一个问题，我们所要实现的业务可能只是一个大流程的一部分，大流程有很多可能是手工操作的，或者是其它系统实现，如果我们只说明一小块边界内的业务，可能会让很多人看不懂，在三分定天下方法下，总论并不太关心边界内还是边界外，把业务说明白最好。

第5张图是总论中说明一下功能列表的文件名是什么。

第6张图很关键哦，那就是功能列表，是系统实现的业务范围划分界限的关键，这一刀非常狠的，一下就把边界内所涉及的内容给圈定住了。注意看图，涉及需求栏，有一行内容是F1.1生产任务单执行情况列表，F1.1就是编号，是遵循第3张图的约定

第7、8张图是分册内容，核心看点有2个，一个是F1下单，另外一个是生产任务单列表的界面，这2个看点非常重要，F1是和功能列表文件中的编号是一致的，属于一条龙服务中的编号索引。界面图就是我们要实现的需求样子，在这里非常明确的给定义下来，就是按照这个图来做，后续环节就是按这个图，和客户确认，按图设计，按图编码、按图测试验证。客户一起看图确认是不是轻松了很多，不要让客户想的太多，也不要让程序员想的太多，这2种多想都会出问题的。把它给确认就什么问题都没有了，所以我才会在上篇文章中和大家说，在三分定天下方法下：需求和客户确认后到没有变更前，我们是没有返工的。

第9-10张图也是分册内容，看图写操作手册，人机交互的过程，怎么写都可以，强制要求必须是边界内的，不能出现等等这类的字眼，有一说一，有二说二。尽量严谨些，这个阶段是属于抠字眼范畴，不像写总论的时候，那是属于编故事范畴，越好听越好。

看完了，是不是感觉也就是这么一回事，可能和各位朋友日常做的没什么太大区别，不就是把需求文档分为三个文档吗，不是的，这些都是台面上形式的东西，在看不到的层面上，我们开始悄悄的在做一件事，控制，对项目的控制，让整个项目良性发展的控制，这种控制在后续的篇章中慢慢的展现给大家。

最后我问个问题：如果收到的需求涉及到多个功能点的变更，该在文档中如何体现？
教大家一个方法：
1、在需求跟踪表中登记此需求。
2、填写需求涉及到的功能点编号，如案例中F1.1、F1.2、F1.3涉及到，就把这些编号写上
3、把分册WORD文档切换成修订模式。
4、在修订模式下修改。
5、在下个版本开始前再把这份文档做接受所有修订的处理。
6、设计、编码、测试等等角色都可以从需求跟踪表中找到涉及到的编号、从编号在找到分册，在修订模式下是不是很方便的比较出新需求的变化。

PS：下章我们将谈谈需求跟踪表，一个非常有特殊作用的管理小工具

评论

17 楼 todo158 2010-10-27  

liuqiancs 写道

非常喜欢大叔的文章，文字来源于实际，不失幽默又很用指导作用，大叔的这篇案例分析也很深入透彻，但是我还是有些疑惑，那就是功能列表是否做的太多了，有些过了呢，比方说界面设计是否在概要设计中才体现出来，如果写的这么细致的话，那我感觉概要设计要做的事情几乎被需求分析给做了，请大叔予以解答，谢谢

是的，这种方法在做需求的时候做了很多设计的东西。

主要的原因就是我们希望找到一个平衡点，能让参与需求沟通的人，在需求描述上没有任何的歧义，原型法效果最好，但是要求太高，使用VISIO工具画界面，熟练的话非常快的。

需求这个源头没控制住，在设计阶段可能会有很多的返工，有时候我们的项目周期太紧，就只做需求，不做设计，只在口头沟通一下就开始编码，有了界面在需求阶段就定义好，即使出现了编码问题也是在可控制范围内，至少看过去和需求一致。

16 楼 liuqiancs 2010-10-27  

非常喜欢大叔的文章，文字来源于实际，不失幽默又很用指导作用，大叔的这篇案例分析也很深入透彻，但是我还是有些疑惑，那就是功能列表是否做的太多了，有些过了呢，比方说界面设计是否在概要设计中才体现出来，如果写的这么细致的话，那我感觉概要设计要做的事情几乎被需求分析给做了，请大叔予以解答，谢谢

15 楼 todo158 2010-10-27  

lb290 写道

大叔的文章很好，让我很长知识。谢谢大叔分享经验

谢谢：）

14 楼 lb290 2010-10-26  

大叔的文章很好，让我很长知识。谢谢大叔分享经验

13 楼 hjk685 2010-10-26  

谢谢您的细心解答，我在小公司混了好几年，知识还是很匮乏。

12 楼 willsunforjava 2010-10-25  

学习了， ，谢谢。期待你的继续分享

11 楼 todo158 2010-10-25  

hjk685 写道

功能需求和非功能需求有什么区别?功能需求定义和业务规则我有点难以区分请指教一下。需求分析是在签合同前进行的呢还是签合同后进行的呢？如果在之后进行那么要怎么给项目报价？

功能需求和非功能需求有什么区别?
功能需求就是客户要拿这个系统做什么事，是业务层面上的。
非功能需求是客户对系统，如性能，数据库，网络、开发工具等等建设上要求。

功能需求定义和业务规则区别？
功能需求定义是客户要系统做哪些业务
业务规则是客户在做业务的过程中需要遵循的要求

需求分析是在签合同前进行的呢还是签合同后进行的呢？
看情况了，一般在签合同前，我们做总论和功能列表，合同签了以后做分册。

如果在之后进行那么要怎么给项目报价？
一般在做报价的时候，我们是依据功能列表算成人日，加上需求分析、设计、实施、迁移、维护等等工序的人日，然后乘上一个系数，再乘上人日费用做报价。系数主要解决人日估算误差，也防止在给客户打折后项目变成亏损增加的，一般1.5/2/3这些数字都行。

10 楼 todo158 2010-10-25  

llyzq 写道

这样的知识太珍贵了！谢谢分享

谢谢：）

9 楼 hjk685 2010-10-25  

很感谢您能给我们迷茫的指导，谢谢

8 楼 hjk685 2010-10-25  

功能需求和非功能需求有什么区别?功能需求定义和业务规则我有点难以区分请指教一下。需求分析是在签合同前进行的呢还是签合同后进行的呢？如果在之后进行那么要怎么给项目报价？

7 楼 llyzq 2010-10-24  

这样的知识太珍贵了！谢谢分享

6 楼 todo158 2010-10-23  

to:  Sunny_kaka
谢谢您的评价：）

5 楼 Sunny_kaka 2010-10-22  

楼主的这些文档虽然不复杂,但是却很实用.
感谢分享

4 楼 todo158 2010-10-20  

lxianhu 写道

，学习，学习、回味以前，感觉收益颇深。

IT这行就是通过不断的交流大步的往前走，谢谢：）

3 楼 lxianhu 2010-10-20  

，学习，学习、回味以前，感觉收益颇深。

2 楼 todo158 2010-10-20  

guofengcn 写道

学习！期待下一篇……现在还在作坊式的公司混，真想去这种正规化的公司看看，学习学习……

谢谢支持：）
文章做了一些改动，主要加了下面这些：
看完了，是不是感觉也就是这么一回事，可能和各位朋友日常做的没什么太大区别，不就是把需求文档分为三个文档吗，不是的，这些都是台面上形式的东西，在看不到的层面上，我们开始偷偷的在做一件事，控制，对项目的控制，让整个项目良性发展的控制，这种控制在后续的篇章中慢慢的展现给大家。

2010.10.20 10:09

1 楼 guofengcn 2010-10-20  

学习！期待下一篇……现在还在作坊式的公司混，真想去这种正规化的公司看看，学习学习……