|
2004 年 10 月 今天的软件行业有许多方面值得骄傲。全球软件和服务市场产值超过 2210 亿美元，已经成为当今时代最重要的经济支柱。从技术上讲，该行业引领着非凡的新技术开发，这些技术开发每天都在提高企业生产力。举几个例子，如图形用户界面、关系数据库、面向对象的编程、第四代语言，以及 Internet。 软件开发所面临的问题？ 但是在前进的同时存在一个令人担忧的潜在问题。软件开发仍然是艺术多于科学。尽管软件在艺术方面需要一定的美学和情感因素，但事实是软件的艺术方面从来就不是一个可依赖的过程。如同艺术本身一样，软件取决于创造力爆发和个人天赋，而不是取决于团队工作和工程规则。另外，现在软件解决的仅仅是 10 年前我们未想到的问题领域。 在 Scientific Americani 近期的一篇文章中，广泛地探讨了软件开发中奇缺的科学进步，这也是作者的观点。尽管许多业内人士认为本文不公正，但 The Standish Groupii 近期的一项研究肯定了几项关键统计数据，这些我们不得不承认：
这些问题触及了软件行业内部的软筋，因为我们都有过如此的经历。在子例程发明 40 年后，为什么我们还受到这些失败的困扰呢？大多数的开发者和研究者都同意以下的原因： 1. 极差的需求管理。我们只顾向前迈进，缺乏用户参与并且没有清楚地了解有待解决的问题。 2. 极差的变更管理。需求和软件开发的变更是无法避免的，然而我们很少跟踪这些变更或了解它们产生的影响。 3. 极差的质量控制。对于系统质量缺乏准确的度量，对影响质量的过程所知甚少，并且在特定的开发策略产生影响后，无相应的反馈信息来修改过程。 4. 对日程安排和成本极少进行控制。从来就没有过精确的规划。 这些问题的根源在于需求管理。毕竟，如果我们对于系统的预期行为没有彻底的了解，那么：1）我们如何能够确定那种行为？2）我们如何设计系统？3）我们如何知道系统是否能按预期的设想工作？4）我们如何度量系统达到的质量水平？5）我们如何预计所涉及的工作？ 简单地说，需求就是用户用于解决某一问题或实现某种目标所需的功能或特性。需求管理是一项系统的方法，用于识别、组织、交流和管理某一软件应用程序不断变化的需求。需求管理的首要任务是产生一个需求规格说明书，该规格说明书"定义并文档化待构建系统的完整外部行为" iii。 一个良好实现的需求管理程序提供了集中的信息库。该信息库包括需求、需求的属性、需求相关的状态信息，以及其他有关企业环境的管理信息。该信息库不仅对项目成功至关重要，它还是一种极具价值的企业资产。可以发展、调整和重用需求和其相关属性，从而降低项目后期开发成本。
更好的需求管理所带来的重要受益 即使根据以上信息，一些人仍然会争论：为什么在这个不必要的步骤上浪费时间；为什么不直接转向实现步骤？经验表明，有效的需求管理可以带来如下利益：
显而易见，做好上述工作可节省可观的时间和资金，更毫无疑问地减少了不成功或部分成功的软件开发所造成的职业挑战。 需求错误的高昂代价 1. 需求错误通常比其他错误多花费 10 倍时间来修复。 2. 需求错误通常占软件项目总错误的 40% 以上。 3. 需求错误的稍微减少能显著地降低返工成本和日程延期。 GTE、TRW 和 IBM 所做的研究度量指出了项目生命周期各个阶段发生错误的成本2。尽管这些研究是独立进行的，但它们几乎得到了相同的结论：如果指出编写代码阶段的错误检测和修复成本单位为 1，那么检测和修复需求阶段错误的成本要小 5 到 10 倍。并且，检测和修复维护阶段的成本大于 20 倍。图 1 显示了结果概要。 图 1
软件生命周期中，需求阶段节约的错误检测成本与维护阶段错误检测成本相比，多达
200:1 。 这个巨大差别的原因在于，很多这样的错误直到发生后一段时间才检测到。检测错误的延迟意味着修复成本既包括纠正错误本身的成本，也包括纠正后期阶段的错误相关投资成本。这些投资包括重新设计和替换代码的成本、文档重写成本和返工或在工作区内替换软件的成本。 需求错误是最常见的错误 这些研究表明，需求阶段的错误修复起来要付出特别高昂的代价。如果这样的错误很少出现，那么这项支出占总成本的比例将不再显得突出。但是，需求错误确实是复杂软件项目中典型的最大比例的错误。在 Sheldon 做的一项 US Air Forceiv 的项目研究中，根据错误的种类将它们进行了归类。结果表明需求错误占错误总数的 41%，而逻辑设计错误仅占 28%。其他案例研究也支持这项结论。例如，Tom DeMarco 引用的 Tavolato 和 Vincena 项目，56% 的bug 可以追溯到需求阶段所犯下的错误4。 通过更有效的需求管理节约成本 在 Raytheon 公司所做的一项研究中，Dion 报告了大约 40% 的项目总投资用于返工成本5。其他研究也表明，对于现在的大多数企业，返工成本占项目总成本的 30 - 40%。由于它们的巨大数额和多重影响，找到并修复需求错误占项目返工总成本的 70 - 85%。 企业（如 Raytheon）已经证实，改进其开发过程。从 CMM 级别 1 升级到CMM 级别 3（在下文中讨论），可以降低返工成本的 50 - 60%，尽管实际的情况有所不同，但显而易见的是，需求错误的稍微减少将显著地节约成本。 这些高昂成本还不包括与需求错误相关的无形成本。无形成本包括缺少可能交付的产品特性、项目团队丧失信心，以及失去可重获的市场，也失去了相关的收入和利益。综合了这些因素，这些成本表明公司不能忽视更好的需求管理带来的利益。 需求管理――来自
SEI 的能力成熟度模型的观点 CMM 为企业定义了 5 个软件成熟度级别，并提供了从一个级别改变到另一级别的框架。CMM 通过帮助企业改进其软件过程（目的是获得可重复性、可控制性和可度量性）为开发人员提供指导。CMM 已在软件密集行业获得很大的信任度。采用 CMM 和相应的软件质量改进，能够显著地降低大型商业企业内部应用程序开发成本9。这些成本节约首先来自返工成本的降低10。 按照 CMM 的定义，过程改进使用"关键过程域"。它们影响到开发过程和最终软件质量的各个方面。表4 显示了 CMM 的 5 个级别和它们的关键过程域。显而易见，表1 表明从级别 1 升级到级别 2 必须用到的关键过程域是需求管理。CMM 的定位是：需求管理是达到过程成熟度的首要步骤之一。
CMM
推荐的需求管理 在 CMM 模式下，必须了解、分析和文档化软件需求。再进一步，需求集合是软件开发计划的最初入口。企业务必要确保所有的软件计划和相关活动与文档化的需求保持一致。这样，需求成为核心项目焦点，并且将需求管理和项目管理不可分割地连接起来。 在 CMM 模式下要严格地管理需求变更。需求变更时，必须更新说明文档。企业同样有责任确保变更软件开发计划和活动，使之与需求变更保持一致。CMM 为每个关键过程域的度量和分析提供了建议域。这些度量为进行中的关键过程域自身改进提供了反馈信息。建议的需求管理中度量的样例包括： 需求管理是迈向过程成熟度的第一步 2. 每个已分配的需求的变更活动。 3. 累积的需求变更数量。包括跟踪变更的数量，这些数字是提议的、开放的、经核准的，并且合并到系统基准中。 4. 显然，管理这些属性的最佳方法是通过一个数据库，该数据库应了解需求本身、需求之间的关系，以及每一项需求的相关属性。 ISO 9000 和 FDA GMP
推荐的需求管理 ISO 9000-312，即"ISO 9001 用于软件开发、供应和维护的指导方针"，明确地将软件和嵌入式软件系统制造商作为管理对象。了解质量标准面向供应商的质量控制的原则后，不难发现焦点明显地集中在需求管理上。特别是在 5.3.1 小节规定： "为了进行软件开发，供应商应有一个全面的、明确的功能需求集合。另外，这些需求应包括满足买方需要的各个方面。可以包括但不局限于下述的方面：性能、安全性、可靠性、保密性。应足够精确地表明这些需求，以便在产品验收期间进行确认。" 本标准的目的是提供关于需求、变更管理和需求管理其他方面的一致的方法。但是，上述内容清楚地表达了两个主要问题：1）在开发之前，必须有一个完全的功能性和非行为性类型的需求集。2）需求必须足够详细，以支持产品确认。 总之，需求管理是一个关键域，必须用它来达到并保持与 ISO 9000 标准一致，并且由此获取质量利益，这也正是标准旨在提供的。 快速原型环境中的需求管理 1. 有一个系统好过没有系统。 2. 需求迟早会自己就显现出来，或者， 3. 工作时，开发人员将指出创建什么。 正确的解决办法首先是要采取各种方法尽可能多地了解需求。采取面谈的方式、团体座谈、发送问题调查表，以及召开讨论会和联系人会议。回顾 bug 报告和现有系统的加强要求。了解正在设计何种相似的或竞争性的应用程序来满足这些需求。最后，使用原型。 在取得一致的用户界面和实现特定功能方面，没有什么能比原型的作用更大。不仅能够通过原型来明确需求，而且还能通过它们来了解客户的需要和想法。 原型有两种：一次性原型和进化式原型。一次性原型以快速、粗略的方法构建，提供给客户用来得到反馈信息，一旦得到所需信息，该原型就废弃不用。一次性原型通常是一个非常短的需求文档，或者是单页的需求清单。一次性文档完成其工作后，在全面开发之前，务必要捕获所得到的需求，形成一个更健壮的需求规格说明书。 进化式原型以高质量方式构建，提供给客户用来得到反馈信息，并且修改它使其更接近用户的要求。一直重复此过程直到其内容集合了所需产品的特性。进化式原型将发展成最终产品，因此不要走开发捷径，相反，在项目开始就应该创建高质量、可全面跟踪的需求规格说明书。 当不了解关键的产品特性或产品结构时，可使用一次性原型。当对产品关键功能有很好的了解，但不了解其他特性时，可使用进化式原型。每一次返回修改时，都要将已了解的需求编辑成文档并规划创建满足这些需求的系统。 值得重复一提的是，一定要记录对需求规格说明书的了解。我们都曾听软件开发者说过，"我已经完成了设计，就差把它编写成文档了"。这毫无意义，特别对于今天的团队环境（要求通过清楚地沟通需求来达到成功）而言。您能接受一个建筑师这样说吗？"我已经完成了您新家的设计，就差画一张设计图了"，或一个小说家这样说，"我已经完成了小说，就差把它写出来了"。 如果您要大量改动需求，那么先不用记录；先规划创建增加的需求项，但这也不是对任意一个增加项的需求规格说明书泛泛工作的借口。 第2部分
使需求管理发挥作用 需求不仅变得更详细了，而且变得更加明确。需求最初产生于客户或用户。可以使用多种技术来获得需求，如面谈、讨论会、原型、问题调查表、质量函数部署技术等等。一旦得出需求之后，一项至关重要的任务是，从每个需求到更多抽象的前需求，和到更详细的后继需求的跟踪。跟踪有助于管理变更，并且是保证质量和健康需求管理的基础。 最后，可以得到更多的详细需求，这样的文档称为需求规格说明书（requirements specification）。本规格说明书必须经过沟通使所有相关方同意。它是设计（使设计者知道要设计何种系统）和测试（使测试者知道要测试何种系统）的基础。好的需求规格说明书具有如下特性： 1. 更低的模糊性。如果需求有多种岐意，那么产品不大可能会满足用户需要。 2. 完全性。尽管不可能了解一个系统的所有特性要求，至少应该详细列出已知的需求。 3. 一致性。如果两种需求互相冲突，那么不可能构建出满足所有需求的系统。 4. 可以追溯至开始。应该确定每一个需求的来源。可能是由一个抽象的需求细化而来，或是来自于一次与目标用户的特定会议。 5. 避免设计。只要需求还利用外部行为，例如被用户或其他交互系统查看，那么不管是何种详细程度，它们还是需求。当力图用需求来指明特定次要成分或其算法的存在，那么它不再是需求了，而变成了设计信息。 6. 需求是可以列举的。大多数的需求规格说明书都通过本身不是需求类的信息作为辅助，来提高需求规格说明书的易读性。这些信息包括介绍性的段落或语句，摘要陈述、表格、术语表，以及其他。应该以某种方式很容易分辨出文档中哪些是实际的需求内容，可以使用特定的字体、标识标签，或者其他突出方式。 此处完整地列出了制定需求规格说明书的原则，引自 Davis 的《201 项软件开发原则》（201 Principles of Software Development）一书中的第 3 章14。
在您的开发项目中存在许多重要的文档：用户需求描述、设计文档、测试计划等等。但有一个特殊的文档，即 SRS 软件需求规格说明书，是软件开发人员首先关注的文档。这个文档的目的是定义待建系统完整的外部特征。它定义了所有的行为方式需求（如本系统应在环境为 B 的情况下执行 A）和非行为方式需求（如本系统可用性应为 99.9%）。尽管标准不是万能的，但企业采用 SRS 标准将获得如下利益：
起草 SRS 时，大量的软件规范标准都可用作起始点。其中一项提供了大量的指导和灵活性，它就是 IEEE/ANSI 830-1993"IEEE 关于软件需求规格说明书的推荐实践"。还可以采用许多其他的标准来满足您的需要。Thayer 和 Dorfman13 编篡了一个很好的资源。13。他们的再版著作中包含了 26 种不同的需求规格说明书，包括国内、国际、IEEE、ANSI、NASA 和美国军事标准。 重要的是，文档提纲应具有准确性、一致性和便于理解。ANSI IEEE 830 可以作为 SRS 的一个好的起点。然后在使用的基础上，您会发现它还有益于修改标准使其成为与企业特定过程和文化更匹配的企业标准。 从文档选择需求 需求文档包含许多并非是系统需求的信息。例如，引言、总体系统描述、术语表和其他解释信息。尽管它们对理解需求起到重要作用，但它们不是系统要完成的需求。 为使需求交流更加简便，并且允许需求管理，编写者应为那些必须实现和随后要测试的部分（文本、图形或嵌入对象）加标签。最好是实际的需求保持"in situ"（拉丁语"在其最初的位置"），而不是存储在多个位置。也就是，即使作为单个需求选择后，也能够在项目文档中对其进行编辑和维护。这样更易于在需求改变时，对项目文档进行更新。 将需求组织起来 无论是采用公认的标准还是您自己的标准，都应该有一个部分用于特定的需求描述。假设有 500 项独立的需求，与其把它们列举为一个长串，还不如找到一种方法将它们分组，这也有助于理解它们。我们推荐的分组依据2：
对于明确定义了状态的应用程序，可以按照对应的运行模式把它们的需求分组。具有大量不同用户的系统，按照用户种类分组可能是最好的方法。例如，电梯控制系统规范可分成三个主要的子部分：乘客、消防人员和维护人员。这提供了一个逻辑方法，用来把特定需求进行分组，使每一类用户都能评审和了解各自的需求。 其他的应用程序根据特点来分组可能最合适－－也就是说，把突出特点和预期行为作为用户查看的依据。但是还有一些其他的系统，如空运系统，它在现实世界中有丰富的服务对象，它的最佳分组方法也许是根据系统对象的行为。这种方法也适用于已采用对象技术作为其开发范例的软件企业。
所有的需求都具有属性，无论我们是否识别它们。这些属性是一个丰富的资源，有助于规划、交流和跟踪整个生命周期中的项目活动。每个项目都有特定的需要，并且应该选择对于项目成功至关重要的那些属性。这里举一个实例： 开发的优先级――只有在考虑了需求相关的用户利益，和实现这些利益所需的工作之后，团队才能在项目日程和预算的双重限制下作出功能权衡。把优先级传达给整个企业，哪些功能要首先完成，哪些功能在时间允许的情况下完成，以及哪些功能可以推迟。在许多项目中，我们可以发现尽管还有更好的分级方法，但只要把相关的需求重要性按照高、中和低或重要、需要和可选这样的等级分类就足够了。 状态――应该能够通过一个或多个状态域跟踪关键决策和进程。在定义项目基准期间，如建议的、批准的和集成的这样的状态选择是恰当的。当进入开发阶段后，可以使用正在进行、完成和验证这样的状态来跟踪项目的关键阶段。 编写者――应在数据库中记录需求的个人（或团队）责任。这些责任可能是输入文本的人员责任或验证需求的人员责任。 责任方――负责确保需求达到满意程度的人。 基本原理――需求由于一些特定的原因而存在。这项属性记录了说明或是说明的参考资料。例如，参考资料可能是需求规格说明书中的一页或几行，或是重要的客户会见录音磁带中的某一分钟的标记。 日期――应在文档中记录需求创建或变更的日期。 需求的版本――随着需求的转化，标识需求变更的版本数（和历史版本）很有帮助。 与其他需求的关系――可以保持需求之间的很多关系。例如，属性域可以记录： 1. 作为本项需求来源的更为抽象的需求。 2. 从本项需求出发得到的更为详细的需求。 3. 本项需求是其子集的需求。 4. 作为本项需求子集的需求。 5. 必须在满足本项需求之前满足什么需求，等等。 保持从需求到所有开发产品（从需求开发而来）的链接非常重要。通过提供这些链接，人们易于确定任何变更带来的影响，并且快速确定开发状态（本状态应作为那些下游存在状态的属性） 需求可跟踪性――确保质量并且管理变更 大多数的美国国防部软件合同中都要求需求可跟踪性，所有高可靠性产品和系统的制造商典型地实践了这个能力。在卫生保健行业中，需求可跟踪性取决于良好生产实践管理（Good Manufacturing Practices Regulation）建议的变更。但是，这些行业外的大多数企业都不常规地实践需求跟踪。可跟踪性是两个事物间的链接或可定义的关系。使用需求可跟踪性的用户发现，它提供的项目控制水平和质量保证，是其他方法很难达到的。在 Abbott 实验室，1987 年就创立了可跟踪性，他们这样形容："如果您不能跟踪某项事物，那么就无法管理它"15。这形成了一项基本概念，原因就是如果没有某种形式的需求可跟踪性，那么就不可能确保需求测试的覆盖度。
需求跟踪带来的利益：简而言之，需求跟踪证明了软件按照设计工作。本过程的关键利益包括：
实现需求可跟踪性 图 3 显示了一个项目文档的简单层次。在这个例子中，产品需求文档是所有需求的"源文档"。在其他例子中，源文档可能是用户需要文档、系统规格说明等。 图中两个文档间的层次关系表明，文档中特定元素之间可能存在相互关系。例如，产品需求文档和软件需求规格说明文档的关系意味着，任何特定的产品需求都通过某个或多个软件需求来满足。同样，任何软件需求可以用于满足某个或多个产品需求。显然，一项产品需求如果没有相关的软件需求或硬件需求，它将无法得到满足。反之也一样，一项软件需求如果没有相关的产品需求，那么它就是多余的，应该将其删除。
除建立文档关系来支持可跟踪性外，还需要某些形式的系统来保持文档层次中单个项之间的链接。完成这项工作有两种方法，可以通过直接在文档内部嵌入链接和标识符来完成，或者通过使用一个独立的电子表格或数据库来管理文档外部的链接。每种方法都有优势和劣势。一种新的需求管理工具可以自动保持可跟踪性链接。理论上，相同的工具也集成了这项功能，来管理和控制文档和文档的单个需求。 变更管理 可跟踪性提供了一个系统的、可控制的过程，来管理应用程序开发过程中必然要出现的变更。如果不进行跟踪，那么对于每项变更，都要求检查特定基础上的文档，来判断哪个项目元素需要更新。因为很难确定所有受变更影响的组件都已经做过标识，因此变更可能导致系统可靠性下降。 利用可跟踪性，变更管理可以按有序的方式进行。可以通过文档层次中可跟踪性关系，来了解变更带来的影响。例如，如果用户需要变更，开发人员能够迅速确定需要改变哪些项目要素，测试人员也可以查明必须修订哪些测试计划，项目经理也可以更好地确定实施变更的难度和可能要花费的成本。 需求报告――易于进行管理评审 本项目共有多少项需求？哪些需求具有高的优先级？ 基本需求所占百分比有多大？何时实现这些需求？ 自从上次客户检查后，哪些需求发生了变更？谁负责这些变更？ 估计变更带来的成本变化是多少？ 高水平的报告有助于产品功能的管理评审。可以按照客户需要、难易程度、所需成本或用户安全需要，来划分需求的优先级。这些专项报告有助于项目经理集中精力于关键的项目问题上，更好地配置有限资源。最终可以达到：项目经理做出更英明的决策，由此改进企业应用程序开发工作的成果。
结束语 需求管理提供了应用程序需求和其相关属性、链接的"实时"库。本"实时"库是与软件设计初衷一致的。它提供了大量信息，可以用于管理和控制项目。软件质量将得到改善，更好地满足客户的需要。由于所有团队成员都可以访问需求数据，极大地改善了团队交流。 现在就开始。通过早期捕获需求错误，显著削减项目成本。试着用简单的描述写下当前项目的所有需求（提示：如果这难以做到，或还没做完，就查明原因）。将这些需求归纳到一个合适的、简短的报告中，并与客户和同事共享。取得他们的反馈意见。是否遗漏了某项需求？是否具有完全性？是否有错误？这是一个好机会来取得这三个问题的答案。如果现在所处阶段太早，不能纠正这些错误，那么就把它们集中存储起来。如果所处阶段太迟，那么征求一下哪些过程可以变更，并预计一下首先做什么工作。 参考书目 ii CHAOS, The Standish Group International, Inc., Dennis, MA, 1994 iii Davis, A., Software Requirements, Objects, Functions, and States, Englewood Cliffs, NJ., Prentice Hall, 1993. iv Sheldon, F. et al, Reliability Measurement from Theory to Practice, IEEE Software, 9,4 (July 1992) 4 Tavolato, P., and K. Vincena. "A Prototyping Methodology and Its Tool." In Approaches to Prototyping, R Budde et al., eds., Berlin: Springer-Verlag, 1984. pp. 434-46 5 Dion, R. "Process Improvement and the Corporate Balance Sheet," IEEE Software, 10,4 (July 1993),pp. 28-35 6 Paulk, M., et al, "Capability Maturity Model , Version 1.1", IEEE Software, 10, 4(July 1993), pp. 18-27. 7 Humphrey, W.S., Managing the Software Process, Reading Mass,Addison Wesley, 1989. 8 Paulk, M., et al, "Capability Maturity Model for Software, Version 1.1," Software Engineering Institute, Pittsburgh, PA, SEI-93-TR-024 9 Humphrey, W., et al., "Software Process Improvement at Hughes Aircraft," IEEE Software, 8, 4 (July 1991), pp. 11-23. 10 Dion, R. "Process Improvement and the Corporate Balance Sheet," IEEE Software, 10,4 (July 1993),pp. 28-35 11 Paulk, M., et al, "Capability Maturity Model for Software, Version 1.1," Software Engineering Institute, Pittsburgh, PA, SEI-93-TR-024 12 ISO 9000-3, "Guidelines for the Application of ISO 9001 to the Development, Supply, and Maintenance of Software", Int'l Organization for Standardization, Geneva, 1991 v Davis, A., 201 Principles of Software Development, New York, NY. McGraw-Hill, Inc., 1995 14 Davis, A., 201 Principles of Software Development, New York, NY: McGraw Hill, 1995. 13 Dorfman, M., and R. Thayer, Standards, Guidelines and Examples of System and Software Requirements Engineering, Los Alamitos, CA: IEEE Computer Society, 1991. 15 Watkins, R., and M. Neal, Why and How of Requirements Tracing ," IEEE Software, 11,4 (July 1994), pp. 104-106.
|
