CMMI5文档之需求管理过程

需求管理过程

文档编号：FHI_CMMI_RM_PRS

文档信息：需求管理过程

文档名称：需求管理过程

文档类别：CMMI过程

密级：内部秘密

版本信息：1.1

建立日期：2016-1-5

创建人：EPG

批准人：李庆林

批准日期：2016.2.25

存放位置：集成公司组织资产库/组织标准过程编辑软件：Microsoft Office 2003 中文版

文档修订记录

变化状态：C――创建，A——增加，M——修改，D——删除

目录

1简介 (5)

1.1前言 (5)

1.2目的 (5)

1.3适用范围 (5)

1.4术语表 (5)

2过程总体描述 (5)

2.1过程概述 (5)

2.2过程结构描述 (6)

3过程元素描述 (6)

3.1需求开发 (6)

3.2需求定义........................................................................... 错误！未定义书签。

3.2.1概述............................................................................ 错误！未定义书签。

3.2.2参与人员.................................................................... 错误！未定义书签。

3.2.3入口准则.................................................................... 错误！未定义书签。

3.2.4任务............................................................................ 错误！未定义书签。

3.2.5出口准则.................................................................... 错误！未定义书签。

3.2.6输出............................................................................ 错误！未定义书签。

3.2.7资源和能力要求........................................................ 错误！未定义书签。

3.3需求追溯 (6)

3.3.1概述 (6)

3.3.2参与人员 (7)

3.3.3入口准则 (7)

3.3.4输入 (7)

3.3.5任务 (7)

3.3.6出口准则 (8)

3.3.7输出 (8)

3.3.8资源和能力要求 (8)

3.4需求状态的跟踪 (9)

3.4.1概述 (9)

3.4.2参与人员 (9)

3.4.3入口准则 (9)

3.4.4输入 (9)

3.4.5任务 (9)

3.4.6出口准则 (10)

3.4.7输出 (10)

3.4.8资源和能力要求 (10)

3.5需求变更 (10)

3.5.1概述 (10)

3.5.2参与人员 (10)

3.5.3入口准则 (11)

3.5.4输入 (11)

3.5.5任务 (11)

3.5.6出口准则 (11)

3.5.7输出 (11)

3.5.8资源和能力要求 (12)

1简介

1.1前言

需求管理的目的是在客户和遵循需求的软件项目之间建立一种共同的理解。

需求管理包括就软件项目的需求同客户建立一个协议，该协议称作“分配给软件的系统需求”。“客户”可解释为系统工程组、销售组、另一个内部组织、或者一个外部客户。协议既包括技术需求，又包括非技术需求（例如交付日期）。该协议形成估计、策划、跟踪整个软件生命周期内软件项目活动的基础。

将系统需求分配给软件、硬件和其他系统成分的工作可能由软件工程组之外的组（例如系统工程组）完成，软件工程组可能对此分配无直接控制。在项目约束范围内，软件工程组采取恰当步骤以保证对分配给软件的需求建档、并加以控制，该组负责处理分配给软件的系统需求。

为实现此控制，软件工程组评审初始的和经修改后的软件系统需求，以便在它们被纳入软件项目之前使问题得以解决。每当改变分配给软件的系统需求时，都要调整受到影响的软件计划、工作产品和活动，使其与更新后的需求保持一致。

1.2目的

需求管理的目的是维护需求并且确保能把对需求的更改反映到项目计划、活动和工作产品中。对需求的管理是要收集需求的变更和变更的理由，并且维持对原有需求和所有产品和产品构件需求的双向跟踪。

1.3适用范围

本文档的适用范围为组织中的各软件项目。

1.4术语表

无

2过程总体描述

2.1过程概述

需求管理过程指策划需求管理，识别、分析、建立软件需求，监控软件需求的状态，控制软件需求的变更过程，进行软件需求的追溯等。为软件项目在需求方面建立和维护与客户的共识；并将所建立的软件需求作为估算、策划、实施和管理项目的基础；控制管理软件需求及其变更，使软件开发计划、工作产品和活动与软件需求保持一致；进行软件需求的追溯，可改善产品质量、降低维护成本、实现重用。软件需求管理的活动贯穿项目的整个生命周期。

2.2过程结构描述

需求管理过程如图表1所示，主要包括软件需求的定义、需求变更、需求追溯、需求状态的跟踪，以及策划以上四项需求管理活动等几个主要过程元素。策划需求管理活动是依据需求管理活动的四项基本要素来定义需求管理的任务项（WBS），依据项目生命周期的产品产出计划进行任务项时间分配；所以可以在项目估计和计划里体现需求管理的策划内容。

