用例描述了主要涉众、解决方案以及为实现主要涉众目标所必需的辅助涉众之间的交互，通常由主要涉众触发。场景描述了角色实现特定目标的一种方式，用例描述了多个场景。用例没有固定的格式，通常包括用例图、用例描述、关系、角色、前置条件、触发器、事件流、后置条件或保证等元素。用例的优势包括澄清范围、提供高层次理解、易于理解、表达系统的功能行为等，限制包括灵活性可能导致信息嵌入、不适合记录决策及其定义决策的业务规则、灵活格式可能导致捕获不适当或不必要的详细信息、用例故意不涉及解决方案的设计等。

#需求探索##需求分析##商业分析#

用例与场景1 目的

用例和场景描述了一个人或系统如何与被建模的解决方案互动以实现目标。

2 描述

用例描述主要涉众、解决方案以及任何为实现主要涉众目标所必需的辅助涉众之间的交互。 用例通常由主要涉众触发，但在某些方法中也可以由另一个系统或外部事件/计时器触发。

用例描述了解决方案支持的特定目标的可能结果。它详细说明了可以遵循的不同路径，通过定义主要和替代流程来实现。主或基本流程代表实现用例目标最直接的方法。导致无法完成用例目标的特殊情况和异常在替代或异常流程中进行记录。用例从执行者的角度编写，并避免描述解决方案的内部工作原理。

用例图显示了与解决方案支持的一个或多个用例相关的涉众之间的关系。

一些用例方法区分业务用例和系统用例，其中业务用例描述了涉众如何与特定过程或业务功能交互，而系统用例则描述了涉众与软件应用程序之间的交互。

场景描述的是角色 1实现特定目标的一种方式。场景被编写为一系列步骤，由角色或解决方案执行，使角色能够实现目标。用例描述多个场景。

3 元素

用例没有固定的、通用的格式。下面的内容经常包含在用例描述中：

1. 用例图

用例图 通过显示与解决方案交互的涉众、他们使用哪些用例以及它们之间的任何关系，从视觉上展示了解决方案的范围。统一建模语言 (UML) 定义了用于表示用例图的标准符号。

关系

角色与用例之间的关系称为关联。 关联线表示一个角色可以访问由用例代表的功能。用例不表示输入、输出、时间或依赖关系。两个常见的用例之间的关系是：

扩展：允许在用例中插入额外的行为。 被扩展的用例必须完全独立，其成功执行不应依赖于扩展的用例。 可以使用这种关系来表示为现有的用例添加了替代流程（表示新的要求）。包含：允许用例使用另一个用例中提供的功能。如果一个用例不直接由一个角色触发，那么被包含的用例不需要成为一个完整的用例。这种关系通常用于需要几个用例共享的功能，或者为了抽象出复杂的逻辑。

.2 用例描述

姓名

用例具有唯一的名称。该名称通常包括一个动词，描述涉众执行的操作，以及名词，描述正在发生的事情或操作的目标。

目标

目标是从主要使用者的角度对用例的成功结果进行简短描述。 这是对用例的总结。

角色们

角色 是解决方案之外的任何个人或系统，与该解决方案交互。每个角色都被赋予了一个独特的名称，以代表它们在与解决方案交互中所扮演的角色。一些用例编写方法建议反对把系统或事件当作角色。

用例由一个被称为 主要角色 的涉众启动。在用例中以支持角色参与的其他涉众称为 从属角色 。

前置条件

前置条件 是在用例开始之前必须为真的任何事实。虽然在用例中没有测试前置条件，但它对用例的执行起到了约束作用。

触发器

触发器 是一个用例中引发事件序列发生的事件。最常见的触发器是由 主要角色 执行的动作。

时间事件（例如，时间）可以启动用例。这通常用于触发根据一天中的时间或特定日历日期执行的用例，例如结束一天例行程序或月底系统对账。

事件流

事件流 是 在用例执行过程中由 行为者 执行并解决的一系列步骤。大多数用例描述都会分离出一个基本、主要或主成功流程，该流程代表了行为者的最短或最简单的成功路径以实现其目标。

用例还可以包括替代方案和异常流程。替代流程描述了可能采取的其他路径，以使涉众能够成功实现用例目标。异常流程描述了解决方案在无法实现目标且用例无法成功完成时所期望的响应。

后置条件或保证

后置条件 是在用例完成后必须为真的事实。 后置条件 必须对用例的所有可能流程成立，包括主流程和备选流程。 用例可以描述针对用例成功和不成功的执行所假定的独立后置条件。 这些可以称为保证； 成功保证 描述了成功执行时的后置条件。 最小保证 描述了即使涉众的目标没有实现也必须为真的条件，并且可能涉及安全要求或数据完整性等问题。

4 使用考虑因素

.1 优势

用例图可以澄清范围，并提供对需求的高层次理解。用例描述易于理解，因为它们具有叙事流程。确保在用例中包含期望的目标或结果，这有助于阐明业务价值。用例描述表达了系统的功能行为。

.2 限制

用例描述格式的灵活性可能导致信息嵌入，这些信息最好使用其他技术捕获，例如用户界面交互、非功能需求和业务规则。决策及其定义决策的业务规则不应直接记录在用例中，而应单独管理并从适当的步骤链接。使用案例的灵活格式可能会导致在试图显示每个步骤或交互的情况下捕获不适当或不必要的详细信息。用例故意不涉及解决方案的设计，因此在开发过程中可能需要付出很大的努力来映射用例步骤到软件架构。

本文同步发表在 软件需求探索的软件需求探索 - 用例与场景

1 商业分析中的五十种分析方法和技巧之39-角色与权限矩阵.软件需求探索 - 角色与权限矩阵