需求调研的阶段组成.docx

需求调研指南

文件变更记录

*A - 增加 M - 修订 D - 删除
变更
版本号
日期
变更类型
（A*M*D）
修改人
变更摘要
备注

1. 需求捕获技术
在需求捕获中最常见的技术就是：
² 用户访谈
² 问卷表
² 小组会议
² 分析同类软件产品。
² 参考行业标准、规则。
² Internet上搜查相关资料。
上述的各种技术在特定场合都能很好发挥作用，应该好好的考虑在何时使用哪项技术。在大多数项目中，捕获需求不可能只采用某个技术。实际情况中，项目组会根据不同的涉众团体采用不同的方法。
1.1 用户访谈
用户访谈一般在下列情况使用
² 需要与少数几个人，进行大量的知识交流
² 项目团队能够与他们会谈
² 无法一次性收集所有涉众的需求
用户访谈一般会经历五个阶段：
² 准备访谈
² 计划和安排访谈日程
² 访谈开始和结束
² 引导访谈
² 后继的访谈整理工作
1.1.1 准备访谈
在进行访谈前，需求分析者应该很好的理解组织结构，行业定位和项目范围和项目目标，访谈会涉及下面内容：
² 组织结构报告
² 年度报告
² 长期发展计划
² 部门目标的陈述
² 已有程序手册
² 系统文档
需求分析者应该理解一般的行业术语（术语表）并且还要熟悉行业上的业务问题
1.1.2  计划访谈日程
准备列表，列出主要话题或问题。这些问题可以找出未意识到的重点，还能有逻辑的引导访谈进行。安排访谈应遵循自上而下的进行。首先访谈部门或地区的领导，然后才是他们下属的雇员。在邀请对方进行会谈时，要解释这次会谈的目的，一般会涉及哪些领域，以及大致需要的时间。
1.1.3 访谈开始和结束
开始访谈时，先介绍你自己，陈述这次访谈的目的，谈谈被访谈者关心的事，并说明有一些简短的会谈记要，在整理后会交给对方审阅。  一般被访谈者认为需求分析者试图找到他们工作中的缺陷。使他们摆脱这种观点。可以讨论他们所熟悉的日常工作的过程。好的访谈者会让被访谈者作为主讲人。因此，需求分析人员应该寻找一些问题让被访谈者对他们开诚布公：
  例如：
  “怎样的变化将使你的工作更简单或更有效？ ”这个问题暗示被访谈者提出改进意见。
  当列表中的所有领域都讨论过后，提出下面问题：
  “还有什么问题我们没有讨论吗？”或是  “我们还需要讨论些别的内容吗？”
  这些问题鼓励被访谈者提出所有应该被讨论的问题。
结束会谈时，一般会简短的总结讨论过的问题，重点指出会谈的要点，并说出你的理解。这使被访谈者知道你认真倾听了谈话，而且有机会澄清误解。在总结会谈以及整个会谈中，需求分析者应采取客观的态度，避免带个人色彩的评论，观察或结论。最后，你必须感谢被访谈者参加这次访谈。如有必要，询问被访谈者能否在近期再参加一次简短的后继访谈活动。
1.1.4 引导访谈
   在访谈中避免提封闭性的问题，因为被访谈者通常会简短的回答完这样的问题，然后等待下一个问题。这样就象是侦探在审问犯人。封闭性的问题：（谁，哪里，什么时间，哪一个）：
² 限制了被访谈者提供信息的类型，层次和数量。
² 通常提供了二选一的回答， 暗示了较极端或不确定性的回答。
² 一般用于澄清问题，探索性提问或仅是希望得到反馈信息
² 花费较少的时间得到细节信息
² 比较容易作笔记
² 有时只能得到很少的信息
² 可能导致被访谈者无法自由提供信息
² 对相关术语和词汇的要求高
在开始一个议题时，一般会用开放性的问题，便于被访谈者展开思路。然后，渐渐转为结论性问题，这样能帮助证证实你的理解。太多的关闭性问题会导致收集的信息不完整，太多的开放性问题可能导致需求分析者的理解失误。
为了会谈后的整理需要，一般会使用简明的符号来做笔记，否则做笔记会使你分心。最好将笔记本放在被访谈者视线外。需求分析者的笔记有助于会谈后回顾要点和会谈时形成的想法。最好是会谈时指定一个记录员。使用录音机也是个好主意。虽然会谈后整理信息会耗费些时间，因为需求分析人员需要听完整个记录。不特别推荐使用录音机，这会使被访谈者有被胁迫的感觉；而且倾听录音，记录其中要点也是耗时较多的工作。无论如何，音频视频记录有优点也有缺点。认真倾听有助维持需求分析者和被访谈人之间的信息交流，维持相互之间适当的反馈。
 认真倾听有五个关键方法
