1. 前言

1.1 意图和价值

意图： 明确需求，确保利益相关者的共同理解，并调整需求、计划和工作产品。

价值： 确保客户的需求和期望得到满足。

1.2 适用范围

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

1.3 名词术语

² 用户需求

是用户对要建立的系统的要求描述，它主要说明用户“要做什么”、“想做什么”的问题。

² 软件需求

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

2. 过程定义

2.1 角色和职责

2.2 入口准则

² 需求开发人员已经确定；

² 初步的《项目计划》已经通过评审。

2.3 输入

² 初步的《项目计划》；

² 《项目合同》；

² 《技术解决方案》；

² 客户原始需求文档。

2.4 过程活动

需求阶段包括需求开发和需求管理两个过程活动。

² 需求开发过程

需求开发过程是获取用户需求并对用户需求进行分析整理形成软件需求的过程。需求开发过程可以包括用户需求调研、用户需求分析、软件需求定义和软件需求评审四个过程，也可以根据具体情况对该过程进行裁减。

需求开发的结果文档包括用户需求类文档、软件需求类文档、有时为了满足软件产品前期设计的需要，也会制作形成业务模型、数据字典、系统开发原型（Demo）文档等。

所有的需求文档经过用户和开发方双方评审认可并签字后，形成项目的需求基线。

² 需求管理过程

需求管理是在需求文档基线化后，对需求实现的跟踪以及当需求发生变更时，对需求变更进行控制和管理的过程。

需求管理包括变更控制、版本控制、需求跟踪过程。需求管理同时包括变更的需求及相关需求之间的关系管理。

2.4.1 需求开发过程

需求开发过程

2.4.1.1 用户需求调研

在项目正式立项后，项目经理组建需求开发团队，需求开发人员根据初步《项目计划》、客户原始需求文档（包括：市场人员从客户那里得到的初步需求文档，投标文件中定义的技术方案内容等），确定需求调研时间及需求获取相关干系人，并将此活动更新到《干系人计划》中，同时制定出《需求调研计划》。在识别需求获取干系人时，需求开发人员需考虑以下几准则：

l 相关干系人要具备足够的业务经验。

l 相关干系人要具有较强的表达能力。

l 相关干系人至少具备初级的计算机水平。

在需求开发人员开始进行用户需求调研之前，要进行充分的事前准备。需要准备的工作包括：

l 需求开发人员要提前了解该行业的标准、相关文件、公司规章制度等。

l 需求开发人员从组织资产库中寻找类似项目的需求资料，对相关需求资料有一个深入了解，以便迅速了解可以重用的业务需求内容，为与客户深入、专业的需求沟通打下基础。

l 需求开发人员确定需求调研方式，具体方式包括：客户主动提供的需求说明文档，与用户面谈或电话访谈或会议访谈、参观用户的工作流程、向用户群体发调查问卷、与同行专家交谈、分析已经存在的同类软件产品等。

l 需求开发人员根据选定的调研方式，准备好《用户需求调查单》。

需求开发人员根据《需求调研计划》开展调研工作。调研工作需要需求开发人员和用户协同完成。调研中需求调研人员要随时做好记录，事后填写好《用户需求调查单》，作为原始用户需求，有进行组织会议访谈的要填写《需求访谈会议纪要》。

需求开发人员根据需求调研的访谈成果，对用户的原始需求进行分析整理，提取需求的精华，对用户需求进行归纳总结，把相同的需求进行归类，把文档尽可能的用用户容易理解的语言撰写（包括：用例图/用例简述/用例规约描述等）。按照归纳总结的用户需求点，需求开发人员编写《用户需求说明书》。

《用户需求说明书》的主要内容包括：

² 需求产生的背景

² 需求目标要求

² 需求内容范围

² 用户角色

² 功能性需求的描述

² 限制条件

² 非功能性要求等。

《用户需求调查单》、《用户需求说明书》编写完成后，需要得到用户和开发方双方的共同确认，确认的方式开始是正式的、也可以是非正式的。一般通过内/外部评审会议、用户签字或非正式的其他方式（如确认邮件等）确认即可。

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

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

2.4.1.2 用户需求分析

用户需求分析的目的是为了明确用户需求的具体细节以及软件产品实现的可行性，把用户需求合理的转化成软件产品需求。用户需求分析的主要内容包括：

² 分析用户需求的实现可行性

