《CMMI5文档之需求管理过程》由会员分享，可在线阅读，更多相关《CMMI5文档之需求管理过程（12页珍藏版）》请在金锄头文库上搜索。
1、需求管理过程文档编号：FHI_CMMI_RM_PRS文档信息：需求管理过程文档名称：需求管理过程文档类别：CMMI过程密 级：内部秘密版本信息：1.1建立日期：2016-1-5创 建 人：EPG批 准 人：李庆林批准日期：2016.2.25存放位置：集成公司组织资产库/组织标准过程编辑软件：Microsoft Office 2003 中文版文档修订记录版本编号或者更改记录编号变化状态简要说明（变更内容和变更范围）修改日期变更人批准日期批准人V1.0C创建2016-1-5张娜娜2016-2-25李庆林V1.1M文档编号去掉版本号2016-4-17邓沛沛2016-4-17李庆林*变化状态：C创建，
2、A增加，M修改，D删除目 录1简介51.1前言51.2目的51.3适用范围51.4术语表52过程总体描述52.1过程概述52.2过程结构描述63过程元素描述63.1需求开发63.2需求定义63.2.1概述63.2.2参与人员73.2.3入口准则73.2.4任务73.2.5出口准则73.2.6输出73.2.7资源和能力要求73.3需求追溯73.3.1概述73.3.2参与人员83.3.3入口准则83.3.4输入83.3.5任务83.3.6出口准则93.3.7输出93.3.8资源和能力要求93.4需求状态的跟踪103.4.1概述103.4.2参与人员103.4.3入口准则103.4.4输入103.4
3、.5任务103.4.6出口准则113.4.7输出113.4.8资源和能力要求113.5需求变更113.5.1概述113.5.2参与人员113.5.3入口准则123.5.4输入123.5.5任务123.5.6出口准则123.5.7输出133.5.8资源和能力要求131 简介1.1 前言需求管理的目的是在客户和遵循需求的软件项目之间建立一种共同的理解。需求管理包括就软件项目的需求同客户建立一个协议，该协议称作“分配给软件的系统需求”。“客户”可解释为系统工程组、销售组、另一个内部组织、或者一个外部客户。协议既包括技术需求，又包括非技术需求（例如交付日期）。该协议形成估计、策划、跟踪整个软件生命周期
4、内软件项目活动的基础。将系统需求分配给软件、硬件和其他系统成分的工作可能由软件工程组之外的组（例如系统工程组）完成，软件工程组可能对此分配无直接控制。在项目约束范围内，软件工程组采取恰当步骤以保证对分配给软件的需求建档、并加以控制，该组负责处理分配给软件的系统需求。为实现此控制，软件工程组评审初始的和经修改后的软件系统需求，以便在它们被纳入软件项目之前使问题得以解决。每当改变分配给软件的系统需求时，都要调整受到影响的软件计划、工作产品和活动，使其与更新后的需求保持一致。1.2 目的需求管理的目的是维护需求并且确保能把对需求的更改反映到项目计划、活动和工作产品中。对需求的管理是要收集需求的变更和
5、变更的理由，并且维持对原有需求和所有产品和产品构件需求的双向跟踪。1.3 适用范围本文档的适用范围为组织中的各软件项目。1.4 术语表无2 过程总体描述2.1 过程概述需求管理过程指策划需求管理，识别、分析、建立软件需求，监控软件需求的状态，控制软件需求的变更过程，进行软件需求的追溯等。为软件项目在需求方面建立和维护与客户的共识；并将所建立的软件需求作为估算、策划、实施和管理项目的基础；控制管理软件需求及其变更，使软件开发计划、工作产品和活动与软件需求保持一致；进行软件需求的追溯，可改善产品质量、降低维护成本、实现重用。软件需求管理的活动贯穿项目的整个生命周期。2.2 过程结构描述需求管理过程
6、如图表1所示，主要包括软件需求的定义、需求变更、需求追溯、需求状态的跟踪，以及策划以上四项需求管理活动等几个主要过程元素。策划需求管理活动是依据需求管理活动的四项基本要素来定义需求管理的任务项（WBS），依据项目生命周期的产品产出计划进行任务项时间分配；所以可以在项目估计和计划里体现需求管理的策划内容。需求开发过程见需求开发过程.doc中的描述。需求追溯3.1需求开发需求状态的跟踪3.2需求管理3需求变更3.3图表 1需求管理过程3 过程元素描述3.1 需求开发关于需求开发过程，参见需求开发过程.doc，在需求开发过程中，将产生用户需求说明书，此说明书将得到用户的认可签字。3.2 需求追溯3.
7、2.1 概述需求追溯包括正向追溯（追溯）和反向追溯（回溯）。通过实施追溯将会使项目在审核、变更影响分析、维护、跟踪、再设计、重用、减小风险、测试等方面受益，具体活动是填写需求跟踪矩阵的需求项、设计项、实现项、测试项，反映出他们之间的关系。项目经理负责并组织在项目的整个工程过程中，对需求进行追溯，以保证系统或产品的完整性和准确性。3.2.2 参与人员l 项目经理：负责审批需求跟踪矩阵；l 软件工程组：负责不同阶段需求跟踪矩阵的填写、分析和再利用。3.2.3 入口准则l 用户需求说明书已经过CCB批准纳入基线。3.2.4 输入l 用户需求说明书3.2.5 任务3.2.5.1 需求跟踪矩阵维护该任务
8、贯穿项目的整个生命周期，即在项目的各个阶段均要进行需求跟踪矩阵维护，且在项目开发计划里把每次需求跟踪矩阵的维护工作的任务要单独列出并计划其实施时间和责任人等。维护分以下步骤：1. 需求定义阶段需求跟踪矩阵的填写由项目经理或项目经理指定项目组成员将用户需求说明书中用户需求编号、需求名称、责任人描述对应填入需求跟踪矩阵中，由项目经理检查或审批。由项目经理或项目经理指定项目组成员将软件需求规格说明书中产品需求编号、需求名称、责任人、优先级项描述对应填入需求跟踪矩阵中，由项目经理检查或审批。2. 设计阶段需求跟踪矩阵的填写由项目经理或项目经理指定项目组成员将概要设计和详细设计中设计编号、责任人描述项对
9、应填入需求跟踪矩阵中，由项目经理检查或审批。3. 编码阶段需求跟踪矩阵的填写由项目经理或项目经理指定项目组成员将源代码程序中代码模块编号对应填入需求跟踪矩阵中，由项目经理检查或审批。4. 测试阶段需求跟踪矩阵的填写由项目经理或项目经理指定项目组成员将测试用例项对应填入需求跟踪矩阵中，由项目经理检查或审批。5. 需求变更时需求跟踪矩阵的填写在项目的不同阶段发生需求变更时，项目经理组织分析需求跟踪矩阵并获得需要变更的内容，软件工程组根据变更内容填写需求跟踪矩阵中“需求状态统计”sheet页，由项目经理审批。具体方法参见需求跟踪矩阵维护规程。3.2.5.2 追溯当发生需求变更时，通过需求跟踪矩阵从需
10、求向后追溯到下游关联的工作产品，可分析出这些关联项是否需要变更，从而达到追溯的目的。在项目计划里需求变更的追溯工作作为不确定工作任务项处理。项目经理监督检查需求变更的追溯。3.2.5.3 回溯通过需求跟踪矩阵从下游工作产品向前回溯到需求，可分析出需求是否得到满足，从而达到回溯的目的。需求管理的回溯工作，在项目计划里作为项目经理和质量保证员的工作任务，在项目周期内的按里程碑开展。3.2.6 出口准则l 需求跟踪矩阵（需求定义阶段）已清晰填写需求功能项对应的需求列l 需求跟踪矩阵（设计阶段）已清晰填写设计项列l 需求跟踪矩阵（实现阶段）已清晰填写源代码模块列l 需求跟踪矩阵（测试阶段）已清晰填写测
11、试用例列3.2.7 输出l 需求跟踪矩阵；3.2.8 资源和能力要求l 项目经理具有需求管理能力。l 软件工程组人员具备需求管理知识。3.3 需求状态的跟踪3.3.1 概述在项目的整个开发过程中，跟踪每项需求的状态是需求管理的一个重要的方面，通过周期性报告需求项的各状态类别以及各状态类别在整个需求中所占的百分比来改进项目的监控工作。状态的跟踪包括状态的定义和状态变更、统计，目的是了解项目是如何达到和完全验证所有批准的需求。需求管理的每项需求的状态的跟踪工作，在项目计划里作为项目经理工作任务，在项目周期内的周期性的开展。质量保证员检查项目组是否开展了这项活动。3.3.2 参与人员l 项目经理：定
12、义需求状态类型；审批需求状态的变更，分析需求跟踪状态结果；负责需求跟踪矩阵的需求状态项的填写和统计需求状态，发布结果。l QA人员：检查需求跟踪矩阵的填写，协助项目经理分析需求跟踪状态结果;3.3.3 入口准则l 软件需求规格说明书经过CCB批准并纳入基线。3.3.4 输入l 软件需求规格说明书3.3.5 任务1. 定义需求状态类别目前定义的需求状态类别包括： 已建议：该需求已被有权提出需求的人建议 已批准：该需求已被分析，估计了其对项目余下部分的影响（包括成本和对项目其余部分的干扰），已用一个确定的产品版本号或创建编号分配到相关的基线中，软件开发团队已同意实现该项需求 已实现：已实现需求代码
13、的设计、编写和单元测试 已验证：使用所选择的方法已验证了实现的需求，例如测试和检测，审查该需求跟踪与测试用例相符。该需求现在被认为完成 已删除：计划的需求已从基线中删除，但包括一个原因说明和做出删除决定的人员 下版本：该需求已被有权提出需求的人（客户或系统分析组成员）接受，但在下个版本实现。2. 需求状态情况填写。3.3.6 出口准则l 需求状态统计完成3.3.7 输出l 需求跟踪矩阵（需求状态统计表）3.3.8 资源和能力要求l 项目经理具有需求管理能力。l CM人员具有软件配置管理。l QA人员具有软件质量跟踪、需求管理能力。3.4 需求变更3.4.1 概述由项目经理负责接收需求变更信息，
14、提交给CCB进行变更评估进入变更流程（参见变更控制规程），变更评估完成进行需求跟踪矩阵的变更。需求变更是不确定性的工作任务，但一旦变更的需求确定下来实施变更的需求就是可以计划的；但对需求管理来说需求变更的管理工作也是随着需求变更的发生而发生的，所以在项目计划里按不确定任务处理。需求变更管理的主要任务包括：执行需求变更审批流程、取得客户对需求变更的承诺等，详细见“3.4.5”任务一节。3.4.2 参与人员l 项目经理：负责接收变更请求表，组织需求变更活动的开展；l 软件工程组成员：负责变更需求、设计、代码或测试内容，填写需求跟踪矩阵；l CM人员：负责将需求基线纳入配置管理；发布基线和需求状态。l CCB：负责评估、批准需求；l 客户代表：参与并确认需求的定义。3.4.3 入口准则l 变更请求表已提交3.4
