需求开发和管理过程

等级:C

需求开发与管理过程

第 1 页/共 1 页
 需求开发和管理过程

变更记录
版本号 修改点说明
V1.0 创建
V1.1 修改个别项目需求变更申请单所列变更内容，
未在产品需求规格说明书中描述；项目的需求
跟踪矩阵: 非功能需求未列入跟踪； 部分项目对

⽤用户需求的跟踪不正确； 个别项目测试⽤用

例的跟踪部分不正确。
部分项目产品需求规格说明书对接口需求定义
不清楚；产品需求规格说明书；部分项目操作
序列未明确定义；个别项目非功能需求部分不
清楚
V1.11 建议需求管理过程中将需求分类，方便变更管
理及度量工作；
V1.12 增加需求确认的证据，试点项目中增加需求确
认
V2.0 修改主要意图和职责

修改点说明的内容有如下几种：创建、修改（ +修改说明）、删除（+删除说

明）

第 2 页/共 1 页
 需求开发和管理过程

第 3 页/共 1 页
 需求开发和管理过程

目录
1. 前言............................................................................................................................3
1.1 意图和价值......................................................................................................3
1.2 适用范围..........................................................................................................3
1.3 名词术语..........................................................................................................4
2. 过程定义....................................................................................................................4
2.1 角色和职责......................................................................................................4
2.2 入口准则..........................................................................................................5
2.3 输入..................................................................................................................5
2.4 过程活动..........................................................................................................6
2.4.1 需求开发过程.......................................................................................6
2.4.2 需求管理过程.....................................................................................11
2.5 输出................................................................................................................17
2.6 出口准则........................................................................................................18
2.7 过程度量........................................................................................................18
2.8 裁剪说明........................................................................................................18
3. 相关指南..................................................................................................................18

1. 前言

1.1 意图和价值

意图： 明确需求，确保利益相关者的共同理解，并调整需求、计划和工作
产品。
价值： 确保客户的需求和期望得到满足。

第 4 页/共 1 页
 需求开发和管理过程

1.2 适用范围

本过程文档是项目经理需求开发人员（包括：售前市场人员、需求调研人
员等）执行需求开发与管理过程活动的依据和指导。本过程适用于公司所有软
件项目，且贯穿于整个生命周期。

1.3 名词术语

 用户需求
是用户对要建立的系统的要求描述，它主要说明用户“要做什么”、
“想做什么”的问题。
 软件需求
也叫产品需求，是软件产品能否满足用户需求的要求描述，它主要说
明软件产品“能做什么”、“不能做什么”的问题。

2. 过程定义

2.1 角色和职责

角 色 职责描述

1. 评审、批准用户需求、产品需求等过程产品，并参与本过程域重要的活动；
高层经理
2. 解决在实施本过程域中所遇到的无法解决的问题

项目经理 1. 为需求开发工作提供各种必要的环境和条件；

2. 制订需求开发计划，并跟踪维护该计划；

3. 负责联系用户和需求人员进行需求开发工作；

4. 参与评审本过程域的工作产品；

5. 完成或协助完成本过程域的工作产品；

第 5 页/共 1 页
 需求开发和管理过程

角 色 职责描述

6. 对需求进行变更管理、跟踪控制；

7. 向高层经理报告本过程域的实施情况；

1. 负责对市场、客户的需求调研；

2. 收集、分析、细化、导出和描述用户需要、期望、约束和接口，并把它们转

换成用户需求；
需求开发人员 3. 完成需求开发，编写《用户需求说明书》和《产品需求规格说明书》等需求

文档；
4. 负责对需求的后期跟踪；

5. 负责执行需求的变更。

1. 根据用户需求和产品需求，在需求开发人员的指导下，完成开发原型 Demo

美工 的制作；
2. 和需求开发人员一起，向用户进行开发原型 Demo 演示。

项目组成员 参加需求开发与管理活动的评审。

1. 配合并参与需求的调研活动；

2. 评审并确认需求开发的所有文档；
客户
3. 对《用户需求说明书》和《产品需求规格说明书》、需求 Demo 等进行确

认；

1. 评审需求文档是否满足了用户的真实意愿。
CCB
2. 审批需求变更申请。

CM 1. 为评审后的需求文档进行配置管理。

1. 检查和监督需求管理活动的有效性和一致性。

QA 2. 将检查出来的问题及时通报给项目经理及项目组成员，并跟踪问题直到关

闭。

2.2 入口准则

 需求开发人员已经确定；
 初步的《项目计划》已经通过评审。

