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

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

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

看图说话：

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

[align=center][img]http://dl.iteye.com/upload/attachment/333809/0c09ff85-fb63-3aa0-aa12-18f585983b2e.jpg[/img][/align]

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

[align=center][img]http://dl.iteye.com/upload/attachment/333812/a20faaed-0b18-3f16-a885-bbf42b44b75c.jpg[/img][/align]

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

[align=center][img]http://dl.iteye.com/upload/attachment/333817/5037e23c-07a7-34ef-a12b-ac4fe182c106.jpg[/img][/align]

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

[align=center][img]http://dl.iteye.com/upload/attachment/333819/9763225b-785b-3b00-bdf5-3f31202a71dc.jpg[/img][/align]

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

[align=center][img]http://dl.iteye.com/upload/attachment/333821/9b088692-8ad1-31af-a907-ff09710c239d.jpg[/img][/align]


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

[align=center][img]http://dl.iteye.com/upload/attachment/333823/a48ea4c2-d1fa-3e4d-bca5-8ee30b66330d.jpg[/img][/align]


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

[align=center][img]http://dl.iteye.com/upload/attachment/333825/34a8bce5-41fc-3028-b576-46097461f9cf.jpg[/img][/align]
[align=center][img]http://dl.iteye.com/upload/attachment/333827/24f58783-1b39-3595-b212-4b691f8aae1b.jpg[/img][/align]

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

[align=center][img]http://dl.iteye.com/upload/attachment/333829/5ff60885-b2d2-3470-81b3-1b9737d6bc47.jpg[/img][/align]
[align=center][img]http://dl.iteye.com/upload/attachment/333832/c3dbf16a-6935-3b04-bc93-86723a057757.jpg[/img][/align]

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

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

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