4. 不必要的特性

　　“画蛇添足”是指开发人员力图增加一些“用户欣赏”但需求规格说明中并未涉及的新功能。经常发生的情况是用户并不认为这些功能性很有用，以致在其上耗费的努力“白搭”了。

　　开发人员应当为客户构思方案并为他们提供一些具有创新意识的思路，具体提供哪些功能要在客户所需与开发人员在允许时限内的技术可行性之间求得平衡，开发人员应努力使功能简单易用，而不要未经客户同意，擅自脱离客户要求，自作主张。

　　同样，客户有时也可能要求一些看上去很“酷”，但缺乏实用价值的功能，而实现这些功能只能徒耗时间和成本。为了将“画蛇添足”的危害尽量减小，应确信：你明白为什么要包括这些功能，以及这些功能的“来龙去脉”，这样使得需求分析过程始终是注重那些能使用户完成他们业务任务的核心功能。

　　时刻记住：软件成功的标准是是否解决用户的问题，而不是它有多Cool的功能。

　　5. 过于精简的规格说明

　　有时，客户并不明白需求分析有如此重要，于是只作一份简略之至的规格说明，仅涉及了产品概念上的内容，然后让开发人员在项目进展中去完善，结果很可能出现的是开发人员先建立产品的结构之后再完成需求说明。这种方法可能适合于尖端研究性的产品或需求本身就十分灵活的情况(McConnell 1996)，不过商业应用大多都不是这种情况。在大多数情况下，这会给开发人员带来挫折(使他们在不正确的假设前提和极其有限的指导下工作)，也会给客户带来烦恼(他们无法得到他们所设想的产品)。

　　6. 忽略了用户分类

　　大多数产品是由不同的人使用其不同的特性，使用频繁程度也有所差异，使用者受教育程度和经验水平也不尽相同。如果你不能在项目早期就针对所有这些主要用户进行分类的话，必然导致有的用户对产品感到失望。例如，菜单驱动操作对高级用户太低效了，但含义不清的命令和快捷键又会使不熟练的用户感到困难。

　　7. 不准确的计划

　　“上述是我对新产品的看法，好，现在你能告诉我你什么时候能完成吗？”许多开发人员都遇到这种难题。对需求分析缺乏理解会导致过分乐观的估计，而当不可避免的超支发生时，会带来颇多麻烦。据报道，导致需求过程中软件成本估计极不准确的原因主要有以下五点：频繁的需求变更、遗漏的需求、与用户交流不够、质量低下的需求规格说明和不完善的需求分析(Davis 1995)。

　　对不准确的要求所提问题的正确响应是“等我真正明白你的需求时，我就会来告诉你”。基于不充分信息和未经深思的对需求不成熟的估计很容易为一些因素左右。要作出估计时，最好还是给出一个范围(如最好的情况下，很可能的，最坏情况下)或一个可信赖的程度(我有9 0 的把握，我能在8周内完成)。未经准备的估计通常是作为一种猜测给出的，听者却认为是一种承诺。因此我们要尽力给出可达到的目标并坚持完成它。

　　什么是优秀的需求

　　讨论软件需求的文章有很多，对于需求的标准也不尽相同，这里我想用NASA的软件开发过程中的概念，软件需求过程的标准是：清楚(Clear)、完整(Complete)、一致(Consistent)、可测试(Testable)，此外还有其他的概念，如可跟踪的、可修改的等等。

　　清楚：目前大多数的需求分析采用的仍然是自然语言（因为如果采用形式化语言的话，和用户的沟通将成为一个大问题，这意味着客户在开发软件之前必须先进行形式化语言培训，这是不现实的）。自然语言对需求分析最大的弊病就是它的二义性。所以我们不得不对需求分析中采用的语言做某些限制。例如尽量采用主语＋动作的简单表达方式。说白了，需求分析中的描述让人看上去像是刚学习写作的小孩子就对了，千万不要采用疑问句、修饰这些华丽的表达方式。

　　除了语言的二义性之外，主意不要使用行话，就是计算机术语。需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。

　　打个比方，如果你要做一个银行的信用卡系统，你就可以这样描述软件需求：银行的卡部管理信用卡，每张信用卡只属于一个帐户。信用卡有卡号、余额。一张信用卡有多笔的交易记录。

　　完整：再也没有什么比软件开发接近完成是发现遗漏了一项需求更糟的事情了。需求的完整性是非常非常重要的，想象一下遗漏需求而不得不返工，这简直就是恶梦。可是令人遗憾的是，需求的遗漏是很经常发生的事情，不仅仅是你的问题，更多的问题发生在用户那里，他们不知道该做些什么。要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各方各面，贯穿了整个过程，从最初的计划制定到最后的需求评审。至于完整性的详细讨论，我们会在下面的章节中讨论，现在你只需要拼命的想象缺乏完整性的坏处，直到你出了一身的冷汗。出了吗？好，那我们继续。

　　一致：一致性也是一个比较大的概念，很难用几句话讲清楚。还记得我们在开始的时候提到的需求的层次吗？简单的来说，就是用户需求必须和业务需求一致，功能需求必须和用户需求一致。严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。在实现过程中，我们还必须把一致性关系细化。比如说用户需求不能超出先前指定的范围。

　　可测试：大家觉得一个项目的测试从什么时候开始呢？有人说从编码完成后开始。更清楚一点的说是编码的时候同时进行单元测试，编码完成后进行系统测试。这些都没有错。但是实际上测试是从需求分析过程就开始了。需求分析是测试计划的输入和参照。这就要求需求分析是可测试的。什么是可测试呢？“我们要用新的系统完成报表自动化处理”，你觉得这个需求是可测试的吗？当然不是，报表包括哪些？自动化处理的标准是什么？这些在需求中都没有说明。因此这项需求是无法测试的，就是不具有可测试性。说到这里，大家可能就会明白之前的需求的几项标准都是为了保证需求的可测试性的。事实就是这样，只有系统的所有需求是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。