需求管理过程

软件过程标准

需求管理过程

V1.0

页脚内容

10

需求曲线的移动

页脚内容

10

需求曲线的移动

修订记录

版本号 0.9 0.99 1.0

日 期 2002/07/19 2002/07/29 2002/08/12 作者 万志鹏 万志鹏 万志鹏 授权人 苏光 苏光 彭柏林 授权日期 描述 2002/07/18 第一次编制, 苏光指导 2002/08/01 根据评审意见修改过程，并转换为公司文档格式。 2002/08/12 通过批准 页脚内容

10

需求曲线的移动

目录

1 2 3 4 5 6 7

目的和范围 ............................................................. 1 术语简称与解释 ......................................................... 1 进入准则 ............................................................... 1 退出准则 ............................................................... 1 阶段交付产品 ........................................................... 2 使用者 ................................................................. 2 过程流图 ............................................................... 3 7.1

过程 ................................................................ 3

7.1.1 需求收集与获取 .................................................... 3 7.1.2 需求评审 .......................................................... 5 7.1.3 需求变更管理过程 ................................................ 6 7.2

过程描述 ............................................................ 7

7.2.1 需求收集与获取规程 ................................................ 7 7.2.2 需求评审规程 ...................................................... 7 7.2.3 需求变更管理规程 .................................................. 8 7.3 7.4 8 9

验证机制 ............................................................ 9 度量 ................................................................ 9

活动职责矩阵 .......................................................... 10 参考资料 .............................................................. 10

10 附件 .................................................................. 10

页脚内容

10

需求曲线的移动

1 目的和范围

本过程的目的在于为公司实施与需求相关的方针提供指南。该过程对所有公司负责需求采集的项目适用，也适用于那些客户在自行采集需求时需要帮助的项目。

2 术语简称与解释

总经理：简称GM，指公司总经理，具备法人代表资格。 副总：简称VGM，公司的一种职务，指公司副总。

项目经理：简称PM，公司的一种职务，一般由具备项目管理经验和行业经验人员承

担，负责项目的管理活动。

项目负责人：简称PL，项目组组长，临时性职务，负责项目的开发活动，如无变更，

生存周期与项目生存周期相同。

需求分析人员：简称RA，通常由项目组中成员承担此角色，可以是项目负责人也可

以项目组中其他人员。

软件设计人员：简称SD。在公司一般指系统分析员和程序员（包括高级程序员）；

在项目中指项目组中的设计人员。

软件质量保证：SQA，一种软件质量保证活动，在公司通常也用SQA代表质量保证活

动者，目前由公司品管部执行此活动。

配置管理员：简称CC，在公司中负责所有项目的配置管理活动。

3 进入准则

进入准则如下：

来自客户的关于需求的文档经过公司审批；

来自客户的标识有意进行某个项目的信函，并且经过公司审批； 总经理对内部项目的授权，有相关文件（文档）表明是经过审批的； 公司与客户签订的合同。

附注：满足其中任何一种条件均可。

4 退出准则

退出准则如下：

SRS的文档已准备好，经过评审和批准。

页脚内容

10

需求曲线的移动

5 阶段交付产品

本阶段交付有：

经过评审并得到批准的SRS文档； SRS评审报告； 变更请求； 变更请求单日志； 影响分析报告。

6 使用者

本文件的使用者如下：VGM、RA、SD、PM、PL、QA。

页脚内容

10

需求曲线的移动

7 过程流图

7.1 过程

7.1.1 需求收集与获取

页脚内容

10

需求曲线的移动

开始需求产生来自客户的需求否是客户是否有自己的格式要求否是按客户格式要求生成SRS按公司格式要求生成SRS评审VGM/PM/PL修改需求是SRS中有缺陷吗？否客户同意后基线化需求RA/CC根据命名规则命名SRSRA/CC将SRS置于配置管理中CC结束

页脚内容

10

需求曲线的移动

7.1.2 需求评审

开始确定评审何时进行，以及持续多长？PM/PL就评审计划和评审参与者PM/PL沟通分发产品给评审人员PL评审者对产品进行个人评审是有缺陷吗？制定个人缺陷列表否主持评审会议分配角色介绍产品X

页脚内容

10

X讨论个人评审中发现的缺陷讨论缺陷达成一致意见确定最终缺陷列表准备评审报告评审小组成员给定评审结果评审小组是是否存在确定下次评审相关缺陷？事宜否批准结束

需求曲线的移动

7.1.3 需求变更管理过程

开始需求发生变化发出变更请求（指南）:--如果影响分析发现变更在项目成本或时间上有重大影响，应通知客户，并进行再评估，征求客户对成本或时间变更的认可。同时通知市场和财务部门更新合同文件。结束启动准则进行影响分析变更是否被接受？否是更新SRS和相关文件为执行变更分配资源（相关文件）:- SRS- 详细设计等)更新过的文件经过评审和批准后置于配置管理之下通知相关人变更情况按照SPTO过程跟踪变更执行情况记录变更执行进程否变更结束是更新PDB结束

页脚内容

10

需求曲线的移动

7.2 过程描述

需求管理过程被分为3部分，包括：需求获取和采集过程、需求评审过程、需求变更管理过程。

7.2.1 需求收集与获取规程

需求可能来自以下任何一种渠道

