2.3.1　软件需求的专门案例

50多年来，软件质量的一个传统定义是“与需求的一致性”。不过，这是一个不成功的定义，因为需求本身就充斥着缺陷，这些缺陷产生的软件缺陷数目能占到总数的20%。目前美国需求缺陷的平均数大约是每个功能点1.00个缺陷。显然，与一个主要的错误来源一致不是稳妥的软件质量定义。

软件需求缺陷不仅为数众多，而且它们也非常难通过静态分析和测试等标准方法来清除。在一个需求缺陷真的出现在已批准的需求文档中后，使用这些文档设计的测试用例往往会证实这个缺陷而不是质疑它。

有害需求通过正常的测试是不可能清除的，一个很好的“有害需求”的例子是著名的Y2K问题。使用两位数字表示年份源于20世纪60年代一个明确的用户需求，当时的存储器是昂贵而有限的。当然，在1999年年末年份要变成2000时，所有基于日期的排序操作都只能丢弃。这也解释了为什么在Y2K的修复上花费了巨资。

另外一个可能导致严重后果的需求错误案例是电子投票器省略了书面记录，这导致很难检测到错误、篡改和蓄意伪造。

软件工程团体有道德义务和职业责任来帮助客户理解并消除有害的需求。不能期望客户自己能理解将业务应用转换到计算机上的复杂过程，所以应由软件工程团体负责阻止他们的客户实施有害的需求。该团体应该有个自己的《希波克拉底誓言》，其中包含“首要之务就是不可伤害”这样的概念。

幸运的巧合是，功能点度量方法的结构能很好地匹配应该包含在软件需求里的根本问题。按照时间先后，这7个基本的主题可以作为需求收集过程的一部分：

1）应由应用程序产生的输出；

2）将传给软件应用程序的输入；

3）须由应用程序维护的逻辑文件；

4）应用程序逻辑文件中的实体和关系；

5）可用于应用程序的查询类型；

6）应用程序、其他系统和用户间的接口；

7）应用程序必须呈现的关键算法和业务规则。

注意，要分析的第一个也是最重要的需求是输出。Gallup和Nielsen等民意调查公司多年前就发现，当需要一个新调查时，第一步是要生成一个模拟的报告，向客户展示调查将会产生哪些信息。

这样做的原因是，如果在清楚地了解输出之前就尝试获取输入，那么往往会收集比真正需要多得多的数据。因此，需求分析过程需要从软件应用程序的输出和可交付成果开始。

这7个主题中有5个是国际功能点用户组（IFPUG）功能点度量方法的基本元素，它们是：输出、输入、逻辑文件、查询和接口。

第4个主题“实体和关系”，是英国Mark II功能点度量方法和较新的COSMIC功能点的一部分。

第7个主题“算法”，是特征点度量方法的标准因子，这种方法在IFPUG用到的5种基础功能点元素上又添加了一些算法。

需求和功能点分析间有很强的协同效应，所以有可能创建一个组合了支持全套功能点方法和需求分析的工具。实际上，这种工具的一个可工作版本已经开发出来了，但是很可惜，委托开发的公司在它可以部署前不幸倒闭了。

如果需求和功能点两者都能全自动化，那么需求本身肯定是有相当好的结构并且是相当完整的。为此，除了这7个根本的需求主题外，还有13个应该在需求收集阶段解决的其他补充主题：

1）应用程序按功能点和源代码统计的规模；

2）应用程序从需求到交付的进度表；

3）应用程序按活动以及按每个功能点计算的成本；

4）就缺陷、可靠性和易于使用的标准而言的质量水平；

5）将运行应用程序的硬件平台；

6）软件平台，如操作系统和数据库等；

7）应用程序及其数据库的安全标准；

8）应用程序的性能标准（如果有的话）；

9）培训需求或者可能需要的辅导材料格式；

10）将应用程序安装到主机平台上的安装需求；

11）应用程序的重用标准，一是应用程序中重用的材料，二是应用程序的特性是否力求能被后续项目重用；

12）期望用户通过应用程序能完成的用例或者主要任务；

13）应用程序中信息的控制流或序列。

这13个附加主题并不是能包含在需求里的全部主题，但是我们不应该不小心忽略其中任何一个，因为它们都会对软件项目产生重大影响。

功能点和软件需求之间的协同效应是足够好的，所以合并需求收集过程和功能点度量以及同时提高这两者，现在在技术上是可行的。

实际上，现代的需求生成和分析工具会包含以下特性和功能。

1）从遗留的应用程序源代码中提取算法和业务规则的方法：大部分“新”应用程序实际上用于替换遗留的应用程序。遗憾的是，多数遗留应用程序没有更新其需求和设计文档，所以源代码成了失去的算法和业务规则的唯一资源库。能够对遗留代码进行类似法医一样的分析工作的工具，对于处理遗留需求而言是一个极大的提高。

