《需求开发与管理过程》.docx

《需求开发与管理过程》.docx

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

《需求开发与管理过程》

需求开发与管理

过程编号

文件状态

[]草稿[√]正式发布[]正在修改

当前版本

V1.0

修订

日期

2007-11-21

审核

日期

批准

日期

发布日期

生效日期

修订历史记录

A-增加M-修订D-删除

变更版本号

日期

变更类型

（A*M*D）

修改人

摘要

备注

1目的

2

定义需求开发与管理过程，为需求开发及跟踪提供有效的流程和方法。

3适用范围

4

4.1机构

4.2

技术部门、CCB及质量部门。

4.3业务

4.4

提供需求工程的过程标准。

5名词术语

6

ØRDM（RequestDevelopmentandManagement）：

需求开发与管理；

SRS（SoftwareRequirementSpecification）：

软件需求规格说明书；

URS（UserRequirementSpecification）：

用户需求说明书；

客户（Customer）：

开发产品订单的付费方；

最终用户（EndUser）：

最终真正操作软件的用户；

用户需求：

指直接来自于客户或者用户的原始需求；

软件需求：

指对用户需求进行需求分析和开发之后生成的对于软件产品开发的需求；

项目的级别分为三类，A类、B类、C类；

✧A类项目：

一般开发周期长（超过6个月）、人员多（超过6个人）、费用高、或对公司利益影响大的项目属于A类项目；

✧

✧B类项目：

开发周期为2～6个月、人员3～6个、对公司利益影响比较大的项目属于B类项目；

✧

✧C类项目：

对于开发周期短（少于2个月）、投入人员少（少于3人），或对公司利益影响较小的项目大多数的情况下可确定为C类项目，C类项目的风险通常比较小，容易控制。

✧

CCB（ChangeControlBoard）：

变更控制委员会。

CCB的组长一般为适用机构的领导，成员一般为质量部门经理及适用机构领导制定的某些特定人员，对于B类项目，CCB可直接由部门的经理担任组长，由质量部门经理、专家、开发人员担任组员；

高层经理：

项目经理的直接主管，如各事业部的部门经理、技术总监等。

7概述

8

项目在工程活动的开始，首先要进行需求开发。

后续所有的工程活动，包括设计、实现、测试均是根据需求展开的，所以需求开发的重要程度是最高的，而由于需求的抽象性，需求开发人员（系统分析员）不仅需要有过硬的专业知识，而且要具备较强的交流、沟通能力，所以需求开发也是最难的。

任何项目，需求在整个工程开发过程中必定会发生变化，因此对需求变更的控制，即需求管理必不可少。

9过程定义

10

10.1需求开发与管理流程图

10.2

10.3

5.1.1角色与职责

角色

职责

需求分析员

1、进行需求调查及需求分析；

2、

3、撰写《用户需求说明书》，《软件需求规格说明书》。

项目经理

1、需求跟踪；

2、

3、提交需求变更申请；

4、

5、组织需求评审。

高层经理

1、评审及确认需求。

CCB

1、审批需求变更申请。

客户

1、需求确认；

2、提交需求变更申请；

3、配合软件需求开发。

5.1.2入口准则

Ø项目已经启动；

Ø

5.1.3输入

Ø项目计划

Ø

5.1.4过程活动

1）、用户需求调查

获取用户（客户和最终用户）的需求信息。

调查需求的方式包括：

Ø与用户交谈，向用户提问题

Ø

Ø参观用户的工作流程，观察用户的操作

Ø

Ø向用户群体发调查问卷

Ø

Ø需求讨论会

Ø

Ø与同行专家交谈，听取他们的意见

Ø

Ø利用原型法

Ø

Ø分析已经存在的同类软件产品，提取需求

Ø

Ø从行业标准、规则中提取需求

Ø

Ø从Internet上搜查相关资料

Ø

在需求调查过程中形成《用户需求调查报告》，最后整理形成《用户需求说明书》，《用户需求说明书》要尽最大努力使搜集到的需求正确无误的反映用户的真实意愿。

2）、评审用户需求说明书

项目经理组织对《用户需求说明书》进行正式评审。

3）、确认用户需求说明书

项目经理将评审通过的《用户需求说明书》提交给客户（或客户代表）进行确认。

4）、对用户需求分析及定义

需求分析员对搜集到的用户需求进行分析细化，以便产生详细的软件需求。

需求分析的主要方法有：

Ø问答分析法。

常见的问题包括：

Ø

²需求是否存在二义性

²需求文档上下文是否有矛盾

²需求是否完备

²需求是必要的吗

²需求可实现吗

²需求可验证吗

²需求的优先级确定了吗

Ø结构化分析方法。

结构化分析方法的主要特点是“自顶向下、逐层分解”，它把系统看作一个过程的集合体，利用图形等半形式化的描述方式表达需求，对问题进行分析。

Ø

Ø基于用例的分析方法。

用例是由一组用例实例组成的，用例实例也称为“使用场景”，是用户使用系统的一个实际的、特定场景。

用例是应用程序开发中的一个关键技术，主要用来捕获系统的高层次（HighLevel）用户功能性需求。

用例分析技术是一种需求合成技术，它利用现有的需求获取技术从客户、原有系统、文档中找到需求，记录下来，然后从这些零散的需求、特性中进行整理、提炼，从而建立用例模型。

Ø

同时需求分析人员应确定每个需求的优先级，级别分别为：

高、中、低。

