1. 前言

1.1 意图和价值

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

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

1.2 适用范围

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

1.3 名词术语

◆ 用户需求

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

◆ 软件需求

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

2. 过程定义

2.1 角色和职责

2.2 入口准则

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

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

2.3 输入

◆ 初步的《项目计划》；

◆《项目合同》；

◆《技术解决方案》；

◆ 客户原始需求文档。

2.4 过程活动

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

◆ 需求开发过程

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

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

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

◆ 需求管理过程

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

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

2.4.1 需求开发过程

2.4.1.1 用户需求调研

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

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

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

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

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

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

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

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

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

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

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

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

◆需求产生的背景

◆需求目标要求

◆需求内容范围

◆用户角色

◆功能性需求的描述

◆限制条件

◆非功能性要求等。

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

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

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

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（软件配置控制委员会）、高层经理审批是否变更及变更时机。

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

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

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

◆更新项目配置库；

如果不允许变更，则直接跳转到“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 需求跟踪

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

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

每周例会时：

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

软件需求评审通过时：

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

项目里程碑时：

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

需求变更时：

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

2.5 输出

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

《用户需求说明书》

《产品需求规格说明书》

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

《需求评审报告》

《需求跟踪矩阵》

《需求变更申请单》

《需求变更记录》

2.6 出口准则

项目结项。

2.7 过程度量

2.8 裁剪说明

3. 相关指南

《需求调研指南》

《用例指南》

附录一：《需求调研指南》

1. 引言

在需求调研中最常见的技术就是：

1、用户访谈

2、问卷表

3、小组会议

上述的各种技术在特定场合都能很好发挥作用，应该好好的考虑在何时使用哪项技术。在大多数项目中，调研需求不可能只采用某个技术。实际情况中，项目组会根据不同的用户情况采用不同的方法。

2. 用户访谈

用户访谈一般在下列情况使用

◆需要与少数几个人，进行大量的知识交流

◆需求开发团队能够与他们集中进行面对面会谈

◆无法一次性集中收集所有涉众的用户需求

用户访谈一般会经历五个阶段

◆访谈前准备

◆计划和安排访谈日程

◆访谈开始和结束

◆引导访谈

◆后继的访谈整理工作

2.1 准备访谈

在进行访谈前，需求分析者应该很好的理解组织结构，行业定位和项目范围和项目目标，访谈会涉及下面内容：

◆组织机构情况（组织机构、组织业务、发展目标、未来规划）

◆部门目标的陈述

◆已有业务业务系统、程序手册

◆已有系统的各类业务文档

◆要建设系统的需求目标、需求范围、

需求分析者应该理解一般的行业术语（术语表）并且还要熟悉行业上的业务问题。

2.2 计划访谈日程

准备列表，列出主要话题或问题。这些问题可以找出未意识到的重点，还能有逻辑的引导访谈进行。安排访谈应遵循自上而下的进行。首先访谈组织、部门或地区的领导，然后才是他们下属的雇员。在邀请对方进行会谈时，要解释这次会谈的目的，一般会涉及哪些领域、哪些角色人员、以及大致需要的时间。

2.3 访谈开始和结束

开始访谈时，先介绍你自己，陈述这次访谈的目的，谈谈被访谈者关心的事，并说明有一些简短的会谈记要，在整理后会交给对方审阅。一般被访谈者认为需求开发者试图找到他们工作中的缺陷。使他们摆脱这种观点。可以讨论他们所熟悉的日常工作的过程。好的访谈者会让被访谈者作为主讲人。因此，需求开发人员应该寻找一些问题让被访谈者对他们开诚布公：

例如：

“怎样的变化将使你的工作更简单或更有效？”这个问题暗示被访谈者提出改进意见；

当列表中的所有领域都讨论过后，提出下面问题：

“还有什么问题我们没有讨论吗？”或是 “我们还需要讨论些别的内容吗？” 这些问题鼓励被访谈者提出所有应该被讨论的问题。

在访谈的内容组织上，要至上而下、分层次进行内容的交流讨论。比如：先访谈用户需求的背景、目标、范围，然后从目标、范围中层层展开具体的需求项，再逐项讨论需求项的细节业务流程、操作人员、前后置条件等内容。

