一顿午饭的需求

转自：http://blog.csdn.net/Owen2007/archive/2008/06/30/2599777.aspx

什么是需求呢，简单地说，是（正在构建的）系统必须符合的条件或具备的功能。

在软件开发中，摆在我们面前的第一个问题就是如何获取和描述正确的需求，而后才能谈得上构建正确的系统来满足对应的需求。可是，需求的获取不是一件容易的事，就拿大家熟悉的日常生活中的活动来看，需求的捕获都不简单。何况，随着系统复杂度和项目规模的增加，系统的需求捕获、定义和管理成为一个复杂的问题。

 

以下借食客（代称“贾方”）和厨师（代称“伊方”）之间的对话来说明一个需求沟通和获取的过程，看看在其中我们可能会碰到的问题和一些常见的陷阱。

 

需求的沟通过程

伊方：“中午吃什么呢”? （了解需求，提出需求的大范围）

贾方：“随便，能吃得下就行”  （想不清楚自己的需求。。。，当然午饭本身就包含了很多需求）

伊方：“就怕你吃不下，吃米饭还是面条” （开始引导需求。。。， 是否还有吃饱子的选择呢？）

贾方：“天热，还是面条吧，做起来简单” （其实已经有需求，就是不想说或是没有意识到）

贾方：“嗯，最近也有些想吃海鲜了”（ 看似随便一说，可能包含了真正的需求）

伊方：“那好啊，我们就做海鲜面吃吧” （总结了一个高层需求）

贾方“嗯，海鲜面嘛，至少得有鱼和虾吧” （开始细化需求）

伊方：“我以前很少做海鲜面，你能给些建议吗？” （考虑需求获取的办法，敞开式问题）

贾方：“应该是汤面，最好要再加点菜”  (更多的功能性需求)

贾方：“夏天了，面汤要清淡一些” （哈哈，非功能性需求？可是，清淡怎么体现？）

伊方：“宽面还是细面？” （再一次使用选择式问题）

贾方：“细面吧”

伊方：“对了，你以前如果有吃过海鲜面的话，回忆看看需要哪些原料” （类比法获取需求）

贾方：“那倒没有印象了，不过我可以上网给你搜索一份海鲜面的菜单；哈哈，有了，面条500克，虾半斤。。。。” （需求还是设计呢？）

伊方：“你有吃过这么做出来的海鲜面吗？这就是你需要的海鲜面吗？” （挖掘问题背后的问题，客户的实际需求是这样的吗？）

贾方“我也没试过，只是看这里这么写的，感觉做出来的会好吃” （是个假象，只是感觉而已，实际的需求还是要好吃的面，可是‘好吃’怎么体现呢？）

伊方“嗯，我打个电话咨询一下，看看怎么做好吃” （咨询专家？头脑风暴？好像已经开始设计了哦？）

伊方“要不，我先少做一点，你先尝尝； （快速原型法？可是对于做顿午饭来说，似乎代价太大了）

伊方“或者，我用少量面和海鲜先做汤，你尝尝口味” （这也可以迭代？面汤是最重要的用例或用户故事？客户最关心汤的味道）

伊方“你看，这里有个海鲜面的图片，希望做出来的是这样的” （原型界面？）

贾方“我们家里有现成做好的虾和鱼丸，就用它们好了” （设计约束？）

伊方“除了海鲜面，还要有其他配菜吗” （开始考虑其他相对次要的需求）

。。。。。。

为了方便，伊方记录了对于海鲜面的需求 （需求规格说明？）

 

故事的继续-烹饪开始

伊方开始了烹饪海鲜面的过程。

先准备好虾、鱼丸、面条、青菜等主料，考虑好烧水、下面、加海鲜、下调料等的顺序（架构，或是其部分？）

为了今后做海鲜面作为参考，将上述的配方和过程记录下来（设计文档？过程文档？）

烧水、下面、海鲜单独加热、加入海鲜、添加调料。。。。。。，哈哈面条要出锅了（实现？）

快出锅前，先尝尝口味，加调料不断调整（测试和修改？）

。。。。。。

 

惊人发现

发现用家中现成的虾和鱼丸来做海鲜面，味道不错，决定批量生产，销路很好（构件化？服务？）

发现用这种方法调制出来的面汤，实在是很鲜美，用它来煮面，有没有海鲜似乎都不重要了（框架？）

终有一日，伊式海鲜面风行天下。。。

 

秘诀

用做软件的方式来做海鲜面，效果果然不同凡响。