n 询问开放性的问题
 开放性问题无法简单的用事或否来回答，应此被访谈者就会提供更多的信息。开放性问题一般会使用这些词语做开头，如什么，怎麽样或是告诉我。而不会使用诸如能够，要作或是何时这样的词语。列举一个需要详尽解释的问题，“告诉我，当顾客打进电话时，什么情况发生？”
开放性问题: (什么, 为什么, 多么)
  · 涉及比较宽广，加在被访谈者上的约束很少
  · 用来确定理解范围。被访谈者会使用明确的回答或是模拟演示来传达需求分析人员不了解的内容
  · 可以得到被访谈者的行业词汇，概念和可参考的知识框架
  · 有助于增强理解，得到一些潜在的理论
n 使用适当的表达
避免使用有感情倾向，让人分心或是难以理解的语言。类似于问题存在于，讨厌的处理过程或是无法控制这样的有感情倾向的语言容易暗示某种结论。避免使用让人分心语言。这些语言包括过多的缩写词或首字母缩写，显示自己才识的语言，有争议性语言，俗语，俚语以及行话。
n 暗示相信被访谈者
人类会使用说话的语气，眼神接触，面部表情，身体姿势和身体的移动来传达某种信息。正确使用，会使被访谈者提供更多的信息。例如，在访谈中避免眼睛接触会被理解为缺乏兴趣，或是对其他人更感兴趣。适当的眼神接触会传达出感兴趣，关注，开放的接受并且尊重别人的见解。 太频繁的眼神接触会被误解为盯着对方。在我们的文化中，如果两个陌生人间眼神接触时间过长则意味着挑战。在其他的一些文化中，会被认为是侵犯隐私。点头表示理解，暗示接受；类似的，表示关注的姿势：端正坐着略向前倾。
缺少经验的需求分析人员通常会犯下面的错误：
² 靠在椅子后背上，双手合拢抱在胸前。这种姿势暗示了不太接受正在讲述的内容，也显示出需求分析人员处于不安的状态。
² 看着屋内的物品或是直盯着窗户，而不是看着被访谈人。这表明需求分析人员更宁愿在其他的地方做其他事，被放谈者通常会缩短访谈的过程。
² 忙于做笔记或是经常翻阅笔记。较之倾听而言，需求分析人员对自己的记录更感兴趣会使被访谈者好奇，到底他记录了什么。
² 坐得太远或太近。坐得太远象是暗示被访谈者会威胁到需求分析人员，坐得太近又显得不恰当地亲密，被访谈者会感觉不自在。
相信的暗示表达了理解而不是同意。
n 重述被访谈者的回答
重述回答是指需求分析人员用自己的语言复述被访谈者的陈述。这显示了两者间进行了有效地沟通，需求分析人员理解了被访谈者的陈述，重述回答一般用在以下场合：
² 访谈者描述一个问题时。这时，需求分析人员的复述表明听见并理解了访谈者的问题。
² 当需求分析人员想检查他的理解是否正确时。这个技巧大多是遇到复杂的陈述时，或是多人参与时，每个人对同一问题有各自不同的见解。
² 需求分析人员希望鼓励访谈者时。重述回答会暗示被访谈者扩展或是详细说明他曾说过的内容。
  重述回答也能克制住因某种原因，不原配合的人
  需求分析人员必须保持中立。例如，如果被访谈者批评现有管理模式，需求分析人员不应该赞同他的批评或是为现有管理模式辩护。需求分析人员只需要表达出被访谈者的感觉是可理解的。
