项目需求调研方法论

调研过程
人员构成
需求调研人员由用户方的业务人员和集成方的技 术人员构成。 技术人员以前端应用开发人员为主，后台ETL处 理人员为辅。 如果需求调研分成不同小组，则在分析过程中需 要有专人从总体上把握用户需求，协调不同小组 之间的问题。 需求调研人员不宜过多，这需要根据项目范围来 确定，但是参与需求调研的技术人员要求有比较 丰富的开发经验。
注意事项
对于用户提出某些业务需求，有时需要进 行适当的调整。这时可以从技术、业务和 使用等方面进行分析，考虑原有业务需求 的优缺点。同时，在此基础上提出切实可 行的替代方案，并分析替代方案给用户带 来的好处，如何弥补用户原有需求中的一 些考虑因素。
注意事项
由于业务流程与管理办法是紧密相关的， 业务的变化会影响到管理模式等，所以在 分析用户的业务需求时，需要注意相关业 务管理办法的同步制定，特别是对业务操 作规范、流程等不很成熟的业务，需要及 时制定业务管理办法指导系统后期的使用， 避免开发后期的大量维护。
注意事项
如何引导用户？
– 如果能够合理的引导用户，会给系统建设打下 良好的基础；
– 需要对业务具有比较深入、透彻的理解，对业 务人员提出的业务需求有比较准确的把握；
– 需要比较丰富的开发经验，特别是涉及到系统 建设范围内的需求方面；
– 通过已有的经验，采用先入为主的方法，主导 用户的思路，合理的引导用户。
调研步骤
前期准备工作
向业务人员和技术人员介绍本项目的主要目标、 项目范围和重点工作，避免在需求调研过程中 业务人员所提需求超出范围，抓不住重点。
技术人员应该预先了解相关业务知识，包括业 务的基础术语、基本概念、基本业务的操作和 处理等。
调研步骤
技术人员需要通过业务人员对基本的业务规范和 操作流程进行了解，尽可能对项目所涉及的业务 给出业务操作流程图、业务数据处理流程图等。 其中，重要的是交流方式，技术人员要采用适当 的方式引导业务人员。 通过业务人员了解相关需求的最终目的和实际应 用等。 分析业务需求，对业务需求列表中的每个问题进 行必要的思考并记录问题。（上述工作可以围绕 业务需求来完成。）
DW项目需求调研方法论
TeamSun
议题
需求调研总体思想和原则 需求调研过程 需求调研人员构成 需求调研步骤 需求调研注意事项
总体思想
分析
总结
根据业务需求的分析 结果进行总结，考虑 需求的分解和合并、 实现方式、用户的使 用，编写最终的功能 需求类别。
根据用户提供的各种 信息，分析具体业务 需求的价值、所涉及 的数据要求及需求与 实际业务的关系等。
调研步骤
针对业务需求列表和业务人员进行讨论，技术人 员需要结合自己对业务的理解和项目建设重源自文库， 合理引导用户。 就讨论后的业务需求进行分析，整合出合理的功 能需求列表。 和业务人员就每个功能需求进行讨论，并在用户 业务需求和技术实现之间取得一致。（上述工作 可以围绕功能需求列表来完成）
根据功能需求类别编写功能需求规格说明书。
功能规格说明书
根据需求功能列表整理功能规格说明书，该说明书 经过用户评审、签字后作为后期设计、开发、验收 的基础和依据。
调研过程
业务需求列表是从业务的角度来分析考虑用户的 使用要求，具体内容可参考如下模板。
需求编号
需求分 类
功能点
需求部 门
业务目标 业务价值
当前状 态
实现方 式
客户期 望
使用者
业务问 题
分析主题
分析维 度
分析指标 数据源说明
优先 级
相关部 门
备注
调研过程
功能需求列表是在业务需求列表的基础上更多的 从技术方面对用户需求进行分析，可参考下页模 板内容。 功能规格说明书则需要从整体到细节对用户的需 求进行清晰、明了的分析和说明，是一份较正式 的文档。 本文档提供的分析模板可以根据具体的业务需要 进行修改、补充、完善，例如权限控制等，以能 准确、全面说明用户的需求为准。
交流
和用户进行充分的沟 通、了解，包括项目 背景、业务流程、系 统用户、业务需求点 等。
调研原则
“业务为主，技术支撑” 项目实施的范围和重点
调研过程
业务需求列表
需求描述、需求提出部门、业务价值、使用者、客 户期望、分析维度、分析指标等（EXCEL格式）
功能需求列表
功能名称、实现方式、权限分配、输入条件、维度 指标、界面展示、展现周期、数据来源等（EXCEL 格式）
Q&A
Thank you