需求开发过程见《需求开发过程.doc》中的描述。

图表 1需求管理过程

3过程元素描述

3.1需求开发

关于需求开发过程，参见《需求开发过程.doc》，在需求开发过程中，将产生用户需求说明书，此说明书将得到用户的认可签字。

3.2需求追溯

3.2.1概述

需求追溯包括正向追溯（追溯）和反向追溯（回溯）。通过实施追溯将会使项目在审核、变更影响分析、维护、跟踪、再设计、重用、减小风险、测试等方面受益，具体活动是填写《需求跟踪矩阵》的需求项、设计项、实现项、测试项，反映出他们之间的关系。项目经理负责并组织在项目的整个工程过程中，对需求进行追溯，以保证系统或产品的完整性和准确性。

3.2.2参与人员

●项目经理：负责审批《需求跟踪矩阵》；

●软件工程组：负责不同阶段《需求跟踪矩阵》的填写、分析和再利用。

3.2.3入口准则

●《用户需求说明书》已经过CCB批准纳入基线。

3.2.4输入

●《用户需求说明书》

3.2.5任务

3.2.5.1《需求跟踪矩阵》维护

该任务贯穿项目的整个生命周期，即在项目的各个阶段均要进行《需求跟踪矩阵》维护，且在项目开发计划里把每次《需求跟踪矩阵》的维护工作的任务要单独列出并计划其实施时间和责任人等。维护分以下步骤：

1.需求定义阶段《需求跟踪矩阵》的填写

由项目经理或项目经理指定项目组成员将《用户需求说明书》中用户需求编号、需求名称、责任人描述对应填入《需求跟踪矩阵》中，由项目经理检查或审批。

由项目经理或项目经理指定项目组成员将《软件需求规格说明书》中产品需求编号、需求名称、责任人、优先级项描述对应填入《需求跟踪矩阵》中，由项目经理检查或审批。

2.设计阶段《需求跟踪矩阵》的填写

由项目经理或项目经理指定项目组成员将《概要设计》和《详细设计》中设计编号、责任人描述项对应填入《需求跟踪矩阵》中，由项目经理检查或审批。

3.编码阶段《需求跟踪矩阵》的填写

由项目经理或项目经理指定项目组成员将源代码程序中代码模块编号对应填入《需求跟踪矩阵》中，由项目经理检查或审批。

4.测试阶段《需求跟踪矩阵》的填写

由项目经理或项目经理指定项目组成员将测试用例项对应填入《需求跟踪矩阵》中，由项目经理检查或审批。

5.需求变更时《需求跟踪矩阵》的填写

在项目的不同阶段发生需求变更时，项目经理组织分析《需求跟踪矩阵》并获得需要变更的内容，软件工程组根据变更内容填写《需求跟踪矩阵》中“需求状态统计”sheet页，由项目经理审批。

具体方法参见《需求跟踪矩阵维护规程》。

3.2.5.2追溯

当发生需求变更时，通过《需求跟踪矩阵》从需求向后追溯到下游关联的工作产品，可分析出这些关联项是否需要变更，从而达到追溯的目的。

在项目计划里需求变更的追溯工作作为不确定工作任务项处理。项目经理监督检查需求变更的追溯。

3.2.5.3回溯

通过《需求跟踪矩阵》从下游工作产品向前回溯到需求，可分析出需求是否得到满足，从而达到回溯的目的。

需求管理的回溯工作，在项目计划里作为项目经理和质量保证员的工作任务，在项目周期内的按里程碑开展。

3.2.6出口准则

●《需求跟踪矩阵》（需求定义阶段）已清晰填写需求功能项对应的需求列

●《需求跟踪矩阵》（设计阶段）已清晰填写设计项列

●《需求跟踪矩阵》（实现阶段）已清晰填写源代码模块列

●《需求跟踪矩阵》（测试阶段）已清晰填写测试用例列

3.2.7输出

●《需求跟踪矩阵》；

3.2.8资源和能力要求

●项目经理具有需求管理能力。

●软件工程组人员具备需求管理知识。

3.3需求状态的跟踪

3.3.1概述

