2.3.4　最小化软件需求缺陷

信息系统软件需求很大却不完整，难于理解，忽略了质量等必要的主题，并且包含很多的缺陷，其中一些可能是“有害的”且根本不应该包含在软件应用程序中。那么可以做些什么来改善软件需求中这些根深蒂固的问题呢？

从长远来看，对当前需求分析方法的完整评估，加上对诸如认证的重用和3D动画等高级主题的尝试，可能会显著改善需求，同时也能改善软件开发实践。

短期内，我们还是不得不采用当前可用且容易获取的需求方法、工具和技术。下面讨论当前可以将软件应用程序中根深蒂固的需求问题减到最少的技术。

1.标准需求大纲

对软件需求规格说明书有一些建议的概要内容。这里给出的概要内容既描述了应用程序自身的特性，也描述了一组在制定需求时需要分析和解决的逻辑主题。表2-7列出了25个描述软件应用程序的主题和20个逻辑主题。

表2-7拟成为一般化的内容表格，适用于信息系统、Web应用程序、嵌入式应用程序和系统软件。军事和政府软件需要包括一些特殊的主题，比如独立验证和确认（IV&V）和独立测试等民用部门很少使用的主题。

需求的一个标准大纲是和多个其他方法的协同作用，可以用于连接联合应用设计（JAD）、质量功能展开（QFD）、用例和很多其他方法。

2.联合应用设计（JAD）

为收集信息系统需求，20世纪70年代中期，IBM多伦多分部开发出了一种名为联合应用设计（JAD）的技术，如今有30多年的经验数据已经展示了其价值。

联合应用设计包含一个由4～8个利益相关者和用户组成的小组和另一个由4～8个软件架构师和设计者组成的小组，由这两组通力合作找出新应用程序的需求。

JAD会议经常在非工作区举行，以使被中断的可能性降至最低。JAD会议期间，要求参与者能够完全空出时间，会议可能持续几天，也可能长达两周。因为每个人都有其他的业务职责，所以JAD会议一般可能会限制在每天6个小时，这样参与者能够处理其日常工作中的一些紧急事务。

软件需求收集的JAD方法已使用了很多年，对于10000个功能点规模范围内的大型应用程序而言，也被证明是成功的。JAD方法常常能收集到至少90%的应用程序初始版本需求。JAD需求中的缺陷往往很少，通常每个功能点小于0.25个。JAD中的需求变更通常低于每月0.5%，或者小于平均变更率的一半。

如果应用程序的规模超过100000个功能点或者用户数超过100000，那么即便是JAD都可能无法让人满意。如果应用程序不仅有软件还有硬件组件的话，那么硬件的代表也必须出席。

3.嵌入式用户

JAD方法最近的一个变种成为了软件开发中敏捷方法的一部分。在开发周期，一个或多个用户代表被自始至终“安插”在开发团队中和团队一起工作，而不再限制开发者和用户群体间的合作期限。

用户代表和开发者共同创建关键特性的需求，这些特性一般需要差不多两周的时间来开发。这被称为sprint。其理念是通过构建能够尽快投入使用的具体特性来构建软件应用程序，而不是作为一个连续的流来设计和构建应用程序。

对很多规模小于约2500个功能点的较小应用程序来说，嵌入式用户方法已被证明是很有帮助的。当应用程序的规模增加到10000个功能点或者用户数超过大约1000时，单个用户代表不再能应付可能会需要的所有特性。

敏捷提出了一些使用户团队结合起来的方法，但是对于非常大的应用程序（大于10000个功能点并多于1000个用户），统一软件过程（RUP）和团队软件过程（TUP）等替代方法的效果似乎比敏捷更好。

当用于1000个功能点规模范围内的较小项目时，嵌入式用户方法似乎是有效的，需求缺陷通常小于每个功能点0.25个。

敏捷环境中的需求蠕变难以度量，因为敏捷的基本理念是以一系列的"sprint"来设计和构建应用程序，每个"sprint"包含一个或多个关键特性。因为sprint如此之短，所以实在没有足够的时间留给计划外的需求变更。

4.用例

Ivar Jacobsen很可能是首次确切阐述软件用例的人，他也是UML以及RUP方面的关键人物。用例大概从1986年开始被使用，并且一般和敏捷开发及其众多变种联系在一起。

用例描述了用户（被称为“参与者”）使用软件应用程序执行特定的功能性任务时的场景。用例有好几种风格，其细节也分为好几个等级，但所有这些都不在本书的范围内。

