混在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:下章我们将谈谈需求跟踪表,一个非常有特殊作用的管理小工具

你可能感兴趣的:(混在IT)