输入与输出

输入：通过访谈、问卷调查等方式获取客户的真实需求

过程活动：需求调研

参与者：客户代表、产品经理、项目经理(或技术经理)

输出：《需求调研报告》

干货

1. 若是乙方公司承接的甲方公司的项目，一般项目经理由是商务角色，技术经理是开发团队负责人，一般由  产品经理、技术经理实施需求调研。
2. 若是公司自有平台的项目，一般项目经理由是开发团队负责人，一般由  产品经理实施需求调研，从业务方获取需求。

调研的过程

1. 需求获取；
2. 需求分析；
3. 需求表达；

了解项目背景

了解项目背景是需求调研的第一步，旨在全面掌握项目的业务目标、现状和约束条件。首先，通过与项目发起方（如业务部门或高层管理者）沟通，明确项目的核心目标和预期价值（如提升效率、降低成本或优化用户体验）。其次，调研现有业务流程和系统，分析当前痛点与改进空间。

举例一个假设的项目背景

中石化旗下拥有一批加油站，每个加油站内设有便利店，主要向过往的司机销售矿泉水饮料、纸巾湿巾、方便食品等商品。目前无法集中管理，库存周期长损耗大导致利润低。现计划开发一套供应链管理系统，类似于连锁超市的管理模式，集中管理所有便利店的采购、库存、零售、收银、结算等核心业务流程，同时支持促销活动、积分管理等功能，并能够计算每个值班销售员（加油员）的销售提成。此外，上级连锁运营部门需要根据季节变化，集中调配货品供应，以优化库存和销售效率。司机可关注微信公众号参与积分抽奖，通过公众号沉淀海量用户提高粘性。

这一背景涉及多个业务环节和角色，便利店的商品管理、销售员的绩效激励，以及上级部门的集中管控。因此，需求调研需要覆盖从基层操作到高层管理的全链条需求，确保系统设计能够满足不同层级的业务目标。

本例中的客户与用户

• 在本例中“中石化”是我们的客户，我们为客户开发一套软件系统，我们与客户签定服务合同赚客户的钱。
• 角色1-值班销售员（加油员）是用户，使用我们的软件系统管理上架、零售、收银。
• 角色2-司机是用户，使用 微信公众号内的H5页面，参与积分抽奖。
• 角色3-线下连锁的运营负责人是用户，使用我们的软件系统的“管理后台”，管理采购、库存，查看报表。

客户的痛点

• 目前无法集中管理，库存周期长损耗大导致利润低

调研的对象

常见的调研对象

• 对系统环境的调研
• 对信息部门的调研
• 对业务部门的调研
• 对业务员工的调研
• 对用户的调研
• 对合作伙伴、竞争对手的调研

本例中的调研对象

1. 对系统环境的调研内容

   • 了解现有加油站和便利店的运营模式、业务流程及信息化现状。
   • 分析当前使用的系统（如收银系统、库存管理系统）的功能和局限性。
   • 评估硬件设施（如收银设备、网络环境）是否支持新系统的部署。

2. 对信息部门的调研内容（IT信息部门）

   • 了解现有IT系统的架构、数据存储方式及接口规范。
   • 确认信息部门对新系统的技术期望（如可扩展性、安全性、集成能力）。
   • 评估信息部门的技术能力和资源，确保系统开发与运维的可行性。

3. 对业务部门的调研内容（线下连锁运营负责人）

   • 明确业务部门的核心目标（如提升销售额、优化库存周转率）。
   • 了解当前业务流程中的痛点（如采购周期长、库存积压、促销活动执行困难）。
   • 确认业务部门对系统功能的优先级需求（如集中采购、销售数据分析）。

4. 对业务员工的调研内容（加油员）

   • 了解加油员在日常工作中的具体操作流程（如收银、商品上架、促销活动执行）。
   • 收集加油员对现有系统的使用反馈（如操作复杂度、系统稳定性）。
   • 确认加油员对新系统的期望（如简化操作、提升提成计算透明度）。

5. 对用户的调研内容（司机）

   • 用户画像与使用场景（如年龄、职业、使用习惯）。
   • 用户痛点与需求（如功能缺失、体验不佳）。
   • 用户对新功能的期望与建议。

