蜗牛派
业务分析技术的清单相当多，每年都有新技术出现。一些技术变得更加流行，并被广泛使用，有些只有在特定的需要时才使用。但总是有一些经久不衰的技术，它们是业务流程图、用例、用户故事、线框和业务规则。
对于两种流行的业务分析技术：用例和业务流程图，有经验的业务分析师也不完全理解这两种技术之间的区别。在这篇文章中，我想说明业务流程图和用例之间的区别。
用例
让我们先看看用例。用例的目的是什么？首先，让我们看看用例图。它向我们展示了系统的边界是什么，有多少用例，参与者和用例之间的关系；用例和用例之间的关系。用例图为我们提供了系统和子系统的范围。让我们看看下面的例子。
然后，我们希望对每个用例提供更清晰的信息，并创建一个用例描述。用例描述提供了一系列的步骤，一个参与者必须通过这些步骤来实现一个目标。用例描述并且还提供了异常和替代流。
让我们看看一个用例描述的简单示例：
UC-01注册帐户
当我们对所有4个用例都这样做时，解决方案就容易设计了， 但在此之前还有其他事情要做。接下来，现在我们必须指定与用例相关的业务规则。BABOK规定业务规则应该单独获取，这样做的目的是如果业务规则修改了，不需要修改用例。让我们看看下面商业规则的例子：
现在让我们看看，如果我们选择一个业务流程图技术，我们必须做些什么。
业务流程图
让我们从范围开始。大家知道，业务流程图显示的序列，因此我们不能使用这种技术来显示系统的范围。那我们该怎么办？我通常用范围图。创建范围图有很多种方法，下面我提供一个范围图可能是什么样子的示例。
此范围图显示了由参与者划分的系统的特性/功能。
因此，当范围比较大时，可以添加功能分类，例如一个完整的范围图可能是这样的：
有些人会说，用例图可以显示用例之间的关系。比如包括、扩展以及还可以显示一个用例可以由几个参与者执行。这也可以在范围图上显示。
现在，让我们绘制一个帐户注册功能/功能的过程。帐户注册过程将是这样的：
类似于用例技术，我们在业务流程图中也需要创建业务规则并跟踪它们。在这种情况下，我们通过业务规则识别重新回到流程步骤。
结论
因此，正如你所看到的，我们使用了不同的技术，基本上结果是相同的。使用什么技术并不重要。这只是一个习惯问题，所以如果你对用例更满意，那么坚持它们，或者如果你更熟悉业务流程图，然后绘制地图。
作为一个例外，我将强调的唯一情况是复杂逻辑的复杂功能的场景，有许多ifs、buts和其他条件。在这种情况下，我更喜欢使用业务流程图，但是我看到人们使用用例， 并且有许多替代和异常流，例如。异常流1的替代流3的异常流3。
