关于将涉及多个参与者的流程拆分为用例的建议

时间:2008-10-02 05:45:32

标签: requirements use-case

假设我正在建模一个涉及两个演员之间的对话或煽动的过程。对于这个例子,我将使用一些易于理解的东西: -

  1. 供应商创建价目表,
  2. 买方选择购买一些物品并发送采购订单,
  3. 供应商收到采购订单并发送货物。
  4. 供应商发送发票
  5. 买方收到发票并付款
  6. 当然,每个步骤本身都可能很快复杂化。您如何将其分解为需求文档中的用例?

    如果将此过程视为单个用例,则可以填写一本书。

    或者,从上述每个步骤中创建一个用例会隐藏一些应该捕获的基本交互和流程。如果有一个用例从“收到订单”开始并以“发送发票”结束然后另一个以“收到发票”开头并以“付款”结束,那么它是否有意义?

    有什么建议吗?

2 个答案:

答案 0 :(得分:1)

是的,这里有很多可能性。在上面的示例中,买方进行多次部分付款以支付账单可能会更加复杂。

您可能需要创建完整的工作流用例。将上述每个步骤拆分成它们自己的用例可能不是很有用,因为一些步骤将具有预先和发布条件。

我处理QuickBooks源代码,事务可以通过系统流动的方式令人生畏。我们的质量保证人员几乎不可能测试每种组合。

答案 1 :(得分:1)

我通常接近这些任务的方式是开始为流程创建UML用例和高级活动图。不要打扰细节,只要给它最好的拍摄。

当你有一个草案时,你几乎可以立即看到它如何改进。然后,您可以继续重构它 - 使用例更小,构建大型活动等等。或者,如果它们太小,你可以把几个用例放在一起。

在不知道项目细节的情况下,我会继续将每个步骤作为一个单独的用例 - 它们似乎都是自包含的,可以在没有任何交叉引用的情况下进行描述。如果这样做,你会发现任何依赖关系,你总是可以重新考虑这种方法。

还可以考虑对日志,安全等常见元素使用'extend'和'include'块。