结束会谈时，一般会简短的总结讨论过的问题，重点指出会谈的要点，并说出你的理解。这使被访谈者知道你认真倾听了谈话，而且有机会澄清误解。在总结会谈以及整个会谈中，需求分析者应采取客观的态度，避免带个人色彩的评论，观察或结论。最后，你必须感谢被访谈者参加这次访谈。如有必要，询问被访谈者能否在近期再参加一次简短的后继访谈活动。

2.4 引导访谈

在访谈中避免提封闭性的问题，因为被访谈者通常会简短的回答完这样的问题，然后等待下一个问题。这样就像是侦探在审问犯人。封闭性的问题：（谁，哪里，什么时间，哪一个）：

◆限制了被访谈者提供信息的类型，层次和数量。

◆通常提供了二选一的回答，暗示了较极端或不确定性的回答。

◆一般用于澄清问题，探索性提问或仅是希望得到反馈信息

◆花费较少的时间得到细节信息

◆比较容易做笔记

◆有时只能得到很少的信息

◆可能导致被访谈者无法自由提供信息

◆对相关术语和词汇的要求高

在开始一个议题时，一般会用开放性的问题，便于被访谈者展开思路。然后，渐渐转为结论性问题，这样能帮助证实你的理解。太多的关闭性问题会导致收集的信息不完整，太多的开放性问题可能导致需求分析者的理解失误。

为了会谈后的整理需要，一般会使用简明的符号来做笔记，否则做笔记会使你分心。最好将笔记本放在被访谈者视线外。需求开发者的笔记有助于会谈后回顾要点和会谈时形成的想法。最好是会谈时指定一个记录员。使用录音机也是个好主意。虽然会谈后整理信息会耗费些时间，因为需求开发人员需要听完整个记录。不特别推荐使用录音机，这会使被访谈者有被胁迫的感觉；而且倾听录音，记录其中要点也是耗时较多的工作。无论如何，音频视频记录有优点也有缺点。认真倾听有助维持需求分析者和被访谈人之间的信息交流，维持相互之间适当的反馈。

认真倾听有五个关键方法：

1. 询问开放性的问题

开放性问题无法简单的用事或否来回答，应此被访谈者就会提供更多的信息。开放性问题一般会使用这些词语做开头，如什么，怎么样或是告诉我。而不会使用诸如能够，要作或是何时这样的词语。列举一个需要详尽解释的问题，“告诉我，当顾客打进电话时，什么情况发生？”

开放性问题：（什么，为什么，多么）

◆涉及比较宽广，加在被访谈者上的约束很少

◆用来确定理解范围。被访谈者会使用明确的回答或是模拟演示来传达需求开发人员不了解的内容

◆可以得到被访谈者的行业词汇，概念和可参考的知识框架

◆有助于增强理解，得到一些潜在的理论

2. 使用适当的表达

避免使用有感情倾向，让人分心或是难以理解的语言。类似于问题存在于，讨厌的处理过程或是无法控制这样的有感情倾向的语言容易暗示某种结论。避免使用让人分心语言。这些语言包括过多的缩写词或首字母缩写，显示自己才识的语言，有争议性语言，俗语，俚语以及行话。

3. 暗示相信被访谈者

人类会使用说话的语气，眼神接触，面部表情，身体姿势和身体的移动来传达某种信息。正确使用，会使被访谈者提供更多的信息。例如，在访谈中避免眼睛接触会被理解为缺乏兴趣，或是对其他人更感兴趣。适当的眼神接触会传达出感兴趣，关注，开放的接受并且尊重别人的见解。 太频繁的眼神接触会被误解为盯着对方。在我们的文化中，如果两个陌生人间眼神接触时间过长则意味着挑战。在其他的一些文化中，会被认为是侵犯隐私。点头表示理解，暗示接受；类似的，表示关注的姿势：端正坐着略向前倾。

缺少经验的需求开发人员通常会犯下面的错误：

i. 靠在椅子后背上，双手合拢抱在胸前。这种姿势暗示了不太接受正在讲述的内容，也显示出需求开发人员处于不安的状态。

ii. 看着屋内的物品或是直盯着窗户，而不是看着被访谈人。这表明需求开发人员更宁愿在其他的地方做其他事，被放谈者通常会缩短访谈的过程。