重述问题常见的错误：
² 重复被访谈者的话，例如，完全重复被访谈者的话而不是使用其他的表达方式。一段话讲完后被完全重复一遍，会使被访谈者感觉不安
² 过多重述回答将使被访谈者分心。
² 改变或是歪曲被访谈者真实的意愿。重述应该尽可能的接近被访谈者的意思
² 在复述结束时提高声音。这个习惯会使复述变成一个问题，会暗示被访谈者回答是或否，而不是让被访谈者扩展他的解释。
这儿有个例子显示了有效的及无效的复述；
  被访谈者的回答：顾客没有支付帐单，我们也会继续销售产品给他们。
  无效的复述：在你们处理定单前为什么不检查顾客的信用状态？（扭曲了被访谈者的意思）
  有效的复述：系统也会处理有信用危险的顾客的定单。（鼓励被访谈者扩展发挥）
n 有效的使用沉默
在提问结束时允许被访谈者收集整理他们的想法。当被访谈者回答不完整时，鼓励他们继续。在会谈已文字记录后，使用封闭性问题可以澄清理解。
1.2 问卷表
问卷表是需求捕获时广泛使用的另一种工具，它采用了统计分析的方法，显得更科学。问卷表一般在下列情况中使用
² 需访谈的个体太多
² 需要回答容易确定的细节问题
² 当你希望有个详细的结果时
  准备问卷表时，注意以下情况
² 使问卷表尽可能的简短。用多个短小的问卷表替代一个长的问卷表。如果在回答了前一五-20个问题后，长的问卷表会使用户感觉厌烦，他们就不会对其余的问题做出正确的判断。通常，一个问卷表包含的问题不超过10-一五.
² 估计回答问题需要的时间，并在问卷表开头标明这个时间，已便让回答者做出相应的安排
² 确保问题是前后一致的，没有让人含混的理解
² 为了保证不会理解含混，让与回答者关系密切的人员来进行问卷调查，并保证他们对问题的理解是正确的。
² 在制定问题前，先确定你需要得到怎样的答案
² 分别列出所有可能的答案
² 一旦所有的需求和问题都准备好了，把需求点当作X轴，问题当作Y轴。确保所有的需求能被问题覆盖。最后，剔除掉与需求无关的问题。
1.3 小组会议
小组会议一般在下列情况中使用：
² 信息平均的分布一小部分个人中
² 无法个别的会见所有的涉众
² 一系列的访谈已经结束，团队需要在同一平台下得到所有的回答者
  在小组会议中，每个人都可讲出自己的想法。团队的答案一般比个人的答案好。小组会议可以减少一部分需求冲突，绕开纷繁的情况得到需求列表
  如果小组会议管理不好，容易出现下列情况
² 少数与会者控制了讨论
² 一部分与会者缺缺乏参与讨论的积极性
  为避免这种情况，需求分析人员要推动讨论的进行。要鼓励缺乏积极性的与会者参与讨论，先直接向他们提一些封闭性问题，然后逐渐转为开放性问题。
  首要的技巧如提一些开放性问题，复述回答来确认理解，建立清楚的议程，指定记录员记录会议等都可使用。
其它一些注意事项：
² 提前确定会议地点，在发出与会邀请时提供路线图。这在一些大公司尤为重要，并不是每个人都熟悉整个办公大楼。
² 提前制定座位安排，平均分布需求分析人员，这样确保所有的回答都能被听到。
² 如果可能，在会议开始时宣布一些希望大家遵守的基本准则，如尊重别人的观点，关闭手机等
² 牢牢控制讨论的话题
² 如果可能，使用录音机，这样能更专注于讨论
² 好好的准备小组会议，所做准备要“N”倍于个人访谈的准备，这里的“N”是指参与讨论的涉众人数。
² 如果这个会议是最终确定需求，而不是探询需求，可采用工作原型演示的方法
² 在小组讨论结束时，感谢大家抽出时间参与讨论，告诉大家整理确认需求的计划并传阅会议纪要。

