Dependencies 一个用例是否可以包含和预处理相同的其他用例？

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

合法访问系统资源

添加项目（创建一个）

我们还知道，未经验证的用户不得使用该系统

我的问题是：

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

2） 如果“获得访问权”是一个用例，“添加项”用例是否包括“获得访问权”用例

用例依赖关系的：

顺序依赖关系

• 用例先决条件反映了用例之间的顺序依赖关系

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

功能相关性

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

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

用例必须产生业务价值。“登录”（或获得访问权等）本身是否带来了业务价值？系统的用户是否会登录，然后不登录？可能不会。因此，登录本身不是一个用例。它可以被记录为用例中的一个步骤（如果您对解决方案了解得足够多并且倾向于这样说），但是请注意不要在用例中指定技术解决方案。您最好指定必须对用户进行一定级别的身份验证，并将其作为先决条件应用，等等

商业价值是关键。识别商业价值是分析的艺术和科学的一部分。例如，如果您没有使用用例对需求进行建模，那么同样的情况也会发生——例如，表单的用户故事“作为需要（行动）的（角色），（业务价值）”再次以业务价值为中心。归根结底，业务价值是任何功能需求的焦点，对其的明确识别应该是您的分析接近其目标的主要指标之一

---

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

登录

不是用例，而是约束。Read Bittner/Spence.Yes登录不是一个用例，但是“获得合法访问权”呢？这是一项要求，我想这是一项要求。这将导致用例的约束。好吧，但是如果它是约束而不是用例，那么如何对扩展“获得访问”的需求建模呢。例如“重置密码”（如果他们希望在登录后重置密码，则重置密码）