BOB体官网手机版

 

因此，截至2009年，需求分析不应该只涉及新的需求，而且还应包括对遗留代码进行数据挖掘，以提取隐藏的业务规则和算法。有些工具可以做到这一点，也有很多的维护工作台可以显示代码，并且帮助提取潜藏的业务规则。虽然，清晰的需求是一个值得称赞的目标，但是对于拥有10000个功能点的App应用来说，这个目标只能是个奢望。到目的为止，笔者只观察到了一个小型项目，它的功能点少于500个。并且该应用的初始需求是清晰的和不变的。

对于大型应用来说，业务需求是动态的，并且不可能是一成不变的。BOB体官网手机版的许多外部事件都会使App应用的需求发生变化，如税法的变化、企业结构的变化、业务流程的再造以及兼并和收的等。另外，大型应用的开发一般需要几年的时间，这使得情况变得更加复杂了。一个企业仅仅为了满足一个App项目的需求而冻结其所有的业务规则，显然是不现实的。最典型的情况是处理拥有10000个功能点应用的需求，收集和分析初始的需求将花费数个月。在随后的设计过程中，每个月的新需求和变更需求将达到2%左右。最终的需求总量将会达到初始需求的50%。在发布了App应用的第一个版本之后。应该终止这些新的和变更的需求，并且在9-12个月之后，在后续的版本中添加新的需求和变更的需求。对于拥有10000个功能点的项目来说，每个月的需求变更比例稍低于0.5%，累计增量不超过原始需求10%，然而，最大的增量可以达到200%。在设计和编码阶段，每个月需求变更的平均比例在1%-3%之间，而之后的变更剧被添加到了以后的版本中了。

同时使用JAD会议、仔细的需求分析、需求审查以及原型可以使需求过程在技术和管理的控制之下。虽然有时需要数月甚至数年才能看到项目的结果，但是大型App项目的成败在需求阶段就已经一口了然了。成功的项目在收集和分析需求上，比失败项目更完整、更彻底。因此，成功的项目变更很少，以及需求蔓延也很少。 然而，由于大多数新应用都是遗留应用的翻新，因此需求应该包括数据挖掘，以提取遗留应用的潜在业务规则和算法。