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

建议二：正式评审与非正式评审结合 正式评审是指通过开评审会的形式，而非正式的评审并没有这种严格的组织形式，一般也不需要将人员集合在一起评审，而是通过电子邮件、文件汇签甚至是网络聊天等多种形式对需求进行评审。往往非正式的评审比正式的评审效率更高，更容易发现问题。因此在评审时，应该更灵活地利用这2种方式。 建议三：分阶段评审 在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审的质量。 　　　比如，可以在形成目标性需求后进行一次评审，在形成系统的初次概要需求后进行一次评审，当对概要需求细分成几个部分，对每个部分进行各个评审，最终再对整体的需求进行评审。 建议四：精心挑选评审员 需求评审可能涉及的人员包括：需方的高层管理人员、中层管理人员、具体操作人员、IT主管、采购主管；供方的市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的领域专家等等。在这些人员中由于大家所处的立场不同，对同一个问题的看法是不相同的。 需要精心挑选评审员。首先要保证使不同类型的人员的都要参与进来，其次在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来。 建议五：对评审员进行培训 在很多情况下，评审员是领域专家而不是进行评审活动的专家，他们没有掌握进行评审的方法、技巧、过程等，因此需要对评审员进行进行培训或指导，以便于参与评审的人员能够紧紧围绕评审的目标来进行，提高评审效率，避免发生案例一和案例二中出现的现象。 建议六：充分利用需求评审检查单 需求检查单是很好的评审工具，需求检查单可以分成2类：需求形式的检查单和需求内容的检查单。 需求形式的检查可以由QA人员负责，主要是针对需求文挡的格式是否符合质量标准来提出的，需求内容的检查是由评审员负责的，主要是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等，这是需求评审的重点。检查单也是随着工程财富的积累逐渐丰富和优化的。  建议七：建立标准的评审流程 对正规的需求评审会需要建立正规的需求评审流程，按照流程中定义的活动进行规范的评审过程。比如在评审流程定义中规定评审的进入条件，评审需要提交的资料，每次评审会议的人员职责分配，评审的具体步骤，评审通过的条件等等。通过评审流程执行可能会避免出现案例五之类的问题。 建议八：做好评审后的跟踪工作 在需求评审后，需要根据评审人员提出的问题进行评价，以确定哪些问题是必须纠正的，哪些可以不纠正，并给出充分的客观的理由与证据。 当确定需要纠正的问题后，要形成书面的需求变更的申请，进入需求变更的管理流程，并确保变更的执行，在变更完成后，要进行复审。切忌评审完毕后，没有对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流。 建议九：充分准备评审 评审质量的好坏很大程度上取决于在评审会议前的准备活动。? 常出现的问题是：需求文档在评审会议前并没有提前下发给参与评审会议的人员，没有留出更多更充分的时间让参与评审的人员阅读需求文档。更有甚者，没有执行需求评审的进入条件，在评审文档中存在大量的低级的错误，或者文档中存在方向性的错误，从而导致评审的效率很低，质量很差。对评审的准备工作，也应当定义一个检查单，在评审之前对照检查单落实每项准备工作。 案例三 　　某软件公司为某公司A做业务流程管理系统的需求评审会，当项目组人员在会议上宣读多达上百页的需求报告时，用户明确提出听不懂，致使会议不得不改日进行。  案例四 　　某软件公司在用户处开完物资管理系统的需求评审会后，与会人员离开会议室时，纷纷摇头，认为本次会议没有多少实际效果，完全是在走过场。 案例五 　　某软件公司在公司内部举行产品的需求评审会时，需求报告的执笔人与产品策划主要策划人员的想法差别很大，致使需求评审会没有必要继续进行下去。 二、需求评审中常见的问题是： 需求报告很长，短时间内评审者根本就不能把需求报告读懂，想清楚； 没有作好前期准备工作，需求评审的效率很低; 需求评审的节奏无法控制； 找不到合格的评审员，与会的评审员无法提出深入的问题； …… 1)大型的需求文档 2) 庞大的审查小组 用以下的方法处理庞大的审查小组： 确保每个参与者都是为了寻找错误，而不是为了解软件需求规格说明中的内容或者为了维护行政上的位置。如果一些参与者只是想大概了解审查的内容，那么就邀请他们去参加总体会议，而不是参加审查会。 理解审查员所代表的观点（例如客户、开发者或测试者），并且委婉地拒绝以相同的观点看待问题的参与者。在准备阶段，你可能要收集持有同样观点的反馈