让我们以登录为例，添加项目作为项目管理系统的两个用例。 客户的要求是:(他需要/希望到：）
我们也知道没有未经身份验证的用户应该使用该系统！
我的问题是：
1）“获取访问权限”是一个用例吗？其他用例的前提条件？或两者 ？ （知道通过命名用例“获取访问权限”而不是“登录”我想强调需要而不是解决方案为了这个需要。
2）如果“获取访问权限”是一个用例，“ 添加项目 ”用例是否包含“< strong>获取访问权限“用例？
使用案例依赖关系：
顺序依赖
用例前提条件反映了用例之间的顺序依赖。
使用案例B和前提条件C只能在 用例A后生成C作为后置条件。 用例B在 用例A后执行;他们的联系是异步的。
功能依赖
相反，包含关系反映了用例之间的功能依赖性。
当用例A与用例B具有包含关系时，意味着用例B的功能是用例A的整体功能的部分。 用例B作为用例A的部分执行;他们的联系是同步。
https://www.batimes.com/articles/use-case-preconditions-a-best-kept-secret.html
答案 0 :(得分：2)
用例必须生成商业价值。是＆＃34;登录＆＃34; （或获取访问权等）自身提供商业价值？系统用户登录然后将其留在那吗？可能不是。因此，登录不是用例本身。它可以记录为用例中的一个步骤（如果您对解决方案有足够的了解并且感觉倾向于说）但请注意不要在用例中指定技术解决方案。您最好指定必须将用户标识为特定级别的身份验证，并将其作为先决条件等应用。
商业价值是关键。认识到商业价值是艺术和分析科学的一部分。例如，如果您没有使用用例来模拟需求，则情况也是如此 - 例如形式的用户故事＆＃34;作为（角色）需要（行动）使（商业价值）＆＃34;再次以商业价值为重点。最终，商业价值是任何功能需求的焦点，明确识别它应该是您的分析接近其目标的主要指标之一。
考虑到这一点 - 顺序和功能依赖。注意不要将系统功能分解为不能反映商业价值的单位。经常引用的ATM示例：支票余额是一个用例，输入PIN 不是（由于上述原因）。但是，您可能希望在执行提取现金时始终检查余额。如果是这种情况，那么您可以使用包含来显示提取现金包含支票余额，但请注意两个用例都提供业务价值在其自身。