发现错误的阶段	成本倍数
需求阶段	1
设计阶段	3-6
编码阶段	10
开发测试阶段	15-40
应用测试阶段	30-70
实际运行阶段	40-1000

为了修正一个错误，所要付出的成本

　　尽管上面的表格已经能够生动地说明：对于任何一个错误，如果能够在需求阶段发现它，那将是多么地节约成本啊！但是，专家说了，这些数字还是很保守的，因为Beohm同志研究的项目都已经完成了，也就是说这些数据中还没有包括至少1/3的没有完成的项目，而这些夭折的项目很大程度上都应该“归功于”需求分析。
　
　　几十年来的经验表明，那些错误的、失败的或灾难性的项目让投资者付出了巨大的代价，而这些项目中的大部分都起源于含混的需求。多数持有某种信仰的人或理想主义者会认为，这个世界上存在着完全确定的东西；当他们筹建一个项目的时候，就把项目要求看成了确实存在的标准。现在，我们接下来他们提出的项目，那么，这一项目要求就成为了我们获得的需求陈述；不幸的是，这一需求陈述在绝大多数情况下是含混的。
　
　　虽然我们在很多时候祈祷上苍的保佑，但在具体实践和委托别人做事的时候，我们总会希望所用的方法是科学的。于是，对于那个存在于理想主义者心中（或者是天堂）的需求陈述，也最好遵守一些科学的准则。
　
　　这里我们就要说明，需求探索过程是一个渐进的、可以逐步测量的过程。而我们的假设就是，我们的所有相关人员当中，的确相信存在着某种明确的需求，并且大家愿意一起来找到它们。
　
　　需求探索过程就象是“历险”。为了避免含混性，我们要随时提醒自己：

　　1、我们不喜欢含混性的原因是含混性需要成本；我们认为含混性发现得越早越好，是因为越早发现成本越低。
　
　　2、时刻反省自己，反省自己在需求过程中的含混性，反省自己被这种含混性所带来的困扰。如果你发现产品并不完全如你所想，你可以问问自己：“是什么需求让我们制造了这样垃圾的产品？”
　
　　在需求工作中，会有若干种含混性产生，主要表现为：１）观察错误和回忆错误，因为我们每个人的观察能力和关注点都会有所差异，因此，任意两个人都不一定会看到完全一致的东西（观察错误），或者完全一致地记住他们所看见的东西（回忆错误）。２）理解错误。３）问题描述的含混性。
　
　　其中观察、回忆和理解错误，都与观察者自己有关；而问题描述的含混性，则与表述者有关。这就牵涉到我们前面说过的符号系统。
　
　　找出含混性来源的办法推荐如下：1、对参与者进行需求文档某些部分的解释进行提问，并把相近结果归成一类。
　
　　2、通过询问每一类中的人们的想法来分析对每一类的理解。
　
　　3、同一类内部的差异来自于观察错误和回忆错误。
　
　　4、为了辨识各类之间的差别，可以请参与者回忆那个他们认为的被问的问题，当然不能给他们再看一遍。这个种方法能够找出解释错误。
　
　　5、通过对观察、回忆、解释错误的分析，找出问题描述中易犯上述错误的地方，修改它，或者做一些详细的注记。
　
　　善用工具来降低需求中的含混性人往往如此；当你了解、学会、掌握、熟练了一种工具之后，就很难接受别的类似工具；而对于那些本质上并不类似的工具，人们也会自然地产生排斥心理。我们知道，每一种工具都有它的针对性和局限性。那么，为了很好地完成需求开发，我们一样需要有专门的工具和技术；针对于需求分析中的某些关键点，我们还需要对之进行更深入的研究。目前市面上有很多很多的项目管理的工具、方法以及软件，是否只要使用好它们我们就能一路顺风了呢？

上一页  [1] [2] [3] [4] 下一页

【责编:Lili】