课件

8.6 需求获取技术.pdf

需求获取技术

Steve McConnell 说过需求获取过程中，最困难的不是记录用户需求，而是与用户探讨磋商，发现真正要解决的问题，确定适用的方案。

这里列出了一些最常用的需求获取技术：

• 面谈：适合在一样的时间、一样的地点，由少量人参与，由分析师驱动的获取模式；
• 问卷调查：针对不同时间、不同地点但是有广泛的大量的人参与，由分析师观察的获取模式；
• 群体诱导技术：适合在相同或不同的地点，但是是在同样的时间，由 20 人左右参与，由分析师参与的群体诱导的活动；
• 参与调查法：在同样的时间、同样的地点，由分析师参与，由被调查者驱动的需求获取活动；
• 文档分析
• 头脑风暴
• 情景分析
• 原型化方法
• 建模方法
• 需求讨论会

面谈

面谈说到底就是问问题听答案。

那么什么时候安排面谈这样的抽取方法比较合适？首先就是我们可以见到干系人，其次就是很少的干系人了解很多内容的时候，而且是干系人是真正的领域专家的时候，且干系人不能被聚到一起进行群体诱导的时候，也不需要干系人彼此之间进行交互来得到最终解答。以上这样的情况非常适合安排用面谈的方法来抽取需求。

面谈按其形式可以分为有组织面谈和自由面谈两类：

• 有组织的面谈通常要事先制订议程，问题可以是开放性的
• 自由面谈则没有既定的议程，可以是面谈者和访谈对象在现场临时安排即兴组织。

面谈的优点是：

• 通过面谈可以获得到大量丰富的数据；
• 有助于发现新观点、了解个人感受、发现目标和事实等等；
• 可以深入探讨，根据面谈前一个阶段获知的内容，动态地调整和补充后续的问题；

面谈的缺点是：

• 面谈获取的数据大都是定性的，比较难以分析
• 也难于对多个问题的回答者进行横向比较
• 面谈的技巧因人而异，也不是很容易掌握

在面谈过程中我们要注意的是不要去问无法回答的问题、基于隐含知识的问题以及脱离了环境和上下文的问题。另外面谈者的态度有可能会导致回答者产生一些有偏见的回答。

简单的面谈技巧：

• 在面谈开始的时候，可以谈一些比较轻松、不太敏感的话题。比如天气、体育比赛、受访者的照片、办公的陈设等等
• 在询问受访者是否同意录音后，将录音笔放在受访者面前，提醒他们可以随时关掉
• 先问比较容易回答的问题。比如关于个人信息您在这里工作多久了等等
• 根据对方提出的某些线索，继续提问，关注用户所说的那些能够暗示以现有的方法可能是错误的这样的情况，你可以说“您可以就此多谈谈吗？”
• 将自由发挥的开放性的问题放在最后，比如你还有什么想补充的、您有没有相关的经验等等

在安排基于访谈的需求获取过程的时候，要完成以下几个步骤：

1. 明确访谈的目的：确定我们通过访谈希望获得哪些方面的信息，什么情况下我们能够确定目的已经达到
2. 设计访谈提纲
3. 界定访谈的目标人群
4. 邀请访谈用户
5. 进行用户访谈：应用上面说到的访谈技巧，轻松开场，注意抽丝、挖掘，注意把控整个访谈的方向
6. 整理访谈数据：对访谈数据进行反馈讨论，也要整理规范化访谈的输出

访谈过程中注意：

• 避免一组固定的问题
• 优先关注用户行为背后的原因
• 避免让用户成为我们自己系统的设计师
• 避免讨论技术细节
• 避免诱导性问题
• 鼓励用户讲故事，讲他个人的观点

问卷调查

面对广泛涉众的时候一般采用问卷调查的方法。开始问卷前要先定义一组问题，问卷的结果收上来以后采用统计学的分析方法，使得问卷调查显得更科学。应用问卷的场景通常是：

• 有大基数的被访者
• 有基于良好定义的特定一组问题和答案
• 能验证有限次面谈得出的结论是否正确
• 当需要一个特定的结果的时候，可以采用相应的问卷设计来获得我们对既定结果的输入的收集

问卷调查的优点是：

• 可快速获得大量反馈
• 可以远程在线执行
• 可搜集关于态度、信念及特性的信息

问卷调查的缺点是：

• 由于问卷简单的分类，往往导致问卷是往往是脱离上下文的
• 留给用户自由表达其需要的空间相对较小，更多是选择题的方式

问卷调查注意事项：

• 选择样本时尽量减少可能存在的偏见
• 自愿的问卷回答者可能存在一定的偏见
• 避免样本规模太小
• 自由发挥问题难于分析
• 对答案有诱导性的提问也会导致问卷本身存在一定偏颇
• 问题设计的妥当性及含糊性都会影响问卷调查的数据采集质量

