第六章软件需求验证.ppt

第六章 软件需求验证 周立新 博士 北京大学软件与微电子学院 课程提纲 软件需求基本理论和概念 软件需求工程过程 软件需求获取 软件需求分析 软件需求规格说明 软件需求验证 软件需求管理 软件需求实现 软件需求工程新进展 软件需求开发与需求管理工具 内容提要 软件的质量属性分析 需求质量验证 需求评审 需求测试 Relationships among selected quality attributes Validation Answer the question “Do I build the right thing?” Requirements validation is done either against real-world user needs or high level requirements specifications Verification Answer the question “Do I build what I was going to build?” Requirements verification is done typically against lower level requirements, design and/or test procedures 需求评审 由一些非软件开发人员进行产品检查以发现产品所存在的问题，这就是技术评审。 需求文档的评审是一项精益求精的技术，它可以发现那些二义性的或不确定的需求，那些由于定义不清而不能作为设计基础的需求，还有那些实际上是设计规格说明的所谓的“需求”。 需求评审也为风险承担者们提供了在特定问题上达成共识的方法。 需求评审方法 非正式评审的方法包括把工作产品分发给许多其它的开发人员粗略看一看和走过场似地检查一遍（walkthrough）。 正式技术评审的最好类型叫作审查（Inspection）。正式评审内容需要记录在案，它包括确定材料、评审员、评审小组对产品是否完整或是否需要进一步工作的判定，以及对所发现的错误和所提出的问题的总结。正式评审小组的成员对评审的质量负责，而开发者则最终对他们所开发的产品的质量负责。 如果你对提高软件的质量持有认真的态度，那么就审查所编写需求文档的每一行。 Software Requirement Review Informal review Peer desk check Pass around, such as through email Walk through Formal reviews Fagan inspection - used by many organization as an effective way to improve software quality 需求审查过程 参与者 产品的开发者及其可能的同组成员——编写需求文档的分析员提供这方面观点。 先前产品的开发者或正在评审的项目的规格说明编写者。 要根据正在审查的文档来开展工作的人们----对于一个软件需求规格说明，你可能需要包括一个开发人员、一个测试人员、一个项目经理和一个用户文档编写人员，他们的工作基础都是软件需求规格说明。这些审查人员将会发现不同类型的问题。 审查组中的审查人员应限制在7个人左右或者更少。 需求审查过程 审查中每个成员扮演的角色 作者。作者创建或维护正在被审查的产品。 调解者。调解者（moderator）或者审查主持者所做的是：与作者一起为审查制订计划，协调各种活动，并且推进审查会的进行。 读者。读者的角色由审查员扮演。 记录员。记录员，或书记员，用标准化的形式记录在审查会中提出的问题和缺陷。记录员必须仔细审查所写的材料以确保记录的正确性。 需求审查过程 审查阶段 规划（Planning）。作者和调解者协同对审查进行规划，以决定谁该参加审查，审查员在召开审查会之前应收到什么材料并且需要召开几次审查会。 总体会议（overview meeting）。总体会议可以为审查员提供了解会议的信息，包括他们要审查的材料的背景，作者所作的假设和作者的特定审查目标。 准备（Preparation）。在正式审查的准备阶段，每个审查员以典型缺陷（defect）清单（在本章的后面部分介绍）为指导，检查产品可能出现的错误，并提出问题。 需求审查过程 审查阶段 审查会议（Inspection meeting）。在审查会进行过程中，读者通过软件需求规格说明指导审查小组，一次解释一个需求。当审查员提出可能的错误或其它问题时，记录员就记录这些内容，其形式可以成为需求作者的工作项列表。会议的目的是尽可能多地发现需求规格说明中的重大缺陷。 重写（rework）。我所观察到的几乎每一个质量控制活动都可能发现一些需求缺陷。因此，作