给各位朋友分享的需求规则说明书是在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、 设计、编码、测试等等角色都可以从需求跟踪表中找到涉及到的编号、从编号在找到分册，在修订模式下是不是很方便的比较出新需求的变化。
