在做一个产品之前，我们要提前做的就是明确需求和对应的场景。对于一个企业系统来说，关注点也是如此。

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

首先，要确定业务场景，首先要理解用例的本质和用户故事。它要求我们不要关注系统提供了什么功能，而要关注用户需要系统支持什么场景！

1.了解用例的关键知识。用例名称应该基于用户场景设置，用业务语言描述，而不是机械地使用“添加、删除、检查”。业务场景中用例的粒度是由组织分工决定的，组织分工的特点是独立的、可报告的、可挂起的单元(一般不是太细的动作)。2人/周的工作量被拆分成更小的故事。另外，保留大故事的原因是为了便于组织小故事，不要忘记你的主动性思维。

2.根据流程图确定系统中涉及的角色。支持这一过程需要哪些角色？非必要角色在系统支持中的价值是什么？如果不纳入会有什么影响？(对优先排序起指导作用)一般来说，执行层的角色会以职位名称命名。如何抽象权限体系中的每个角色？

3.根据流程图确定业务场景。我们要思考系统应该支持哪些业务活动，部分支持哪些业务活动，审批点是否属于系统，判断点是否是独立的环节。

(下图是一套体检系统的流程图。如果项目排期优先考虑电子化内部操作，则体检员一栏暂不纳入电子化系统。红圈是现在要开发的系统支持的任务活动)

4.补充业务场景是由时间、状态触发的常见业务场景，如信用卡还款到期、信用卡因长期逾期状态而冻结等。

5.画一个用例图。注意三种常见的关系——包含、延伸和概括。

包含关系——的公共子事件流(不需要展示给用户)，比如查座位信息。扩展——不一定要执行的扩展事件流(需要显示给用户看)，比如处理等待队列。泛化关系——公共事件流，比如checkout。

2.商业场景的六步分析1。业务场景概述(包括业务目的、前后条件等。)

2.把场景提炼成事件流，整理出用户期望的步骤，思考扩展和异常事件流。

注意两点：

用例的描述侧重于人机交互和意图，没有过多的人机界面和动作结构化语言的描述，较少表达“如果……”；或者扩展备选事件流单独列出，降低理解成本。3.对于每一步，思考并列出用户可能遇到的问题。

4.思考解决问题的方法。

5.考虑环境和业务特性带来的影响或需求，主要是三个方面：性能、可用性和部署环境。

6.开始初步的交互设计。

本文由@PM大云小原创发布。大家都是产品经理，未经作者允许，禁止转载。

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