第 6 页/共 1 页
 需求开发和管理过程

2.3 输入

 初步的《项目计划》；
 《项目合同》；
 《技术解决方案》；
 客户原始需求文档。

2.4 过程活动

需求阶段包括需求开发和需求管理两个过程活动。
 需求开发过程
需求开发过程是获取用户需求并对用户需求进行分析整理形成
软件需求的过程。需求开发过程可以包括用户需求调研、用户需求
分析、软件需求定义和软件需求评审四个过程，也可以根据具体情
况对该过程进行裁减。
需求开发的结果文档包括用户需求类文档、软件需求类文档、
有时为了满足软件产品前期设计的需要，也会制作形成业务模型、
数据字典、系统开发原型（Demo）文档等。
所有的需求文档经过用户和开发方双方评审认可并签字后，形
成项目的需求基线。
 需求管理过程
需求管理是在需求文档基线化后，对需求实现的跟踪以及当需
求发生变更时，对需求变更进行控制和管理的过程。
需求管理包括变更控制、版本控制、需求跟踪过程。需求管理
同时包括变更的需求及相关需求之间的关系管理。

2.4.1 需求开发过程

第 7 页/共 1 页
 需求开发和管理过程

2.4.1.1 用户需求调研

在项目正式立项后，项目经理组建需求开发团队，需求开发人员根据初步
《项目计划》、客户原始需求文档（包括：市场人员从客户那里得到的初步需
求文档，投标文件中定义的技术方案内容等），确定需求调研时间及需求获取
相关干系人，并将此活动更新到《干系人计划》中，同时制定出《需求调研计
划》。在识别需求获取干系人时，需求开发人员需考虑以下几准则：
 相关干系人要具备足够的业务经验。
 相关干系人要具有较强的表达能力。
 相关干系人至少具备初级的计算机水平。
在需求开发人员开始进行用户需求调研之前，要进行充分的事前准备。需
要准备的工作包括：
 需求开发人员要提前了解该行业的标准、相关文件、公司规章制度
等。
 需求开发人员从组织资产库中寻找类似项目的需求资料，对相关需
求资料有一个深入了解，以便迅速了解可以重用的业务需求内容，
为与客户深入、专业的需求沟通打下基础。
 需求开发人员确定需求调研方式，具体方式包括：客户主动提供的

第 8 页/共 1 页
 需求开发和管理过程

需求说明文档，与用户面谈或电话访谈或会议访谈、参观用户的工
作流程、向用户群体发调查问卷、与同行专家交谈、分析已经存在
的同类软件产品等。
 需求开发人员根据选定的调研方式，准备好《用户需求调查单》。
需求开发人员根据《需求调研计划》开展调研工作。调研工作需要需求开
发人员和用户协同完成。调研中需求调研人员要随时做好记录，事后填写好
《用户需求调查单》，作为原始用户需求，有进行组织会议访谈的要填写《需
求访谈会议纪要》。
需求开发人员根据需求调研的访谈成果，对用户的原始需求进行分析整理，
提取需求的精华，对用户需求进行归纳总结，把相同的需求进行归类，把文档
尽可能的用用户容易理解的语言撰写（包括：用例图 /用例简述/用例规约描述

等）。按照归纳总结的用户需求点，需求开发人员编写《用户需求说明书》。
《用户需求说明书》的主要内容包括：
 需求产生的背景
 需求目标要求
 需求内容范围
 用户角色
 功能性需求的描述
 限制条件
 非功能性要求等。
《用户需求调查单》、《用户需求说明书》编写完成后，需要得到用户和
开发方双方的共同确认，确认的方式开始是正式的、也可以是非正式的。一般
通过内/外部评审会议、用户签字或非正式的其他方式（如确认邮件等）确认即

可。
用户需求确认后，需求开发人员创建《需求跟踪矩阵》，并将用户需求项
填入《需求跟踪矩阵》中。

用户需求调研活动可参考《需求调研指南》。

第 9 页/共 1 页
 需求开发和管理过程

2.4.1.2 用户需求分析

用户需求分析的目的是为了明确用户需求的具体细节以及软件产品实现的
可行性，把用户需求合理的转化成软件产品需求。用户需求分析的主要内容包
括：
 分析用户需求的实现可行性
在允许的成本、性能要求下，需求开发人员要分析每项用户需求进行软
件产品实现的可行性，同时明确与每项需求实现相联系的风险，包括与
其它需求的冲突，对外界因素的依赖和技术障碍等。
 确定需求的优先级别