2．需求调研的阶段组成
 需求捕获的活动可大致分成下面四个阶段或步骤：
² 场外准备
² 现场启动
² 现场执行
² 场外分析；
场外准备
挑战
指导
1、缺乏场外准备的指导手册
2、项目启动没有足够的时间。
3、 项目的范围和类型缺乏清楚定义
1、 使用列表来列出在场外准备阶段需要做的所有工作。
2、 在提出进度安排时要包括足够的准备时间，同时要考虑团队规模等因素。
3、 不采用全面现场启动的方式，而启动一个领航似的小团队来估计项目涉及的范围。
需要的培训

1、需求分析培训未进行
2、需求分析提供的材料太多了
3、需求分析没针对系统增值和技术领域
4、公司组织的培训不是针对项目的
1、 确保在现场启动前，所有的项目组成员参加过需求分析培训，或在近期经过培训。标准不是关键，经验才是关键。
2、 获得公司培训的帮助，定制需求分析课程以适应你的项目类型。使用定制组件的方法剪除不相关的部分。
3、 设计培训内容以满足项目需要。要提前执行系统的课程设计过程来达到该目的。
现场启动
启动问题

1、 现场启动会议缺少指导手册或议程安排
2、 缺少时间或缺乏紧迫感来开始收集需求
1、 提前计划会议，并通知客户议程安排，需要的时间和希望参加人员
2、 与客户讨论启动会议的意图和希望取得的结果
3、 第一次“预启动会议”要熟悉客户的高层领导，介绍项目团队的大概情况，告之需求捕获的基本过程，分析可能存在的问题，确定问题解决流程等
4、 第二次“启动”会议要召集两方所有的涉众。介绍项目团队成员，共享资源等。如座位安排，进度表，里程碑，需求捕获的过程，交流方法，确认客户期望值，描述办公室位置，文化特点等
现场执行
挑战
指导
质量体系文档 
1、 质量管理体系文档（QMSD）无法提供必要的过程帮助
2、 必须使用客户的过程体系
3、 在客户现场无法得到质量管理体系文档（QMSD）工具包
1、 将项目中得到的最好的实践经验添加到工具包中
2、 针对项目的类型，问题域，方法论等特点建立项目帮助
3、 求助流程改进部门，获得项目详细的过程帮助
软技能
1、 对于期望达到的目标缺乏坚定信心
2、 项目团队成员要使用本地语言? 口音问题
3、 书面表达能力不强
5、 着装问题
6、 个人卫生习惯
7、 太好强或太害羞
8、 不能明确或清楚地表达想法
1、 规定行为准则并告之项目团队中每个成员
2、 周期性的在项目团队内部进行讨论，指出达到的目标需要坚定信心
3、 建议用降低语速的方法解决口音问题。
4、 在会谈中要确认会谈另一方容易理解会谈内容
5、 进行邮件和文本讨论来确保沟通良好
8、 帮助害羞的队员，使他们能深入需求捕获活动
9、 必要时，可以干预那些过于好强的队员
10、 必要时，在现场执行的初期识别出那些太好强或太害羞的队员，尽量少安排与客户沟通的工作
11、 指导缺乏相关工作经验的团队成员
12、 必要时，制止散漫的情况
方法论的确定 
1、 没有已确定的方法论
2、 了解的方法论很少
3、 不能比较各种方法论的优缺点
1、 如果客户不指定方法时，跨项目的过程方法应该标准
2、需求分析培训课程应该强调方法论。要求培训部门在为你的项目需求设计课程时，注意此目的
3、 在需求分析培训课程应要求信息交流做相关培训
4、 请过程咨询顾问为项目制定一套标准
5、 创建过程基准
6、 在软件工程技术理论的帮助下识别系统收集需求的过程
需求的变更 
1、 收集的需求很少
2、 需求表述含混
4、 并非所有的用户组都能参加需求捕获阶段的工作
5、 项目范围不好控制
6、 无法得到需求的认可
7、 时间安排不充足
8、 系统的边界范围不确定
1、 进行周期性的需求回顾来去掉含混的需求
2、 在需求分析的课程中，培训需求书写技巧
3、 在需求初期，按涉众类别进行条理清楚地分析
4、 在需求捕获启动会议上设计好逐步确认涉众的过程
5、 在开始下一个生命周期前时，要确认客户已认可需求
6、 说明需求阶段成果评估的原则
7、 说明系统边界评估的原则
工具 
缺乏需求捕获工具的了解
在需求分析课程中包括必要的工具培训
项目的依赖性 
1、 无法清楚定义系统接口
2、 并非所有的系统接口都有文本描述
3、 用户并不了解所有的系统接口
4、 获得外部接口信息有困难
1、 使用系统接口文档模版
2、 对每个接口进行影响力分析
3、 使用跨功能（部门）团队来进行接口研究
4、 全面理解组织现有（As-Is）系统或工作模式
5、 提前计划好外部接口的分析，并建议客户的IT团队参与分析
需求冲突 
1、 并非所有人都清楚商业目标
2、 用户组不同步
3、 已取得的需求与期望要求之间的差距导致冲突
4、捕获需求的目标用户组不正确
5、 用户组的关键领导人无法解决争议
1、 在现场启动会议上对所有的涉众解释商业目标
2、 与最高管理层确认商业目标后，将商业目标写成文档并传递给所有的涉众
3、 召开冲突解决会议并充当中间人角色，解释冲突两方面的观点
4、 在需求文档中，重点标示已有问题和假设
5、 扮演涉众的角色，让他们确认你理解他们在目前系统中的责任
6、 详细说明增加了的业务规则并保证能正确使用
7、 确定IT工作和商业团队的结合点
涉众识别 
1、 缺乏适当的架构来识别涉众
2、 缺乏对客户结构的认识
1、 使用标准模版和框架来识别涉众
2、 项目团队应检查整个建议的涉众，并确定要重点关注的。
3、 在现场执行前，请销售经理召开技术支援会议
4、 现场启动会议要包括已识别的涉众
5、 告之所有的涉众，你对他们在目前系统中的责任的理解，以及需要他们提供的帮助
现场复审 
1、 缺少现场复审
2、 在复审现有提交物时，客户缺乏兴趣
1、 建立现场复审的指导原则
2、 在项目开发的过程中要包括现场复审
3、 在进行现场复审前，安排项目团队进行复审机制的培训
4、 根据提交物的不同确定不同复审方式，并相应安排项目组成员参加复审
5、 邀请客户参加复审前，先进行一轮内部复审
6、 提前准备复审计划并得到客户同意
7、 避免与客户多次复审同一个提交物，这可能导致大家缺少兴趣，产生错误观点
文化交叉问题 
1、 不遵守时间
2、 有忽视文化交叉的观点
3、 太开放而感觉不适应
1、 在最初列出行为准则
2、 周期性召开内部会议以鼓舞士气
3、 集体讨论所有已知的文化差异问题，并提议适当的指导原则
4、 对所有的项目成员队员进行文化差异敏感性培训
5、 从了解相同客户和地区的人员那里收集文化细节信息
问题域 
1、 缺乏商业分析（BA）人员
2、 捕获的需求不够详细或不完整
3、 获取信息的权限不具备
4、 团队无法对工作过程的改进提出好的建议
1、 在项目范围中考虑问题域的复杂性
2、 安排领域专家做场外评审
3、 从客户团队中邀请商务专家在问题域可改进部分，创建新的业务流程
技术 
1、 新技术缺少培训
2、 缺少技术架构师（TA）但需要开发新的技术架构
1、 寻找受过培训的技术架构师(TA)，让他培训团队中的其他成员
2、 在项目范围定义时考虑到技术复杂性