iii. 忙于做笔记或是经常翻阅笔记。较之倾听而言，需求开发人员对自己的记录更感兴趣会使被访谈者好奇，到底他记录了什么。

iv. 坐得太远或太近。坐得太远像是暗示被访谈者会威胁到需求开发人员，坐得太近又显得不恰当地亲密，被访谈者会感觉不自在。

4. 重述被访谈者的回答

重述回答是指需求开发人员用自己的语言复述被访谈者的陈述。这显示了两者间进行了有效地沟通，需求开发人员理解了被访谈者的陈述，重述回答一般用在以下场合：

◆访谈者描述一个问题时。这时，需求开发人员的复述表明听见并理解了访谈者的问题。

◆当需求开发人员想检查他的理解是否正确时。这个技巧大多是遇到复杂的陈述时，或是多人参与时，每个人对同一问题有各自不同的见解。

◆需求开发人员希望鼓励访谈者时。重述回答会暗示被访谈者扩展或是详细说明他曾说过的内容。

重述回答也能克制住因某种原因，不愿配合的人。

需求开发人员必须保持中立。例如，如果被访谈者批评现有管理模式，需求开发人员不应该赞同他的批评或是为现有管理模式辩护。需求开发人员只需要表达出被访谈者的感觉是可理解的。

重述问题常见的错误：

◆重复被访谈者的话，例如，完全重复被访谈者的话而不是使用其他的表达方式。一段话讲完后被完全重复一遍，会使被访谈者感觉不安。

◆过多重述回答将使被访谈者分心。

◆改变或是歪曲被访谈者真实的意愿。重述应该尽可能的接近被访谈者的意思。

◆在复述结束时提高声音。这个习惯会使复述变成一个问题，会暗示被访谈者回答是或否，而不是让被访谈者扩展他的解释。

这儿有个例子显示了有效的及无效的复述；

被访谈者的回答：顾客没有支付帐单，我们也会继续销售产品给他们。

无效的复述：在你们处理定单前为什么不检查顾客的信用状态？（扭曲了被访谈者的意思）

有效的复述：系统也会处理有信用危险的顾客的定单。（鼓励被访谈者扩展发挥）

5. 有效的使用沉默

在提问结束时允许被访谈者收集整理他们的想法。当被访谈者回答不完整时，鼓励他们继续。在会谈已文字记录后，使用封闭性问题可以澄清理解。

3. 问卷表

问卷表是需求调研时广泛使用的另一种工具，它采用了统计分析的方法，显得更科学。问卷表一般在下列情况中使用：

◆需访谈的个体太多

◆需要回答容易确定的细节问题

◆当你希望有个详细的结果时

准备问卷表时，注意以下情况：

◆使问卷表尽可能的简短。用多个短小的问卷表替代一个长的问卷表。如果在回答了前15-20个问题后，长的问卷表会使用户感觉厌烦，他们就不会对其余的问题做出正确的判断。通常，一个问卷表包含的问题不超过10-15。

◆估计回答问题需要的时间，并在问卷表开头标明这个时间，以便让回答者做出相应的安排。

◆确保问题是前后一致的，没有让人含混的理解。

◆为了保证不会理解含混，让与回答者关系密切的人员来进行问卷调查，并保证他们对问题的理解是正确的。

◆在制定问题前，先确定你需要得到怎样的答案。

◆分别列出所有可能的答案。

◆一旦所有的需求和问题都准备好了，把需求点当作X轴，问题当作Y轴。确保所有的需求能被问题覆盖。最后，剔除掉与需求无关的问题。

4. 小组会议

小组会议一般在下列情况中使用：

◆信息平均的分布一小部分个人中

◆无法个别的会见所有的涉众

◆一系列的访谈已经结束，团队需要在同一平台下得到所有的回答者

在小组会议中，每个人都可讲出自己的想法。团队的答案一般比个人的答案好。小组会议可以减少一部分需求冲突，绕开纷繁的情况得到需求列表

如果小组会议管理不好，容易出现下列情况

1. 少数与会者控制了讨论

2. 一部分与会者缺乏参与讨论的积极性

