章需求质量验证.pdfVIP

下载 第1 4章 需求质量验证 大多数软件开发者都经历过在开发阶段后期或在交付产品之后才发现需求的问题。当以 原来需求为基础的工作完成以后，要修补（ f i x ）需求错误就需要作大量的工作。有研究表明： 比起在需求开发阶段由客户发现的一个错误，然后更正这一错误需要多花 6 8 ~ 11 0倍的时间。 另外一个研究发现，在需求开发阶段发现的一个错误，平均仅需要花 3 0分钟修复，但是在系 统测试时发现的错误需要花 5 ~ 1 7个小时来修复（K e l l y, Sherif and Hops 1992 ）。检测需求规格 说明中的错误所采取的任何措施都将为你节省相当多的时间和金钱。 在许多项目中，包括使用典型的瀑布型生存周期法的项目，测试是一项后期的开发活动。 与需求相关的问题总是依附在产品之中，直到通过昂贵并且耗时的系统测试或由客户才可最 终发现它们。如果你在开发过程的早期阶段就开始制订测试计划和进行测试用例的开发，就 可以在发生错误时立即检测到并纠正它。这样可以防止这些错误进一步产生危害，并且可以 减少你的测试和维护费用。 用户需求和验 验收测试 收测试计划 功能需求和系 系统测试 统测试计划 体系结构和集 集成测试 成测试计划 时间 详细设计和单 单元测试 元测试计划 编码 图14-1 软件开发的V字模型 图1 4 - 1描绘了软件开发的 V 字模型，它表明了测试活动总是与开发活动平行发展的 （Davis 1993 ）。这个模型指明了验收测试是以用户需求为基础的，系统测试是以功能需求为基 础的，而集成测试是以系统的体系结构为基础的。在相应的开发阶段，必须规划测试活动并 为每一种测试设计测试用例。不可能在需求开发阶段真正进行任何测试，因为还没有可执行 的软件。然而，你可以在开发组编写代码之前，以需求为基础建立概念性测试用例，并使用 它们发现软件需求规格说明中的错误、二义性和遗漏，还可以进行模型分析。 需求验证是需求开发的第四部分（其余三个为获取、分析和编写规格说明） 。需求验证 一些作者在需求工程这阶段中使用“确认”这一术语（ T h a y e r和D o r f m a n 1 9 9 7 ）。验证决定了开发成的产品 是否能满足开始时所确定的需求（即正确完成任务）。确认只评估了过渡产品或最终产品是否能真正满足最 高层次的特定需求（即完成特定任务）。对于软件需求，这两个术语的差别是微妙的并且是有争议的，所以 需求工程阶段，我采用I E E E 的术语“验证”。 第1 4章 需求质量验证 117 下载 所包括的活动是为了确定以下几方面的内容： • 软件需求规格说明正确描述了预期的系统行为和特征。 • 从系统需求或其它来源中得到软件需求。 • 需求是完整的和高质量的。 • 所有对需求的看法是一致的。 • 需求为继续进行产品设计、构造和测试提供了足够的基础。 需求验证确保了需求符合需求陈述（ requirement statement ）的良好特征（完整的、正确 的、灵活的、必要的、具有优先级的、无二义行及可验证的）并且符合需求规格说明的良好 特性（完整的、一致的、易修改的、可跟踪的）。当然，你只能验证那些已编写成文档的需求， 而那些存在于用户或开发者思维中的没有表露的、含蓄的需求则不予验证。 在