现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种思想可以同时应用在产品设计、研发和测试多个阶段，可以比较生动地描绘出事件触发时的情景，从用例开始到结束遍历这条路径上所有基本流和备选流。

基本概念

场景用例示意图

changjingfa-w120

基本流：采用直黑线表示，是经过用例的最简单的路径（无任何差错，程序从开始直接执行到结束）

备选流：采用不同颜色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不在加入到基本流中；（各种错误情况）

主要的场景类型

正常的用例场景
备选的用例场景
异常的用例场景
假定推测的场景

通常从正常的用例场景分析开始，然后再着手其他的场景分析

实例分析

目标

完成一套出租车预定系统

功能

顾客进行出租车的预定
系统完成扣款
出租车司机的任务分配

流程简述

顾客中的大部分在出租车租赁公司立有相关存款账户
顾客一般通过电话的方式进行预约，有些是要求立马预定的，也有一些是预定几周后的
系统需要确保这些存款账户到目前为止是有效的
系统需要知道什么时候顾客需要出租车，以及接送地址和他们的目的地(接送地址一般来说是顾客账户信息上填写的地址)
根据车辆调度员的经验，告诉顾客最佳的接送时间
系统根据订阅情况产生一个司机工作编号并记录预定过程中的详细信息
系统根据接送时间的顺序对这些信息按照接送的时间进行排序，然后给顾客一个订阅的确认信息，同时包括司机的工作编号

正常业务场景建立

识别业务事件流
1. 事件名
2. 输入数据（由这个事件引起的输入数据）
3. 输出数据（为了响应这个事件产生的输出数据）
画一个非正式的业务场景草图
把这个场景草图形成场景

顾客进行出租车预定的业务场景建立

I 事件流

graph TD
A[用户想要预定出租车] --> B(发出出租车预定请求)
O((这是事件名))-->A
B --> C(系统安排出租车预定行为)
E((这是系统输入)) --> B
C --> D[发送一个出租车预定确认信息给顾客]
F((这是系统输出)) --> D

II 画一个非正式的业务场景草图

III 把草图形成场景

1) 顾客告诉我们他想预定出租车 2) 调度员需要知道顾客的账户号码，那么他是否也需要知道顾客的账户姓名？调度员是否需要询问乘客的姓名？ 3) 调度员核实账户号及支付信息的有效性，那是否也需要核对账户姓名的有效性？（关注衍生信息有效性的检查） 4) 调度员需要向顾客询问接送的日期，时间，地址和目的地 5) 调度员需要告诉顾客最佳的接送时间 6) 调度员分配一个工作接送号给司机，那这个工作号是从哪里产生的？(关注数据从哪里产生)
7) 调度员记录所有预约工作的细节 8) 调度员跟顾客确认订阅的详细信息

预约出租车正常的用例场景如下：

1) 客户打电话到出租车公司预约出租车 2) 出租车调度员询问账号号码以及账号的姓名 3) 出租车调度员核实顾客的账号详情以及支付的方式 4) 调度员询问接送的地址，预定的接送时间以及目的地 5) 调度员告诉顾客最佳的接送时间 6) 调度员分配预定的工作号给出租车司机 7) 调度员记录详细的预定信息 8) 调度员反馈预定成功的确认信息给顾客

如何发现备选流

I 备选的用例场景

从基本流开始，在某个特定条件下执行，然后重新加入基本流

对正常用例场景中的每一步列出一份==问题检查列表==：

这一步是否如实按照规定的发生？
对于描述中每一个名词，动词我们是否都知道精确的含义?—是否有任何数据上的遗漏?
是否存在一些主观上的判断？
我是否已经做了所有的假设？
这么做是否真正有意义？

II 备选用例场景分析

1) 顾客打电话告诉我们他想预定出租车,那么顾客是一个个人还是一个组织？顾客是否经常通过电话进行交流？顾客是想预约一辆出租车还是可能会预约多辆出租车？ 2) 出租车调度员向顾客询问账号号码，姓名以及乘客的姓名,是否只有调度员询问顾客还是有其他人也一起来询问？顾客是否都在出租车租赁公司有一个账号？是否可能会出现多个乘客的姓名？

通过问这一系列问题，将会发现顾客未必都会有一个账号的，乘客也可能是多个，这样就能构建一个备选流的用例场景了

备选的用例场景一

预约出租车，顾客没有存款帐号
出租车调度员询问顾客有关乘客的姓名和帐户信息
出租车调度员核对客户的帐户信息
出租车调度员增加“无账号”信息到预约详细信息中

III 异常用例场景

异常用例是指当错误发生或者一个不需要的处理条件发生了

发现异常用例场景的方法

什么样的数据条件将会导致这一步不能继续处理?
什么样的历史数据将会导致这一步不能继续处理?
什么样的人为行为将会导致这一步不能继续处理?

IV异常用例场景分析

出租车调度员核实顾客的账户信息和支付方式,如果出租车调度员发现顾客提供了错误的账户信息将会发生什么？
顾客的帐户支付方式过期了怎么办？
如果顾客账号在预先约定好的时间内未进行及时支付将会怎么样？

V 假定推测场景

以正常的用例场景作为起点，对每一个步骤鉴别约束条件
如果约束条件不存在的话，将会发生什么？

假定推测场景分析

顾客打电话告诉我们要预定一辆出租车,其中一个约束就是顾客用电话联系，如果移除这个约束，顾客将会通过什么样的方式来联系？
一个很明显的方式就是通过网络，也有可能是通过旅行社代理订购，或者是出租车的代金券,如果改用信用卡支付会是怎样的等等。
一旦移除了约束，思考各种可能的情况，就可以发现更多需求中遗漏的点

Mr Shang

利用场景法建立用户业务场景