需求管理过程

XXX有限公司需求管理过程

需求管理过程

文档版本号：VI.0文档编号：XXXX_RM_PROC_RM

文档密级：内部公开归属部门/项目：研发部

编写人；XXXX生效日期：XXXX-XX-XX

文档修订记录

版本修订说修订

修订日期修订人审核日期审核人批准人

号明状态

V1.0XXXXXXX正式版AXXXXXXXXXXX

修订状态：A--增加，M--修改，D-删除

日期格式:YYYY-MM-DD

目录

1.目的/方针.....................................................................1

2.范围..........................................................................1

3.术语..........................................................................1

4.角色与职责....................................................................1

5.入口准则......................................................................1

6.输入..........................................................................2

7.流程图........................................................................2

8.主要活动......................................................................3

8.1.需求确认................................................................3

8.1.1.需求评审.........................................................4

8.1.2.需求承诺.........................................................5

8.2.需求变更................................................................5

8.2.1.需求变更申请....................................................5

8.2.2.需求变更的实施..................................................6

8.3.需求跟踪................................................................6

8.3.1.建立需求跟踪矩阵...............................................6

8.3.2.需求跟踪矩阵的维护与使用......................................6

9.输出..........................................................................7

10.出口准则....................................................................7

II.引用文档.....................................................................7

12.使用模板....................................................................7

1.目的/方针

通过定义需求管埋过程，规范公司软件开发项目的需求管理活动，提高需求质量，从而

提高软件生产率，降低开发成本，改进软件质量。

需求管理应控制需求的变更，并确保项目工作产品与需求的一致性。

2.范围

适用于公司所有产品研发类、实施类、合同开发类以及维护开发类项目。

3.术语

术语或缩略语解释

软件需求在IEEE软件工程标准词汇表（1997年）中定义软件需求为：（1）用户解决问

题或达到目标所需的条件或能力。（2）系统或系统部件要满足合同、标准、

规范或其它正式规定文档所需具有的条件或能力。（3）一种反映上面⑴或

（2）所描述的条件或权能的文档说明。通俗的讲，“需求”就是用户的需要，

它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，

它是一个程序或系统开发工作的说明，表现形式一般为文档形式。

用例是在系统中执行的一系列动作，这些动作将生成对特定参与者可见的价值

结果，一个用例定义了一组用例实例

需求分析是指在需求开发过程中，对所获取的需求信息进行分析，及时排除错误和

弥补不足，确保需求文档正确地反映用户的真实意图。需求分析的关键就

是对问题域的研究与理解。为了便于理解问题域，现代软件工程方法所推

荐的做法就是对问题域进行抽象，将其分解为若干基本元素，然后对元素

之间的关系进行建模。

4.角色与职责

角色职责

项目经理负责组织软件开发项目的需求分析和管理工作

需求分析师负责需求的获取，分析以及定义、并对需求进行评审

研发部评审委员会接受需求评审申请，组织进行需求的评审

CCB参与需求的确认、需求变更的确认

客户参与需求的确认、需求变更的确认

5.入口准则

•项目立项

1/8

6.输入

•项目立项公告

7.流程图

图1：需求管理过程（需求确认）流程图

2/8

＜需求管理流程图）

输入专业系统部需求分析帅项目经理项目组成员客户血II

（开始）

_zr

▼

需求变史中请不

变更a；求

___—J一—一一一.

-----——卡通寸—­*

不通过•修改—通过»得求承诺

\I

需求跟鼠矩阵

祈求yH踩艳

势的，田和

使用

T.工T..J_____、_____

r.m

图2：需求管理过程（需求变更：详见《变更管理规程》中基线变更流程）流程图

8.主要活动

软件需求工程包括了需求开发和需求管理两个部分，需求管理的目的是在客户与项目组

之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。需

求管理的主要活动包括：需求确认，需求变更和需求跟踪控制。

需求获取前应该制定《需求开发计划》。

8.1.需求确认

需求确认是指项目组和客户（或客户代表）共同对《用户需求规格说明书》或《软件需

求规格说明书》进行评审，双方对需求达成共识后做出承诺。需求确认包含两个重要工作：

“需求评审”和“需求承诺

3/8

8.1.1.需求评审