在允许的成本、性能要求下，需求开发人员要分析每项用户需求进行软件产品实现的可行性，同时明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍等。

² 确定需求的优先级别

应用需求分析方法来确定系统特性或单项需求实现的优先级别。以优先级为基础确定软件产品将包括哪些特性或哪类需求。

² 建立业务模型（可选）

有时为了满足软件产品前期设计的需要，或者需求开发人员对比较复杂的用户需求难以理解时，一般对需求进行建模分析，以帮助软件开发人员更好地理解需求。

根据用户需求分析得到的需求描述，借助于需求分析工具建立相应的业务模型。根据项目的实际情况，选择不同的建模方法。如：采用结构化的需求分析方法或采用面向对象的需求分析方法，通过UML方法来进行创建业务模型。

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

² 建立数据字典（可选）

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

2.4.1.3 产品需求定义

首先，需求开发人员进行产品需求定义，把用户需求向软件需求转化前，要确认《用户需求说明书》已经通过了用户确认。

由需求开发人员根据《用户需求说明书》，对用户需求进行更加详细的专业化定义，形成用户需求到软件需求的映射。完成《产品需求规格说明书》的编写。

当需求开发人员或用户不能确定需求时，可以考虑实现一个系统开发原型（DEMO），这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的冲突之处。

系统如果建立原型，则需向用户演示原型，或请用户试用原型系统，记录使用中的问题并修订原型直至客户满意。原型的格式和内容由项目经理、美工以及客户协商自定。

※由于《用户需求说明书》与《产品需求规格说明书》在内容上存在很多的共同之处，有时为了项目的具体需要，两个文档可以考虑合并成一个文档。但合并成一个文档时需注意：

² 要明确用户需求和产品需求之间的对应关系，建立起用户需求和产品需求之间的映射表（通过映射表可以建立起用户需求和产品需求之间的需求跟踪矩阵）；

² 用户需求和产品需求之间的对应关系，特别是软件产品无法实现的用户需求内容，要在合并文档中明确记录，并向用户详细说明情况，取得双方的沟通一致；

² 合并的文档内容要用用户易于理解的语言进行表述，切勿使用软件专业性强而用户无法理解或理解有歧义的语言，一般考虑使用用例图/用例规约的方式。

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

2.4.1.4 产品需求评审

产品需求评审的目的是为了确保用户和开发方双方对需求的理解一致，消除歧义，并取得双方之间的共同认可。评审时由项目经理邀请客户、相关干系人参加，要对《产品需求规格说明书》中的内容逐条逐项进行验证，如果发现存在问题，则由需求开发人员继续调研，加以修改，直至评审通过。

软件需求评审要注意如下几点：

² 明确说明用户需求和软件产品需求之间的映射关系，对软件产品不能实现或暂时无法实现的用户需求，需求开发人员要向用户详细说明原因，取得用户的认可。

² 可以通过演示系统原型（Demo）方式，直观形象的向用户进行软件产品需求的演示，取得用户的认可。

² 软件需求确认不同于用户需求的确认，用户需求的确认可以是非正式（如邮件确认），软件产品需求确认必须是正式的，《产品需求规格说明书》必须得到用户的书面确认。产品需求确认后，形成正式的软件产品需求基线，作为后续需求变更控制的基础。

2.4.2 需求管理过程

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

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 还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS 。除了功能需求外， SRS 中还包含非功能需求，包括性能指标和对质量属性的描述。

4-4、质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。

4-5、约束（constraint）限制了开发人员设计和构建系统时的选择范围，如局限于软件工程学科。

注：分清楚那些是业务需求、哪些是用户需求、哪些是功能性需求和非功能性需求对软件的开发有着重大的指导意义，绝不可以以偏概全，错误地去揣摩用户的心思；对于开发者而言，所有软件功能的开发我们都应该一一征求用户的意见，对需求有了清晰的认识后再进行实质性的开发工作。

2.4.2.1 需求变更控制

1、 需求变更申请

对于一、二级变更，变更申请人必须填写《需求变更申请单》，提交项目经理。三级变更可以不填写《需求变更申请单》，直接告知项目经理即可；

2、 变更评估

项目经理对变更申请进行变更影响分析、评估，确定是否变更、变更影响范围及变更时机。

3、 变更决策

对于三级变更，项目经理直接审批是否变更及变更时机，并进行后续的变更实施处理；

对于一、二级变更，需要提交CCB（软件配置控制委员会）、高层经理审批是否变更及变更时机。

