dependencies - 一个用例可以包含和前置相同的其他用例吗？

Question

让我们以登录和添加项目为例，作为项目管理系统的两个用例。客户的要求是：（他需要/想要：）

1. 获得对系统资源的合法访问权；
2. 添加项目（创建一个）。

我们也知道未经身份验证的用户不应使用该系统！

我的问题是：

1）“获得访问权”是一个用例吗？其他用例的先决条件 ? 或两者 ？（知道通过将用例命名为“ Gain Access ”而不是“Logging in”，我想强调需求而不是该需求的解决方案。

2) 如果“ Gain Access ”是一个用例，“ Add Item ”用例是否包括“ Gain Access ”用例？

用例依赖项：

顺序依赖

• 用例前置条件反映了用例之间的顺序依赖关系。

• 带有前置条件 C 的用例 B 只能在用例 A 产生 C 作为后置条件后开始。用例 B在用例 A之后执行；它们的连接是异步的。

功能依赖

• 相反，包含关系反映了用例之间的功能依赖关系。

• 当用例 A 与用例 B 具有包含关系时，这意味着用例 B 的功能是用例 A 的整体功能的一部分。用例 B 作为用例 A 的一部分执行；它们的连接是同步的。

https://www.batimes.com/articles/use-case-preconditions-a-best-kept-secret.html

标签： dependenciesincludeumlsoftware-designuse-case

Answer 1

用例必须产生业务价值。“登录”（或获得访问权限等）本身是否提供了商业价值？系统的用户会登录然后离开吗？可能不是。因此登录本身不是用例。它可以记录为用例中的一个步骤（如果您对解决方案有足够的了解并且愿意说的话），但请注意不要在用例中指定技术解决方案。您最好指定必须将用户标识为特定级别的身份验证并将其应用为先决条件等。

商业价值是关键。识别商业价值是分析艺术和科学的一部分。例如，如果您不使用用例对需求建模，情况也是如此——例如，“作为（角色）需要（行动）以便（业务价值）”形式的用户故事再次成为业务-以价值为中心。最终，业务价值是任何功能需求的焦点，明确识别应该是您的分析接近其目标的主要指标之一。

记住这一点——顺序和功能依赖。注意不要将系统的功能分解为不反映业务价值的单元。经常引用的 ATM 示例：检查余额是一个用例，输入 PIN不是（出于上述原因）。但是，您可能希望在执行Withdraw Cash时始终检查余额。如果是这种情况，那么您可以使用包含来显示Withdraw Cash包括Check Balance，但请注意，两个用例本身都提供业务价值。