【问题标题】：Advice on splitting up a process involving multiple actors into Use Cases关于将涉及多个参与者的流程拆分为用例的建议
【发布时间】：2008-10-02 05:45:31
【问题描述】：
假设我正在模拟一个涉及两个演员之间对话或交流的过程。对于这个例子，我将使用一些容易理解的东西：-
- 供应商创建价目表，
- 买家选择一些要购买的商品并发送采购订单，
- 供应商收到采购订单并发货。
- 供应商发送发票
- 买家收到发票并付款
当然，每个步骤本身都可能很快变得复杂。您将如何在需求文档中将其拆分为用例？
如果将此过程视为单个用例，它可以填满一本书。
或者，从上述每个步骤中创建一个用例会隐藏一些应该捕获的基本交互和流程。有一个用例从“收到采购订单”开始，到“发送发票”结束，然后另一个用例从“接收发票”开始，到“付款”结束，这是否有意义？
有什么建议吗？
【问题讨论】：
标签：
requirements
use-case
【解决方案1】：
我通常处理此类任务的方式是刚开始为流程创建 UML 用例和高级活动图。不要在意细节，只要尽力而为。
当您有草稿时，您几乎会立即从中看出如何改进它。然后你可以继续重构它——让用例更小，构建大型活动等等。或者，如果它们太小，您可以将几个用例放在一起。
在不知道您项目的细节的情况下，我会继续将每个步骤作为一个单独的用例 - 它们似乎都是独立的，可以在没有任何交叉引用的情况下进行描述。如果这样做时您会发现任何依赖项，您总是可以重新考虑该方法。
还可以考虑对常见元素（如日志记录、安全性等）使用“扩展”和“包含”块。
【解决方案2】：
是的，这里有很多可能性。在您上面的示例中，买方进行多次部分付款以支付账单可能会更加复杂。
您可能需要创建完整的工作流用例。将上述每个步骤拆分为自己的用例可能没有用，因为某些步骤将具有前置和后置条件。
我从事 QuickBooks 源代码的工作，交易可以通过系统流动的方式数量之多令人望而生畏。我们的 QA 人员几乎不可能测试每个组合。