2）识别和显示被很多相似应用程序使用的通用特性的方法：多数软件应用程序中大约有75%的特性在其他应用程序中也用到了，可以将这些通用特性归并到一组可重用对象中，这组对象包含源代码、测试用例、需求规格说明书和用户信息。在需求分析开始时如果有一份标准的可重用组件列表，那么需求分析工作将会得到极大的简化。该主题及前一主题具有协同效应，因为遗留应用程序的法医式分析应该能识别常见的和通用的特性。

3）作为需求分析的自然副产品，自动估算应用程序规模的方法：因为功能点度量方法和应用程序需求紧密相关，所以规模数据可以从需求列表中自动产生。实际上，手工的功能点分析是基于需求的，这一过程能实现完全的自动化。通过模式匹配进行应用程序规模的估算已经成为可能。把这种能力扩展到针对特定的特性而不是整个应用程序，能为需求分析过程增加价值。除了规模估算外，能够执行风险分析、解决方案建模和总体拥有成本（Total Cost of Ownership，TCO）预测等相关特性，都能让需求分析更加实际。

4）作为需求分析的自然副产品，自动定义测试用例的方法：“可测试的需求”一旦确定，则测试计划和测试用例也就准备好了，这是逻辑上的必然性。对于来自于遗留应用程序的需求，测试用例和其他材料应该是可重用材料包中的一部分。如果不是的话，那么负责提取丢失的算法和业务规则的数据挖掘工具就应该同时定义测试用例。对于新的和独特的应用程序，可测试的需求应该自动地结合需求自身与测试用例和测试脚本。

5）处理软件应用程序动态方面的方法：软件在执行时有更多的移动部件，并且其移动速度比其他任何已知的产品都快。这个事实表明，软件需求和设计工具不应该单单基于静态的表现方式，如文本、表格、图表和屏幕图像。软件需求工具应该能够为运行着的应用程序建模，这意味着需要动画——很可能是全彩三维动画。

6）处理需求随时间推移而增加的方法：度量过的开发过程中的需求增加比率大约是每月1%。软件部署后，只要还在使用，那度量过的软件持续加强或者修改的平均比率大约是每年8%。这些百分比的基数是需求阶段结束时应用程序的预测规模。起始的需求应该设想到多年、多个版本的策略需要，并方便划分应用程序的子集，避免因规模过大而无法在一个版本里设计。

7）处理运行在Windows、Linux、Leopard和Android等多种平台上的应用程序的方法：此外，需求分析过程也需要考虑较新的主题（如云计算和SOA）。当今世界上，许多应用程序可以在多种平台上运行，并且既能以安装的应用程序又能以Web驱动的应用程序的形式来使用。所有可能的托管和部署版本都应该包含在需求中。

8）处理运行在多个国家的应用程序的方法：本土化和区域化如此普遍，所以健壮的需求分析工具要包含处理这些主题的内建导航：语言翻译、货币汇率、本地法律和政策，甚至像处理频繁的电力中断这样的主题（这个主题目前不是很普遍，但将变得更加普遍）。不同国家的本地法律和安全限制方面的信息也是需要的。最近巴林禁用黑莓手机事件说明了为什么本土化是软件需求中的关键主题，虽然巴林事件中的政治成分比技术成分更多。

9）评审和分析过去已开发或在相同行业中广泛部署的类似应用程序案例的方法：这类数据将包含成本基准和进度信息、架构和设计特性以及用户团体调查。从10～50个类似的应用程序中收集数据是非常有效的，而不是一抹黑地仅使用本地需求。实际上，这些应用程序的某些特性对于本地应用程序的需求分析可能是有帮助的。本书写作时，本书的一位作者正在（美国）某州政府做软件风险评估工作。其中有一个要评估的应用程序已经在其他几个州尝试并且失败了。这种对类似应用程序的调查能在需求分析阶段提供重要信息。

10）处理安全漏洞和可能的安全攻击的方法：现代世界中，所有软件应用程序都存在风险。处理财务数据、医疗档案、国家安全、税务信息和其他各种各样的重要信息的应用程序更是处于极度危险中。现代的需求生成工具应该包含关于开发开始前安全漏洞处理的专家建议，并且应该提供将“拒绝服务”攻击、病毒、蠕虫、僵尸网络和其他现代安全问题的风险最小化的最有效的策略建议。实际上，在今天，不仅要考虑传统的安全问题，还要考虑可能由电磁脉冲（EMP）导致的电子设备和计算机中断。

总而言之，现代的需求生成工具很可能支持3D、全彩、动画的图形表现方式，包含一个以可重用形式提供的通用特性的完整清单，并包含规模估算、测试用例生成和安全预防方法生成的特性。还应支持多种平台和多个国家并链接到基准资源（如ISBSG），从而找出具有同样规模、样式和种类的应用程序。

[1]希波克拉底为古希腊医生，被奉为西方“医学之父”。《希波克拉底誓言》是每个医学生第一堂课要学习的内容，其中最重要的是不造成任何伤害。——编辑注