优先级的定义有利于帮助项目组在项目的范围、进度、资源、预算等相关制约因素之间产生冲突时，能够正确地对需求实现的范围或实现的优先程度做出取舍。

一个实现这种权衡的方法是：

当接受一个新的高优先级的需求或者其它项目环境变化时，删除低优先级的需求，或者把它们推迟到下一版本中去实现。

（具体优先级评价标准参考：

《iASPEC-SP-RDM-G01需求开发与管理指南》）

在对需求进行分析和定义时，需求分析员同时撰写《软件需求规格说明书》。

其内容主要包括：

Ø产品介绍

Ø

Ø描述用户群体的特征

Ø

Ø定义软件的范围

Ø

Ø需求的优先级别

Ø

Ø阐述软件应当遵循的标准和规范

Ø

Ø定义软件中的角色

Ø

Ø定义软件的功能性需求

Ø

Ø定义软件的非功能性需求，如用户需求、软硬件环境、质量等需求

Ø

5）、评审软件需求规格说明书

项目经理组织对《软件需求规格说明书》进行正式评审。

如果是需求说明书变更后的评审，变更范围包括《用户需求说明书》和《软件需求规格说明书》，那么此次评审需要对两个文档进行评审。

6）、需求跟踪

当《用户需求说明书》、《软件需求规格说明书》通过评审并且《用户需求说明书》客户确认之后，需求开发人员要依据其编制《需求跟踪矩阵》。

随着软件设计、编码、以及测试开发的不断推进，各个阶段的负责人员在各个阶段产品形成时，将相关的信息填入《需求跟踪矩阵》，建立与维护“需求文档－设计文档－代码－测试用例”之间的一致性，使阶段工作产品与需求形成对应关系。

对于已纳入《需求跟踪矩阵》的相关工作产品产生的变更，则由《需求跟踪矩阵》的维护人员（项目配置管理员）在每次变更完成后根据变更修改《需求跟踪矩阵》的对应关系，在每个里程碑时由项目经理指定人员负责对跟踪矩阵的完整、正确、一致性进行确认。

7）、需求变更申请

项目组外的需求变更由变更申请人向项目组提出，如由客户经理提交需求变更申请单给项目经理；项目组内部的需求变更，由项目经理提交需求变更申请单。

具体的变更流程请参考“变更控制与管理”过程域。

8）、审批需求变更申请

CCB进行需求变更申请的审批。

9）、变更需求文档

需求分析员根据CCB确认的变更方案对《用户需求说明书》和《软件需求规格说明书》进行变更处理；项目经理要进行评审及确认变更需求。

模板参见“变更控制与管理”过程域的变更单模板。

5.1.5输出

Ø用户需求说明书；

Ø

Ø软件需求规格说明书；

Ø

Ø需求跟踪矩阵；

Ø

Ø需求变更申请单；

Ø

5.1.6出口准则

Ø项目已结项；

Ø

5.1.7过程度量

1）度量人员对以下数据进行度量

Ø工作量；

Ø

Ø进度；

Ø

Ø需求变更的次数；

Ø

Ø《用户需求说明书》、《软件需求规格说明书》的规模；

Ø

5.1.8确认与验证

ØQA对需求开发与管理过程及其产生的产品的规范性进行检查；

Ø

Ø项目经理对需求开发与管理过程进行监督，组织对产生的产品进行审查；

Ø

Ø高层经理及客户对《用户需求说明书》进行确认；

Ø

ØCCB对需求变更申请进行审批；

Ø

11规程

12

无

13指南

14

《IASPEC-SP-RDM-G01需求开发与管理指南》

15标准与规范

16

《IASPEC-SP-RDM-C01需求开发与管理检查单》

17裁剪指南

18

9.1用户以规范形式提供了《用户需求说明书》的情况下可裁剪用户需求调查活动；

9.2当需求比较简单或需求调研工期比较短的情况下可裁剪《用户需求调查报告》；。

9.3对于非合同项目《用户需求说明书》可以裁减，直接书写《软件需求规格说明书》

19模板与表格

20

10.1《IASPEC-SP-RDM-T01用户需求调查报告模板》

10.2《IASPEC-SP-RDM-T02用户需求说明书模板》

10.3《IASPEC-SP-RDM-T03软件需求规格说明书模板》

10.4《IASPEC-SP-RDM-T04软件需求跟踪矩阵表单模板》

21实施指导

22

“需求开发与管理”是CMMI中的工程类过程。

以下是对“需求开发与管理”过程实施时的进一步指导说明：

1）、管理配置项

对“需求开发与管理”过程产生的所有有价值的文档应纳入配置管理的适当层次。

主要文档示例如下：

Ø用户需求调查报告

Ø

Ø用户需求说明书

Ø

Ø软件需求规格说明书

Ø

Ø需求跟踪矩阵

Ø

Ø需求变更申请单

Ø

2）、培训人员

组织应该对所有或部分参与“需求开发与管理”过程的相关人员进行培训。

主要培训专题示例如下：

Ø需求分析方法

Ø

3）、使项目干系人适时介入

Ø对于需求调查的用户需求要得到所有项目干系人的共同理解和承诺。

Ø

4）、QA根据计划和控制“需求开发与管理”过程，并且采取适当的纠正措施。

5）、项目经理在执行“需求开发与管理”过程中，应注意收集对过程的改进建议，并提交给组织EPG。

6）、评审及确认需求时，如客户及最终用户纳入存在困难，可以在征求高层经理的同意下，由高层经理代表客户需求，其他指定人员代表最终用户需求进行评审。