1. 前言

1.1 意图和价值

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

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

1.2 适用范围

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

1.3 名词术语

用户需求

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

软件需求

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

2. 过程定义

2.1 角色和职责

角 色

职 责 描 述

高层经理

1. 评审、批准用户需求、产品需求等过程产品，并参与本过程域重要的活动；

2. 解决在实施本过程域中所遇到的无法解决的问题

项目经理

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

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

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

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

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

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

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

需求开发人员

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

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

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

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

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

美工

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

2. 和需求开发人员一起，向用户进行开发原型Demo演示。

项目组成员

参加需求开发与管理活动的评审。

客户

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

2. 评审并确认需求开发的所有文档；

3. 对《用户需求说明书》和《产品需求规格说明书》、需求Demo等进行确认；

CCB

1. 评审需求文档是否满足了用户的真实意愿。

2. 审批需求变更申请。

CM

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

QA

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

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

2.2 入口准则

需求开发人员已经确定；

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

2.3 输入

初步的《项目计划》；

《项目合同》；

《技术解决方案》；

客户原始需求文档。

2.4 过程活动

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

需求开发过程

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

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

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

需求管理过程

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

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

2.4.1 需求开发过程

需求开发过程

2.4.1.1 用户需求调研

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

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

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

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

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

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

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

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

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

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

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

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

需求产生的背景

需求目标要求

需求内容范围

用户角色

功能性需求的描述

限制条件

非功能性要求等。

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

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

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

2.4.1.2 用户需求分析

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

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

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

确定需求的优先级别

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

建立业务模型（可选）

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

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

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

建立数据字典（可选）

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

2.4.1.3 产品需求定义

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

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

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

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

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

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

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

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

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

2.4.1.4 产品需求评审

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

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

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

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

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

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 需求跟踪

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

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

l每周例会时：

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

l软件需求评审通过时：

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

l项目里程碑时：

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

l需求变更时：

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

2.5 输出

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

² 《用户需求说明书》

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

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

² 《需求评审报告》

² 《需求跟踪矩阵》

² 《需求变更申请单》

² 《需求变更记录》

2.6 出口准则

项目结项。

2.7 过程度量

№

度量点

执行人

度量时机|频率

存储位置

M-1

需求变更数

需求开发人员

每周

《需求跟踪矩阵》

M-2

需求变更工作量

需求开发人员

每周

《需求跟踪矩阵》

2.8 裁剪说明

裁剪对象

类型（过程活动或工作产品）

裁减要素（增加、删除、修改）

裁减条件

产品

业务模型、数据字典

删除

用户需求易于理解时

产品

系统开发原型（Demo）

删除

用户需求易于理解时

3. 相关指南

《需求调研指南》

《用例指南》

附件：

需求调研指南1. 引言

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

用户访谈

问卷表

小组会议

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

2. 用户访谈

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

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

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

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

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

² 访谈前准备

² 计划和安排访谈日程

² 访谈开始和结束

² 引导访谈

² 后继的访谈整理工作

2.1 准备访谈

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

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

² 部门目标的陈述

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

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

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

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

2.2 计划访谈日程

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

2.3 访谈开始和结束

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

例如：

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

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

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

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

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

2.4 引导访谈

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

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

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

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

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

² 比较容易作笔记

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

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

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

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

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

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

1.询问开放性的问题

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

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

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

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

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

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

2.使用适当的表达

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

3.暗示相信被访谈者

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

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

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

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

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

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

4.重述被访谈者的回答

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

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

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

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

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

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

重述问题常见的错误：

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

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

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

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

这儿有个案列显示了有效的及无效的复述；

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

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

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

5. 有效的使用沉默

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

3. 问卷表

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

² 需访谈的个体太多

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

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

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

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

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

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

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

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

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

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

4. 小组会议

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

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

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

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

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

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

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

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

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

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

其他一些注意事项：

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

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

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

² 牢牢控制讨论的话题。

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

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

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

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