为避免这种情况，需求开发人员要推动讨论的进行。要鼓励缺乏积极性的与会者参与讨论，先直接向他们提一些封闭性问题，然后逐渐转为开放性问题。

首要的技巧像提一些开放性问题，复述回答来确认理解，建立清楚的议程，指定记录员记录会议等都可使用。

其他一些注意事项：

◆提前确定会议地点，在发出与会邀请时提供路线图。这在一些大公司尤为重要，并不是每个人都熟悉整个办公大楼。

◆提前制定座位安排，平均分布需求开发人员，这样确保所有的回答都能被听到。

◆如果可能，在会议开始时宣布一些希望大家遵守的基本准则，如尊重别人的观点，关闭手机等。

◆牢牢控制讨论的话题。

◆如果可能，使用录音机，这样能更专注于讨论。

◆好好的准备小组会议，所做准备要“N”倍于个人访谈的准备，这里的“N”是指参与讨论的涉众人数。

◆如果这个会议是最终确定需求，而不是探询需求，可采用原型演示的方法。

在小组讨论结束时，感谢大家抽出时间参与讨论，告诉大家整理确认需求的计划并传阅会议纪要。

附录二：《用例指南》

1. 定义与解释

用例——用例实例是系统执行的一系列动作，这些动作将生成特定主角可观测的结果值。一个用例定义一组用例实例。

下面对此定义进行解释：

用例实例：以上定义所说的序列实际上是贯穿整个系统的某个特定事件流，即一个实例。可能会有许多事件流，而许多事件流可能非常相似。为了使用例模型便于理解性，应该将相似的事件流组合到一个用例中。确定和说明某个用例实际上就是确定和说明一组相关的事件流。

系统执行：这意味着系统提供用例。主角和系统的某个用例实例进行通信。

可观测的结果值：您可以给一个成功执行的用例赋予一个值。用例应该确保主角可以执行某个具有可确定值的任务。确定用例的正确级别或粒度是非常重要的事情。正确级别是指所实现的用例不是太小。在某些特定的环境中，可以将一个用例当作组织内的一个计划单元，该单元包括了担任系统的主角角色的个人。

动作：一个动作就是一个计算或算法过程。当主角向系统提供信号或当系统得到时间事件时，动作即被调用。动作可能包含向调用的主角或其他主角进行的信号传输。动作是不可分的，它要么完全执行，要么根本不执行。

特定主角：主角是查找正确用例的关键，这尤其是因为主角可帮助您避开太大的用例。例如，考虑一个可视化建模工具。该应用程序有两个真正的主角：开发人员，他负责以该工具作为支持来进行系统开发；系统管理员，他负责管理该工具。这两个主角对系统都有各自的要求，因而需要自己的用例集。

系统的功能由不同的用例来定义，每个用例都代表了一个特定的事件流。用例说明将定义执行用例时在系统中发生的事件。

图1- 1 ATM系统用例图

例如，在自动柜员机中，客户可以从帐户中提取现金、将现金转入帐户或核对帐户余额。这些功能对应于可以用用例来代表的事件流。

每个用例本身就有一个要执行的任务。所收集到的用例组成了所有可能的系统使用方法。只需注意一下用例任务的名称，就可以对该用例任务有一个大致的了解。

2. 如何发现用例

以下问题可以帮助您确定用例：

◆对于已确定的各个主角，哪些任务会涉及到系统？

◆是否需要将系统中发生的某些特定事件通知给此主角？

◆此主角是否需要将突发变更或外部变更通知给系统？

◆系统是否给业务提供了正确的行为？

◆您已经确定的用例是否可以执行所有功能？

◆哪些用例将支持和维护系统？

◆在系统内应该修改或创建什么信息？

有些用例不代表系统的主要功能，因而通常会被忽略。这些用例可能属于以下类型：

◆系统启动和停止。

◆系统的维护。例如，添加新用户和建立用户简档。

◆维护在系统中存储的数据。例如，所构建的系统和遗留系统平行工作，所以数据需要在两个系统之间达到同步。

◆修改系统行为所需的功能。例如创建新报告的功能，它不仅可以创建硬代码，还可以对系统中存储的数据创建一组特定报告。

3. 用例如何演进

