需求管理过程.docx

需求管理过程.docx

《需求管理过程.docx》由会员分享，可在线阅读，更多相关《需求管理过程.docx（14页珍藏版）》请在冰豆网上搜索。

需求管理过程

需求管理过程

本文件属深圳天源迪科信息技术股份有限公司所有，

未经书面许可，不得以任何形式复印或传播。

2008-1—31发布2008—2—18实施

文件建立/修改记录

序号

版本

建立或修改

建立/修改人

日期

审核人

日期

批准人

日期

1

简介

1.1目的

制定需求管理过程的目的是管理产品和组件的需求，识别需求与项目计划及工作产品之间的不一致，有效地控制需求变更、以及跟踪需求的演进,指导项目组管理需求。

1.2适用范围

本过程适用于公司所有的软件项目，贯穿项目的整个生命周期。

1.3背景描述

无.

1.4术语表

●软件需求:

用户解决某一问题或者得到某一目标所需的软件功能。

●基线:

基线是经过评审和批准的配置项的集合，其作用是明确划分项目各阶段，确定各阶段的结束点。

在项目的开发过程中,最基本的基线有需求基线、开发基线、发布基线等.

●配置控制委员会（ConfigurationControlBoard）：

简称CCB，是确定配置基线，评估、批准变更，并保证已批准变更的实施的组织。

●需求变更：

需求变更主要来自三个方面－客户、高层和开发人员。

因此,无论哪一方面提出需求变更的要求,都应当对变更请求进行评估。

需求变更通常包括三项内容：

新增需求、修改需求、删除需求.每一种变更都可能影响到其他需求的变化，因此在进行变更时需要利用需求跟踪记录。

●需求跟踪：

需求跟踪主要是跟踪需求及其实现之间的一致性，需求跟踪通过管理需求跟踪记录来进行.在需求的阶段已经建立了需求跟踪记录，在后续的开发过程中，通过不断填写需求跟踪记录，将设计、开发和测试等阶段产品与需求进行一一对应。

同时，在任何一个阶段发生变更时,都要检查需求跟踪记录是否需要进行变更.需求跟踪是分布在各个开发阶段之中的。

●涉众：

专指所有会受到项目结果重大影响的人。

要有效地解决任何复杂的问题,就会涉及到满足不同涉众的需要。

涉众通常会对问题持有不同的观点，因而必须用所提供的解决方案来满足不同的需要.许多涉众都是系统的用户。

其中许多涉众只是系统的间接用户，或者只受到系统所影响的业务结果的影响。

还有许多涉众是系统的经济型买主或支持者。

了解涉众的组成及其特定需要是开发有效解决方案的关键。

典型的涉众有客户（或客户代表）、用户（或用户代表）、投资者、股东、生产经理、买方、项目经理、设计人员、测试人员、QA、销售/市场人员等。

●需求工程师：

负责整个需求过程，一般来说，需求工程师应当具有和用户进行有效沟通的能力，观察分析总结问题的能力。

1.5参考资料

《软件工程术语》GB/T11457-1995

《质量管理体系要求》GB/T19001-2000

《CMMI模型》　　　　CMMI—DEV,V1.2,CMU/SEI-2006-TR—008，ESC—TR—2006—008

2总体描述

2.1概述

整个需求过程大致可以分为需求获取、需求分析、需求管理三大过程。

需求管理过程是其中一个主要过程,包括需求培训、需求跟踪和需求变更管理三个活动。

在完成需求分析活动后，需求工程师对项目人员进行需求培训，目的是确保项目人员对需求的理解保持一致。

在整个项目生命周期内，都需要实施需求跟踪活动确保需求和计划及工作产品的一致性.需求跟踪活动主要有两种实践方式：

一是通过需求跟踪矩阵，来建立和维护需求和工作产品之间的双向可追溯性;二是对阶段性工作产品进行评审,检查工作产品和需求之间的一致性。

需求变更管理的目的是合理有效地控制并执行需求变更，具体参见《需求变更管理规范》。

2.2职责分工

2.2.1需求工程师

●负责整个需求过程。

●获取业务需求，分析需求，编写需求文档（如：

SRS、业务流程图、业务术语表、业务规则文档、界面原型、用例规约、补充规约等）。

●对项目人员进行需求培训，负责解释需求规约。

建立需求跟踪矩阵。

参与需求变更评估.

2.2.2设计人员

●填写需求跟踪矩阵，检查设计和需求是否一致.参与需求变更评估。

2.2.3测试人员

●填写需求跟踪矩阵，检查测试用例和需求是否一致。

参与需求变更评估。

2.2.4项目经理

●负责需求变更评估.

2.3结构描述

需求管理流程

3活动描述

3.1需求培训

概述

在需求确定之后，应当对设计人员、开发人员、测试人员进行需求培训，保证相关人员更好地理解用户的业务领域和需求。

参与人员及职责

●需求工程师：

负责需求培训

●设计人员：

