软件应用要�

截至2009年，如果是从应用是否是第一次开发的层面。超过80% 的软件应用程序都不是新的。目前，大多数应用程序都是旧应用程序或过时应用程序的替代品。因为这些应用程序已经过时，所以它们编写的功能规范文档常常被忽略，这些规范也已过时。然而，尽管缺少当前文档，遗留应用程序仍包含成百上千个需要转换为新应用程序的业务规则和算法。

因此，从2009年开始，需求分析不应只涉及新需求，还应包括遗留代码的数据挖掘，提取隐藏的业务规则和算法。有一些工具可以做到这一点，并且有许多维护工作台可以公开代码并帮助提取底层业务规则。虽然明确的需求是一个值得称赞的目标，但对于一个拥有10000个功能点的软件应用来说，这个目标只能是意料之中的。到目前为止，笔者只观察过一个功能点不到500个的小项目。并且应用程序的初始要求是明确且不变的。

对于大型应用程序，业务需求是动态的，不能是静态的。许多外部事件都会改变软件应用程序的要求，例如税法的变化、公司结构的变化、业务流程的再造以及并购。此外，大型应用程序的开发通常需要数年时间，这使情况更加复杂。一家公司仅仅为了满足一个软件项目的需要而冻结所有的业务规则显然是不现实的。最典型的情况是处理一个应用程序有10000个功能点的需求。收集和分析初始需求需要几个月的时间。在后续的设计过程中，新增和变更需求将达到每月2%左右。最终总需求将达到初始需求的50%。在发布软件应用程序的第一个版本之后。这些新的和变更的要求应该被终止，并且在9-12 个月后，新的和变更的要求应该被添加到后续版本中。 10000个功能点的项目，月需求变化率略小于0.5%，累计增量不超过原需求的10%。但是，最大增量可以达到200%。在设计和编码阶段，每月的需求变更平均比例在1%到3%之间，后续的变更剧会添加到以后的版本中。

同时使用JAD 会话、仔细的需求分析、需求审查和原型制作使需求过程处于技术和管理控制之下。虽然有时需要几个月甚至几年才能看到项目的结果，但是一个大型软件项目的成败在需求阶段就已经知道了。成功的项目比失败的项目更完整、更透彻地收集和分析需求。因此，成功的项目变更很少见，需求蠕变也很少见。然而，由于大多数新应用程序都是遗留应用程序的改造，因此要求应包括数据挖掘以提取遗留应用程序的底层业务规则和算法。