需求管理培训教材

2006, ZTE Corporation. All rights reserved.,需求管理,- 需求管理规程,版本修订记录,课程安排,概述 需求管理及开发计划 需求工作产品 需求追踪 需求状态跟踪 需求变更管理 需求评审 需求度量,什么是需求？,IEEE的定义用户解决问题或达到目标所需的条件或能力(capability)。系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。一种反映上面两条所描述的条件或能力的文档说明。比较好理解的定义需求是系统必须符合的条件或具备的功能 。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。,概述,需求不总是显而易见的，而且它可来自各个方面。 需求并不总是能容易用文字明白无误地表达。 存在不同种类的需求，其详细程度各不相同。 如果不加以控制，需求的数量将难以管理。 需求之间相互关联关系，而且需求也和软件工程流程中的其他可交付工件有关。 需求涉及众多相关方面，这意味着需求要由功能交叉的各组人员管理。 需求会变更。,收集和管理需求并非易事,概述,需求重要性,优秀的软件产品是建立在优秀的需求基础之上的。而高质量的需求来源于需求开发人员与客户的充分交流与合作。需求不合理、需求不清楚都极易造成需求变更频繁，项目计划不受控，项目延期；导致资源浪费，成本增加。所以做好需求对项目是非常重要的。,概述,1991年由J. Martin提出“需求工程”(requirement engineering，简称RE)概念：以工程化的方法解决需求相关问题。需求工程又分为需求开发（RD：requirement development）和需求管理（RM：requirement management）。,需求工程,概述,需求开发与管理流程,概述,包括需求收集、需求分析、需求描述和需求验证四个主要活动。这四个活动反复迭代，完成了从用户需求定义到产品需求定义的过程，使得需求逐步地明确和完整。,包括建立需求基线、控制需求变更、建立需求追踪关系、进行需求状态跟踪等活动。目的是使得在客户、用户和开发方之间已达成一致的需求，能够最终反映在实现的产品中。,需求开发,需求管理,概述,需求开发和需求管理的关系,需求开发负责获取真实的用户需求，并转化为完整、正确、符合开发要求的产品需求。需求管理则确保随后的研发活动、计划、工作产品以基线化的需求为根据，并与基线化的需求保持一致,概述,与其他工程活动的关系,需求是项目管理，特别是制定项目计划的依据，需求活动也需要计划并按照计划执行。需求是设计的前提，也是编写系统测试用例和实施测试的依据。 同时，需求反映设计和实现上的决策和技术约束等因素。开发过程中如果发现没有预见的技术约束，经过和负责需求的人员沟通，得到批准，就引发需求变更，达到开发活动和需求保持一致的效果。,概述 需求管理与开发计划 需求工作产品 需求追踪 需求状态跟踪 需求变更管理 需求评审 需求度量,需求管理划,目的,作为项目计划的一部分，规划和监控需求开发和管理活动,活动,规划需求开发活动规划需求管理活动 评审,输出,需求开发和需求管理计划,需求管理计划,规划需求管理活动,包括但不限于：确定参与需求管理的人员职责；选择需求管理工具；确定需要追踪的工作产品；定义需求的状态和状态变迁条件；确定需求变更管理方式制定需求管理进度计划。,计划评审,需求开发和管理计划不作为一个独立的文档，而是作为项目主计划文档的一部分内容，随项目主计划一起进行同行评审。 通过对计划的评审，识别计划、需求等工作产品的不一致，并使项目成员对需求实现相关活动达成一致并做出承诺。,概述 需求管理与开发计划 需求工作产品 需求追踪 需求状态跟踪 需求变更管理 需求评审 需求度量,工作产品,方针政策（公司层面） 软件开发与管理工作总要求规程 需求开发与管理规程,组织层面,指导书/规范 原始需求收集系统使用指导书需求变更管理指导书 需求追踪指导书 用户界面规范-BS 用户界面规范-CS 用户界面通用规范用户界面规范-BS（外部网站）用户界面规范-BS（对外产品）,工作产品,模板 用户需求说明书模板 产品需求说明书模板 关键需求识别表模板 软件需求说明书模板-面向对象 软件需求说明书模板-面向结构 软件需求说明书模板-BI主题类 产品计划书模板 总体方案模板 -面向结构 详细方案模板 -面向结构 约束假设与潜在故障识别表模板,工作产品,工作产品,评审检查单 PR检查单-用户需求说明书 PR检查单-产品需求说明书 PR检查单-软件需求说明书PR检查单-系统用例模型 QA检查单 QA工作产品检查单-需求开发 QA过程检查单-需求管理QA工作产品检查单-BS界面QA工作产品检查单-CS界面,工具 原始需求收集系统 Rational RequisitePro Rational Clearcase Rational Clearquest Rational Rose,工作产品,需求开发过程,需求的输出工件,总 体 方 案,详 细 方 案,软件需求说明书,结构化,面向对象,用户需求说明书,用户需求说明书,软件需求说明书,产品需求说明书,产品需求说明书,产品计划书,产品计划书,工作产品,概述 需求管理与开发计划 需求工作产品 需求追踪 需求状态跟踪 需求变更管理 需求评审 需求度量,需求追踪,测试项/测试用例,程序单元设计类/方法,代码文件,原始需求,用户需求,产品需求,软件需求,其中，用户需求与产品需求的追踪关系在产品需求说明书中维护；其它的追踪关系在RP中维护,需求追踪关系显示工作产品元素之间的关系,需要追踪的工作产品类别及其追踪粒度,需求追踪,需求追踪,需求追踪关系的建立和维护,建立并维护用户需求、产品需求与软件需求之间的追踪关系,BA工程师,建立并维护软件用例与程序单元、设计类和方法之间的之间的追踪关系,设计工程师,建立并维护设计类与代码文件之间的追踪关系,开发工程师,建立并维护软件需求和测试用例之间的追踪关系,测试工程师,需求追踪,角色与权限,RP追踪关系及视图,需求追踪的支持工具：RP一般地，需要在RP中创建的视图类型：属性矩阵追踪矩阵追踪树追踪关系创建时机： 在用户需求、产品需求、设计、实现、测试等工作产品提交评审前，相关负责人建立本阶段的工作产品元素与上游的工作产品元素之间的需求追踪关系。如果需求之间存在关系，需要建立需求之间的横向追踪关系。 追踪关系变更： 当需求、设计、实现、测试等工作产品发生变更时，负责修改本工作产品的人员检查原有需求追踪关系是否需要修改，必要时在变更结束前修改需求追踪关系 追踪关系评审：通过需求追踪评审来检查需求追踪关系的一致性和正确性。需求追踪评审安排在用户需求、产品需求和软件需求的同行评审时同步进行，在产品发版评审时进行总体评审。,需求追踪,需求追踪,属性矩阵属性矩阵便于对某一类型需求的各种属性取值进行批量维护,命名规则： A-属性类型。例如：A-用户需求，A-软件需求,属性矩阵 对于在CQ上的需求变更，与RP建立关联的，在RP的Enhancement属性下会自动关联变更号。对需求的实现版本和更新版本必须按规定填写。,需求追踪,追踪矩阵检查是否“实现遗漏”：列上没有追踪关系 检查是否“实现镀金”：行上没有追踪关系纵向追踪：用户需求-软件需求-设计、业务功能-软件需求-设计；横向追踪：同层次需求间的追踪,需求追踪,命名规则：垂直追踪：TM-行需求类型-列需求类型（要求：行为下游产品、列为上游产品）水平追踪：TM(H)-需求类型-需求类型（例如，用例间的水平追踪：TM(H)-用例-用例）,追踪树（前向追踪树、后向追踪树） 可以表达间接追踪关系，多种需求间关系 便于评估工作量、变更影响和风险 命名规则： 前向追踪树：TTI-需求类型 后项追踪树：TTO-需求类型,需求追踪,RP需求追踪包结构,需求追踪,需求追踪-需求文档,面向对象类,面向结构类,需求追踪,需求追踪-需求项,面向对象类,面向结构类,需求追踪,需求追踪-必建视图,“01 用户需求”目录下: 用户需求需求矩阵： A-用户需求-版本号 用户需求前向追踪树： TTI-用户需求-版本号 用户需求追踪矩阵： TM-假设约束-用户需求-版本号 、TM-潜在故障-用户需求-版本号 、TM(H)-用户需求-用户需求-版本号 “02 产品需求”目录下： 业务功能属性矩阵： A-业务功能-版本号 业务功能前向追踪树： TTI-业务功能-版本号 “03 软件需求”目录下：用例需求属性矩阵： A-用例-版本号 补充需求需求属性矩阵：A-补充需求-版本号软件需求追踪矩阵： TM-用例-用户需求-版本号、TM-用例-业务功能-版本号TM(H)-用例-用例-版本号、TM(H)-接口-用例-版本前向追踪树：TTI-用例-版本号,面向对象类项目,需求追踪,需求追踪-必建视图,“01 用户需求”目录下: 用户需求需求矩阵： A-用户需求-版本号 用户需求前向追踪树： TTI-用户需求-版本号 用户需求追踪矩阵： TM-假设约束-用户需求-版本号 、TM-潜在故障-用户需求-版本号 、TM(H)-用户需求-用户需求-版本号 “02 产品需求”目录下： 业务功能属性矩阵： A-业务功能-版本号 业务功能前向追踪树： TTI-业务功能-版本号 “03 软件需求”目录下：用例需求属性矩阵：A-软件需求-版本号 软件需求前向追踪树：TTI-软件需求-版本号软件需求追踪矩阵：TM-软件需求-用户需求-版本号、TM-软件需求-业务功能-版本号、TM(H)-软件需求-软件需求-版本号、TM(H)-接口-软件需求-版本号,面向结构类项目,需求追踪,需求追踪参考,需求追踪,需求追踪指导书.doc,概述 需求管理与开发计划 需求工作产品 需求追踪 需求状态跟踪 需求变更管理 需求评审 需求度量,需求状态跟踪,需求状态跟踪的目的： 跟踪并及时反映需求所处的状态。,项目负责人或者其他指定的人员根据需求管理计划，在触发需求状态更新的事件发生时，及时在RP系统中更新已经基线化的需求状态。,需求状态及其定义,需求状态跟踪,需求状态图,需求状态跟踪,状态跟踪活动分为如下几步：查询需求追踪记录，识别需求依赖的所有工作产品元素识别工作产品元素是否已完成根据工作产品元素完成情况，识别并标识需求的状态统计并在项目里程碑报告中报告需求状态分布、关键或受关注需求的状态及近期状态变更历史,需求状态跟踪,需求状态的变迁,需求状态跟踪,需求状态的变迁是由项目相关人员根据需求实现的实际进展进行设置的,概述 需求管理与开发计划 需求工作 产品 需求追踪 需求状态跟踪 需求变更管理 需求评审 需求度量,需求变更,所有对于已经基线化的工作产品的变更请求都要申请变更。变更管理用来系统地评估每个提交的工程变更和对基线化文档的修改要求，评估总的变更影响：从与受影响功能进行协调，到部署变更，到准时地实现变更。根据变更的影响范围，被提交的变更请求区分为一级变更、二级变更和三级变更。不同等级的变更有不同的变更处理过程。在给变更请求确定级别时，必需要完整的考虑所有的变更分级因素。这些因素包括很多支持、运行和培训方面的考虑。,需求变更管理,需求变更流程,需求变更管理,变更措施处理流程,需求变更管理,需求变更来源,新需求：是没有现成系统实现，需要立项开发新系统来实现的一类需求 。变更需求：是在已有系统上需要实现的一类需求 。它可分成三种类别：修改已有的需求、作为当前版本的新增需求、作为未来版本的新增需求 。 除了来自原始需求收集系统的变更需求外，还有因各种原因引起需要对已有需求进行变更而在CQ系统直接提交的变更请求，如在项目中需求基线化后对需求的变更等,需求变更管理,需求变更需要提请CQ变更处理流程根据变更等级确定是否需要CCB审核 ：三级变更不需 CQ中变更处理方式：除了属于紧急变更需求由事件驱动处理外，其它的采取定期集中处理，如每周处理1次对于影响面大的需求变更，如可能会影响项目范围和项目进度 的，项目CCB不能决定的，则提交上一级的CCB进行决策，项目CCB安排人员进行跟踪 根据需求追踪记录、项目计划及其他必要资料评估变更影响变更实施活动：项目经理调整项目计划，更新受影响的文档，配置管理组建立新需求基线，更新需求追踪记录。对于基线化工作产品的变更通过CC进行版本控制 验证变更,需求变更处理,需求变更管理,变更影响分析：通过广泛的确认，对变更进行分析，以确定受变更影响的工作产品及可能的变更工作量，并进而估计变更对项目进度、成本、质量的影响。可以利用RP进行变更影响分析：参考RP的追踪矩阵和追踪树视图，可分析哪些内容需要变更。通常对需求变更进行影响分析时要考虑如下几方面：1) 对系统性能的影响；2) 对设计的影响；3) 需求变更实现的难度和风险；4) 对其他需求优先级产生的影响；5) 对计划的影响；6) 对成本(产品成本和销售成本)的影响；7) 需求变更的取舍,需求变更的影响分析,需求变更管理,变更处理关联RP需求,在CQ处理流程中，需求的变更类型有“新增需求”和“变更需求”，这两种类型的变更要执行关联RP操作，关联规则如下：,如果一个需求变更会影响到多个RP需求项，一定要完全关联。如用户需求的变更，除了要修改本用户需求外，可能会引起其它用户需求、产品需求、软件需求以及设计的变更，那么执行关联RP操作是要覆盖所有这些有变更的需求项,需求变更的标识,产品计划书在产品计划书中标识变更需求时，列出原来的业务功能编号和名称，在名称后面加上“（变更）”；或者对多个变更需求，可先写上“变更需求：”，然后，在此标识下面列出多个待变更的需求。在产品功能与用户需求对应表中，对发生变更的用户需求说明书，把状态设为变更，在版本栏加上解决变更的版本号用户需求说明书在用户需求说明书中修改需求时，对于变更部分用中括号括起来，并在中括号后标出变更日期。如：对于变更要取消的需求部分，采用的方式为：“取消需求：2005-12-05”；对于变更需求部分，采用的方式为：“变更需求：2005-12-05”。 在汇总表中对应变更需求的预期版本栏中加入对应的解决版本号软件需求说明书在软件需求说明书中修改需求时，对变更的部分要用颜色标识，对删除部分使用删除线进行标识。一般只需要保留最新版本的变更标识信息，前期版本的可以取消。,需求变更管理,概述 需求管理与开发计划 需求工作产品 需求追踪 需求状态跟踪 需求变更管理 需求评审 需求度量,同行评审基本概念,同行评审（peer review）是由生产者的同行 为识别异常和需要修改的部分而对软件工作产品进行的有组织有计划的检查 。同行评审用来评价软件产品的质量而不是软件开发人员的能力，需要参加同行评审的人员能够坦诚地提出对工作产品的各种意见。进入和退出准则用来决定一件产品是否可以接受同行评审（进入）和是否已经成功完成该过程（退出）。不同的软件工作产品有不同的进入准则 。PR检查单为评审员提供找出可能的异常的向导，同时也是需求接收的准则。一般有审查、走查和单人复审、多人复审四种同行评审方式。重要性和复杂性不同的产品应该接受不同形式的同行评审。通过同行评审可以识别需求、项目计划等工作产品的不一致。,需求评审,审 查,审查工作由一个主持人、讲解员、记录员、作者和其他审查员组成的小组来执行 。审查组由同行中与被审产品有较为密切关系的人组成。典型的审查组由4到6人组成，最少不能低于3人，建议不要超过7人 。 每个组员都是审查员。其中主持人的主要责任是保证审查过程顺利完成。此外主持人还负责选择小组成员、主持审查会并报告审查结果。讲解员的任务是引导审查组通读工作产品。记录员的责任是准确记录审查会中发现的每个异常。作者的责任是回答审查员的问题并在审查结束后修正发现的异常。 。 审查的过程：准备 概要介绍（可选）预审 审查会议 第三小时（可选） 修改跟踪。预审阶段是审查过程的关键阶段，一般地，预审时间至少需要两天 。,需求评审,产品需求评审,必须采用审查方式进行 。产品需求评审的评审员要包括产品经理、项目经理、BA、架构设计、测试工程师，其中产品经理是评审主持人。产品需求评审一般以用户需求作为背景材料，以PR检查单-产品需求说明书.xls作为评审向导。PR检查单对不同角色的评审员设定了不同的评审要求和重点。评审的必需内容是产品需求说明书、RP追踪，如果有demo，也可以一起进行。,需求评审,软件需求评审,必须采用审查