应用需求分析方法来确定系统特性或单项需求实现的优先级别。以优先
级为基础确定软件产品将包括哪些特性或哪类需求。
 建立业务模型（可选）
有时为了满足软件产品前期设计的需要，或者需求开发人员对比较
复杂的用户需求难以理解时，一般对需求进行建模分析，以帮助软件开
发人员更好地理解需求。
根据用户需求分析得到的需求描述，借助于需求分析工具建立相应
的业务模型。根据项目的实际情况，选择不同的建模方法。如：采用结
构化的需求分析方法或采用面向对象的需求分析方法，通过 UML 方法

来进行创建业务模型。
建议使用 Rational Rose、MS Visio 等建模工具进行需求的建模分析，

通过分析系统的功能模型、结构模型和行为模型，进行系统建模。建模
的过程包括系统功能建模、系统数据建模和体系结构建模，在需求开发
阶段应至少完成功能建模。功能建模的方式包括静态建模和动态建模。
静态建模要求画出用例图、主要的类图和对象图，动态建模要求画出主
要的状态图、时序图、协作图和活动图等。另外在用例图中，需标明每
个用例的业务描述、业务数据、业务流程、入口条件、输出结果、异常
处理等要素。
 建立数据字典（可选）

第 10 页/共 1 页
 需求开发和管理过程

数据字典是用户需求中的各类实体（业务对象、数据对象、业务流程对
象等）的专业化名称解释，它能够保证用户和开发方对需求沟通、理
解的一致性，同时也是后续进行数据库对象设计的最重要依据之一。

2.4.1.3 产品需求定义

首先，需求开发人员进行产品需求定义，把用户需求向软件需求转化前，
要确认《用户需求说明书》已经通过了用户确认。
由需求开发人员根据《用户需求说明书》，对用户需求进行更加详细的专
业化定义，形成用户需求到软件需求的映射。完成《产品需求规格说明书》的
编写。
当需求开发人员或用户不能确定需求时，可以考虑实现一个系统开发原型
（DEMO），这样使得许多概念和可能发生的事更为直观明了。用户通过评价

原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档
与原型之间所有的冲突之处。
系统如果建立原型，则需向用户演示原型，或请用户试用原型系统，记录
使用中的问题并修订原型直至客户满意。原型的格式和内容由项目经理、美工
以及客户协商自定。
※由于《用户需求说明书》与《产品需求规格说明书》在内容上存在很多
的共同之处，有时为了项目的具体需要，两个文档可以考虑合并成一个文档。
但合并成一个文档时需注意：
 要明确用户需求和产品需求之间的对应关系，建立起用户需求和产
品需求之间的映射表（通过映射表可以建立起用户需求和产品需求
之间的需求跟踪矩阵）；
 用户需求和产品需求之间的对应关系，特别是软件产品无法实现的
用户需求内容，要在合并文档中明确记录，并向用户详细说明情况
取得双方的沟通一致；
 合并的文档内容要用用户易于理解的语言进行表述，切勿使用软件
专业性强而用户无法理解或理解有歧义的语言，一般考虑使用用例
图/用例规约的方式。

第 11 页/共 1 页
 需求开发和管理过程

 合并的文档不仅仅给用户看，还要满足软件产品后续设计的需要，
所以内容的描述尽可能正确、完整、易于理解、无歧义。

2.4.1.4 产品需求评审

产品需求评审的目的是为了确保用户和开发方双方对需求的理解一致，消
除歧义，并取得双方之间的共同认可。评审时由项目经理邀请客户、相关干系
人参加，要对《产品需求规格说明书》中的内容逐条逐项进行验证，如果发现
存在问题，则由需求开发人员继续调研，加以修改，直至评审通过。
软件需求评审要注意如下几点：
 明确说明用户需求和软件产品需求之间的映射关系，对软件产品不
能实现或暂时无法实现的用户需求，需求开发人员要向用户详细说
明原因，取得用户的认可。
 可以通过演示系统原型（Demo）方式，直观形象的向用户进行软
件产品需求的演示，取得用户的认可。
 软件需求确认不同于用户需求的确认，用户需求的确认可以是非正
式（如邮件确认），软件产品需求确认必须是正式的，《产品需求
规格说明书》必须得到用户的书面确认。产品需求确认后，形成正
式的软件产品需求基线，作为后续需求变更控制的基础。

2.4.2 需求管理过程

