CEN第八章需求验证与确认剖析.pptVIP

? 案例二 某软件公司内部举行产品的需求 评审会，主要是公司内部的领域专家 参加，在评审会开始后不久，某领域 专家就对需求报告中的某个具体问题 提出了自己的不同意见，于是，与会 人员纷纷就该问题发表自己的意见， 大家争执不下，结果，致使会议出现 了混乱状况，主持人无法控制局面， 会议大大超出了计划评审时间。 ? 案例三 某软件公司为某公司 A 做业务流程 管理系统的需求评审会，当项目组人员 在会议上宣读多达上百页的需求报告时， 用户明确提出听不懂，致使会议不得不 改日进行。 ? 案例四 某软件公司在用户处开完物资管理 系统的需求评审会后，与会人员离开会 议室时，纷纷摇头，认为本次会议没有 多少实际效果，完全是在走过场。 ? 案例五 某软件公司在公司内部举行 产品的需求评审会时，需求报告 的执笔人与产品策划主要策划人 员的想法差别很大，致使需求评 审会没有必要继续进行下去。 二、需求评审中常见的问题是： ? 需求报告很长，短时间内评审者 根本就不能把需求报告读懂，想清楚； ? 没有作好前期准备工作，需求评 审的效率很低 ; ? 需求评审的节奏无法控制； ? 找不到合格的评审员，与会的评 审员无法提出深入的问题； …… 1) 大型的需求文档 2) 庞大的审查小组 用以下的方法处理庞大的审查小组： ? 确保每个参与者都是为了寻找错误，而不是为了解软件 需求规格说明中的内容或者为了维护行政上的位置。如果 一些参与者只是想大概了解审查的内容，那么就邀请他们 去参加总体会议，而不是参加审查会。 ? 理解审查员所代表的观点（例如客户、开发者或测试 者），并且委婉地拒绝以相同的观点看待问题的参与者。 在准备阶段，你可能要收集持有同样观点的反馈人的信息， 但只要派其中的一个作为代表参加会议。 三、需求评审的困难 第八章 需求验证与评审 ? 软件需求验证与评审概述 ? 软件需求评审过程 ? 软件需求评审问题与困难 ? 如何做好软件需求评审 8.1 软件需求验证与评审概述 在需求开发阶段发现的一个错误，平均 仅需要花 30 分钟修复，但是在系统测试时发 现的错误需要花 5~17 个小时来修复。 一、需求验证概述 １、 需求验证的活动如下： ? 软件需求规格说明正确描述了预期的系统 行为和特征。 ? 从系统需求或其它来源中得到软件需求。 ? 需求是完整的和高质量的。 ? 所有对需求的看法是一致的。 ? 需求为继续进行产品设计、构造和测试提 供了足够的基础。 ２、需求验证的目的 ? 需求符合需求陈述（ requirement statement ）的良好特征（完整的、 正确的、灵活的、必要的、具有优先 级的、无二义行及可验证的）。 ? 符合需求规格说明的良好特性（完 整的、一致的、易修改的、可跟踪 的）。 ? 只能验证那些已编写成文档的需求 ，而那些存在于用户或开发者思维中 的没有表露的、含蓄的需求则不予验 证。 二、需求验证概述 例： 一个来自四个用户代表的软件需求规格说 明的评审工作正在进行。一个用户提出了一个灾 难性的问题：它将使需求做重大更改。会后，需 求分析员和项目经理很恼火，因为在前两个月的 定义需求会议上，该用户也在场，但她却没有提 出这一问题。经过一些调查之后才发现该用户已 经反复提出了这个问题，但都被忽略了。在评审 过程中，当许多用户一致认为这是一个严重的问 题时，分析员和项目经理意识到，他们再也不能 忽略这一问题了。 需求评审 即 技术评审 。 需求文档的评审是一项精益求精 的技术，它可以发现那些二义性的或 不确定的需求、那些由于定义不清而 不能作为设计基础的需求，还有那些 实际上是设计规格说明的所谓的“需 求”。 技术评审 分为 正式评审 和 非正式 评审。 （１）正式评审： ? 遵循预先定义好的一系列步骤过程。 ? 正式评审内容需要记录在案，它包 括确定材料、评审员、评审小组对 产品是否完整或是否需要进一步工 作的判定，以及对所发现的错误和 所提出的问题的总结。 ? 正式评审小组的成员对评审的质量 负责，而开发者则最终对他们所开 发的产品的质量负责。正式技术评 审的最好类型叫作审查。 （２）非正式评审 ? 非正式评审的方法包括 : 把工作产品分发给许多其它的开 发人员粗略看看 , 或者走过场似地检查一 遍 (walkthrough) ，执行者描述产