参加需求培训

●测试人员：

参加需求培训

●开发人员：

参加需求培训

入口准则

形成软件需求基线

输入

●业务流程图、业务术语表、业务规则文档

●原型

●需求规格说明书

任务/步骤

1.需求工程师制定需求培训计划

2.实施需求培训

●需求工程师进行领域知识讲解，包括业务逻辑、业务规则的讲解;

●需求工程师讲解系统需解决的范围

出口准则

●参加培训的人员理解了用户需求和业务流程、业务规则和业务术语，对待开发的产品有了深入了解.

输出（工作产品）

●培训记录

资源和能力要求

●资源：

需求工程师的工作时间保证

●能力：

⏹需求工程师深入了解需求并具有培训能力

度量

度量元

采集点

进行培训的工作量

周报表

裁剪指南

裁剪内容

裁剪准则

可裁剪

当设计人员,开发人员，测试人员能够很好理解需求时可以不用执行.

3.2建立需求跟踪矩阵

概述

在需求开发过程中，需求工程师要建立需求跟踪矩阵，记录业务需求与用户需求及用户需求和软件需求的对应关系。

具体详见《需求分析过程》。

参与人员及职责

●需求工程师:

建立需求跟踪矩阵，建立业务需求到用户需求及用户需求到软件需求的对应关系

●SQA：

检查需求跟踪矩阵，确保没有需求被遗漏

入口准则

完成需求分析活动

输入

●通过评审的需求规格说明书

任务/步骤

1、需求工程师建立需求跟踪矩阵，记录业务需求和用户需求及用户需求和软件需求的对应关系

2、SQA检查需求跟踪矩阵，确保没有需求被遗漏

出口准则

●评审过的软件功能需求都被完整地记录在需求跟踪矩阵中

输出（工作产品）

●需求跟踪矩阵

资源和能力要求

●资源：

相关人员的工作时间保证

●能力:

⏹相关人员应接受过相应方法的培训。

度量

度量元

采集点

进行需求跟踪的工作量

周报表

裁剪指南

裁剪内容

裁剪准则

不可裁剪

无

3.3维护需求跟踪矩阵

概述

在项目人员完成阶段性工作产品或工作产品发生变更时，需要维护需求跟踪矩阵，建立需求和工作产品的双向追溯关系。

参与人员及职责

●需求工程师：

维护业务需求到用户需求及用户需求到软件需求的对应关系

●设计人员：

维护需求和设计的对应关系

●开发人员：

维护设计和代码的对应关系

●测试人员:

维护需求和系统测试用例的对应关系

●SQA：

在项目人员完成阶段性产品或工作产品发生变更时，检查需求跟踪矩阵是否被相应地维护

入口准则

完成阶段性工作产品或工作产品发生变更

输入

●需求跟踪矩阵

●阶段性工作产品

●产品变更文档

任务/步骤

1、需求工程师维护业务需求和用户需求及用户需求和软件需求的对应关系

2、设计人员维护需求和设计的对应关系

3、开发人员维护设计和代码的对应关系

4、测试人员维护需求和系统测试用例的对应关系

出口准则

●完整地记录了工作产品和需求的双向追溯关系

输出（工作产品）

●需求跟踪矩阵

资源和能力要求

●资源：

相关人员的工作时间保证

●能力：

相关人员应接受过相应方法的培训。

度量

度量元

采集点

进行需求跟踪的工作量

周报表

裁剪指南

裁剪内容

裁剪准则

不可裁剪

无

3.4检查一致性

概述

项目人员在完成阶段性工作产品或工作产品发生变更时,要及时维护需求跟踪矩阵并检查工作产品和需求的一致性.项目经理在对工作产品进行评审时，工作产品和需求的一致性是个重要的评审准则。

SQA定期检查需求跟踪矩阵，确保需求跟踪矩阵的完整性和一致性.

参与人员及职责

●需求工程师：

检查业务需求到用户需求及用户需求到软件需求的一致性

●设计人员：

检查需求和设计的一致性

●开发人员:

检查设计和代码的一致性

●测试人员：

检查需求和系统测试用例的一致性

●SQA：

检查需求跟踪矩阵，确保需求跟踪矩阵的完整性和一致性

入口准则

完成阶段性工作产品或工作产品发生变更

输入

●需求跟踪矩阵

●阶段性工作产品

●产品变更文档

任务/步骤

1、项目人员在完成阶段性工作产品，填写需求跟踪时，检查工作产品和需求的一致性.如果不一致性在本组内可以解决,则直接维护工作产品和需求跟踪矩阵；如果不一致性需要其他组修改工作产品，则填写并提交《需求不一致记录表》；如果项目人员认为需要变更需求,则填写并提交《需求变更登记表》。

2、在工作产品发生变更时，负责变更的项目人员维护需求跟踪矩阵，检查工作产品和需求的一致性.如果不一致性在本组内可以解决，则直接维护工作产品和需求跟踪矩阵；如果变更需要其他组修改工作产品，则填写《需求不一致记录表》；如果变更人员认为需要变更需求，则填写并提交《需求变更登记表》。