问卷调查也需要原型化的方法和测试，在设计好问卷以后可以寻找几个受访对象，对问卷进行测试，看是否其效果是问卷设计者预期的效果

群体诱导技术

群体诱导技术在执行的时候往住往是在同一个会议地点中，聚集 3~20 个干系人，每个人都将自己的观点大声说出来，这时群体的答案往往要比个体提供的方案要全面。

以下情况适合采用群体诱导技术：

• 当每个人都只有关于整体的部分知识的时候
• 人们需要彼此交互来对答案进行优化的时候
• 当我们能够让这些人在同一时间聚在一起的时候
• 如果要保持每个人的匿名性，可采用一些工具，让他们彼此间隔离进行
• 在不同的地方进行群体诱导也可以采用一些工具

群体诱导技术按其组织形式有以下类型:

• 一类是专题小组会议
• 一类是头脑风暴

优点：

• 人们的交互比正式的面谈来的自然
• 人们之间可互相激发，抛砖引玉，可运用实体模型、故事版，使群体诱导变得更有趣

缺点：

• 分组不一定自然 (可能会令某些参与者不适应) ，由此出现少数服从多数所带来的偏见和风险
• 对技术问题的探讨往往只是表面化的回答，没有面谈来的深入
• 群体诱导的成功执行需要训练有素的协调人

群体诱导过程中的注意事项：

• 避免样本选择的偏见
• 可能在诱导过程中出现统治与屈从的情况
• 当群体诱导由几个人控制时，引导者需要站出来，为每个人分配5分钟的规定时长，来陈述他们的观点，以确保每个人都有说话的机会
• 当发现有些人参与度不够时，引导者需要站出来，给每个人法“好主意”券作为一种激励机制
• 当出现无理取闹的参与者时，发放“恶意中伤” 券，惩罚那些发言不够严肃的人

需求研讨会

需求研讨会的目标是介绍项目的成员和干系人，收集需求列表，并在会议过程中，运用头脑风暴、故事板、角色扮演、现有系统评估等方法获取需求。

其指导原则是由主持人组织研讨，给每个人发言的机会，保持研讨话题的相关性，定义每条需求的属性，记录新需求的发现，并在最后总结所获得的需求，就需求给出大家的决策和结论性的意见。

会议

会议是一种重要的需求获取的途径和方法。可以用于总结获取成果、取得用户反馈，在每个阶段结束的时候与干系人安非会议，讨论信息搜集阶段取得的成果，对需求作出结论性的意见，并为某项设计取得大家的共识。通过会议，我们可以确认所获得的信息，讨论新的发现。

同时，会议也是一种重要的管理手段，用于推进项目开发的进展。会议的执行需要首先确定会议执行的目标，要对会议进行仔细的筹划，确保会议是有效的、有目的的。

以需求获取为目的的会议可能存在的目标：首先是对需求内容对陈述、介绍，解决遇到的问题，协调矛盾的需求，分析项目进展，搜集和汇总数据，用户培训，对下一轮进行规划。

在会议的执行之前和过程中，需要进行仔细的规划和安排，首先在会前要进行日程及设施的安排，确定日程后要提前通知给所有与会人。根据会议的目的决定会议的组织形式。在会议执行期间，要控制好会议的进度。事后要对会议进行书面总结并给与会人发放会议记录。正式的陈述报告、项目预演、头脑风暴遵循其执行规则。

头脑风暴

头脑风暴的目标是是要通过群组效应，激发大家对新产品、新系统的新想法。它在需求不完全明确的情况下比较有用。

进行头脑风暴的指导性方针包括：

• 要采用有组织的研讨会的形式
• 做到大家百花齐放，不评价、不争论、不批评
• 不受现实的可行性的限制
• 新观点的采集和产生多多益善
• 大家彼此之间抛砖引玉、互相启发，其目的就是为了获取尽可能多的新观点，是一个发散的过程

参与观察法

参与观察法是让分析师深入到干系人的日常工作环境中来，从侧面观察干系人的行为，在这个过程中，分析师的角色越被动观测效果越好。需要注意的是，分析师从旁观察可能影响到了干系人的行为，也就是说观察到的结果可能和干系人的日常行为存在一些差异。观察参与者时，要进行相应的“动作研究”，那什么时候进行观察呢？那就是当有人或事需要观察才能获得相关信息的时候，也是当干系人的知识无以言表、是行为指使的时候。

参与观察法是一种面向纵深的调查方法，由于观察者参与到被观察对象的日常活动中，成为组织中的一员，因此该方法的优点是：

• 总是上下文相关的
• 能够发现其它方法无法发现的一些细节

