做一款产品前，我们事先要做的就是明确需求与对应场景。对一款企业系统来说，关注点也是如此。

继上一篇业务流程识别与分析篇后，本文主要分享业务场景识别与分析相关知识点。

一、识别业务场景

首先是要理解用例和用户故事的本质，它要求我们不是去关注系统提供什么功能，而是用户在什么场景下需要系统提供支持！

1. 用例的关键知识认知

1. 用例名称要基于用户场景去设定，使用业务语言去描述，而不是机械式的使用“增删改查”
2. 在业务场景中的用例粒度是由组织分工决定的，特征是独立、可汇报、可暂停的单元（一般不会是太细化的动作）
3. 2人/周的工作量分拆成更小的故事，另外大故事要保留的原因是方便组织小故事，不忘初心。

2. 基于流程图识别参与系统的角色。

1. 对这个流程提供支撑需要有哪些角色？
2. 非必需的角色纳入系统支持中有什么价值？不纳入的话有什么影响？（在优先级排序时有指导作用）
3. 一般执行层的角色会用岗位名称命名
4. 在权限系统中要如何抽象各个角色

3. 基于流程图识别业务场景

我们要思考在流程过程中，哪些业务活动要系统支持，哪些是部分支持，审批点是否属于系统内，判断点是否为独立环节。

（下图是一套体检系统的流程图，假如工程排期优先内部作业电子化，故体检者一栏暂时不纳入电子系统。红圈则是现要开发的系统所支持的任务活动）

4. 补充业务场景

常见如由时间、状态而触发的业务场景，如信用卡到期还款以及长期逾期状态导致信用卡冻结的场景。

5. 绘制用例图

注意常见三个关系_包含、扩展、泛化。

• 包含关系——公共子事件流（不需给用户看），如检查座位信息。
• 扩展关系——不一定执行的扩展事件流（需给用户看），如处理等候队列。
• 泛化关系——公共事件流，如办理结账。

二、六步分析业务场景

1. 概述业务场景（包括业务目的、前后置条件等）

2. 把场景细化成事件流，整理去用户预期的步骤，并思考扩展和异常事件流。

注意两点：

• 用例描述重在人机交互和意图，不需要过多些人机界面和动作
• 结构化语言描述，少用“如果..就”的表达方式了；扩展或备选事件流单独列出来分支，降低理解成本。

3. 针对每一个步骤，思考并罗列用户可能遇到的问题

4. 针对问题思考解决方案

5. 考虑环境与业务特点带来的影响或要求，主要是性能、易用性、部署环境等三方面

6. 开始初步的交互设计

本文由 @PM达云霄 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。