编辑导读：作为一个产品经理，每天要接触到大大小小不同的需求。要对这些需求进行分析，才能更好地了解问题，从而制定相应的解决方案。那么，怎么做需求分析呢？本文作者基于自身经验，对此展开分析，希望对你有帮助。

很多同学不清楚如何做需求分析，希望通过本文简单的介绍可以帮助大家。

一、需求分析常规步骤

在接收一个需求的时候，需要搞清楚这个需求的使用场景是什么，用户是谁，用来解决什么问题。当我们清晰的了解问题以后，就可以对产生的原因进行分析，然后制定相应的解决方案。

在需求沟通时，需要挖掘用户的潜在需求吗？需要注意只需要挖掘问题，不挖掘方案。因为在问题级的探讨中用户是理性的，而在方案级的探讨中用户是感性的。用户只是问题专家，我们才是解决方案专家。

使用场景：细化业务场景，分析有多少个流程，整理用户预期的正常流程，再确认存在变化的情况。

• 功能是谁使用的，什么时候使用？
• 具体业务是怎么做的，流程是什么样的？
• 有需要明确的业务术语吗？
• 业务量如何，功能使用频率是多少？
• 用户操作环境有何特点？

存在问题：针对这些流程，从用户的角度思考当前存在的问题，会遇到什么问题。

• 想要解决谁的什么问题？
• 现在遇到这个问题是如何解决的？
• 问题中有需要进一步明确的概念吗？

解决方案：针对这些问题，思考系统应该提供什么样的功能。

• 要解决这个问题有哪些可行的方案？
• 这些方案的实现成本有多大？
• 哪个方案最合适？
• 该解决方案对用户来说有什么优缺点？
• 用户希望什么样的解决方案？

二、干系人识别步骤

需求分析时，确认关键干系人至关重要，决定着上线的功能是否满足了用户需求。

干系人分析需要侧重他们的关注点，就是正需求，不过他们的阻力点（担心点，负需求）也是十分重要的，有时候用户特别关注不能怎么做。

1. 根据目标识别关键干系人

读组织架构图，将相关业务部门负责人标识为关键干系人。

如果这些部门有分支机构则分支机构负责人也标识为关键干系人。

意见领袖、业务专家标识为关键干系人。

2. 根据风险识别关键干系人

对一大批基层用户带来影响的，则基层用户是关键干系人。

具有一票否决权的，也是关键干系人。

技术实施存在风险的，开发团队也是关键干系人。

三、业务子系统划分

当系统复杂、涉及到不同的业务时，就需要通过业务子系统划分，将系统分解成更小的业务单元，以解决系统过于复杂的问题。根据系统特点，选择合适的划分策略进行分解。

对于支持管理业务的系统而言，最典型的业务子系统划分策略就是按部门职能进行划分的。

通常在开发外部服务系统时，可以先梳理出业务结构，然后以不同的产品服务作为划分线索。

对于新开发的系统而言，最常用的策略是按业务职能分解、按产品/服务分解、职能/服务双维度划分、按关键特性分解。

对于系统优化的开发而言，最适合的方法是分析有哪些新增、修改，有哪些影响。

四、业务接口分析步骤

接口分析主要目的是了解各业务子系统之间的服务关系。

1. 明确接口的用途与业务价值

接口由哪些子系统实现更为合理？

哪些子系统会使用这些接口、什么时候使用、实现什么业务价值？

接口的使用频率如何、接口相关的业务发生的频率如何？

2. 细化接口的交互过程

接口的交互由谁发起？

需要几次交互？

都是什么数据？

3. 确定接口设计约束

数据传输、通讯、内容包需要采用特定的协议标准吗？

接口实现时受到硬件、网络、操作系统的限制吗？

接口的性能要求如何、要支持多大的并发、要达到什么样的相应速度？

接口相关的安全性、可靠性要求如何？

五、业务流程分析与优化步骤

识别业务流程时涉及两种边界，一是职能边界，就是跨越了我们未涉及的业务领域；二是系统边界，就是不属于系统关注的部分，做好边界分析，确定系统的边界。

信息系统的核心价值包括支持管理和支持业务，支持管理的核心是通过管理流程事前规避风险，通过规则和审批事中控制风险，通过数据分析做事后优化；支持业务的核心是对业务流程的固化、优化和重构。

1. 选择流程图描述方式

强调每个角色执行的活动：跨职能流程图

强调各角色间的协作交互：顺序图

强调数据处理过程：数据流图

2. 画流程主体

从提出服务请求开始到服务被满足的流程中涉及哪些角色？

每个角色负责完成哪些独立的业务活动？

这些业务活动如何协作起来，串行、并行、异步？

有针对不同情况的处理过程吗？

3. 补充事中管控点

在过程中应加入哪些审核点，以便控制风险？

在流程各环节有什么相关的规则？

有完全无法按这个流程执行的特殊情况？

4. 分析流程执行过程的监管需求

管理者如何来监控流程执行的进度效率？

管理者对流程的哪些异常关注？如何来监控？

六、业务报表分析步骤

做报表的时候，一般要确认报表的内容、使用者及为什么要做这个报表。

1. 明确报表的使用场景

谁是报表的主要使用者？

有其他使用者吗？

使用频率如何？

谁是报表的数据生成者？

2. 分析报表的内容

实现报表需要哪些数据源？

数据的挑选标准是什么？

报表由哪些数据模块构成？

3. 整理报表的输出要求

需要导出、打印吗？

需要用图表来展示吗？

有特殊的排序要求吗？

默认展示什么条件的数据？

七、业务数据分析步骤

当确定了业务数据以后，还需要细化每个业务数据的构成细节，另外也需要对数据应用、数据特点进行分析。

1. 数据构成分析

该业务数据有哪些字段构成？

这些字段是什么类型的？

最大长度、取值范围、非空、键值吗？

2. 数据应用分析

哪些流程会用到该数据？

这些流程中会增删改查该数据的记录吗？

每个流程需要使用的数据字段有哪些？

3. 数据特点分析

哪些字段是常用的？

哪些字段常为空值？

哪些字段会作为关键字搜索？

哪些数据有扩展需求？

八、约束分析步骤

一般项目方面的约束，可以从预算、资源、进度三个角度来分析。实现方面的约束，可以从技术选型、部署环境、开发环境来分析。

1. 明确进度要求

系统最晚何时上线？

可以分阶段满足吗？

2. 明确资源支持

用户方的指定接口人是否明确？

是否应要求客户成立项目组？

是否应要求客户提供场地、设备等资源支持？

3. 明确预算要求

用户有明确的预算限制？

预算范围是多少？

涉及的业务范围有多大？

同类系统的建设资金在什么范围？

4. 明确技术选型约束

有相关技术规范做出明确要求吗？

5. 明确部署环境带来的约束

服务器、终端、网络选型会对系统实现产生约束？

法规对系统实现有哪些潜在约束？

用户的文化、使用环境对实现有约束？

系统的生命周期会对实现产生约束？

6. 明确开发环境带来的约束

开发团队能力、开发工具、环境对系统带来约束？

扩展：

产品需求的三个层次：基础性需求、期望性需求、兴奋性需求

马斯洛需求五个层次：生理需求、安全需求、社交需求、尊重需求、自我实现

需求管理的四个环节：采集需求、分析需求、筛选需求、处理需求

需求分析四象限：重要并紧急、重要不紧急、不重要但紧急、不重要不紧急

作者：小红牛，微信公众号：ipmdog(人人都是产品狗)

本文由 @小红牛 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议