而缺点有：

• 时间成本和代价比较大
• 获取过于丰富的细节知识，难于将无关细节去除
• 无法就改进建议所带来的结果给出更多评价

注意事项：观察者往往由于参与到环境中，过于深入，有被同化的危险，失去了客观的立场。

亲身实践

亲身实践与参与观察有一定的相似性，但又不尽相同。参与观察的过程中用户是从旁观看，而且亲身实践是通过观察、提问甚至亲自操作，来更精确地了解工作内容。它建议实时实地的开展实践工作，并获得干系人的及时的反馈。

亲身实践的适用场景是：

• 当用户太忙无法安排专门时间来参加面谈时，可以由工程师到用户的工作场景中去亲自实践任务的流程
• 人们往往只是在既定的流程中完成相应的工作，并没有意识到每天的工作实际上是在做什么，换句话讲，是下意识地完成这些任务时，通过亲身实践能够更好地恢复出工作的流程和步骤
• 实践者通过反复的观察干系人执行该动作的过程，并且学习任务的技能反过来做给用户看，让用户确认他所做的步骤是否正确，从而获得第一手的实践知识和任务相关的描述，这样做也有利于与用户和顾客建立密切的沟通联系，为后续的工作奠定很好的交流的基础

文档分析

文档分析是一个非常好的入手点，它的目标是为了理解待解决的问题，可以作为下一步做业务流程建模和访谈的前期基础。

进行文档分析的指导方针包括：

• 要确定当前的业务流程或者产品的优缺点
• 找出产品或信息中可以重用的部分
• 从多个来源抽取用户的需求

原型

仿真原型是用户最偏爱的需求获取手段之一，它的目标是为了：

• 明确那些含糊不确定的需求
• 简化需求文档，确认需求
• 尽早获得最终用户和容户的反馈

它的适用场景和指导方针是：

• 用于确认需求
• 用于提供需求评估的数据基础
• 用于评估不同的用户界面方案
• 帮助用户可视化关键的功能
• 直观、有效的沟通工具

情景分析

基于情景的分析方法是课程要重点介绍的方法之一，情景分析的主要目标是要清楚地定义有用户参与完成的业务事件的步骤，获取对用户来说可见的系统动作。

与其它方法相比它有着得天独厚的优势，因为对用户来说它几乎不需培训，用户只要直接写出它期望的与系统交互的流程，就已经是情景分析最好的素材。

情景分析的适用场景和指导原则是：它要确定与用户间可能的交互活动，具体包括定义业务事件以及感兴趣的领域性质。我们将业务事件细化为具体的业务活动和业务过程并将其描述出来，形成情景分析的结果。

概念建模

概念建模是我们课程要重点探讨的另外一项研究内容。概念建模的目标就是要图形化的手段描述现实世界的问题，建立未来系统的模型，对未来系统进行抽象的表示。在建模过程中对原始需求进行评估和扩展，得到清楚、完整、正确、一致的需求描述。

它的指导原则主要是对系统进行不同角度的抽象，建立不同类型的模型，例如：

• 对系统分而治之、对子系统的结构进行描述的分解模型
• 对数据进行描述的 ER 模型
• 面向对象模型
• 以描述行为为中心的用例模型、过程模型、活动模型等等

竞争性需求分析

我们在软件产品的设计过程中，其实是有两种创新的程度，一个是演化型的产品的设计，还有一类是全新产品的设计。在新产品的设计过程中，首先要对它进行系统的分析和评估，这里我们给出一种基于竞争性需求分析的框架，该框架为我们提供了五个思维基点，让我们对新的产品的策划进行可行性的评估。

竞争性需求分析框架：

• 需求Need：首先我们要了解的是新的产品的创意是不是解决了用户的需求？解决的用户的哪方面的需求？这个明确需求的过程就是我们获得市场上用户认可的一个基础。
• 方法Approach：在方法这层面，我们找到了需求以后下一步该怎么办？我们是不是有独特的方法来解决用户的问题？这些新鲜的方法不仅仅是技术上的，也可以是商业模式上的，比如可以是关于这个产品运行的地域、使用人、行业或者是成本方面，只要是在任何一个方面我们有了独特之处，那么该产品就是有可能吃立在市场上不被打败的。
• 收益Benefit：即评估新产品可能给用户带来的收益。此时我们既有了独特的做法，又有了用户的需求，那么我们就要了解这个产品给用户带来的真正好处是什么？如果它已经有了现有的解决方案的话，那我们用什么方法能够让它离开现有的产品来使用新设计的产品，这是一个关于用户迁移成本、用户代价的权衡利弊过程。
• 竞争Competition：即评估我们这个产品的竞争力有多大、市场有多大，有多少竞争者在瓜分这个市场，我们的新产品如果不是最先进入市场的，那么有没有取得成功的可能性，这里就涉及到先发优势和后发优势这两个方面，所以竞争性的需求分析最核心的问题就在于看清新产品的优势在哪里、劣势在哪里。
• 推广Delivery：产品研发完成后我们如何去交付和推广，交付和推广实际上在新品的成功中也扮演着重要的角色，一个好的产品无法推广到用户的面前，那么它也是很难得到广泛的应用获得市场的成功的。