在项目的整个开发过程中，跟踪每项需求的状态是需求管理的一个重要的方面，通过周期性报告需求项的各状态类别以及各状态类别在整个需求中所占的百分比来改进项目的监控工作。状态的跟踪包括状态的定义和状态变更、统计，目的是了解项目是如何达到和完全验证所有批准的需求。需求管理的每项需求的状态的跟踪工作，在项目计划里作为项目经理工作任务，在项目周期内的周期性的开展。质量保证员检查项目组是否开展了这项活动。

3.3.2参与人员

●项目经理：定义需求状态类型；审批需求状态的变更，分析需求跟踪状态结果；负责《需求跟

踪矩阵》的需求状态项的填写和统计需求状态，发布结果。

●QA人员：检查《需求跟踪矩阵》的填写，协助项目经理分析需求跟踪状态结果;

3.3.3入口准则

●《软件需求规格说明书》经过CCB批准并纳入基线。

3.3.4输入

●《软件需求规格说明书》

3.3.5任务

1.定义需求状态类别

目前定义的需求状态类别包括：

已建议：该需求已被有权提出需求的人建议

已批准：该需求已被分析，估计了其对项目余下部分的影响（包括成本和对项目其余部分的干扰），已用一个确定的产品版本号或创建编号分配到相关的基线中，软件开发团

队已同意实现该项需求

已实现：已实现需求代码的设计、编写和单元测试

已验证：使用所选择的方法已验证了实现的需求，例如测试和检测，审查该需求跟踪与测试用例相符。该需求现在被认为完成

已删除：计划的需求已从基线中删除，但包括一个原因说明和做出删除决定的人员

下版本：该需求已被有权提出需求的人（客户或系统分析组成员）接受，但在下个版本实现。

2.需求状态情况填写。

3.3.6出口准则

●需求状态统计完成

3.3.7输出

●《需求跟踪矩阵》（《需求状态统计表》）

3.3.8资源和能力要求

●项目经理具有需求管理能力。

●CM人员具有软件配置管理。

●QA人员具有软件质量跟踪、需求管理能力。

3.4需求变更

3.4.1概述

由项目经理负责接收需求变更信息，提交给CCB进行变更评估进入变更流程（参见《变更控制规程》），变更评估完成进行《需求跟踪矩阵》的变更。

需求变更是不确定性的工作任务，但一旦变更的需求确定下来实施变更的需求就是可以计划的；但对需求管理来说需求变更的管理工作也是随着需求变更的发生而发生的，所以在项目计划里按不确定任务处理。需求变更管理的主要任务包括：执行需求变更审批流程、取得客户对需求变更的承诺等，详细见“3.4.5”任务一节。

3.4.2参与人员

●项目经理：负责接收《变更请求表》，组织需求变更活动的开展；

●软件工程组成员：负责变更需求、设计、代码或测试内容，填写《需求跟踪矩阵》；

●CM人员：负责将需求基线纳入配置管理；发布基线和需求状态。

●CCB：负责评估、批准需求；

●客户代表：参与并确认需求的定义。

3.4.3入口准则

●变更请求表已提交

3.4.4输入

●《变更请求表》

●《需求跟踪矩阵》

3.4.5任务

1.由CCB依据《变更请求表》和《需求跟踪矩阵》进行变更评估，确定变更受影响的变更项，

参见《变更控制规程》；

2.《变更请求表》中用户需求变更应详细写明变更内容，如果内容较多，可以加附件，变更表

需要得到客户认可签字。

3.经CCB批准变更后，要及时通知相关组和客户。

4.需求人员依据批准后的《变更请求表》修改《用户需求说明书》，经CCB签字并纳入基线；

5.如果需求变更涉及下游工作产品，软件工程组成员变更下游工作产品，经CCB签字并纳入基

线；

6.CM人员负责将需求基线或下游工作产品纳入配置管理，发布变更和基线，统计需求变更总

数；

7.软件工程组成员根据变更后的《用户需求说明书》及下游工作产品，填写《需求跟踪矩阵》；

8.项目经理变更需求状态，统计需求状态情况。

3.4.6出口准则

●变更被拒绝，CCB批准签字

●变更被取消，CCB批准签字

●变更获得相关组和客户的承诺

●基线更新，变更被执行，CCB批准签字，进行了验证

●需求变更涉及的下游工作产品变更并纳入基线

●《需求跟踪矩阵》变更完成

3.4.7输出

●《变更请求表》

●《项目问题日志》

●《CCB会议记录》

●《需求跟踪矩阵》

3.4.8资源和能力要求

●项目经理具有需求管理能力。

●CM人员具有软件配置管理。

●软件工程组人员具备需求管理知识。

●CCB成员具有需求管理能力。

●