在精化的早期迭代中，只对少数几个用例（在构架方面有重要意义的用例）进行比简要说明更为详细的说明。在深入到细节之前，通常应该先编写用例的提纲（按照分步格式）。此分步提纲应该是您定义用例事件流结构的首次尝试。始终要从基本的用例流开始。一旦对基本流提纲形成了一致意见，就可以添加与基本流相关的备选流内容。

当精化阶段即将结束时，应完成您计划要详细说明的所有用例。

4. 是否详细说明了所有用例？

模型中通常会有一些简单的用例，它们不需要详细的事件流说明，对它们使用分步提纲就可以了。要做出这一决定，依据的标准是：您没有发现作为读者的用户对该用例的含义存在异议，而且设计人员和测试人员对于按分步格式提供的详细程度感到满意。这种简单用例的示例之一是描述简单的输入或从系统中检索某些数据的用例。

5. 用例的范围

通常很难判断一组系统交互或对话是否属于一个或几个用例。请考虑回收机的使用情况。客户将贮藏物品（如罐子、瓶子和箱子）插入回收机。当插入所有的贮藏物品后，她按下某个按钮，打印了一份收据。这样，她就可以用这一收据换取现金。

是否插入贮藏物品属于一个用例，而索取收据属于另一个用例？或者，以上过程只是一个用例？此过程有两个动作，缺少了任何一个，另一个动作都对客户没有任何意义。所以，应该将所有插入和获取收据当作一个完整对话，这样才对客户有意义。因而，从插入第一个贮藏物品到按下按钮获得收据的完整对话过程是一个完整的用例，也就是一个用例。

此外，最好将这两个动作连在一起，这样就可以同时对它们进行复审、修改、测试、为它们编写手册，并且在一般情况下将它们当作一个单元来管理。在大型系统中，明显需要这样处理。

6. 用例如何实现

用例可以说明当主角通过与系统交互来执行该用例时在系统中发生的事件。至于系统如何在内部利用协作对象来执行任务，用例并不加以定义。这将由用例实现来说明。

示例：

以打电话为示例，用例会说明以下内容：当呼叫方拿起听筒时，系统将发出一个信号，然后，系统会接收数字输入、查找接收方、使接收方的电话振铃、接通电话、传送语音等等。

在执行系统中，用例实例并不对应于实施模型中的任何特定对象（例如，代码中类的实例）。它所对应的是特定的事件流，该事件流由主角调用并且作为一组对象中的一个事件序列来执行。也就是说，用例实例对应于被实施对象的通信实例。我们将其称为用例的实现。通常，相同的对象会参与多个用例的实现。例如，银行业务系统中的“存款”用例和“取款”用例可能在它们的实现中同时使用某个特定的帐户对象。这并不表示这两个用例可以相互通信，它们只是在它们的用例实现中使用了相同的对象。

您可以认为一个事件流是由几个分支流构成的，这几个分支流组合到一起就形成了总的事件流。您还可以在其他用例的事件流中复用某个分支流的说明。一个用例事件流说明中的分支流可能是其他用例事件流说明中所共有的分支流。在进行设计时，应该让相同的对象来执行全部相关用例所共有的行为；也就是说，无论正在执行哪个用例，只应该有一组对象执行来这一行为。

示例：

在自动取款机系统中，“取款”用例和“核对余额”用例的事件流中的初始分支流是相同的。这两个用例的事件流都从检查卡标识和客户的个人访问代码开始。

7. 一个用例具有许多可能的实例

一个用例实例几乎可以遵循无限多的路径，但这些路径仍然可以计数。路径代表了用例事件流说明中的用例实例可以选择的各种方案。路径的选择取决于事件。事件类型包括：

来自主角的输入。例如，主角可以从几个选项中决定下一步应该做什么。

示例：

在自动柜员机系统的“取款”用例中，如果客户要求提取的金额大于他的帐户金额，事件流就会有所不同。因而，用例实例将遵循不同的路径。

8. 名称

每个用例都应有一个名称，以表明它与主角进行交互的结果。名称应该是“动词+名词”，使用便于理解的单词。用例名称不应重复。

示例：

回收机示例中的“回收贮藏物品”用例可以具有以下的不同名称：

◆接收贮藏物品

