需求调研与分析流程

 

参考HK公司的需求设计培训，结合需求调研的工作整理如下：

需求调研的目的：

1. 问题：存在的问题是驱动项目产生的关键
2. 背景：（业务场景、业务数据、业务环境）
3. 解决方案：提出一个满足业主需求的解决方案；

需求分析的难点：

1. 用户需求描述不清
2. 需求变更频繁
3. 对需求理解有偏差

整体需求调研的流程根据如下几步：

一、明确方向：

• 项目背景分析：

1. 1. 谁提出了项目（高层）
   2. 对项目的关键预期
   3. 当前遗留系统（后续针对成本可指定利旧规则）
   4. 业务假设（如业务量）
   5. 技术假设（是否有技术选型要求）

• 目标分析：
  1. 访谈项目干系人
  2. 组织相关人员进行研讨（可采用头脑风暴）
  3. 描述问题（针对研讨结果）
  4. 分析问题（针对研讨结果）
• 干系人分析：
  1. 选择对业务了解，容易访谈的对象；
  2. 对关注点进行整理，识别调研中存在的冲突
• 项目约束分析：
  1. 进度约束（如领导视察）
  2. 预算约束（可以直接问，也可以通过其经营规模、客户数量、历史同行投入推导）
  3. 其他约束（法律法规、技术标准、社会文化等）
  4. 资源支持（如场地等）

二、明确范围：

（此处划分的子系统不同于总体逻辑架构中的子系统，而是从业务层次划分）

• 子系统划分:通过构件、接口、服务（虚线）、使用（实现）
• 业务流程
  1. 业务流程要注重事件驱动，事件可以使外部、也可以是内部；
  2. 要关注异常流程和辅助流程；
  3. 要确定业务需求的优先级；

              （此处的业务流程是子系统之间的）

三、梳理脉络及细化：

（此处类似于对每个子系统内部的需求进行梳理）

• 每个子系统描述以下内容：
  1. 接口（子系统对外接口）
  2. 业务流程（用例图、活动图、协作图）
  3. 管控点（报表）
  4. 领域模型（ER图或领域图）
  5. 质量（质量属性）：除非客户或产品有明确要求，否则质量属性切勿占比太多；关注可靠性、可用性、兼容性、安全性等等；
• 对于业务需求的调研注意三点：

1. 1. 倾听：不要打断被调研对象
   2. 问：问题不能太粗，切记避免类似遇到什么问题之类的，要关注异常
   3. 反馈：通过手绘的草图与被调研对象确认需求是否正确

    注：在电子政务的项目中可以参考《GB-T 19487-2004 电子政务业务流程设计方法》，从组织架构、岗位职责、业务协同、权限等领域关注；

后续：

1. 产品侧拿到需求分析报告后进行功能层面的需求分析、架构设计等；
2. 需求分析人员会在全流程跟踪需求；PS：前期的工作中也有产品的架构师介入

/********************************************************************************** 

感想：

1. 相对H公司的IPD流程，这套需求分析的思路更加侧重前期（售前阶段）需求的理论和方法，在这块比IPD更加详细和贴近实际业务场景，特别是针对企业和政府用户；
2. 但与研发体系的衔接，比如端到端的需求分级、需求跟踪，如何保证需求（落地到硬件、整机、软件、系统等）的设计、实现、验收的一致性；质量需求到质量设计的全面性等还有所欠缺；所以当前只是一个在解决方案部开始推广的实践，全流程体系还有待磨合