需求调研工作总结
需求：分为需求调研、需求分析、需求文档编制。需求分析和需求文档的编制，都需要依靠需求调研工作的成果。
需求调研的关键点
1、在合同已经定额，合同范围已经基本确定的情况下，，要合理引导客户需求，在保证客户业务完整实现基础上，争取对本方有利的条件，控制需求范围，尽量减少项目成本、时间的支出。
2、调研形成的需求、客户实际的需求、客户自己想象的需求，前两者要保持一致，利用自己的专业性，引导客户自己想象的需求向第二者靠拢。
3、项目的目标决定需求调研的要求，比如：
（1）如果项目目标就是为了我方单纯盈利，那么调研出来的需求，要是可以快速实现的，最好使用成熟技术框架或者间接复用之前某个类似项目的交付物。
（2）如果项目目标是为了提高我方的市场竞争力，做标杆项目，那么调研出来的需求，就是要多使用新技术，用户界面更加地友好和标新立异。
4、需求调研要注意自顶向下，从客户方领导层开始，这样才能保证获得更多的支持。
5、需求调研是项目实施过程中比较容易产生矛盾的环节，主要体现在应对客户提出的需求变更。建议应保持平和的心境，切莫存在“消除客户需求变更”的思想，冷静应对客户提出的需求变更，合理分析和疏导。
6、需求调研阶段，除本身的需求调研工作以外，项目经理也应该注意建立与客户方所有项目相关干系人的良好关系。努力树立自己专业、高效、负责的正面形象，展示自己优质的服务态度，从而赢得客户的信任，也是为项目后期的实施打下坚实的基础。
需求调研的常见问题
1、需求说明书双方确认之后，客户提出了更多的业务需求。
原因：
（1）前期需求调研，需求人员做了错误的引导，未理解清楚客户实际的需求；
（2）客户对需求的理解本身是渐进明细的过程，无法控制，但是前期未能合理有效地引导客户需求的话，客户就会提出更多的诉求；
（3）需求说明书未能获得主要相关方（包括客户方领导、最终用户等）的全力支持，可能只是因为工期的原因，草草结束，各方进行了妥协的结果。
需求调研的内部准备
1、项目情况了解：
（1）形式：讨论会议；
（2）参加对象：市场人员、前期售前人员以及预期的需求人员；
（3）材料：合同、可行性报告等；
（4）议题一：了解客户建设系统的原因，客户所在的行业，需要实现的业务需求，需要解决什么问题；
（5）议题二：分析需求调研可能的难点所在，这个非常重要；
（6）议题三：了解客户背景，组织架构，确定本次调研客户方关键人信息，一部分是不参与业务但是级别较高的人员，这是优先的具有决策权的人；另一部分是业务系统的使用者，这是需求的提出者，也是有级别之分的，区分上下级关系。
2、调研计划制定：
（1）调研内容，模块划分，侧重点，要从客户重要而紧急的模块开始；
（2）时间行程划分；
（3）调研组人员职责和工作分工；
（4）日常规定，每日例会，当日工作汇报形式，常见问题解决方案；
（5）调研工具约定统一：Visio/Axure等（不仅需要考虑组内成员转发穿越，也要方便客户的使用和查看）
（6）文档形式约定统一；
注意：计划制定完成之后，提交内部进行评审，评审完成，首先要看客户有没有自己的调研计划，如果有，则双方共同沟通调整确定；如果没有的话，就把我们的调研计划要提前发给客户，客户方主要是查看时间安排，没问题就按照我们的计划来。
需求调研客户现场
1、召开需求调研启动会
（1）形式：正式会议，需要专人进行会议纪要，完成之后分发给会议参加人员及所有项目干系人。
（2）参加对象：我方全体调研组人员、客户方相关领导和业务部门人员（这是务必的）。
（3）议题一：一一介绍我方项目组成员，项目总体计划，需求调研计划和行程，重要的里程碑点，说明需要客户方提前完成的事宜，比如涉及银行直连接口的，需要客户方提前约好银行人员。
（4）议题二：确定客户方唯一的总体协调人员（领导）、各个模块唯一的接口负责人（业务负责人）。
（5）议题三：确定每日需求调研内容的沟通方式，以及当日的总结汇报机制，汇报哪些人员。
（6）议题四：说明我方的需求分析和文档编制过程。
（7）议题五：获取客户方内部的需求确认流程，需求确认人员是哪些，流程是怎么样的。
需求调研过程
1、客户行业知识的了解
需求调研之前，要对客户所在的行业领域，要进行较为深入的了解，至少需要懂得一些专业词汇。如果是较难理解的行业，最好由公司指派相应方面的业务专家参与。
2、需求内容的展示
获取客户方的需求之后，要立刻进行复述和确认，客户一般都喜欢图形化的展示方式，可以将需求内容转化为用例图、用户界面原型图、业务流程图、单据状态变更图、时序图等。
3、获取需求的方式
（1）向客户提问，尽量规避论述题，最好以选择题或者判断题的形式。
（2）参观用户工作流程，观察用户操作。
4、与客户的交流方式
（1）尽量站在客户方或者最终用户的角度，考虑界面友好性和功能适用性。
（2）使用用户的语言，与客户进行交流。
（3）遇到客户不明确的地方，尽量总结自己以往项目实施经验，展示自己的专业性，进行建议和引导。
5、4W和1H的方式
（1）Why：客户为什么要建设这套系统。拓展新的业务领域？增强业务处理能力？提高部门间协作效率？
（2）What：建设这套系统，包括哪些业务流程，哪些功能模块？要解决什么问题？功能需求、非功能需求是什么？
（3）Where,Who,When:分析哪些人，什么时间，在哪个地方，做怎样的操作，这样可以串起一个流程。
根据Why,Where,Who,When,可以初步定义一个大致的需求框架。
（4）How：在需求框架之内，考虑怎样实现。怎样进行数据的输入输出，怎样进行状态的变更。
6、过程注意事项
（1）严格执行调研计划
如果情况有变，比如某个模块调研时间延期或者某个关键人未到等情况，要及时修正调研计划，并与客户进行确认，按照新的计划执行。
（2）灵活掌握调研进程和工作氛围
调研工作要切中主题，把握重点。调研工作持续时间久了，无论是客户还是我方调研人员，都容易分神或者乏了，这时可以适当延伸聊一下题外话，但是切不可扯远了，要掌握时间和内容尺度，及时拉回正题。
（3）及时记录
和客户在访谈过程中，如果来不及记录的，可以安排专人记录，或者是全程录音。
（4）遵循需求由总入细的原则
先从大的方面谈起，从总体到局部，尽量不要一开始就陷入细节当中，否则很容易出现延期或者忽略重点的情况发生。
（5）挖掘客户最原始的需求
客户描述的需求，往往不是最原始的需求，可能只是他理解的对需求的实现方式，我们应该问他为什么要这样做，这样的目的是什么。通过这个过程，可以规避因为客户了解IT系统，而提出的重复或者非必要功能。
（6）挖掘客户的潜在需求
客户描述的需求，往往只是他需要实现什么功能，但是实现这个功能往往需要配套的辅助功能。比如实现一个成绩查询申请，不仅仅是新建一个单据，然后走多层审批即可，而是需要建立多个配套的值表管理，比如学生管理、课程管理、学院管理等。切忌复杂问题简单化，否则一旦考虑缺失，在设计或者是开发阶段就很难弥补，造成成本和时间的溢出，同时也会引起客户不信任和反感。
（7）规避客户不合理的需求，控制范围
客户永远没有错，错的只有我们没有真正理解客户的需要。调研时要把握主题的能力，分清有用功能、可选功能用、无用功能及不可实现功能，及时表达我们的观点，让谈话接近主题。调研的过程中，不可避免的会出现客户提出一些我们现有条件下根本无法实现或者即使实现也非常困难的要求。这种情况就需要需求调研人员的聪明的头脑和快速反应能力，同时也需要调研人员的良好的沟通技巧，要能巧妙地说服客户放弃这种方式并且还要客户能够理解，而不致认为你在逃避问题不想解决。一般可以采取这些方式：
a.客户提出这些要求后能马上了解客户提出这个要求的真实目的，然后快速思考出另外的简单的方式同样能实现客户的这个目的。这是最好的方式；
b.必要时直接告诉客户无法实现并且给出合理的理由，特别是在客户说某某系统已经实现了这个方式时，比如他们用的是什么什么平台支持，这个平台支持需要另外付费等等；
c.直接告诉客户虽然能实现，但是需要很大的精力和成本，而这个可能是客户无法承受的，当然你一定要能说出客户听起来合理的理由。这些都不是绝对的，需要调研人员丰富的软件开发经验和灵活的头脑较好的表达能力临场发挥。
（8）提高需求的全面性，谨防个人需求
虽然前期确定了某个业务模块唯一的接口人，但是也要谨防需求变成他的个人需求。因为其接口人存在着离职、换岗位、不受重视等因素影响，其负责产出的需求，在后期可能就会面临着全盘推翻的风险。故要提高需求的全面性，不能让需求带有接口人强烈的个人特征，要多与该业务模块其它人员多进行访谈沟通，确定需求的普遍性和适用性。同时，在需求调研开始阶段，就务必要将此风险告知客户方领导人，以便于其安排合适的业务模块接口人，也是为了后期一旦出现这个情况，客户不会找我们的责任。
（9）当天需求内容及时归纳总结
组内各成员当天的需求调研原始材料，及时进行汇总，查漏补缺。
进行深入讨论、分析，形成总结材料，并梳理仍然存在的疑问（第二天及时进行确认）。
以上内容，及时转发给组内成员、各方干系人等，并请业务模块接口人进行确认，是否是和他们理解的一致，在取得他们相对正式的确认之后，才能进行下一天的调研工作。
（10）需求业务模块要分优先级，不要被细节拖累
不同的需求业务模块要分优先级，模块内的需求也要分优先级。
（11）建立合同与需求功能对照表，需求调研过程中适当而潜移默化的向客户展示和强调合同范围，坚持需求范围基准。
需求调研输出
- 收集用户业务开展过程中需要产生的单据和报表 ；表单及报表的适用对象。
- 根据单据和报表，编写规范化的数据字典。
- 收集用户类型和参与的事务，建立用户模型，绘制用例图。
- 画出业务流程图，并认真检查和核对每条路径中是否完备，特别注意异常情况怎样处理。
- 依据流程图收集每个步骤需要使用和操作的数据，确定数据的来源、类型和范围。
- 画出业务实体及其关系，绘制业务实体可能存在的状态变更图，并估计业务实体的产生频率和数据量。
- 评估业务流程和实体中需求变化的可能性。
- 不同用户的权限分类。
- 用户对信息系统的理解和使用熟练程度现状。
- 收集用户对系统界面风格、版式、颜色的偏好和需求。
- 对系统将来使用的硬件、操作系统、网络情况进行了解。
- 收集系统初始化生产数据，或者要求客户进行收集和整理，明确期限时间。
- 编制界面原型（该步骤也可放在需求分析之后完成，再次和用户进行沟通）。
需求调研成果的确认
1、编制总的需求调研报告（这里不是需求规格说明书），尽量以图形化形式说明调研结论，突出未来可能为有变更风险的重要模块。需求调研报告是为了对需求框架，重点内容进行确认，建议不过多体现细节。有条件的，可以使用Axure绘制系统基本原型，该原型应该包含所有功能模块、主要功能页面、基本的界面风格，还应该具备动态交互性，把重要业务流程走通，而不仅仅只是页面展示。
2、召开需求调研总结大会
（1）形式：正式会议，需要专人进行会议纪要，完成之后分发给会议参加人员及所有项目干系人。
（2）参与对象：我方调研组全体、客户方领导、客户方唯一的总体协调人员（领导）、各个模块唯一的接口负责人（业务负责人）等。
（3）议题一：项目经理肯定调研期间客户方人员的大力支持配合和宝贵意见，说明双方共同的工作成果。
（4）议题二：以PPT或者需求调研报告投影的形式，项目经理讲解需求调研报告内容，要快速清晰，不要陷入细节。
（5）议题三：项目经理说明后续需求分析、编制需求文档的工作安排，可以顺带提一下需求延期对整个项目进度的影响。
（6）议题四：请各业务模块接口人确认需求。（此部分工作建议在会议之前应该完成，保证达成共识。）
（7）议题五：请客户方领导人总结或者提出指导意见。
（8）议题六：请客户现场确认需求调研报告内容。
备注：客户对需求的理解始终是渐进明细的过程，本阶段即使客户签字确认需求调研报告内容，也无法避免客户之后提出新的需求变更内容。项目经理需要做的是，站在客户的角度，本着互惠互利，双方共同推进项目早日完工的目的，一是提前和客户说明越往后提出需求变更，付出的变更成本和损失就会越大；二是对客户的需求变更进行合理分析：
a.若为范围以外且是业务非必要的，则予以适当拒绝；
b.若为范围之外，且是本阶段业务必要的，则评估影响和工作量并通知客户走商务流程；
c.若为合同范围之内且业务非必要的，则尽量引导客户做上线之后的遗留功能处理，进行迭代更新；
d.若为合同范围之内且业务非、必要的，则就需要返回查看之前的需求调研工作是否存在大的遗漏，需要今早查漏补缺。
当然，考虑需求变更是否接受还有一个重要因素，就是需求变更的提出人是谁，其是否会对项目推进有重大影响。
以上为参考其他博客，并结合自己的感悟加以总结。欢迎拍砖指正，共同进步！
参考博客，感谢：《如何进行有效的需求调研》《如何做好需求调研》