含混性的形式和来源
无论什么时候，如果人们仅仅使用那些忽略了人性因素的自动化工具，就绝不可能完美地描述需求。而且，含混性随之而来，看起来整整齐齐的需求规格说明书可能会带来各种各样的解释。
我们认为，含混性有多种形式，比如：
（1）表意不全。也就是说，这种需求陈述缺少很多必要的产品性质描述。例如，对于某种方案的使用方法、耐用性、成本，对这种产品的大小、形状、重量、寿命，以及对于这种东西可能应该包含的功能、所处的物理环境、文化氛围等等都是需求陈述中非常重要的组成部分。
（2）表意不清。用词含糊是含混性的重要来源。尤其要注意一些模糊概念的词汇运用，比如说，大、小、多、少、非常、很，等词汇都非常难以度量。
（3）理解者自以为是。几乎世界上所有的人都拥有他们对某些认识上的成见，而视那些不同看法为偏激或是钻牛角尖。人性的弱点让他们自以为是地代表了大部分人的意见，从而把自己的偏见当成了共识，最终陷入真正的误解。
需求中的含混性，在有经验的开发人员眼里，无疑就是开发过程中需求不断扩展、进度不断延期、质量不断下降、可控性不断落空的罪魁祸首。
《软件工程经济学》的作者Barry W. Beohm同志通过对63个软件开发项目的研究，得出了下面的表格，不妨一读，右边的是表格对应的柱状图，不妨一看。 发现错误的阶段 成本倍数
为了修正一个错误，所要付出的成本
尽管上面的表格已经能够生动地说明：对于任何一个错误，如果能够在需求阶段发现它，那将是多么地节约成本啊！但是，专家说了，这些数字还是很保守的，因为Beohm同志研究的项目都已经完成了，也就是说这些数据中还没有包括至少1/3的没有完成的项目，而这些夭折的项目很大程度上都应该“归功于”需求分析。
文章来源于领测软件测试网 https://www.ltesting.net/