◆正在接收贮藏物品

◆返回贮藏物品

◆贮藏物品

9. 简要说明

用例的简要说明应反映用例的角色和目的。在撰写说明时，应参考用例中所涉及的主角、词汇表，并根据需要定义新概念。

示例：

以下是回收机系统中“回收贮藏物品”用例和“添加新的瓶类型”用例的简要说明示例：

回收贮藏物品：用户使用本机器来自动统计所有回收物品（瓶子、罐子以及箱子），并得到一张收据。收据将在收银机处兑现。

添加新的瓶类型：在“学习模式”中启动机器，然后与返回回收物品时一样插入 5 个样本，从而将瓶子的新类型添加到机器中。这样，回收机就能够测量这些瓶子，并知道如何识别它们。管理人员指定新的瓶类型的返款额。

10. 事件流 - 内容

用例事件流包含用例建模工作所得到的最重要的信息。应该清楚地说明用例的事件流，让外行也能很容易地理解它。请记住，事件流应该说明系统做什么，而不是说明为了执行所需的行为而对系统进行的设计。

以下提供了有关事件流内容的指南：

1) 说明用例如何开始和结束

2) 说明在主角和用例之间交换的是什么数据

3) 不要详细描述用户界面，除非要理解系统行为就必须详细了解用户界面。例如，如果事先知道应用程序将基于 Web，那么最好使用一组有限的 Web 专用术语。否则，您的读者就可能认为用例文本过于抽象。您可以在术语中包括这些词语：“导航”、“浏览”、“超链接”、“页”、“提交”和“浏览器”。不过，引用“框架”或“Web 页”时最好不要造成对两者之间界限进行臆测的效果。这是一项关键的设计决策。

4) 说明事件流，而不只是功能。为了做到这一点，每个动作都应从“当主角... 时”开始

5) 只说明属于该用例的事件，而不是发生在其他用例中或系统外部的事件

6) 避免不明确的术语，如“例如”、“等等”和“信息”

7) 详细说明事件流，即回答所有包含“什么”的问题。请记住，测试设计人员将使用此文本来确定测试用例。

如果您已经在其他用例中使用了某些特定术语，则务必要在此用例中使用完全相同的术语，并确保它们表达相同的含义。为了管理常用术语，应该将它们放入一个词汇表。

11. 事件流 - 结构

事件流的两个主要部分是基本事件流和备选事件流。基本事件流应包括在执行用例时“通常”会发生的事件。备选事件流包括与正常行为相关的可选或异常特征的行为，同时也包括正常行为的各种变形。您可以将备选事件流看作是基本事件流的“绕行道”，有些备选事件流将返回到基本事件流，而有些将结束此用例的执行。

图11- 1 事件流典型结构

事件流的典型结构。直线箭头代表基本事件流，而曲线则代表与正常行为相关的备选事件流。有些备选路径返回到基本事件流，而其他备选路径则结束此用例。

应该将基本事件流和备选事件流进一步构建为步骤或分支流。为进行构建时，您的主要目标应该是文本的可读性。这里的经验法则是，分支流应该是用例中的一个行为段，该行为段必须具有明确目的并且“不可分”（也就是说，要么执行所述的全部动作，要么不一个也不执行）。您可能会需要使用几个级别的分支流，但应尽量避免这样，因为多个级别的分支流会使文本更为复杂、更难于理解。可以用活动图来说明事件流的结构。

这种书面文本分为连续的小节，这本身就向读者提示：分支流之间存在一定顺序。为了避免误解，始终应该指出分支流的顺序是否是固定的。这种考虑事项通常与以下内容相关：

◆业务规则。例如，在系统可以使某些数据可用之前，用户必须得到授权。

◆用户界面设计。例如，系统不应强制行为的某个特定顺序，该序列对于某些用户可能是显而易见的，但对于其他用户却并非如此。

为了阐明备选事件流在结构中的合适位置，需要为基本事件流的每条“绕行道”说明以下内容：

◆基本事件流中可以插入备选行为的位置。

◆为使备选行为开始而需要满足的条件。

◆基本事件流重新开始的方式和位置，或者用例结束的方式。

示例：

在回收机系统的“回收贮藏物品”用例中有一个备选分支流。