调研方式

常见的调研方式

（1） 收集客户相关的文档资料，如公司概况、主要产品和业务、财务核算制度等，可以从客户的网页、宣传手册等获取，也可以要求客户方提供。
（3） 客户访谈：与客户面对面的访谈，可以一对一或一对多，要求准备一个问题列表，用来获得有关客户问题和潜在解决方案的整体特征的信息。
（2） 用户调查：使用设计好的用户调查表，以书面的形式收集用户需求。
（4） 开会讨论：头脑风暴会议，对跨部门、跨岗位的业务，可以把相关人员召集在一起，提出对现在问题的理解和思考，涉众提出问题、愿望和潜在解决方案的建议。
（5） 在客户环境中工作：需求收集人员在客户的实际环境中与客户共同工作一段时间，以更加深入的了解客户的问题、要求及应用环境。
（6） 需求研讨班：将所有涉众集中在一起，进行一次深入的、有重点的会议，从项目涉众那里收集全面的“愿望列表”，并区分优先顺序。
（7） 用例讨论班：一个有组织的集体讨论会议，用来确定系统的主角、边界、用例和事件流等用例相关内容。
（8） 制作示意板：使用工具向客户说明系统如何适应组织的需要，系统如何运转。
（9） 原型开发：开发软件系统的早期缩型，显示新系统的部分功能，以明确客户需求。

本例中的调研方式

• 客户访谈：与客户面对面的访谈，通过与项目发起方（如业务部门或高层管理者）沟通，明确项目的核心目标和预期价值。
• 用户调查：使用设计好的用户调查表，以书面的形式收集司机用户需求。

需求表达的方法

1. 文字描述

   • 通过自然语言详细描述功能需求、业务流程和用户场景。
   • 优点：灵活易懂，适合初步沟通；缺点：易产生歧义，需结合其他工具补充。

2. 图形化工具

   • 用例图：展示系统与外部参与者的交互关系，明确功能边界。
   • 活动图：用流程图形式描述业务流程的动态行为（如顺序、分支）。
   • DFD（数据流图）：聚焦数据流动和处理过程，适用于需求分析阶段。
   • 层次结构图：展示系统模块的层级关系，帮助理解整体结构。

3. 结构化规范

   • 用例规约：详细描述用例的执行步骤、前置条件和异常处理，确保需求完整性。
   • HIPO（层次化输入-处理-输出图）：通过模块层次和IPO图（输入-处理-输出）细化功能细节，适用于系统设计阶段。

4. 原型设计

   • 低保真原型（如线框图）：快速验证功能逻辑。
   • 高保真原型（如交互式界面）：模拟用户体验，减少需求理解偏差。

方法选择原则：

• 需求阶段：

  • 早期需求分析：文字描述 + 用例图 + DFD。
  • 功能细化阶段：用例规约 + 活动图 + 原型。
  • 系统设计阶段：HIPO + 层次结构图。

• 团队协作：结合图形化工具（如用例图、DFD）与文字说明，确保开发、测试、业务方理解一致。

通过灵活组合这些方法，可系统化地表达需求，降低沟通成本，为后续开发奠定坚实基础。

调研报告的内容

《需求调研报告》讲划包含以下5部分内容：

1. 说明背景：可以让客户代表和产品经理人员，在一个“上帝视角”对本软件系统有全局的了解。作为项目组成员了解本系统的“背景材料”。
2. 分析问题：定义软件的总体要求，分析客户的痛点，罗列解决的问题。
3. 定义角色：说明本系统有哪些使用者。 核心思路是“把业务穿起来”，核心的体现就是：什么角色 使用什么功能 完成什么业务。
4. 定义功能范围：定义行为需求:，说明本系统要完成什么功能，规定系统实现功能范围，用于指导产品经理进一步深入设计软件产品。
5. 补充非行为需求：有效性、可靠性、安全性、可维护性、可移植性、可见性、容量、精度 等等。

模板

需要模板的读者，请下载附件集中的模板《需求调研报告模板-简洁版》。