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