需求管理过程包括：需求的变更控制、需求的实现跟踪两个方面。 软件需
求包括 3 个不同的层次――业务需求、用户需求和功能需求。除此之外，每个
系统还有各种非功能需求。需求的分类是软件需求阶段必不可少的工作，它可
以指导开发人员理解不同的行业的业务、了解用户的真实需求，清楚这些之后
确立好功能项；当开发人员对整体需求有了明确的目标后，就可以按部就班快
速有效地进行功能项开发，一般就不会背离系统开发需求的初衷。
1、业务需求

第 12 页/共 1 页
 需求开发和管理过程

业务需求（Business requirement）表示组织或客户高层次的目标。业务
需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部
门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望
达到的目标。使用前景和范围（ vision and scope ）文档来记录业务需求，
这份文档有时也被称作项目轮廓图或市场需求（ project charter 或 market
requirement ）文档。
2、用户需求
用户需求（user requirement）描述的是用户的目标，或用户要求系统必
须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效
途径。也就是说用户需求描述了用户能使用系统来做些什么。
3、功能需求
功能需求（functional requirement）规定开发人员必须在产品中实现的
软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被
称作行为需求（ behavioral requirement ），因为习惯上总是用“应该”对
其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求
描述是开发人员需要实现什么。
4、非功能性需求
  4-1、系统需求（system requirement）用于描述包含多个子系统的产
品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包
含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承
担。
  4-2、业务规则包括企业方针、政府条例、工业标准、会计准则和计算
方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范
围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符
合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能
实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正
是一条特定的业务规则。
  4-3、功能需求记录在软件需求规格说明（ SRS ）中。 SRS 完整地描
述了软件系统的预期特性。 SRS 我们一般把它当作文档，其实， SRS 还可以
是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信

第 13 页/共 1 页
 需求开发和管理过程

息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项
目管理和其他相关的项目功能都要用到 SRS 。除了功能需求外， SRS 中还包
含非功能需求，包括性能指标和对质量属性的描述。
  4-4、质量属性（quality attribute）对产品的功能描述作了补充，它
从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、
效率和健壮性，它们对用户或开发人员都很重要。其他的非功能需求包括系统
与外部世界的外部界面，以及对设计与实现的约束。
  4-5、约束（constraint）限制了开发人员设计和构建系统时的选择范
围，如局限于软件工程学科。
注：分清楚那些是业务需求、哪些是用户需求、哪些是功能性需求和非功
能性需求对软件的开发有着重大的指导意义，绝不可以以偏概全，错误地去揣
摩用户的心思；对于开发者而言，所有软件功能的开发我们都应该一一征求用
户的意见，对需求有了清晰的认识后再进行实质性的开发工作。

第 14 页/共 1 页
 需求开发和管理过程

2.4.2.1 需求变更控制

1、 需求变更申请
对于一、二级变更，变更申请人必须填写《需求变更申请单》，提交项
目经理。三级变更可以不填写《需求变更申请单》，直接告知项目经理
即可；
2、 变更评估
项目经理对变更申请进行变更影响分析、评估，确定是否变更、变更影
响范围及变更时机。
3、 变更决策
对于三级变更，项目经理直接审批是否变更及变更时机，并进行后续的

第 15 页/共 1 页
 需求开发和管理过程

变更实施处理；
对于一、二级变更，需要提交 CCB（软件配置控制委员会）、高层经理
审批是否变更及变更时机。
 如果允许变更，项目经理安排变更任务，必要时制定详细的变更计
划。变更内容主要有：
 更新受影响的《项目计划》、《项目进度表》等管理文档；
 更新受影响的各类技术文档（需求、设计、开发、测试文档
等）；
 更新项目配置库；
 如果不允许变更，则直接跳转到“6、变更沟通存档”步骤。
4、 变更实施
变更责任人根据变更任务实施变更。
项目经理或 CCB 进行变更后的审批及发布，通知受影响的组或个人。对

于影响较小的变更可以暂时不更新基线，对于影响较大的变更（需更新
基线时），由相关责任人提交《基线创建申请单》，审批通过后建立新
的基线。
5、 变更验证
项目经理对变更进行跟踪验证、直到变更结果和预期相符，相关内容进
行了更新，工作产物符合版本管理要求为止。
QA 监督变更过程活动，如有协商不一致的问题，则记录到《不一致项问
题跟踪表》中，并提交给高层。
6、 变更沟通存档
将变更后的内容通知可能会受到影响的人员，并将变更记录汇总归档，
如提出的变更在变更决策时被否决，其初始记录也应与保存。

需求变更按照严重程度，分为一、二、三级变更：
 一级变更