应对所形成的需求文档进行评审，以便作为下一阶段工作的基础。需求评审的方式分为

“技术评审会议”与“组内评审”两种。

项目组根据需求分析的进展情况，采用“组内评审”的方式分阶段对需求分析的阶段成

果进行评审，分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低

了需求返工的风险，提高了评审的质量。组内评审要求：

•评审组长：项目经理；

•评审组成员：研发部经理、需求分析师、系统分析师、测试工程师，适当邀请组外

专家参与：

•输入：《软件需求规格说明书》，《用户需求规格说明书》

•输出：会议纪要

•检查单：需求评审检查单

当需要召开技术评审会议时，由项目组向研发部提苗需求技术评审申请，由研发部组织

按“技术评审会议”的方式实施需求评审。技术评审会议要求如下：

•评审组织部门：研发部

•评审组成员：

a）项目组代表

b）测试组代表

0公司的技术专家与业务专家

d）客户服务部门代表

e）客户或客户代表

0系统关联组代表

g）QA工程师

・输入：《软件需求规格说明书》，《用户需求规格说明书》

•输出：评审报告

•检查单：需求评审检查单

4/8

关于“组内评审”、“技术评审会议”的要求详见《评审过程》。

8.1.2.需求承诺

项目经理将评审通过的《软件需求规格说明书》提交给客户（或客户代表）、系统关联

项目组进行确认，确认的方式可以是以下方式之一：

•直接签字：由承诺方在评审报告上直接签字或盖章确认

•邮件方式：由项目经理将《软件需求规格说明书》与评审报告通过邮件发送给接收

方，并明确确认通过的准则（如：如果在一周内未予以回复则默认为确认通过）；

•发送会议纪要函：如果承诺方参加了评审会议并在会上达成了共识，则可以编制会

议纪要在纪要中描述参加评审的人员、评审的结论等，并通过纪要函的方式发送给

承诺方。

项目的软件需求规格说明书经过评审与确认后，应根据《配置管理过程》的要求建立需

求基线。

8.2.需求变更

对一个软件项目来说，无论最初的需求分析有多么明确，开发过程中的需求变化也还是

不可避免的。这主要有以下几种原因：

1.软件所应用的外部环境发生变化；

2.随着用户对软件的熟悉和应用，又提出新的需求；

3.项FI组进行需求分析时未能彻底分析用户的需求，或分析错误；

4.用户在开始时不能很全面的知道所需软件的功能。

8.2.1.需求变更申请

项目组外的需求变更由变更申请人通过填写《需求变更申请单》向项目组提出进行，变

更申请人一般是客户代表，需要得到客户项目负责人签字确认，并盖以单位公章，签字盖章

后传真回公司，提交到研发部评审，经过部门评审后反馈给客户和项目负责人；项FI组内部

的需求变更通过《软件变更申请单》提出。

5/8

8.2.2.需求变更的实施

项目组根据《变更管理规程》中的要求实施变更。

在变更完成后，若需要发布新的需求基线，项目组应根据《配置管理过程》中“基线发

布”的要求重新建立需求基线，并通知相关的人员。

8.3.需求跟踪

对一个软件项目来说，当需求确定下来以后，应该保证在软件设计过程中每个需求都被

实现，且项目的其它工作产品与需求保持一致。因此，一个比较好的方法就是建立一种需求

双向跟踪机制。双向跟踪却：

•正向跟踪：当发生需求变更时，通过从需求向后追溯到下游相关工作产品，可分析

出这些美联项是否需要变更，从而达到追溯的日的；

•逆向跟踪。通过从下游工作产品回溯到需求，可分析需求是否得到满足，从而达到

回溯的目的。

进行需求双向跟踪的一个简单的方法是建立一个映射，从需求到设计，从设计到编码，

以及从编码到测试用例，把每个需求都映射到对应的位置。这个映射可以用需求跟踪矩阵来

实现。

8.3.1.建立需求跟踪矩阵

当《软件需求规格说明书》通过评审之后，项目经理应组织根据确定的需求跟踪他粒度

编制《需求跟踪矩阵》。项目经理指定人员对需求跟踪矩阵进行个人复查，确保跟踪粒度合

理、跟踪项适用。

8.3.2.需求跟踪矩阵的维护与使用

随着软件设计、编码、以及测试开