3、项目经理在组织对工作产品进行评审时，需要评审工作产品和需求的一致性.如果存在不一致性，则填写《需求不一致记录表》；如果评审认为需要变更需求,则填写并提交《需求变更登记表》。

4、SQA检查需求跟踪矩阵，检查需求和工作产品的一致性和需求是否被遗漏。

如果存在不一致性，则填写《需求不一致记录表》。

出口准则

●工作产品和需求是一致的

输出（工作产品）

●需求跟踪矩阵

●《需求不一致记录表》

●《需求变更登记表》

资源和能力要求

●资源：

相关人员的工作时间保证

●能力：

相关人员应接受过相应方法的培训。

度量

度量元

采集点

进行需求跟踪的工作量

周报表

裁剪指南

裁剪内容

裁剪准则

不可裁剪

无

3.5采取更正行动

概述

项目经理将《需求不一致记录表》发给受影响的小组的负责人和SQA，受影响的小组维护相关工作产品和需求跟踪矩阵，SQA检查《需求不一致记录表》的处理情况。

如果

参与人员及职责

●项目经理:

通知受影响的小组，如设计组、开发组、测试组。

●设计人员、开发人员、测试人员：

维护工作产品和需求跟踪矩阵

●SQA：

检查《需求不一致记录表》的处理情况

入口准则

发现工作产品和需求存在不一致性并需要其他组修改工作产品

输入

●需求跟踪矩阵

●《需求不一致记录表》

任务/步骤

1、项目经理将《需求不一致记录表》发给受影响的小组的负责人和QA。

2、受影响的小组维护相关工作产品和需求跟踪矩阵.

3、检查《需求不一致记录表》的处理情况。

出口准则

●工作产品和需求不一致的问题已被处理

输出（工作产品）

●需求跟踪矩阵

●和需求一致的工作产品

资源和能力要求

●资源：

相关人员的工作时间保证

●能力:

相关人员应接受过相应方法的培训。

度量

度量元

采集点

进行需求跟踪的工作量

周报表

裁剪指南

裁剪内容

裁剪准则

不可裁剪

无

3.6需求变更管理

概述

在项目生命周期的任何一个阶段，都有可能发生需求变更。

当需求变更发生时，应当通过需求变更管理有效地控制变更。

具体详见《需求变更管理规范》。

参与人员及职责

●变更申请人：

提交需求变更申请

●项目经理：

组织对变更进行评估

●相关组（如质量组、测试组）人员：

对变更进行评估

●客户或用户代表：

参与评估需求变更

●CCB：

评估需求变更申请，确定是否进行需求基线变更.

入口准则

有需求变更请求提出

输入

●需求变更请求

任务/步骤

1.需求变更的提出人可能是客户、开发人员等，对于这些原始的变更请求需要经过需求变更缓冲，可以由开发人员收集并记录这些变更请求，当变更请求积累到一定数量或者要变更的需求优先级比较高时，提出需求变更申请。

在变更申请表中填写变更原因、变更内容和变更所处阶段。

2.项目经理对变更进行评估，确定变更影响的范围，估计实施变更的工作量和风险，并填入需求变更申请表.

3.若变更影响范围涉及到相关组，相关组应对变更进行评估确定实施变更的工作量和风险，并填入需求变更申请表.

4.客户或用户代表对变更进行评估,确定变更对其它需求的影响，以及估计风险。

5.变更经过评估后，如果影响比较重大，应组织CCB和客户（用户代表）对变更进行评审,确定是否变更.

6.无论变更是否被批准,项目经理须填写变更记录，并表示处理状态（同意/不同意）.

7.若执行变更，项目经理应将变更通知相关人员,并按照《配置管理过程》变更相关工作产品.

出口准则

●需求变更申请得到有效处理。

输出（工作产品）

●需求变更申请表

●SCCB会议纪要

●需求变更记录

●（如果执行变更）变更通知、变更的工作产品、基线

资源和能力要求

●资源：

相关人员的工作时间保证

度量

度量元

采集点

需求变更的工作量

需求变更申请的次数

需求变更申请批准的次数

需求变更发生的阶段

周报表

需求变更记录

需求变更记录

需求变更记录

裁剪指南

裁剪内容

裁剪准则

不可裁剪

无

4附录

4.1附录A－相关过程

需求获取过程

需求分析过程

软件设计过程

软件实现过程

项目计划过程

项目监督与控制过程

风险管理过程

软件配置管理过程

4.2附录B－相关规范、指南

需求变更管理规范

4.3附录C－相关模板列表

模板

使用人

使用时间

需求跟踪矩阵

需求工程师

设计人员

测试人员

需求建立、跟踪

需求变更登记单模板

需求管理员

提出需求变更时

需求变更记录单模板

项目组成员

当需要发生变更时