是指该变更会导致工作量延迟超出整个工程过程阶段计划总工作量的
10%（或超过 10 个工作日）的变更，对项目的进度、成本、质量等关
键要素造成严重影响，需要重新定义需求工作，大量开发代码需要重

第 16 页/共 1 页
 需求开发和管理过程

新编写。
 二级变更
是指该变更会导致工作量延迟整个工程过程阶段计划总工作量的 5～
10%（或超过 5 个工作日，小于 10 个工作日）的变更，对项目的进度、
成本、质量等关键要素未造成重大影响。
 三级变更
是指该变更会导致工作量延迟小于整个工程过程阶段计划总工作量的
5%（或小于 5 个工作日）的变更，几乎不会对项目的进度、成本、质
量等关键要素造成较大影响。
三种级别的需求的变更均可以由项目经理、需求开发人员或者相关用户提
出，需求变更提出后，交予项目经理确认，由项目经理分析变更影响，初步确
定变更级别。
确认为一、二级的需求变更，经项目经理提交 CCB。如果 CCB 同意了该变

更申请，则由项目经理组织项目组成员和需求开发人员进行需求变更工作，即
重新进行需求开发、需求确认，更新《用户需求说明书》和《产品需求规格说
明书》，填写《需求变更记录表》，需求开发人员及时更新《需求跟踪矩阵》。
如果变更申请被拒绝，CCB 则需要在变更申请中说明理由，项目则继续按原计

划进行。
确认为三级的需求变更，需求的变更人无需填写《需求变更申请书》，经
项目经理确认后将变更项填入《需求变更记录表》中即可，然后直接进行后续
的变更操作，无需再交由 CCB 进行评审。但当三级变更数量达到 20 条以上范围

时，或累积产生的影响达到一、二级变更的影响时，应当引起项目经理高度注
意，查找问题所在，并提交用户确认。
所有的一、二级变更项，须得到用户的确认签字，三级的需求变更定期告
知用户即可，无须用户的正式确认签字；但当三级变更累积产生的影响达到一、
二级变更的影响时，则需要提请用户予以确认签字。
所有的一、二级变更项经过处理后，需要变更需求相关文档的版本号，从
VX.Y 版本变更到 VX.(Y+1)版本，超出整个工程过程阶段计划总工作量的 20%或成
本超出整个工程过程阶段计划总成本的 20%以上的一级变更，从 VX.Y 版本直接
变更到 V(X+1).0 版本。

第 17 页/共 1 页
 需求开发和管理过程

2.4.2.2 需求跟踪

当《用户需求说明书》编写完成，经过需求评审、用户签字后，需求开发
人员创建需求跟踪矩阵，需要填写具体用户需求编号，需求类别，当前状态等。
需求跟踪矩阵创建完成后，需求开发人员需要在以下时机成熟时更新该矩
阵：
 每周例会时：
需求开发人员在每周例会上根据本周完成的需求或与此需求相关的
工作产品完成情况更新《需求跟踪矩阵》。
 软件需求评审通过时：
《产品需求规格说明书》及其附件内容（业务模型、数据字典、系
统 Demo 等）评审通过并且用户确认签字后，需求开发人员更新
《需求跟踪矩阵》。
 项目里程碑时：
在项目进入里程碑阶段（需求结束、系统测试结束等）时，也要及
时进行更新。需求开发人员更改所有相关需求文档，以及相应的工
作产品，使得每一个软件的需求均能够与后续工作成果保持一致。
 需求变更时：
当需求发生变更时，项目变更或者需求开发人员发现需求与项目实
施过程存在不符合项时，也要及时更新《需求跟踪矩阵》。

2.5 输出

 《用户需求调研记录》及《用户需求调查单》
 《用户需求说明书》
 《产品需求规格说明书》
 系统开发原型 Demo、业务模型、数据字典等
 《需求评审报告》
 《需求跟踪矩阵》
 《需求变更申请单》

第 18 页/共 1 页
 需求开发和管理过程

 《需求变更记录》

2.6 出口准则

项目结项。

2.7 过程度量

№ 度量点 执行人 度量时机|频率 存储位置

M-1 需求变更数 需求开发人员 每周 《需求跟踪矩阵》

M-2 需求变更工作量 需求开发人员 每周 《需求跟踪矩阵》

2.8 裁剪说明

裁剪对象 类型（过程活动或工作产品） 裁减要素（增 裁减条件

加、删除、修

改）

产品 业务模型、数据字典 删除 用户需求易于理解时

产品 系统开发原型（Demo） 删除 用户需求易于理解时

3. 相关指南

 《需求调研指南》
 《用例指南》

第 19 页/共 1 页