目录
前言：
11.2.1 直接的用户访谈
1 . 准备访谈
2 . 访谈过程
3 . 访谈的后续工作
4 . 用户访谈的优缺点
11.2.2 问卷调查
1 . 调查表的制作
2 . 问卷调查的优缺点
3 . 提高问卷返还率的方法
11.2.3 采样
1 . 样本大小
2 . 采样的优缺点
11.2.4 情节串联板
1 . 情 节 串 联 板 的 概 念
2 . 情 节 串 联 板 的 类 型
3 . 情 节 串 联 板 的 制 作
4 . 情 节 串 联 板 的 优 缺 点
11.2.5 联合需求计划 J R P =》更好地获取需求
1 . 联 合 应 用 开 发
2 . J R P 会 议
3 . 主要原则
11.2.5 竞品分析
11.2.6 需求记录技术
1. 任务卡片
2 . 场景说明：senario
3 . 用户故事
4. Volere 白卡
前言：
需求获取是一个确定和理解不同的项目干系人的需求和约朿的过程。
需求获取是一件看上去很简单，做起来却很难的事情。需求获取是否科学、准备充分，对获取出来的结果影响很大，这是因为大部分用户无法完整地描述需求，而且也不吋能看到系统的全貌。因此，需求获取只有通过系统分析师与用户的有效合作才能成功。系统分析师必须建立一个对问题进行彻底探讨的环境，而这些问题与将要开发的系统有关。让用户明确了解，对于某些功能的讨论并不意味着即将在系统中实现它。
作为一名系统分析师，掌握各种不同的需求获取技术，并且熟练地在实践中运用它，是十分必要的。
备注：
需求获取=>业务需求=》用户需求：目的是获取客户的真实需求，而不是分析客户的需求，因此，需求获取不会对客户的需求进行主观或客观的评判，收集原始的需求是主要的目标！！！因此，以用户故事、业务场景、用例图等输出为主！！！需求获取是完全站在客户的角度，定义用户的需求！！！把目标系统完成看成一个黑盒子，站在黑盒外部，对信息系统提出需求。
需求分析=》功能需求、非功能需求：就是把客户的需求变成软件产品的需求！！！！得到软件或产品的需求规格说明书！！！是站在产品经理和系统工程师的角度，对软件系统提出的需求！！！
11.2.1 直接的用户访谈
用户访谈是最基本的一种需求获取手段，其形式包括结构化和非结构化两种。结构化是指事先准备好一系列问题，有针对地进行；而非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。最有效的访谈是结合这两种方法进行，毕竟不吋能把什么都一一计划淸楚，应该保持 R 好的灵活性。为了进行有效的用户访谈，系统分析师需要在三个方面进行组织，分别是准备访谈、
主持访谈和访谈的后续工作。
1 . 准备访谈
每一次成功的访谈都需要精心的准备。在准备访谈过程中，
首先也是最重要的步骤是确定访谈的目的，
其次是确定访谈中应该包括哪些用户。不同的用户代表某一种角色或干系人。
这两个步骤结合得非常紧密，因此通常一起完成。参加访谈的用户数 M 取决于访谈的目的。通常，最好限制参加访谈的人数。例如，一次超过3 个用户的访谈有可能使得讨论时间变长，这在有时候可能会适得其反。在很多情况下，系统分析师每次只和一个用户进行访谈，这对中小规模的项目尤其适用。准备访谈的第三步是为访谈准备一些详细的问题。系统分析师可以根据己经获得的表格和报表写出一些具体的问题，并作好笔记。问题可以分为开放式问题和封闭式问题两类。所谓开放式问题，就是类似于“你如何完成这项功能”的问题，鼓励用户与系统分析师对问题进行讨论和说明；所谓封闭式问题，就是类似于“你每天处理多少张表格”的问题，可以用来获得具体的事实。一般而言，幵放式问题有助于开始对问题进行讨论，并且鼓励用户说明所有的业务过程和业务规则细节。准备访谈的最后一步是作出最终的访谈安排，并把这些安排通知所有参加者。具体的时间和地点应该事先征求被访谈者的同意。如果可能的话，应尽董选择一个安静的地点以避免外界干扰。每个参加者都应该知道访谈的目的，而且在适当的时候，参加者也应该有机会预览一下将要访谈的问题或材料。另外，值得注意的是，系统分析师应该在访谈之前进行一些领域相关的知识培训，充分阅读相关材料，以保证自己有较专业的理解与认识，让用户能够信任 自己。
2 . 访谈过程
在具体访谈时，系统分析师及项目组成员一定要准时到达。可能的话，尽景早到一
点。在访谈的过程中，要做好以下几项工作：
(1) 限制访谈时间。
当确定了访谈目的并准备好了问题之后，访谈的时间应该控制在 90分钟左右。如果访谈需要更多的时间来覆*一些其他的问题，比较好的方法是中断本次访谈，并安排另一次访谈，因为举行几次比较短的访谈要比举行一次马拉松式访谈的效果要好得多。一系列访谈提供了收集各种材料的机会，这些材料将在随后的过程中被不断细化。在几次比较短的访谈后，系统分析师和被访谈者都将获得对系统的较好理解。
(2) 寻找异常和错误情况。
系统分析师要找机会问一些类似于“如果……那会怎么样”的问题，要有意识地去确定所有的特殊情况，并与用户深入探讨。
(3) 深入调查细节。
除了寻找意外情况外，系统分析师必须进行深入调査，以确保获得对过程和规则的完全理解。
(4) 认真作好记录。
主要包括本人记录、第三人记录或者是录音/录像的形式。如果采用录音/录像的方式，应该征得被访谈者的同意。这种方法虽然看上去比较有效，不容易丢失信息，但容易让被访谈者感到紧张，也会给后面的整理工作带来一定的工作量和难度。因此，手写笔记是一个好主意，好的笔记不仅为下一次访谈的成功奠定基础，而且也为建立分析模型提供了基础。
在访谈时，系统分析师一定要注意措词得当，充分尊重用户。否则，将会破坏访谈的气氛，从而使访谈的效率大打折扣。在访谈时，一定要注意保持轻松的气氛，在说话、提问时应该尽量采用易于理解和通俗化的语言，避免使用专业术语。
3 . 访谈的后续工作
后续工作的首要任务是吸收、理解和记录访谈所获得的信息。通常，系统分析师通过构造业务过程的模型来记录访谈的细节，和项目组其他成员一起复査访谈中发现的结果，然后在一天或至多两天内记录下结果。
在访谈过程中，系统分析师可能会问一些用户回答不上来的问题，不要丢失或遗忘这些问题，这是非常重要的。根据需要进一步详细说明的问题或者访谈中错过的信息，系统分析师可以生成一张新的问题列表，为下一次访谈作好准备。
另外，为了维持用户的友好和信任关系，应该送给他们一份总结了访谈内容的备忘录。其中需要提到被访谈者对项目的贡献，并给他们机会澄清可能在访谈期间得出的任何错误回答。
4 . 用户访谈的优缺点
总的來说，用户访谈具有良好的灵活性，有较宽广的应用范围。但是，也存在着许多困难，例如，用户经常较忙，难以安排时间；面谈时信息量大，记录较为困难；沟通需要很多技巧，同时需要系统分析师具有足够的领域知识等。另外，在访谈时，还可能会遇到一些对于企业来说比较机密和敏感的话题。因此，这看似简节的技术，也需要系统分析师具有丰富的经验和较强的沟通能力。
11.2.2 问卷调查
用户访谈最大的难处在于很多关键人员时间有限，不容易安排过多的时间。而且，如果用户较多，不可能一一访谈。因此，就需要借助问卷调查，通过精心设汁调查表，
然后下发到相关的人员 f •中，让他们填写答案。这样，就可以有效地克服用户访谈方法
中存在的问题。
1 . 调查表的制作
问卷调查表使系统分析师可以从大量的项目 T 系人处收集信息，甚至当项目干系人
在地理上分布很广时，他们仍然能通过问卷调查表来帮助获取需求。一张好的问卷调査
表要花费大量的时间来进行设计与制作，包括确定问题及其类型、编写问题、设计问卷
调查表的格式三个重要活动。
(1) 确定问题及其类型。
与用户访谈一样，问卷调查表上使用的基本问题有幵放式
问题和封闭式问题。但不同的是，问卷调査表的问题必须非常清楚，组织顺序必须有说
服力，必须能够预见用户可能的回答。
( 2 ) 编写问题。
在具体问题的编写中，要注意使用“用户的语言”，不要使用含糊的词语，但也要避免过度明确的问题，保持问题的简短，避免措词上的偏向。
( 3 ) 设计问卷调査表的格式。
一份精心设计的、恰当的问卷调查表，能帮助用户克服不愿意回答问题的情形。设计调查表的格式时，应该提供足够的空白空间让用户填写表格。对用户重要的问题放在最前面，内容相似的问题放在一起。例如，表 11-1是一个关于某在线教育平台系统的调查表的例子，其中包含了常见的各种问题类型。
2 . 问卷调查的优缺点
与用户访谈相比，问卷调查可以在短时间内，以低廉的代价从人景的回答中收集数
据；问卷调查允许回答者匿名填写，大多数用户可能会提供真实信息；问卷调査的结果
比较好整理和统计。问卷调查最大的不足就是缺乏灵活性，其他缺点还有：
(1) 双方未见面，系统分析师无法从用户的表情等其他动作来获取一些更隐性的信
息，用户也没有机会立即澄清对问题有含糊或错误的回答。
(2) 用户有可能在心理上会不重视一张小小的表格，不认真对待，从而使得反馈的
信息不全面。
( 3 ) 调查表不利于对问题进行展开的回答，无法了解一些细节问题。
(4) 回答者的数 S 往往比预期的要少，无法保证用户会回答问题或进一步说明所有
问题。
因此，较好的做法是将用户访谈和问卷调査结合使用。具体来说，就是先设计问题，
制作成为问卷调査表，下发填写完后，进行仔细的分组、整理和分析，以获得基础信息。
然后，再针对分析的结果进行小范围的用户访谈，作为补充。
3 . 提高问卷返还率的方法
问卷调查的返还率通常比较低，系统分析师在采用问卷调查的方式获取需求时，除
了设计适当的问题，选择合适的调查人群之外，一定要事先考虑到如何解决问卷返还率
低的问题。为了提高问卷返回率，通常吋以采取以下措施：
( 1 ) 向所有的工作人员解释问卷的目的，以及如何使用这些信息。
(2) 说明这份问卷是（客户）企业的每个 T .作人员都要冋答的。
(3) 拜托相关领导督促他所管辖的工作人员回答问卷，并及时返还。
(4) 尽量参加一次（客户）企业的全体会议，在会议上解答工作人员提出的问题，并解释这些信息的用处。
(5) 更改问卷中的问题，尽量减少回答问卷所花费的时间。
(6) 设置一些奖品或奖励，激励大家及时返还问卷。
11.2.3 采样
釆样是指从种群中系统地选出有代表性的样本集的过程，通过认真研究所选出的样本集，可以从整体上揭不种群的有用信息。对丁•信息系统的开发而言，现有系统的文档(文件）就是采样种群。当开始对一个系统做需求分析时，查看现有系统的文档是对系统有初步了解的最好方法。但是，系统分析师应该查看哪些类型的文档，当文档的数据庞大，无法一一研究时，就需要使用釆样技术选出有代表性的数据。 '
1 . 样本大小
采样技术的关键是如何确定样本集的规模，即如何确定样本大小，使样本具有代表性。事实上，这又取决于希望样本具有多大的代表性。有研究人员给出了一个用于确定
2 . 采样的优缺点
釆样技术不仅可以用于收集数据，还可以用于采集访谈用户或者是采集观察用户。在对人员进行采样时，上面介绍的采样技术同样适用。通过采样技术，选择部分而不是选择种群的全部，仅加快了数据收集的过程，而且提高了效率，从而降低了开发成木。另外，采样技术使用了数理统计原理，能减少数据收集的偏差。伹是，由于采样技术基于统计学原理，样本规模的确定依赖于期望的可信度和己有的先验知识，很大程度上取决于系统分析师的主观因素，对系统分析师个人的经验和能力依赖性很强，要求系统分析师具有较岛的水平和丰富的经验。
11.2.4 情节串联板
在需求获取的过程中， 虽然系统分析师很大的一部分精力在于理解和分析业务（不管软硬件如何实现，只关心实际的业务模型），了解潜在的问题，但仍然不可避免地涉及一些解决方案的探讨，因为只有让用户了解“系统如何做”时才会更容易达成共识。而且，很多用户对信息系统是没有直观认识的，这样就很容易产生盲区，而这种时候，系统分析师就需要通过情节串联板技术来帮助用户消除盲区，达成共识。
1 . 情 节 串 联 板 的 概 念
情节串联板通常就是一系列图片，系统分析师通过这些图片来讲故事。（让客户理解在一般情况下，图片的顺序与活动事件的顺序一致，通过一系列图片说明会发生什么。人们发现，通过以图片辅助讲故事的方式叙述需求，有助于畚效和准确地沟通。在情节串联板中可以使用的图片类型包括流程图、交互图、报表和记录结构等。
简单地说，情节串联板技术就是使用工具向用户说明（或演示）信息系统如何适合企业的需要，并表明系统将如何运转。系统分析师将初始的情节串联板展示给讨论小组，小组成员提供意见，以便更好的获取需求。
2 . 情 节 串 联 板 的 类 型
情节串联板的类型包括被动式、主动式和交互式，其复杂程度依次递增。被动式情节串联板通常由草图、图片、屏幕截图、幻灯片等组成。系统分析师充当系统的角色，让用户预演情节串联板，简单地表述为“当这样做时，会出现这样的情景”。主动式情节串联板试图使用用户能够看到类似“电影样片”，它可以动播放，描述系统在典型用法或典型场景中的行为方式。交互式情节串联板让用户体验系统的行为，系统需要用户的参与才能继续运行。
交互式情节串联板可以是仿真器、实物模型，甚至是抛弃式原型。
3 . 情 节 串 联 板 的 制 作
制作情节串联板的工具大致可以分为两大类：静态工具和动态工具。
静态工具主要有纸和铅笔、白板、即时贴和 PowerPoint 等，
动态工具主要有 Flash、Macromedia Director和其他动画工具。
为了避免分散注意力，一般最好使用简单的工具，例如，图表、白板或 PowerPoint 等。情节串联板应该易于创建和修改，系统分析师不要企图将情节串联板制作得太好，因为情节串联板既不是原型，也不是真实事物的演示。图 11-1表示了情节串联板的复杂程度与成本之间的关系。
备注：
情节串联板的图片没有固定的语法规定，有随意发挥的成分。
4 . 情 节 串 联 板 的 优 缺 点
由于情节串联板给用户一个直观的演示，因此它是最生动的需求获取技术，其优点是用户友好、交互性强，对用户界面提供了早期的评审。情节串联板的缺点是花费的时间很多，使需求获取的速度大大降低。
11.2.5 联合需求计划 J R P =》更好地获取需求
为了提高需求获取的效率，越来越多的企业倾向于使用小组工作会议/workshop来代替大量独立的访谈。联合需求计划 （Joint Requirement Planning ， J R P ) 是一个通过高度组织的群体会议来分析企业内的问题并获取需求的过程，它是联合应用开发 （Joint ApplicationDevelopment , J A D ) 的一部分。
联合应用开发(Joint Application Development)是一个方法论，它通过一连串的合作研讨会，也叫JAD(joint application design sessions)会议，它使得一个应用程序的设计和开发中的客户或最终用户参与其中。IBM的Chuck Morris和Tony Crawford在20世纪70年代末开发了JAD，并且在1980年开始通过研讨会讲授这个观念。
比起更传统的方法，JAD观念被认为其成倍地加快了开发的速度，并且增大了客户的满足感，因为客户参与了开发的全过程。相比之下，在系统开发的传统观念中，开发者利用通过一系列面对面的交谈而得到的客户输入信息来调研系统需求并且开发应用程序。
JAD的一个变种——快速应用开发(RAD)通过例如使用更少的形式方法学和重用软件组件从而更快地创作出一个应用程序。
1 . 联 合 应 用 开 发
J A D 是以小组形式定义和建立系统的，它是由企业主管部门经理、会议主持人、用户、协调人员、 I T 人员、秘书等共同组成的专题讨论组。由这个专题讨论组来定义并详细说明系统的需求和可选的技术方案。 J A D 的过程大致如下：
(1) 确定 J A D 项目，主要指确定系统的范围和规范。
(2) 在 J A D 专题预备会上，会议主持人向参与者介绍项目和 J A D 专题讨论内容。
(3) 准备 J A D 专题讨论材料。
(4) 进行 J A D 专题讨论会，其目的是要达成对需求的一致意见，并对各种可选的技术方案加以讨论，从中研究出几套可供选择的方案。
J A D 方法充分发挥了 J A D 专题讨论会的优势，以使更好地满足用户的需求。使用J A D 法，比传统的收集需求的时间更快，可以加速系统开发周期。 J A D 方法充分发挥了管理人员和用户的积极性，增强了管理人员和用户的责任感，从而使系统幵发工作做得更好。
2 . J R P 会 议
J R P 是一种相对来说成本较高的需求获取方法，但也是十分有效的一种。它通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求。通常该会议的参与人数为6〜 18人，召开时间为1〜 5 小时。
在会议之前，应该将与讨论主题相关的材料提前分发给所有将要参加会议的人。在会议开始之后，按照以下步骤进行：
(1) 应该花一些时间让所有的与会者互相认识，以使交流在更加轻松的气氛下进行。
会议的最初，针对所列举的问题进行逐项专题讨论。
(2) 对现有系统和类似系统的不足进行开放性交流。鼓励与会者在短时间内说出尽量多的想法，在这一过程中不对这些想法发表任何评论。
(3) 大家在此基础上对新的解决方案进行一番设想，在这个过程中，需要把这些想法、问题、不足记录下来，形成一个要点清单。
(4)针对这个要点清单进行整理，明确优先级，并进行评审。
为了更好地进行以后可能碰到的类似 J R P 会议， J R P 会议后一般会让与会者完成一
个评价性的调查问卷。 J R P 会议最后有一个总结性的报告，主要内容是与会者达成•一致
的需求和未解决的问题。
3 . 主要原则
J R P 的主要意图是收集需求，而不是对需求进行分析和验证。实施 J R P 时应把握以下主要原则：
(1) 在 J R P 实施之前，应制订详细的议程，并严格遵照议程进行。//这是关键，也是目标和规划
(2) 按照既定的时间安排进行。
(3) 尽量完整地记录会议期间的内容。
(4) 在讨论期间尽量避免使用专业术语。
( 5 ) 充分运用解决冲突的技能。
(6) 会议期间应设置充分的间歇时间。
(7) 鼓励团队取得一致意见。
(8) 保证参加 J R P 的所有人员能够遵守事先约定的规则。
J R P 将会起到群策群力的效果，对于一些问题最有歧义的时候、对需求最不清晰的领域都是分有用的一种方法。这种方法最火的难度是会议的组织、计划和相关人员的能力，要做到言之有物，气氛开放。否则，将难以达到预想的效果。
备注：
JRP的目标是收集需求，而不是提供解决方案！！！！
11.2.5 竞品分析
分析竞争对手的产品是获取客户需要重要的手段！！！
11.2.6 需求记录技术
在需求获取的过程中，将会产生大景的信息，系统分析师要将这些信息有条理地记录下来，就需要借助一些工具。在信息系统开发实践中，有时候进行需求获取的人员和进行需求分析的人员不是同一个人（团队），有时候在同-一个项目中有多个系统分析师参加需求获取，因此，需要统一需求记录工具，以便让所有人的获取结果是同一口径的。
常用的需求记录工具有任务卡片、场景说明、用户故事和 Volere 白卡等。
1. 任务卡片
在各种需求记录工具中，任务卡片是一种比较简单的工具，它特别适合对业务活动级的信息收集与整理。常用的任务卡片示例如图11-2所示。在 图 11-2屮，各个项目的内容及解释如表11-3所示。任务卡片还有一个增强版，它的信息更加全而，如 图 11-3所示。增强版任务卡片在基本任务卡片的基础上，增加了问题点描述和解决方案提示。其中方案示例是针对问题点，系统需要实现什么样的功能，以便验证这些解决方案是否能够解决用户提出的问题。
2 . 场景说明：senario
有时候，系统分析师可能很难总结出子任务和任务变体，因为这需要对任务执行过程进行抽象。此时，系统分析师可以使用场景说明来对用户的描述进行整理，抽象出子任务。
简单地理解，场景说明就是用户对其工作场景和过程的详细描述，这些描述将在编写测试用例和用户培训手册中再次用到。
3 . 用户故事
用户故事描述了对用户有价值的功能，吋包括三个方面内容，分别是书面描述（用于计划和备忘）、交 谈 （细化故事）和测试用例（验证故事实现)。用户故事描述的传统形式是手工书写的用户故事卡，系统分析师辅助用户编写故事，告诉用户所编写的故事是进一步讨论的引子，而不是详细的需求规范。在任何项目中，需要用户团队根据故事的重要性来安排开发工作，回答所有开发问题，编写所有的故事。在编写故事之前应该建立用户角色模型，必须包含对项 H 成功至关重要的角色，尽量保证所有用户对系统完全满意。
用户故事具有6 个基本属性：独立性、可协商性、对用户有价值、可预测性、短小精悍和可测试性。
(1) 独立性。
尽讨能避免故事之间存在依赖关系，因为依赖关系会产生优先级和规
划问题。
( 2 ) 可协商性。
故事是可协商的，不是必须实现的书面合同或者需求。
(3) 对用户有价值。
确保每个故事对用户有价值的最好方式是让用户编写故事。
( 4 ) 吋预测性。
系统分析师应该能够预测（至少大致猜测）故事的规模，以及实现
所需要的工作量。
(5) 短小精悍。
故事规模对实现有影响，何种故事规模最合适，取决于开发团队的规模和能力，以及技术实现等方面。
(6) 可测试性。
所编写的故事必须是可测试的。
4. Volere 白卡
Volere 白卡是一种类似于任务卡片的需求记录工具，其格式如图11-4所示。
用户故事和 Volere 白卡定位的是最小的需求项，因此在实际应用中会导致量比较大,
一般在敏捷方法中使用。有关敏捷方法的洋细知识，请阅读8.3.4节。
系统分析师在选择需求记录工具时，既可以借鉴现有的模板，也町以根据自己的需要进行扩展或重新定义。另外，选择记录工具时要考虑项目团队所使用的开发方法、用户的实际情况、系统分析师的技能等因素。