l 如果允许变更，项目经理安排变更任务，必要时制定详细的变更计划。变更内容主要有：

² 更新受影响的《项目计划》、《项目进度表》等管理文档；

² 更新受影响的各类技术文档（需求、设计、开发、测试文档等）；

² 更新项目配置库；

l 如果不允许变更，则直接跳转到“6、变更沟通存档”步骤。

4、 变更实施

变更责任人根据变更任务实施变更。

项目经理或CCB进行变更后的审批及发布，通知受影响的组或个人。对于影响较小的变更可以暂时不更新基线，对于影响较大的变更（需更新基线时），由相关责任人提交《基线创建申请单》，审批通过后建立新的基线。

5、 变更验证

项目经理对变更进行跟踪验证、直到变更结果和预期相符，相关内容进行了更新，工作产物符合版本管理要求为止。

QA监督变更过程活动，如有协商不一致的问题，则记录到《不一致项问题跟踪表》中，并提交给高层。

6、 变更沟通存档

将变更后的内容通知可能会受到影响的人员，并将变更记录汇总归档，如提出的变更在变更决策时被否决，其初始记录也应与保存。

需求变更按照严重程度，分为一、二、三级变更：

² 一级变更

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

² 二级变更

是指该变更会导致工作量延迟整个工程过程阶段计划总工作量的5～10%（或超过5个工作日，小于10个工作日）的变更，对项目的进度、成本、质量等关键要素未造成重大影响。

² 三级变更

是指该变更会导致工作量延迟小于整个工程过程阶段计划总工作量的5%（或小于5个工作日）的变更，几乎不会对项目的进度、成本、质量等关键要素造成较大影响。

三种级别的需求的变更均可以由项目经理、需求开发人员或者相关用户提出，需求变更提出后，交予项目经理确认，由项目经理分析变更影响，初步确定变更级别。

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

确认为三级的需求变更，需求的变更人无需填写《需求变更申请书》，经项目经理确认后将变更项填入《需求变更记录表》中即可，然后直接进行后续的变更操作，无需再交由CCB进行评审。但当三级变更数量达到20条以上范围时，或累积产生的影响达到一、二级变更的影响时，应当引起项目经理高度注意，查找问题所在，并提交用户确认。

所有的一、二级变更项，须得到用户的确认签字，三级的需求变更定期告知用户即可，无须用户的正式确认签字；但当三级变更累积产生的影响达到一、二级变更的影响时，则需要提请用户予以确认签字。

所有的一、二级变更项经过处理后，需要变更需求相关文档的版本号，从VX.Y版本变更到VX.(Y+1)版本，超出整个工程过程阶段计划总工作量的20%或成本超出整个工程过程阶段计划总成本的20%以上的一级变更，从VX.Y版本直接变更到V(X+1).0版本。

2.4.2.2 需求跟踪

当《用户需求说明书》编写完成，经过需求评审、用户签字后，需求开发人员创建需求跟踪矩阵，需要填写具体用户需求编号，需求类别，当前状态等。

需求跟踪矩阵创建完成后，需求开发人员需要在以下时机成熟时更新该矩阵：

l 每周例会时：

需求开发人员在每周例会上根据本周完成的需求或与此需求相关的工作产品完成情况更新《需求跟踪矩阵》。

l 软件需求评审通过时：

《产品需求规格说明书》及其附件内容（业务模型、数据字典、系统Demo等）评审通过并且用户确认签字后，需求开发人员更新《需求跟踪矩阵》。

l 项目里程碑时：

在项目进入里程碑阶段（需求结束、系统测试结束等）时，也要及时进行更新。需求开发人员更改所有相关需求文档，以及相应的工作产品，使得每一个软件的需求均能够与后续工作成果保持一致。

l 需求变更时：

当需求发生变更时，项目变更或者需求开发人员发现需求与项目实施过程存在不符合项时，也要及时更新《需求跟踪矩阵》。

2.5 输出

² 《用户需求调研记录》及《用户需求调查单》

² 《用户需求说明书》

² 《产品需求规格说明书》

² 系统开发原型Demo、业务模型、数据字典等

² 《需求评审报告》

² 《需求跟踪矩阵》

² 《需求变更申请单》

² 《需求变更记录》

2.6 出口准则

项目结项。

2.7 过程度量

2.8 裁剪说明

3. 相关指南

² 《需求调研指南》

² 《用例指南》