几十年来的经验表明，那些错误的、失败的或灾难性的项目让投资者付出了巨大的代价，而这些项目中的大部分都起源于含混的需求。多数持有某种信仰的人或理想主义者会认为，这个世界上存在着完全确定的东西；当他们筹建一个项目的时候，就把项目要求看成了确实存在的标准。现在，我们接下来他们提出的项目，那么，这一项目要求就成为了我们获得的需求陈述；不幸的是，这一需求陈述在绝大多数情况下是含混的。
虽然我们在很多时候祈祷上苍的保佑，但在具体实践和委托别人做事的时候，我们总会希望所用的方法是科学的。于是，对于那个存在于理想主义者心中（或者是天堂）的需求陈述，也最好遵守一些科学的准则。
这里我们就要说明，需求探索过程是一个渐进的、可以逐步测量的过程。而我们的假设就是，我们的所有相关人员当中，的确相信存在着某种明确的需求，并且大家愿意一起来找到它们。
需求探索过程就象是“历险”。为了避免含混性，我们要随时提醒自己：
我们不喜欢含混性的原因是含混性需要成本；我们认为含混性发现得越早越好，是因为越早发现成本越低。
时刻反省自己，反省自己在需求过程中的含混性，反省自己被这种含混性所带来的困扰。如果你发现产品并不完全如你所想，你可以问问自己：“是什么需求让我们制造了这样垃圾的产品？”
在需求工作中，会有若干种含混性产生，主要表现为：１）观察错误和回忆错误，因为我们每个人的观察能力和关注点都会有所差异，因此，任意两个人都不一定会看到完全一致的东西（观察错误），或者完全一致地记住他们所看见的东西（回忆错误）。２）理解错误。３）问题描述的含混性。
其中观察、回忆和理解错误，都与观察者自己有关；而问题描述的含混性，则与表述者有关。这就牵涉到我们前面说过的符号系统。
找出含混性来源的办法推荐如下：
对参与者进行需求文档某些部分的解释进行提问，并把相近结果归成一类。
通过询问每一类中的人们的想法来分析对每一类的理解。
同一类内部的差异来自于观察错误和回忆错误。
为了辨识各类之间的差别，可以请参与者回忆那个他们认为的被问的问题，当然不能给他们再看一遍。这个种方法能够找出解释错误。
通过对观察、回忆、解释错误的分析，找出问题描述中易犯上述错误的地方，修改它，或者做一些详细的注记。
善用工具来降低需求中的含混性
人往往如此；当你了解、学会、掌握、熟练了一种工具之后，就很难接受别的类似工具；而对于那些本质上并不类似的工具，人们也会自然地产生排斥心理。我们知道，每一种工具都有它的针对性和局限性。那么，为了很好地完成需求开发，我们一样需要有专门的工具和技术；针对于需求分析中的某些关键点，我们还需要对之进行更深入的研究。目前市面上有很多很多的项目管理的工具、方法以及软件，是否只要使用好它们我们就能一路顺风了呢？
文章来源于领测软件测试网 https://www.ltesting.net/
