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