客户的需求文档 工作范围描述文档 电子邮件 合同

随后，进行需求文档格式的评审：

当需求不是以公司格式提交时，项目经理/项目负责人可选择如下处理办法： 将需求转换成金恒宇公司的格式，或采用用户的需求文档格式。 当客户特别要求用他们自己的格式时，应满足他们的要求。 就以下方面对评审需求

正确性。正确性取决于技术人员

完整性。完整性取决于技术人员以及SQA人员

可行性。可行性研究由PM/PL在评审时进行，在进行估计时进一步完善对可行性的研究

一旦在需求文件中发现缺陷/问题，将编制评审报告，并从客户那里征求进一步的阐述或建议或更多输入

如果评审报告表明需求清晰、完整而且正确无误，需求文档得到基线化； 需求文档命名应遵守命名规则，并检入配置管理（CM）工具/库； SRS的评审报告也要置于配置管理之下

7.2.2 需求评审规程

在SRS被用于开展进一步的策划和开发活动之前，SRS必须经过评审

制定评审计划，选定SRS评审人员，主要有：VGM、PM、PL、RA、SD、关键技术

人员。

评审进度安排要通知给评审小组成员，交流的方式可以是E-MAIL亦可是书面通知

页脚内容

10

需求曲线的移动

分发SRS文档以及其他客户提供的资料和参考资料，评审小组成员就SRS进行个人评审，如果发现任何缺陷，将他们列入个人的缺陷清单 评审者参加评审会议，分配评审组角色 读者朗读SRS文档

当任何评审组员发现潜在的缺陷时，读者停止朗读，小组讨论它是否是SRS的一个缺陷，若确实存在缺陷，由记录员负责记录下来 以上过程反复进行直到所有的缺陷均被讨论并达成一致意见 记录员做出最终缺陷列表，评审小组负责人将其通知客户 需求分析人员就评审中发现的缺陷征求客户的意见 评审小组就缺陷严重程度决定是否进行再评审

一旦再评审是必须的，评审报告应反映这个情况并采用本规程安排及执行再评审

如果在SRS文件中找不到重要缺陷，亦认为再评审无必要，则可批准该SRS文档，并基线化

基线化的SRS版本应检入配置管理（CM）工具/库

7.2.3 需求变更管理规程

当需求发生变更，公司要提出变更请求、这个工作可以由公司或客户来做 变更请求必须有一个唯一的编号

对变更进行影响分析，以评估变更的规模。一旦发现变更影响巨大，以至波及到项目工作量、进度，成本，变更将转送到公司高层经理和市场/财务部门决策是否变更合同

当变更被认可（小变更由公司控制，大变更要经过客户许可）变更申请转变成变更令，并付诸实施

更新SRS文件。如果有要求，更新其他文件

为这些变更的进行提供资源（人，软件、硬件），如有必要时。 将更新过的文档置于CM的管理之下（CM工具/库） 将SRS及其他文件的变更通知所有相关人员 按照项目跟踪过程与活动，对变更的执行进行跟踪

一旦变更实施，且实施通过验收，变更请求单上将标注为闭合

页脚内容

10

需求曲线的移动

为便于在以后参阅，关于该变更的所有信息将保存在过程数据库中

7.3 验证机制

验证机制如下： 配置审计

对执行期超过六个月的项目应当在每个月、每个版本发布前、任何外部审计前进行。

对执行期少于六个月的项目应当在每15天、每个版本发布前、任何外部审计前进行。

由SQA/独立小组进行的内部审计

对执行周期超过六个月的项目每个月组织内部审计。 对执行周期少于六个月的项目每15天组织内部审计。 外部审计

ISO监督审计—由外审人员安排日程。 CMM相关评估——由评估人员安排日程。 给管理高层的关于需求管理相关活动的定期报告 对执行期少于六个月的项目应当每周进行报告 对执行期超过六个月的项目应当每15天进行报告

7.4 度量

对需求相关活动的评估指标如下： 编号 1 2 3 4 5 6 7 评估指标 需求数量 需求变更数量 已认可的变更数量 正在执行的变更数量 需求相关活动中耗费的工作量 预期在需求管理中耗费的工作量 实际在需求管理中耗费的工作量 频率 每15天 每周 每周 每周 每周 每周 每周 10

责任 PM / PL PM / PL PM / PL PM / PL 来源 SRS 变更日志 变更申请日志 项目状态报告 所有参与需求相时间表 关活动人员 PM / PL 项目计划 所有参与需求活项目状态报告 动人员 页脚内容

需求曲线的移动

8 活动职责矩阵

编号. 1 2 3 4 5 6 7 8 9 活动 获得需求 评审需求 准备SRS 评审SRS 认可SRS 认可变化 影响分析 管理SRS 升级PDB - S - S S S S S - VGM S P S P P P P S - PM S P P P S S P P - PL P P P P S P P S - RA SQA/ SEPG - S - S S S S S P 附注： P: 主要职责 S: 次要职责

9 参考资料

SEI-CMM version 1.1

10 附件

TM_SDLC_SRS

SRS模板

FM_SDLC_REVW 缺陷评审/测试表 CL_SDLC_REQE 需求获取检查单 CL_SDLC_RQRW SRS评审检查单 SRS评审报告

变更请求表 变更请求记录表 影响分析表

页脚内容

10