浅谈软件项目上的长期慢性需求问题

        英文原文链接：Chronic Requirements Problems 

        本文的作者 Capers Jones 是 Namcook Analytics 公司的副总裁和首席技术总监。他一直在收集软件质量和开发效率上的数据。他写了几十本关于软件质量、最佳实践方法、评估、测量方面的著作。

        在处理软件需求时，有三个问题一直折磨着我们，并使软件项目消耗无数资金。其中很大一部分都产生在项目交付并运行后的新需求的收集工作中。

        下面是在软件需求处理中三个广泛存在的问题，需要我们去寻找比当前普遍的常规做法更有效的解决方案：

• 很多需求是非常危险或是有毒的，需要坚决抵制。
• 很多客户坚持要在软件中强加入一些额外的、多余的功能。
• 需求永远提不完，并以每月1% 的速率增加。

        软件开发者道德上有义务、职业上有责任在这些问题上提醒客户，并尽可能的帮助他们解决这些问题。换句话说，软件开发者需要充当的角色类似于一个医生。我们有责任帮助客户诊断目前已知的需求，并开出有效的处方。

        当然，一旦用户需求收集完成，分析整理完成，承诺的软件规格就应该如实的交付给客户。然而，为了保证软件能安全有效的交付，危险的或有毒的需求 必须被除去，多余的和不必要的需求需要让用户知道，潜在的能导致需求滋生的不清晰的地方需要被明确、量化。用户应该从软件开发技术团队那里获得专业的帮 助，而不应该在需求收集和分析上被动的扮演旁观者角色。

        不幸的是，需求上的缺陷并不能通过普通的测试来消除。如果需求上的错误未能预防而出现，或没有能够通过常规的检查或其它方法消除，那么，从需求 上构造出来的测试用例只能再次证实需求的正确，而不是发现其中的错误。(这就是为什么多少年的软件测试都不曾发现并消除”2000 年”问题)

        另一类需求上的问题，对于一些全新的创造性的软件应用，很可能最初用户只有原创者，没有第二人。参考一些成功的软件的历史，如 APL 编程语言，第一个电子制表软件，早期的 Web 搜索引擎(之后成为谷歌)。

        这些具有革命性的应用软件全是发明人自己用来解决他们自己的问题的。他们并不是按照常规概念上的“用户需求”开发出来的。除非演示程序被开发完 成，其他人基本无法认识到这些软件发明的价值所在。因此，“用户需求”对于一些全新的革命性的软件来说不是能完全适用的，除非它们已经公开发布。

        软件需求会不断的发展、繁殖、变化，在其随后的设计和编码阶段统计出的数据，每月增加的量大概是1% 到4%，基于这种现状，很显然，要想达到对需求的完全理解是十分困难的。

        需求是软件开发的重要一环节，但由于掺杂着有毒的需求，缺失的需求和多余的需求，使得简单的诸如“品质的标准就是照需求完成”这样的定义成为了软件工业的毒药。

        软件交付之后

        “增长的需求”这个问题经常不受重视。一旦软件应用交付给客户或用户，需求并不是终止或不变了。对于大多数的应用，需求的增长的延续会一直伴随着应用的使用期间。它们增长的速率最高能达到每年 15%。

        因为需求在增长，软件应用的体量也会变大——不论从功能点，逻辑代码量或其它尺度测量。

        为了说明这种持续性增长，下面的表格显示了一个我研究的大型 Java 应用的变化。

        这些数字在第 4 年和第 8 年有一个超出平均值的增加。对于商业软件，为了跟最新的其它软件竞争，有必要增加一些重大的新功能。这叫做“中期提升”。

        正如你看到的，需求增加在软件应用使用期间永不会停止，除非开发者开发出相同类型的新产品而放弃对老产品的支持。当然，一些软件会很好的运行 10 几年。例如，美国空中交通管制系统已经使用了超过 30 年了。

        怎么办…

        软件需求是软件工程技术中最薄弱的一个环节。因为需求总是不完备的，总是含有错误的，这就要求软件开发者一定要使用最先进的软件需求方法。用户 并没有培训过这些需求收集/分析技术，在没有经过受训的需求专家的帮助下无法提供完整无误的需求，更重要的，软件开发者应该理解——甚至拥抱——这样的事 实：在软件交付运行之后，跟用户关于需求的对话将不会停止。