2.1. 瓶子阻塞

在 基本事件流“插入贮藏物品”中，如果一个瓶子被卡在入口处，入口周围的传感器和测量门将检测到这个问题。传送带停止传送，机器发出警报，让操作人员来解决问题。回收机将一直等待，直到操作人员指示问题已得到解决。然后，回收机从基本事件流的某一位置继续工作。

在上例中，备选事件流插入了基本事件流中的一个特定位置。有些备选事件流也可以在多个位置插入，一些备选事件流甚至可以在基本事件流中的任意位置插入。

示例：

在回收机系统的“回收贮藏物品”用例中有一个备选分支流：

2.2. 前面板被取走

如果有人将回收机的前面板取走，将使罐子压缩功能不可用。没有前面板就无法启动罐子压缩操作。取走前面板的同时将激活向操作人员发出的警报。当重新安装好前面板时，回收机又将从它在基本事件流中停止的位置恢复操作。

如果备选事件流非常简单，您可能想就在基本事件流部分对其进行说明（使用某种不正式的“if-then-else"结构）。但应该避免这样。太多的备选事件流将使正常行为难于识别。而且，如果在基本事件流部分包括备选路径，将使文本更加“类似于伪代码”，从而会降低文本的可读性。

通常，如果抽取事件流的各个部分并且分别对这些部分进行说明，就可以增加基本事件流的可读性，并改进用例和用例模型的结构。您可以将抽取的部分建模为：

◆基本用例中的一个备选事件流（如果抽取的部分是一个简单变量、选项或基本事件流的例外情况）。

◆基本用例中的明确包含项（如果您希望将抽取的部分封装，以便其他用例复用）。

◆基本用例中的隐含包含项（如果基本用例具有完整的基本事件流，即具有确定的开始和结尾）。使用扩展流的情况应该是：您希望将其隐藏在基本用例的说明中，以降低该说明的复杂性。

◆基本事件流中的分支流，并可能作为另一个选项（如果以上方案都不适用）。例如，在“维护雇员信息”用例中，可能有单独的分支流分别用于添加、删除和修改雇员信息。

12. 事件流 - 风格

可以按照多种风格来说明用例。作为示例，我们将以三种不同的风格来说明“管理订单”用例的基本事件流，它们的主要区别在于正式程度不同。第一种风格（如下面的示例 1 所示）易于理解、条理清晰，所以是推荐使用的风格。文本分为带有编号和名称的各个小节。这些编号便于对小节进行引用。小节名称使读者只需浏览文本的标题就可迅速地获得对从事件流的总体了解。

在下面的示例 2 中，事件流的说明没有阐明事件发生的顺序。如果以这种风格撰写，您和其他人都可能会错过一些与系统相关的重要信息。

下面的示例 3 显示了另外一种风格。如果您觉得很难清楚地表示事件的序列，就可以采用这种风格。这种伪代码风格更为准确，但非技术人员在阅读和理解这种文本时会有困难，尤其是在需要快速领会事件流时。

示例 1：

用例说明：在这种风格中，文本易于阅读，事件流易于理解。在说明中应尽量采用这种风格。

示例 2：

用例说明：这种风格具有可读性，但事件流都不清晰。

示例 3：

用例说明：编写员在上例中选择了一种使用伪代码的正式风格。这种风格会使读者难于快速领会流程步骤，但在不容易准确获取事件流的情况下，这种风格相当有用。

13. 事件流 - 示例

“管理订单”用例事件流的完整说明（包括其备选流）可能如下所示：

1. 基本事件流

1.1. 用例开始

当主角操作员通知系统创建一个评测订单时，用例开始。然后，系统将检索所有的网络元素主角、它们的测评对象以及特定操作员可以使用的相应测评功能。可用的网络元素是那些正在运行的网络元素和操作员有权访问的网络元素。测评功能的可用性依赖于为某一特定类型的测评对象所设置的评测功能。

1.2. 配置测评订单

系统让操作员主角选择要评测的网络元素，然后将显示所选网络元素可以使用的测评对象。系统让操作员从这些测评对象中进行选择，然后选择需要为每个测评对象设置的测评功能。

系统让操作员输入对评测订单的文本注释。