其他 
1、 客户的业务部门和IT部门的冲突
2、 两个业务部门间的冲突
3、 对客户而言，讨厌工作变成机械性操作
4、销售团队不适当的期望植
6、 并非所有类型的需求都收集了，例如性能需求
1、 采用成本利益分析的方法解决冲突
2、 识别违反标准的提交物需求
3 、 确认新扩展的业务标准，改标准正常的应用
4 、产品期望值的设定要依次通过需求获取（RE）小组、销售经理(AM)。在场外的技术支援计划会议上，将设定产品期望值安排为一个议程
5 、使用预先定义的模版来收集性能需求
6 、观察用户的活动，详细理解并识别性能需要，花一天时间与用户待在一起，观察他们的工作模式，得到工作量的模型，用户响应时间，系统瓶颈，系统负载与时间模式，以及系统响应时间的需要
现场最佳实践
 计划两次现场启动会议：第一次与高层管理人员，第二次与双方所有风险承担人。 
² 在第一次现场启动会议上介绍项目组的概要情况
² 会议纪要在交给与会者传阅前，要通过内部评审
² 使用录音机记录讨论会议的情况。这样团队就有更多的时间积极参与讨论，同时也显得更专业
² 预先确定座位，使项目组核心成员和客户间隔而座。提前到达会议室5到 10分钟，依次入座。这种排座方式建立了融合的氛围，避免象谈判对手似的对立，也有助于倾听嗓音低沉者的发言
² 集体讨论所有已知的文化差异问题，并提议适当的指导原则
² 从客户团队中邀请商务专家在问题域增值部分创建新的商务流程
² 召开一个现场会议感谢大家花费时间提供帮助，移交需求文档，分享将来的计划，介绍产品中角色设定和职能划分等
² 观察用户的活动，详细理解并识别性能需要，花一天时间与用户待在一起，观察他们的工作模式，得到工作量的模型，用户响应时间，系统瓶颈，系统负载与时间模式，以及系统响应时间的需要
场外分析
挑战
指导原则
现有系统研究 
1、 缺少时间
2、 研究现有系统获得的收益不明显
1、 让场外小组同时研究目前的系统
2、 研究现有系统，提炼工作流程
3 、 确认用户是否对期望于现有系统（As-Is）进行研究
专门的小组 
1、 在需求获取阶段无法咨询
1、 在项目范围定义时考虑技术复杂性
2、 考虑技术架构师（TA）加入项目团队中
3、 考虑从场外获得咨询支持
工作划分

