截至2009年，假如从应用是否是首次开发的层面来讲。80%以上的软件应用都不是新的。当前，大多数应用都是旧的或过时的应用的替代品。由于这些应用程序都是过时的，因此它们的书面功能规格说明文档通常会被忽视，并且这些规格说明也是过时的。然而，虽然缺乏当前的文档，但是旧应用却包含数百或数千的业务规则和算法，因此需要将这些业务规则和算法转换到新应用中。
因此，截至2009年，需求分析不应该只涉及新的需求，而且还应包括对遗留代码进行数据挖掘，以提取隐藏的业务规则和算法。有些工具可以做到这一点，也有很多的维护工作台可以显示代码，并且帮助提取潜藏的业务规则。虽然，清晰的需求是一个值得称赞的目标，但是对于拥有10000个功能点的软件应用来说，这个目标只能是个奢望。到目的为止，笔者只观察到了一个小型项目，它的功能点少于500个。并且该应用的初始需求是清晰的和不变的。
对于大型应用来说，业务需求是动态的，并且不可能是一成不变的。网站制作的许多外部事件都会使软件应用的需求发生变化，如税法的变化、企业结构的变化、业务流程的再造以及兼并和收的等。另外，大型应用的开发一般需要几年的时间，这使得情况变得更加复杂了。一个公司仅仅为了满足一个软件项目的需求而冻结其所有的业务规则，显然是不现实的。最典型的情况是处理拥有10000个功能点应用的需求，收集和分析初始的需求将花费数个月。在随后的设计过程中，每个月的新需求和变更需求将达到2%左右。最终的需求总量将会达到初始需求的50%。在发布了软件应用的第一个版本之后。应该终止这些新的和变更的需求，并且在9-12个月之后，在后续的版本中添加新的需求和变更的需求。对于拥有10000个功能点的项目来说，每个月的需求变更比例稍低于0.5%，累计增量不超过原始需求10%，然而，最大的增量可以达到200%。在设计和编码阶段，每个月需求变更的平均比例在1%-3%之间，而之后的变更剧被添加到了以后的版本中了。
同时使用jad会议、仔细的需求分析、需求审查以及原型可以使需求过程在技术和管理的控制之下。虽然有时需要数月甚至数年才能看到项目的结果，但是大型软件项目的成败在需求阶段就已经一口了然了。成功的项目在收集和分析需求上，比失败项目更完整、更彻底。因此，成功的项目变更很少，以及需求蔓延也很少。然而，由于大多数新应用都是遗留应用的翻新，因此需求应该包括数据挖掘，以提取遗留应用的潜在业务规则和算法。