2.3.3　软件需求的规模、结构和完整性

任何试过阅读大型应用程序的软件需求的人都知道，这类材料通常晦涩难懂，阅读起来非常费劲。这应该一点都不奇怪。

一方面，软件应用程序本身通常由约20%的输入屏、50%的无形处理逻辑以及30%的输出显示和报告组成。

另一方面，软件需求由约75%的文本、15%的图形和表格、5%的屏幕图像和5%的图表组成。在需求的表述方式中，文本被用得最为广泛，但却不是非常有效。如果把统一建模语言（UML）用于需求，图形内容的比例会更高。即使有用例和一些图形化表述方式（如UML提供的那些内容），要看完并理解需求也往往是一项艰巨的任务。

表2-4显示了软件需求的大概规模和完整性，对应的应用程序规模在10到100000个功能点之间。表2-4基于一般的信息系统应用程序。原始发明的需求和嵌入式软件的需求有着不同的属性。

应用程序的完整性随着规模的增长越来越差，其主要原因是，如果需求文档的页数真实地反映了软件应用程序的整体规模，那么按照普通大学毕业生的阅读速度，大约50000个功能点的需求文档的厚度就会超过其一生的阅读量。

为何需求会在软件开发过程中增加和改变，普通需求中的缺口和遗漏是原因之一。表2-5显示了需求月增长率的近似值，以及从需求阶段结束到部署阶段间的累积增长。

从表2-5中可以看出，对于有1000个功能点的应用程序，不到10%的交付特性是由于需求变更而增加的，但是对于有10000个功能点的应用程序，原始需求阶段之后的需求变更贡献了27%的交付特性。对于100000个功能点规模范围内的大规模系统而言，因需求变更而贡献的总增长率可达到50%。项目的工期越长，需求变更导致的增长率越大。

某些需求变更是由糟糕的需求分析导致的，其他变更是由于一些外部事件，如税法的变更、新任务、兼并与收购，以及其他在软件开发团队所能控制的范围之外的业务问题。

在设计和编码阶段软件需求的增长最为迅速。在某个时间点，有必要冻结当前版本的所有新需求并将其推迟到未来的版本中。这个时间点通常接近于编码阶段结束、在专业测试人员开始正式测试之前。因此，表2-5中需求增长的时间段被人为地设置为整个工期中按月计算的50%。当然这是比较武断的简单化，现实世界是存在差异的。

这在软件文献中并没有被广泛地认识到或者讨论，不过软件需求的变更往往比原始需求有着更多的潜在缺陷（由于赶工）和更低的缺陷清除效率（由于质量控制不严格）。因此，需求变更引起的缺陷超过了其在软件应用程序全部缺陷中应有的水平。如果变更需求让应用程序的规模增长10%，那将会造成交付缺陷增加大约12%。如果变更需求让应用程序的规模增长30%，那会造成交付缺陷增加超过40%。

表2-6给出了软件需求缺陷的近似数量和部署前的平均缺陷清除效率。表2-6基于普通的信息系统，其需求来自于用户和利益相关者。

表2-6假设需求缺陷的质量控制是平均但不充分的。换句话说，在表2-6中，测试是主要的缺陷清除方法，并且假设没有正式的需求审查、质量功能展开（QFD）和联合应用设计（JAD）。

当分析由发明者创造的需求或者嵌入式应用程序和商业软件包的需求时，会发现其需求和潜在缺陷来源与普通信息系统中的是非常不同的。

对于个人发明者为了解决对其个人来讲非常重要的问题而创建的软件应用程序而言，公平来讲其中没有需求缺陷。当然，快速追随者会很快改进最初的概念，但当独特而新颖的软件应用程序刚刚出现时，除了发明者外，没有别人使用。

对于控制实体设备的嵌入式应用程序而言，多数软件需求来自于硬件需求。这些硬件需求中可能有缺陷，但它们或多或少在软件开发组的控制之外。任何情况下，嵌入式应用程序中的软件需求缺陷数量似乎只有信息系统中的20%左右。

操作系统、办公套件和ERP软件包等商用软件的设计和源代码中有大量的bug和缺陷，但却没有多少需求缺陷。原因是其需求往往基于市场上竞争对手有哪些特性，而不是基于用户或利益相关者想到的特性。

实际上，很多商用软件包更多地遭受“特性膨胀”（feature bloat）之苦而不是需求缺陷。举个例子，本书的一位作者用Microsoft Word写过15本书和200多篇期刊文章，不过他用到的特性几乎不超过这个大型软件全部特性的5%。2011年，Microsoft Word的规模很可能接近5000个功能点，而写普通的格式化文本以及借助拼写检查特性来编辑只需要大约250个功能点。

当然，Microsoft Word拥有千百万用户，每个人需要的特性集可能稍有不同。有些用户需要数学公式，有些需要很多不同的字体，有些需要多列页面，等等。

通常情况是，某些竞争性领域的商业软件产品习惯于“特性竞争”，每个新版本都会推出一些（期望）竞争对手没有的东西。因为商业软件包在竞争压力下经常不得不更新，所以每年其特性都变得越来越多，越来越复杂。