1、 缺乏详细的场外需求分析（RA）的指导
2、 缺乏文档书写技巧
3、 场外分析该做什么？
4、 需求无法转递给场外的人员
1、 需求分析（RA）阶段的细节范围，定义了场外分析要做什么
2、 从类似的项目中得到输入信息
3、 使用一些简单的需求文档作基准
4、 确定需求文档一致性检查列表
5、 计划内部的需求文档审核
6、 场外分析人员可做以下工作
  o 技术研究
  o 继续深入，取得详细要求（Follow-up on h/w & s/w procurement）
  o 验证一些想法
  o 为下一个阶段做准备或评审提交物
  o 进行问题域指导，尤其是缺少业务分析（BA）人员的问题域
  o 利用现有系统验证需求有效性
  o 研究现有系统
  o 建立用户（UI）界面原型
  o 需求文档的整理和装订
7、 分析使用以前项目的场外资料
8、 请场外分析人员阅读需求并识别其中的缺陷
问题域 
1、 需求不够详细或是不完整
2、 访问相关资源的权限问题
3、 团队无法对工作过程的改进提出好的建议
4、 场外团队没有问题域经验
1、 公布问题域细节信息的WEB资源
2、 定义问题域细节知识成熟度模式
3、 在教育和研究部门的日程上安排问题域知识的培训
4、 在资格认证组织的帮助下为场外团队召开问题域理解会议
5、 为提高学习问题域知识的兴趣，搞些问题域测试
技术 
出现新技术但缺少培训
1、 为场外团队提供详细的技术培训
2、 要求团队成员参加相关技术的短期技术研究会
其他 
1、 缺乏参与项目的积极性和基本的责任心
2、 由于时差关系，存在沟通问题
1、 确定一个场外办公室的关键联系人
2、 定期与场外工作团召开会议，赞赏他们的工作状态和工作进展。
3、 及时确定协议

3.4.202511:3711:37:5125.3.411时37分11时37分51秒3月. 4, 254 三月 202511:37:51 上午11:37:51
2025年3月4日星期二11:37:51