用例度量和功能点度量在理论上有些重复，它们都涉及软件应用程序带给用户的价值方面。从实际应用的角度看，用例界还没像国际功能点用户组（IFPUG）那样，形成一个广泛采用的标准功能点度量方法。相反，一个独立的“用例点”被开发出来以提供定量化的类似表示。

标准功能点能应用到使用了用例的应用程序，但反之则不行。用例点只能用于度量那些使用了用例的项目。因此，使用用例的项目和使用其他方法（如用户故事、Nassi-Shneiderman图、决策表等）的项目间是不能使用用例进行横向比较的，虽然很容易通过标准的功能点来完成比较。

用例稍微有点冗长，在100到大约1500个功能点的规模上，应用程序的每个功能点平均约为1.5页。超过这个规模，单个功能点的用例数会减少，因为会有太多的用例需要跟踪记录。用例不可能覆盖100%的软件操作和活动，所以需要另外的方法来表述数学算法和某些业务规则。

对于给定规模的应用程序，用例的潜在缺陷和文本表述的基本相同，即每个功能点约有0.5～1.15个缺陷。可以对用例进行审查，而且这确实是在复杂系统中保证用例质量的推荐步骤。

使用UML的图形化表述构建的用例非常容易理解和审查。

5.用户故事

敏捷方法已经一致正确地指出，过度的文档是软件的慢性问题，的确是这样。用户故事（user story）试图创建一种相当简洁和非正式的方法来描述用户需求，它使用较短的语句和较少的段落。

一个典型的用户故事可能类似这样开始：“当我使用应用程序开始一个会话时，我希望能选择创建一个新会话或恢复最近使用过的会话。”

对于规模在1000个功能点以下且用户总数不到100的小项目，用户故事方法看上去简单明了，而且几乎没有缺陷。每个功能点的用户故事平均约为0.5页，每个功能点的缺陷个数小于0.5。

不过对含有10000个或者更多功能点、用户数多达甚至超过1000（且他们使用软件的方式各不相同）的应用程序而言，用户故事方法就不那么好用了。在这么大的应用程序中，每个功能点的用户故事个数很可能多达1.25页，而每个功能点的缺陷可能高达0.75。

除了审查外，没有其他有效的方法来消除用户故事中的需求缺陷。从用户故事中创建测试用例是可行的，也是我们所推荐的，但是需求质量的基本目标是在需求缺陷进入源代码之前消除它们。

6.原型

在正式构建软件应用程序前做原型，这种做法具有很长的历史和相当多的经验数据，且普遍比较成功。然而，如下所述，原型有些限制和边界条件需要加以考虑。

用来写原型的编程语言通常比用来写应用程序的更高级。例如，原型可能使用Visual Basic来构建，而应用程序自身可能会使用Java或Objective-C来构建。平均而言，原型具有大约10%的应用程序功能。这个事实有些隐含意义。

原型极少用于规模小于100个功能点的应用程序，因为整个应用程序能相当容易、快速地开发出来，基本上不需要原型。

多于10000个功能点的应用程序中也极少使用原型，因为即使只对10%的功能做原型，那也有1000多个功能点，这本身也是巨大的工作量。因为软件应用程序最常见的规模在大约500到1500个功能点之间，原型对中等规模的开发项目而言是很有价值的辅助。

原型有3种不同的类型：淘汰式（disposable）、演化式（evolutionary）和时间框式（time box）。顾名思义，“淘汰式”原型在达到试验应用程序的特性和接口目的后即可抛弃。相反，演化式原型试图逐步形成和发展，直到成为真正的应用程序。时间框式原型是按特定时间窗（比如一个或两个星期）来构建的。较短的时间限制意味着大多数时间框式原型是淘汰式的。

大体上，与演化式原型相比，淘汰式原型和时间框式原型更为廉价，性价比更高。原因是原型通常会很快开发出来，有些粗枝大叶，极少会有正式的审查，也不会为原型准备正式的测试用例和测试脚本。软件质量保证（Software Quality Assurance，SQA）组极少参与原型的验证。当然，静态分析工具可以并且应当用于原型。根本问题是，演化式原型的质量控制如此松懈，以至于它们常常含有相当数量的潜在缺陷，每个功能点多达1.25个bug或缺陷。除非使用静态分析工具，原型的缺陷清除效率通常低于80%。

淘汰式原型无疑含有相同数量甚至更多的潜在缺陷，但淘汰式原型中的缺陷是临时的，原型被丢弃后缺陷也就不存在了，因而大部分都不会出项在最终的应用程序中。

