产品经理进阶需求用例分析之异常流
⇨⇦
问题的引出
备选流，又称备选事件流，英文是Alternative Flow。在RUP和UML中，备选流的解释如下：备选事件流包括与正常行为相关的可选或异常特征的行为，同时也包括正常行为的各种变形。您可以将备选事件流看作是基本事件流的＂绕行道＂，有些备选事件流将返回到基本事件流，而有些将结束此用例的执行。
分析RUP对于备选流的定义，可以看到备选流可以分成两类：
1，不同做法但仍然达成用例目标;
2，异常情况，无法达成用例目标。
在实际用例分析中，由于备选流可能存在两种情况，导致备选流存在2种主要写法：
1.在备选流中说明基本流以外的异常情况的处理，可能仍然回到基本流，也可能导致用例结束。
在备选流中说明基本流以外的其它正常和异常情况的处理，覆盖了其它功能。
第1种写法的例子比较常见，下文将出现，这里不再赘述。
第2种写法的例子如下：
用例名称：填写请购单
简要说明
员工在线填写图书请购单，内容包括：图书名称、出版社、作者、价格、订购人(系统自动识别)、订购部门、订购日期等，填好后提交给图书管理员审核。
填写请购单的主角是员工。
事件流
员工选择＂填写请购单＂，用例开始。
基本流
员工选择＂填写请购单＂，提交＂填写请购单＂请求;
显示＂填写请购单＂窗口并列表显示请购单信息(已填写未提交、已提交审核未通过)， 两种状态的请购单信息通过选择分别列出，审核未通过的原因只能查看不能修改;
请购单信息包括：请购单编码(系统自动生成)、订购部门、订购人、订购日期、订购原因、备注，和图书明细包括：图书名称、出版社、作者、单价、数量等，图书明细包括：新增，修改，删除;
请购单信息输入操作见备选流;
新增：系统具体执行见＂备选流 新增＂
修改：系统具体执行见＂备选流 修改＂
删除：系统具体执行见＂备选流 删除＂
选择＂提交＂，系统把选中的请购单提交给图书管理员审核，此用例结束。
备选流
填写请购单基本流中抽取出三个备选流：
请购单信息：新增、修改、删除;
新增
(一)员工在＂填写请购单＂信息区选择＂新增＂，提交＂新增＂请求;
(二)系统弹出＂新增请购单＂空白模式窗口;
(三)请购单信息包括：图书名称、出版社、作者、单价、数量等;
(四)请购单信息输入完毕后，选择＂保存＂提交，系统验证数据有效性，如验证不成功，针对所提示错误信息修正输入数据，验证成功关闭＂新增请购单＂窗口;
若继续新增请购单，则重复㈠㈡㈢㈣步骤。
修改
(一)员工在＂填写请购单＂信息区列表选中要修改的请购单，提交＂修改＂请求;
(二)系统弹出＂修改请购单＂模式窗口，并显示当前请购单信息;
(三)修改相应数据后，选择＂保存＂提交，系统验证数据有效性，如验证不成功则根据错误提示重新输入，验证成功后保存数据并关闭＂修改请购单＂模式窗口同时刷新请购单信息列表;
若继续修改，则重复㈠㈡㈢步骤。
删除
(一)员工在＂填写请购单＂信息区列表选中要删除的请购单，提交＂删除＂请求;
(二)若选中的请购单属于审核未通过，系统提示＂不能删除审核未通过的请购单＂;
(三)删除后刷新请购单列表信息同时系统提示＂编号为XXX的请购单已删除!＂;
若继续删除，则重复㈠㈡㈢步骤。
特殊需求
无
前置条件
员工登录系统。
后置条件
无
—例子结束—-
第2种写法中，在备选流中说明了基本功能，用例篇幅已经变长，如果备选流中出现异常，备选流将显得更加臃肿。因此第2种写法比较少见。
为了解决备选流的不同情况，人们识别率异常流来解决上述问题。
异常流是什么?
Bernd Lohmeyer提出来如下分类规则
(见http://www.lohmy.de/2013/03/06/writing-use-cases-exception-or-alternate-flow/)
l Result negative: An Exception is anything that leads to NOT achieving the use case’s goal. 负面结果：异常，任何导致不能达成用例目标的事情
l Result positive: An Alternate Flow is a step or a sequence of steps that achieves the use case’s goal following different steps than described in the main success scenario. But the goal is achieved finally. 正面结果：备选流，一步或多个步骤序列达成了用例目标，但与主成功场景不一样的步骤。最终目标是达成的。
见如下例子：