操作员通知系统完成评测订单。系统将作出以下响应：为该评测订单生成一个唯一的名称，并设置评测开始时间、评测重复频率和评测持续时间的默认值。对于每个操作员，这些默认值都是唯一的。然后，系统让操作员编辑这些默认值。

1.3. 初始化订单

操作员通知系统初始化评测订单。系统将记录创建操作员的身份、创建日期以及测评订单的“预定”状态。

1.4. 用例结束

系统向该操作员确认已对测评订单进行了初始化，其他主角在此时可以看到该测评订单。

2. 备选事件流

2.1. 没有可用的网络元素

在“1.1. 用例开始”中，如果发现目前没有该操作员可以评测的网络元素，系统将通知该操作员。该用例随即结束。

2.2. 没有可用的评测功能

在“1.2 配置评测订单”中，如果所选的网络元素没有可用的评测功能，系统将通知该操作员并让他选择其他网络元素。

2.3. 撤消评测订单

系统将允许操作员在用例执行过程中的任意时刻撤消所有动作。然后，系统将返回到该用例在开始之前所处的状态，并结束该用例。

14. 前置条件和后置条件

利用前置条件和后置条件的概念来阐明事件流如何开始和结束是一种非常有用的方法。然而，只有当用例的读者认为该方法可以增加价值时才应将其采用。

前置条件是开始用例前所必需的系统及其环境的状态。后置条件是用例结束后系统可能具备的状态。

请考虑以下方面：

◆前置条件或后置条件所说明的状态应该是用户可以观察到的状态。“用户已经登录系统”或“用户已经打开文档”都是可观察状态的示例。

◆前置条件是对用例何时开始的约束。它并不是使用例开始的事件。

◆虽然可以在分支流级别定义前置条件和后置条件，但是一个用例的前置条件并不只是一个分支流的前置条件。

◆无论执行了哪些备选流，用例的后置条件都应为“真”；它只应对主事件流不为“真”。如果可能出现故障，则应在后置条件内包括“该动作已经完成，或者，如果可能出现故障，则不执行该动作”，而不只是“该动作已经完成”。

◆当同时使用后置条件和扩展关系时，应确保扩展用例不引入违反基本用例后置条件的分支流。

◆后置条件是一种对用例进行说明的有力工具。您可以首先定义用例应该实现什么，即后置条件。然后，可以说明如何达到这一条件（所需的事件流）。

示例：

自动柜员机中“提取现金”用例的前置条件为：客户拥有一张个人专用卡，这张卡正好可以塞进读卡器，并且该卡已经分到一个 PIN 号，还向银行业务系统进行了登记。

自动柜员机中“提取现金”用例的后置条件为：当用例结束时，所有帐户和交易日志都已收支平衡，与银行业务系统的通信已重新初始化，并且银行卡已经返还给客户。

15. 扩展点

扩展点使用例具有了扩展的可能性。一个扩展点有一个名称和一系列对用例事件流中一个或多个位置的引用。一个扩展点可以引用用例内的两个行为步骤之间的单个位置。它也可以引用一组不连续的位置。

使用已命名的扩展点将有助于将扩展用例的行为规约从基本用例的内部细节中分离出来。您可以对基本用例进行修改或重新整理，只要扩展点的名称保持不变，那么这种变更将不会影响扩展用例。同时，您不用在说明基本用例事件流的文本中包括有关行为可能在何处扩展的细节。

示例：

在电话系统中，可以由抽象用例“显示呼叫方身份”来扩展用例“打电话”。这是一项可选服务，通常称为“呼叫方 ID”，接收方可能已请求该服务，也可能还未请求。用例“打电话”中扩展点的说明可能如下所示：

名称：显示身份

位置：在“基本事件流：使接收方的电话振铃”之后。

16. 用例图

您可能会选择在一个用例图（在很少的情况下会需要多个用例图）中阐明一个用例（用例图属于该用例）与主角以及其他用例的关系。如果用例涉及到许多主角，或者与很多其他用例有关系，那么用例图将非常有用。由于这种图只是从一个用例的角度来显示用例模型，而不用于解释整个用例模型的一般事实，所以它具有“局部”特征。

附录三：《用户需求调查单》

附录四：《需求调研记录》