第八讲 杏腓求验证 .pptVIP

第八讲 需求验证（第五章） 验证是为了确保需求说明准确、完整地表达必要的质量特点。当你阅读软件需求规格说明(SRS)时，可能觉得需求是对的，但实现时，却很可能会出现问题。当以需求说明为依据编写测试用例时，你可能会发现说明中的二义性。而所有这些都必须改善，因为需求说明要作为设计和最终系统验证的依据。客户的参与在需求验证(requirement verification)中占有重要的位置。 1)审查需求文档 对需求文档进行正式审查是保证软件质量的很有效的方法。组织一个 由不同代表(如分析人员，客户，设计人员，测试人员)组成的小组，对SRS及相关模型进行仔细的检查。另外在需求开发期间所做的非正式评审也是有所裨益的。 2)以需求为依据编写测试用例 根据用户需求所要求的产品特性写出黑盒功能测试用例。客户通过使用测试用例以确认是否达到了期望的要求。还要从测试用例追溯回功能需求以确保没有需求被疏忽，并且确保所有测试结果与测试用例相一致。同时，要使用测试用例来验证需求模型的正确性，如对话框图和原型等。 3)编写用户手册 在需求开发早期即可起草一份用户手册，用它作为需求规格说明的参考并辅助需求分析。优秀的用户手册要用浅显易懂的语言描述出所有对用户可见的功能。而辅助需求如质量属性、性能需求及对用户不可见的功能则在SRS中予以说明。 4)确定合格的标准 让用户描述什么样的产品才算满足他们的要求和适合他们使用的。将合格的测试建立在使用情景描述或使用实例的基础之上。 以下重点讨论1）和2）。 大多数软件开发者都经历过在开发阶段后期或在交付产品之后才发现需求的问题。当以原来需求为基础的工作完成以后，要修补(fix)需求错误就需要作大量的工作。有研究表明：比起在需求开发阶段，由客户在应用时发现一个错误，然后更正这一错误需要多花68-110倍的时间。 另外一个研究发现，在需求开发阶段发现的一个错误，平均仅需要花30分钟修复，但是在系统测试时发现的错误需要花5-17个小时来修复。检测需求规格说明中的错误所采取的任何措施都将为你节省相当多的时间和金钱。 在许多项目中，包括使用典型的瀑布型生存周期法的项目，测试是一项后期的开发活动。与需求相关的问题总是依附在产品之中，直到通过昂贵并且耗时的系统测试或由客户才可最终发现它们。如果在开发过程的早期阶段就开始制订测试计划和进行测试用例的开发，就可以在发生错误时立即检测到并纠正它。这样可以防止这些错误进一步产生危害，并且可以减少测试和维护费用。 图5-1描绘了软件开发的V字模型，它表明了测试活动总是与开发活动平行发展的。这个模型指明了验收测试是以用户需求为基础的，系统测试是以功能需求为基础的，而集成测试是以系统的体系结构为基础的。在相应的开发阶段，必须规划测试活动并为每一种测试设计测试用例。不可能在需求开发阶段真正进行任何测试，因为还没有可执行的软件。然而，可以在开发组编写代码之前，以需求为基础建立概念性测试用例，并使用它们发现软件需求规格说明中的错误、二义性和遗漏，还可以进行模型分析。 需求验证是需求开发的第四部分(其余三个为获取、分析和编写规格说明)。需求验证所包括的活动是为了确定以下几方面的内容： 软件需求规格说明正确描述了预期的系统行为和特征。 从系统需求或其它来源中得到软件需求。 需求是完整的和高质量的。 所有对需求的看法是一致的。 需求为继续进行产品设计、构造和测试提供了足够的基础。 需求验证确保了需求符合需求陈述(requirement statement)的良好特征(完整的、正确的、灵活的、必要的、具有优先级的、无二义性及可验证的)，并且符合需求规格说明的良好特性(完整的、一致的、易修改的、可跟踪的)。当然，这里仅验证那些已编写成文档的需求，而那些存在于用户或开发者思维中的没有表露的、含蓄的需求则不予验证。 在收集需求并编写成需求文档后，我们所进行的需求验证并不仅仅是一个独立的阶段。一些验证活动，例如对渐增型软件需求规格说明的反复评审，将贯穿着反复获取需求、分析和编写规格说明的整个过程。其它的验证步骤，例如软件需求规格说明的正式审查，是在正式确定软件需求规格说明基线之前对需求分析质量进行的最后一次有用的质量过滤。当项目计划或实际工作中的独立任务破坏了结构性时，就要结合进行需求验证活动，并且为随后出现的返工预先安排一段时间，这通常会在质量控制活动之后进行。 有时，项目的参与者不愿意在评审和测试软件需求规格说明上花费时间。虽然在计划安排中插入一段时间来提高需求质量似乎相应地把