(CEN)第八章需求验证与确认选读.ppt

第八章 需求验证与评审;软件需求验证与评审概述 软件需求评审过程 软件需求评审问题与困难 如何做好软件需求评审;8.1软件需求验证与评审概述 　　在需求开发阶段发现的一个错误，平均仅需要花30分钟修复，但是在系统测试时发现的错误需要花5~17个小时来修复。 一、需求验证概述 １、需求验证的活动如下： 软件需求规格说明正确描述了预期的系统行为和特征。 从系统需求或其它来源中得到软件需求。 需求是完整的和高质量的。 所有对需求的看法是一致的。 需求为继续进行产品设计、构造和测试提供了足够的基础。;２、需求验证的目的 需求符合需求陈述（ requirement statement）的良好特征（完整的、正确的、灵活的、必要的、具有优先级的、无二义行及可验证的）。 符合需求规格说明的良好特性（完整的、一致的、易修改的、可跟踪的）。 只能验证那些已编写成文档的需求 ，而那些存在于用户或开发者思维中的没有表露的、含蓄的需求则不予验证。;二、需求验证概述 例： 　　　一个来自四个用户代表的软件需求规格说明的评审工作正在进行。一个用户提出了一个灾难性的问题：它将使需求做重大更改。会后，需求分析员和项目经理很恼火，因为在前两个月的定义需求会议上，该用户也在场，但她却没有提出这一问题。经过一些调查之后才发现该用户已经反复提出了这个问题，但都被忽略了。在评审过程中，当许多用户一致认为这是一个严重的问题时，分析员和项目经理意识到，他们再也不能忽略这一问题了。 ;　　需求评审即技术评审。 　　需求文档的评审是一项精益求精的技术，它可以发现那些二义性的或不确定的需求、那些由于定义不清而不能作为设计基础的需求，还有那些实际上是设计规格说明的所谓的“需求”。 　　技术评审分为正式评审和非正式评审。;（１）正式评审： 遵循预先定义好的一系列步骤过程。 正式评审内容需要记录在案，它包括确定材料、评审员、评审小组对产品是否完整或是否需要进一步工作的判定，以及对所发现的错误和所提出的问题的总结。 正式评审小组的成员对评审的质量负责，而开发者则最终对他们所开发的产品的质量负责。正式技术评审的最好类型叫作审查。;（２）非正式评审 　非正式评审的方法包括: 　　　把工作产品分发给许多其它的开发人员粗略看看,或者走过场似地检查一遍(walkthrough) ，执行者描述产品，且征求意见。非正式评审对于培养其他人对产品的认识并获得反馈是有利的，但非正式评审是非系统化的，不彻底的。 　非正式评审不需要记录备案。非正式评审可以根据个人爱好的方式进行评审。;８．２软件需求评审过程 一、软件需求评审计划 确定评审范围和评估对象 确定评审参与者（审查组中的审查人员应限制在7个人左右或者更少，但不要少于4人） 确定评审时间 确定评审议程和所需要的信息;二、评审参与人员一般由以下人员组成： 审查参与者必须代表以下几个方面的观点： a. 产品的开发者及其可能的同组成员。 b. 先前产品的开发者或正在评审的项目的规格说明编写者。 c. 客户或者用户代表。这类人群可以保证需求规格说明能正确和完整地描述他们的需求。 d. 要根据正在审查的文档来开展工作的人们。包括 设计人员，测试人员和项目经理。 审查组中的审查人员应限制在7个人左右或者更少。;审查中每个成员扮演的角色： 作者： 　　创建和编写正在被审查的SRS的人。系统分析员只能听取其他审查员得评论并做解释回答，不能参与讨论。 调解者： 　　审查的调解人与主持人，一般为项目总负责人。与作者一起制定审查计划，协调审查期间各种活动。 读者： 　　审查人员。审查SRS的内容，并提出问题以及自己的理解。 记录员： 　　以标准的形式与格式记录在审查中提出的问题和缺陷。;;三、需求评审过程 ;２、评审过程 （１）理解评审流程 （２）理解评审员的角色 作者（介绍员） 调解者（主持者） 读者（评审员） 记录员 （３）指定协调员 （４）评审（保持简短） （５）确定问题，而不是解决问题;;规划(Planning)： 　　由作者和调节者对审查进行规划，决定所有参与人员，审查人员应该收到的材料，日程如何安排。 总体会议(Overview Meeting)： 　　为审查员提供了解会议的信息：待审查的材料背景，作者所作的假设和审查目标。 准备(Preparation)： 每个审查员以典型缺陷(defect)审查清单为指导，检查SRS中可能出现的问题，并且提出问题。 　　;审查会议(Inspection Meeting)： 在会议过程中，读者通过SRS来指导审查小组，一次解释一次需求。当审查员提出可能的错误或其它的错误时，记录员须记录下这些内容。会议的目的是尽可能发现SRS中的重要缺陷和错误。 重定、重写(Rework)： 当发现SRS中出现问题时，应