1.2 每个项目都有需求

　　Frederick Brooks在他1987年的经典的文章“No Silver Bullet：Essence and Accidents ofSoftware Engineering ”中充分说明了需求过程在软件项目中扮演的重要角色：

　　开发软件系统为困难的部分是准确说明开发什么。为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。

　　每个软件产品都是为了使其用户能以某种方式改善他们的生活，于是，花在了解他们需要上的时间便是使项目成功的一种高层次的投资。这对于商业终用户应用程序，企业信息系统和软件作为一个大系统的一部分的产品是显而易见的。但是对于我们开发人员来说，并没有编写出客户认可的需求文档，我们如何知道项目于何时结束？而如果我们不知道什么对客户来说是重要的，那我们又如何能使客户感到满意呢？

　　然而，即便并非出于商业目的的软件需求也是必须的。例如软件库、组件和工具这些供开发小组内部使用的软件。当然你可能偶尔勿需文档说明能与其他人意见较为一致，但更常见的是出现重复返工这种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文档的代价。

　　近来，我遇到一个开发小组开发包括流程图工具和源代码编辑器在内的一套计算机辅助软件工程工具。不幸的是，在他们开发完这个工具后，发现这个工具不能打印出源代码文件，而用户当然希望有这个功能。结果这个小组只好手工抄写源代码文档以供代码检查。这说明那怕需求明确无误并构思准确，如果我们没有编写文档，软件达不到期望目标也只能是咎由自取了。

　　相反的情况，我曾为一个要集成到“商业错误跟踪系统”中的简单电子邮件界面写了一页需求说明。而U n i x系统管理员在为处理电子邮件写脚本时发现简单的一张需求清单竟是如此有用。我依据需求对系统进行测试时，此系统不仅非常清晰地实现了所有必需功能，而且未发现任何错误。

　　1.3 什么情况将会导致好的群体发生不合格的需求说明

　　不重视需求过程的项目队伍将自食其果。需求工程中的缺陷将给项目成功带来极大风险，这里的“成功”是指推出的产品能以合理的价格、及时限在功能、质量上完全满足用户的期望。

　　下面将讨论一些需求风险。第5章将介绍怎样应用软件风险管理防止与需求有关的风险的出现。

　　不适当的需求过程所引起的一些风险

　　用户不多导致产品无法被接受。

　　用户需求的增加带来过度的耗费和降低产品的质量。

　　模棱两可的需求说明可能导致时间的浪费和返工。

　　用户增加一些不必要的特性和开发人员画蛇添足（gold-plating）。

　　过分简略的需求说明以致遗漏某些关键需求。

　　忽略某类用户的需求将导致众多客户的不满。

　　不完善的需求说明使得项目计划和跟踪无法准确进行。

　　1. 无足够用户参与

　　客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫，开发人员可能也不重视用户的参与。究其原因：一是因为与用户合作不如编写代码有意思；二是因为开发人员觉得已经明白用户的需求了。在某些情况下，与实际使用产品的用户直接接触很困难，而客户也不太明白自己的真正需求。但还是应让具有代表性的用户在项目早期直接参与到开发队
伍中，并一同经历整个开发过程。

　　2. 用户需求的不断增加

　　在开发中若不断地补充需求，项目越变越庞大以致超过其计划及预算范围。计划并不总是与项目需求规模与复杂性、风险、开发生产率及需求变更实际情况相一致，这使得问题更难解决。实际上，问题根源在于用户需求的改变和开发者对新需求所作的修改。

　　要想把需求变更范围控制到小，必须一开始对项目视图、范围、目标、约束限制和成功标准给予明确说明，并将此说明作为评价需求变更和新特性的参照框架。说明中包括了对每种变更进行变更影响因素分析的变更控制过程，有助于所有风险承担者明白业务决策的合理性，即为何进行某些变更，相应消耗的时间、资源或特性上的折中。

　　产品开发中不断延续的变更会使其整体结构日渐紊乱，补丁代码也使得整个程序难以理解和维护。插入补丁代码使模块违背强内聚、松耦合的设计原则，特别是如果项目配置管理工作不完善的话，收回变更和删除特性会带来问题。如果你尽早地区别这些可能带来变更的特性，你能开发一个更为健壮的结构，并能更好地适应它。这样设计阶段需求变更不会直接导致补丁代码，同时也有利于减少因变更导致质量的下降。

　　3. 模棱两可的需求

　　模棱两可是需求规格说明中为可怕的问题(Lawrence 1996)。它的一层含义是指诸多读者对需求说明产生了不同的理解；另一层含义是指单个读者能用不止一个方式来解释某个需求说明。