总体而言，同样验证用户接口和关键运算，淘汰式原型要比演化式原型更快、更廉价，也可能更安全。根据定义，原型是“快的”，且这种快速不会使它演化成完整的应用程序。

7.质量功能展开（QFD）

QFD是在日本比在美国使用得更为广泛的先进质量方法之一。其早期工作是20世纪70年代由水野滋和赤尾洋二两位博士在制造业背景下完成的。QFD在许多复杂产品的设计中获得成功，并逐步跨过太平洋进入美国以及软件行业。

QFD具有广泛的文献基础和大量的书籍和文章。QFD还有一个名为QFD研究所（Quality Function Deployment Institute）的大型用户协会。QFD有几部分已成为习语，并被广泛引用：“顾客的声音”（The voice of customer）和“质量屋”（The house of quality）。第一个习语是指用于分析客户质量需求的正式QFD方法。第二个习语是指一种特有的图示方法，酷似一个有斜屋顶的房子。该图示方法结合了来自用户的质量需求和来自工程团体的质量答复。

QFD的经验数据揭示了它确实有益于软件质量并能最大限度地减少需求缺陷。此外，这些好处大多数是针对大型的复杂应用程序的，其他方法对这些应用程序而言效果似乎都不理想。

从在美国能获得的有限数据来看，QFD和其他需求方法相比，似乎减少了大约75%的需求和设计缺陷。然而，QFD不是软件需求和设计的100%的解决方案，所以它可以和UML图、用例以及其他各种表述方式结合起来。

8.正式的需求审查

本节要讨论的最后一个方法是最古老的可行方法之一：使用IBM于20世纪60年代末至70年代初开发的方法进行软件需求的正式审查。

正式审查有大量的文献和许多书籍、文章可以利用。网上也有一个非盈利的软件审查用户协会（Software Inspection User Association）。

要使用正式审查，需要有一个训练有素的团队，包括一个仲裁人和一个记录员。此外，还需要其他审查人员，当然还有待审查产品的开发人员。审查团队最少需要3个人（仲裁人、记录员和负责人）、一般为5个人（仲裁人、记录员、负责人和两个其他的审查人），最多是8个人。

大型审查团队中额外的审查人员通常是整个质量团队的一部分，其工作是SQA、测试，有时会是技术写作者。

正式审查给出了有记录的最高缺陷清除率。寻找缺陷时通常能达到85%，最高时达到97%。此外，审查对所有的软件可交付成果都同样有效，包括但不限于：

●需求；

●设计；

●项目计划；

●源代码；

●测试计划；

●测试用例；

●用户手册；

●培训材料；

●帮助文档。

审查可以覆盖100%的特定可交付成果，或者只用于最关键的特性。显然，100%的审查更全面但也更昂贵。

正式审查规则约定提前一个星期给出要审核的材料，从而团队可以提前查看。第一个审查会议由记录员收集好在这一周时间内发现的缺陷报告开始。

因为审查团队还有其他工作，审查被限制为两小时的会议，且每个工作日最多安排两次会议。审查通常会在私密的会议室以面对面会议的形式举行。但也有可能通过Skype或网络会议工具等进行远程审查。一般审查会议规定文本材料长度不超过25页，大约是150条源代码语句，或者大约10个测试用例。

关于审查重要的一点是，其主要目的是找出缺陷，而不是当场修复它们。每个缺陷都要记录，但修复工作会在审查会议之后完成。

有时可能会在材料中发现太多的缺陷，以至于审查团队决定就修改后的材料再做一次审查。

像IBM这样的大型公司通常会有一个审查协调员，负责预订审查会议室，分发要审查的材料，以及负责审查时间、成本和发现的缺陷等数据（这些数据在每次审查结束后都要进行报告）。

虽然审查过程的描述可能使其听上去是耗时和昂贵的，但经验数据表明，应用程序使用正式审查后，与只进行测试的类似应用程序相比，其工期更短，成本更低。最好的例子是20世纪70年代IBM IMS数据库产品。在审查之前，IMS测试组需要花费90天做三轮测试。而进行了审查之后，同样的测试周期缩短到30天，只做一轮测试。

审查不仅是最好的缺陷清除方法，也是最好的缺陷预防方法。它是如此有效的缺陷预防方法的原因是，审查的参与者都会自然地避免出现审查中发现过的同样问题。因此，进行审查后大约一年内，所有审查过的可交付成果中潜在缺陷个数往往会下降50%。