A/B测试

许多互联网公司都在使用A/B测试的方法，研究人员也用这种方法进行研究。

A/B 测试看起来很简单，如果你的产品已经有用户在用，但是你想对用户界面做一些改进又不知道用户是否会欢迎这样的改进时，我们就可以配置A/B测试环境。

步骤：

1. 选定要实验的是哪两种不同的 UI
2. 确定衡量界面的标准
3. 确定数据搜集的流程
4. 确定试验运行的时间和人数，通常我门选择 5%-10%的全量用户
5. 通过技术实现A/B测试环境的搭建
6. 搜集用户的行为数据
7. 分析数据
8. 最后得出我们要得到的实验结论

在A/B测试过程中我们最主要的是要获得系统和用户之间交互的反馈，比如在下边的图中，AB 两种方案中我们最终得到 B 方案获得了更多用户的正面反馈，因此在这个测试的过程中我们得到的结论是 B 方案优于 A 方案。

用户行为数据在线采集

互联网平台目前成为软件运行的基础平台，这使得用户行为数据的采集成为可能，许多软件提供商都在线的将用户访问数据进行分析和统计，由此得出对下一步新产品设计的启示。

能够访问到的用户的数据包括交互过程数据、眼动数据、页面访问时间、页面访问内容、用户偏好等。

基于平时的日常交互数据的采集结果，我们可以对操作数据进行统计分析，包括：用户偏爱的厂商、版本、用户访问的 IP 地址和所来自的地域、产品的日访问量和访问频次、用户的身份、平均访问时长以及用户的打分等等。

通过对这些数据的分析我们能够得出一些关于用户偏好以及产品现在表现的基本数据证据，由此推断出下一步对产品的改进。

获取技术选择

上面介绍了众多需求获取技术和方法，在选用时我们要根据获取的需求的具体内容来有效地选择。例如，获取界面需求时，原型法、情景法和建模法是比较有效的；在获取业务逻辑时采用观察法、亲身实践、面谈和情景的方法则有利于业务逻辑的精确理解和描述；对未来系统的信息和数据结构进行获取时，面谈、现有系统的分析是最行之有效的：

要建立完整精确的需求模型很困难，建立完整的原型也不是很现实，因此我们要根据需要和客观条件灵活地搭配组织运用，形成针对一个具体问题的最有效的获取方案。

注意事项

用户需求获取是一门倾听的艺术

也就是说在需求获取中，我门更要关注的是导干系人让他们更好地、更多地提供有价值的信息，需求分析师的作用就是协助、鼓励干系人表述他们的需求。

什么是“足够好”的需求管理

由 Alan Davis 教授提出的 Just Enough Requirements Management ，也就是足够好的需求管理，他提到什么是足够好的需求管理，足够好就是要让你完成用户的预期的功能，让用户满意，但是又没有在需求管理过程中消耗掉所有的项目时间和精力，使得没有足够的时间和精力去做开发。正如足够多的人寿保险，买的保险足够多，使得我们晚上可以睡得安心，不会担心我们所关心的人会得不到足够的照顾，但我们还没有买太多的保险使得我们会担心明天支付不上保险的预付金。

比谁更聪明？

假如一个客户来找你，跟你说“我的电梯太慢了”，你是直接跟他说“我不这么认为，我觉得你的电梯有吞吐量问题而不是速度问题”，还是静下来耐心听他说“好的，告诉我为什么你觉得它们是慢的”，这两种截然不同的态度就代表了面对一个用户的时候，正确的和错误的态度。在和客户沟通交流的时候，不要尝试向干系人证明你是更聪明的，要抓住所有的机会表现出你认为干系人是聪明的，这样他们才更愿意跟你分享他们认为对的事情，以及他们真正的痛点是什么。

维护术语表

实践经验表明，很大一部分需求沟通的错误都是由术语表达存在歧义造成的。确定术语表的时候，我们要针对关键的术语询问，该术语的含义是什么？并把所有已经取得了共识的术语的定义明确地写出来，这样为后续的阅读者和参照提供依据。

采用合适的需求获取技术

在需求获取过程中，只采用一种抽取技术是不够的，技术的选择和项目的参与人相关，与待理解的需求相关，与具体的应用领域相关。