需求验证 需求评审.ppt

需求验证 需求评审 案 例 　案例一 　　某领域专家A先生就某企业的成本管理系统做用户需求报告的评审工作，在评审会开始时间不长，就被在场的某企业的一位副总B先生打断，认为A先生提出的方案不适合本企业，A先生提出的管理改进方案在企业中无法实施。该副总提完意见后，与会的用户方人员纷纷跟随B先生的提出了他们的反对意见，致使评审会无法再进行下去，最终该报告被用户否决。 案例二 　　某软件公司内部举行产品的需求评审会，主要是公司内部的相关领域的专家参加，在评审会开始后不久，某领域专家就对需求报告中的某个具体问题提出了自己的不同意见，于是，与会人员纷纷就该问题发表自己的意见，大家争执不下，结果，致使会议出现了混乱状况，主持人无法控制局面，会议大大超出了计划评审时间。 　 案 例 　案例三 　　某软件公司为某公司A做业务流程管理系统的需求评审会，当项目组人员在会议上宣读多达上百页的需求报告时，用户明确提出听不懂，致使会议不得不改日进行。 案例四 　　某软件公司在用户处开完物资管理系统的需求评审会后，与会人员在离开会议室时纷纷摇头，认为本次会议没有多少实际效果，完全是在走过场。 案例五 　　某软件公司在公司内部举行产品的需求评审会时，需求报告的执笔人与产品策划的主要策划人员的想法差别很大，致使需求评审会没有必要继续进行下去。  问题出在哪里 　◇?需求报告很长，短时间内评审者根本就不能把需求报告读懂、想清楚； 　　◇?没有作好前期准备工作，需求评审的效率很低； 　　◇?需求评审的节奏无法控制； 　　◇?找不到合格的评审员，与会的评审员无法提出深入的问题； 　　……  　　那么究竟如何做好需求评审呢？ 为防止错误而花费1美元将可以为你修补错误节省3 ~ 1 0美元。 需求缺陷 需求评审重要性的直观描述 需求验证是需求开发的第四部分 需求验证所包括的活动是为了确定以下几方面的内容： ? 软件需求规格说明正确描述了预期的系统行为和特征。 ? 从系统需求或其它来源中得到软件需求。 ? 需求是完整的和高质量的。 ? 所有对需求的看法是一致的。 ? 需求为继续进行产品设计、构造和测试提供了足够的基础。 需求验证确保: 需求符合需求陈述（ requirement statement）的良好特征（完整的、正确的、灵活的、必要的、具有优先级的、无二义行及可验证的）。 符合需求规格说明的良好特性（完整的、一致的、易修改的、可跟踪的）。只能验证那些已编写成文档的需求。 那些存在于用户或开发者思维中的没有表露的、含蓄的需求则不予验证。 需求评审 通常，总是由一些非软件开发人员进行产品检查以发现产品所存在的问题，这就是技术评审。 需求文档的评审是一项精益求精的技术，它可以发现那些二义性的或不确定的需求、那些由于定义不清而不能作为设计基础的需求，还有那些实际上是设计规格说明的所谓的“需求”。 评审类型：评审、检查、走查。 使用不同的技术有助于你验证需求的正确性及其质量。将重点介绍两种最重要的验证技术：正式和非正式的需求评审。 正式评审 遵循预先定义好的一系列步骤过程。 正式评审内容需要记录在案，它包括确定材料、评审员、评审小组对产品是否完整或是否需要进一步工作的判定，以及对所发现的错误和所提出的问题的总结。 正式评审小组的成员对评审的质量负责，而开发者则最终对他们所开发的产品的质量负责。正式技术评审的最好类型叫作审查。 非正式评审 包括把工作产品分发给许多其它的开发人员粗略看一看和走过场似地检查一遍。同时执行者描述产品，且征求意见。 非正式评审对于培养其他人对产品的认识并获得非结构化的反馈是有利的，但非正式评审是非系统化的，不彻底的，或者在实施过程中具有不一致性。非正式评审不需要记录备案。 非正式评审可以根据个人爱好的方式进行评审 评审流程 评审流程是一个重复进行的循环过程：评审员提出问题—〉讨论问题—〉对问题进行确认 —〉确定缺陷（确定需要解决的地方），直到没有确定的问题时再继续下一步 。 评审会议流程 审查过程 1. 参与者 审查参与者必须代表三个方面的观点： a. 产品的开发者及其可能的同组成员。 b. 先前产品的开发者或正在评审的项目的规格说明编写者。 c. 要根据正在审查的文档来开展工作的人们。 审查组中的审查人员应限制在7个人左右或者更少。 2. 审查中每个成员扮演的角色 作者 调解者 读者 记录员 评审会议角色 3. 审查阶段 根据如下因素调整审查速度： ? 一页中的文字数量 ? 规格说明的复杂性 ? 待审查的材料对项目成功的重要程度 ? 以前的审查数据 ? 软件需求规格说明作者的经验水平 审查过程阶段 审查速度与发现的错误数量之间的关系 4. 进入审查的标准 关于需求文档的进入审查的标准： ?