什么是用例？附示例和免费工具

用例是一种用于识别系统业务目标的工具。识别用例有助于界定系统范围，确保所发现的需求都与业务价值、需求和战略保持一致。

什么是用例？

用例代表通过与系统交互，由某人、某些各方或某些子系统所要实现的高层次业务目标，该系统可以是正在开发的系统，也可以是需要维护的系统，具体取决于软件项目的性质。

Use case

用例既不是系统需求，也不是需要实现的功能。事实上，将用例与需求分开非常重要，因为您需要一组清晰的用例来帮助您定义业务目标和系统范围。事实上，需求的收集应在识别用例（史诗）之后进行，然后将其分解为一组相应的用户故事（业务目标）。

用例的图形化形式

用例可以用UML用例图进行可视化。用例在图中以椭圆表示，其名称位于形状的中间。除了用例外，典型的用例图还包含另外两个元素——参与者和关联。

Use case diagram

参与者是指与系统交互以实现一个或多个由用例所代表的业务目标的角色。参与者与用例之间的交互通过关联（连接）来表示。请注意，参与者并不一定代表某个具体的实体（例如约翰），而只是一个角色（例如客户）。实际上，一个角色可以由不同的人担任，反之，一个人也可以担任多个角色。

如何识别用例？

用例是通过与企业所有者或公司高级管理人员沟通来发现的。我们通常称他们为业务利益相关者。与业务利益相关者一起识别用例非常重要，而不是其他人，因为他们清楚公司的方向和实际运营情况。他们还拥有做出商业决策所需的权威和信息。因此，所识别出的用例都与公司的业务价值观、需求和战略保持一致。

为什么要使用用例？

许多人认为识别用例是一个冗余步骤，他们更愿意直接进入系统需求的识别。那么，用例方法真的无用吗？

当你准备开发一个大型系统时，通常会涉及许多利益相关者，他们对最终系统有不同的期望，最终导致需求集合变得难以管理。用例可以作为占位符，容纳一组相关用户故事，这些用户故事共享一个更大的、共同的业务目标和范围。

请记住，用例是通过与企业所有者和高级管理人员沟通来发现的，他们负责公司的发展，并具备制定战略商业决策的能力。因此，用例直接反映了目标系统必须实现的业务目标。通过基于用例来寻找需求，这些需求极有可能处于系统范围内，从而实现所有者所期望的业务价值。此外，用例还有助于对需求进行有意义的分类。所提出的软件功能可以根据用例的重要性来规划，而不是仅仅依赖一线利益相关者的观点，这些观点可能并不完全符合企业所有者的期望。

用例示例

以下是一些示例，用于说明用例的使用方法。此处给出的示例仅用于说明目的，对于特定目标系统应识别哪些用例，并没有固定的方法。用例识别过程的通用原则始终是与业务利益相关者积极互动和参与的结果。

系统

用例

  • ATM
    • 取现、转账、捐款、支付账单、修改密码
  • 在线相册
    • 上传照片、分享照片、删除照片
  • 健康追踪应用
    • 记录锻炼、生成锻炼统计、挑战目标

基于上述示例，我们可能会进行以下讨论：

用例产生可观察的目标

用例示例——ATM

ATM是在解释用例或用例分析概念时的经典示例。你可能会疑惑，为什么没有‘登录’这个用例，而登录是所有ATM操作中必不可少的步骤。正如所说，用例是需要实现的业务目标。它们会为与系统交互以实现用例的参与者产生可观察的结果。在这里，‘登录’只是其他操作的一部分。‘登录’本身并不会产生任何可观察的结果——没有人只是登录ATM就离开吧？因此，我们不将‘登录’视为一个用例。

‘修改密码’难道不会太小而不能成为一个用例吗？答案是：用例的识别既不基于用户需要完成的工作量，也不基于需要开发的系统功能数量。只要它是业务利益相关者希望目标系统实现的业务目标，它就是一个用例。在这种情况下，我们认为客户通过ATM修改密码是一个用例。

用例示例——在线相册

典型的在线相册允许用户为其上传的照片添加标签。那么‘添加照片标签’是否是一个用例呢？答案是：这取决于具体情况。如果业务相关方希望用户能够访问系统以添加照片标签，即使在会话中不做其他任何操作，那么‘添加照片标签’就应该作为一个用例。然而，如果他们认为添加照片标签只是上传照片过程的一部分，并且之后没有其他方式可以添加标签，那么‘添加照片标签’就不应被视为一个用例。另一种情况是，相关方只是希望用户能够编辑他们上传的照片，例如修改标题、描述、标签等属性。在这种情况下，很可能就会创建一个‘编辑照片’的用例。由此可见，用例的识别并非随意之举。你可以想象，在‘添加照片标签’和‘编辑照片’这两个用例下，支持照片标签功能的方式将会大不相同。

用例示例——健康追踪应用

尽管用例并非需求本身，但这并不意味着用例是抽象且缺乏重点的。以健康追踪应用为例，记录锻炼、生成锻炼统计数据以及设定目标挑战，这些内容在界定功能范围方面都已足够清晰。那么，‘保持良好健康’能否成为一个用例呢？其实这是一个糟糕的选择，因为它的范围过于宽泛。每个健康追踪应用都在努力帮助用户实现这一目标，但有了这样一个宏大的目标，我们却无法确定这些应用实际能够实现哪些功能！

如何编写用例？

用例最简单的形式由一个+或描述业务目标的动词构成。以下是一些示例：

  1. 注册账户
  2. 下单
  3. 取现
  4. 发布职位空缺
  5. 调查案例失败原因

如前所述，用例的设计目的是识别业务目标。不要用它来编写需求，也不要用来描述用户与系统之间的交互。所有这些步骤将在后续的开发活动中详细展开，而不是现在。

结合用例与用户故事使用

用户故事也是敏捷开发中的一个重要工具。每个用户故事都包含一个从用户视角出发的简短描述。以下是一些用户故事的示例：

  1. 用户希望使用信用卡支付。
  2. 用户希望使用PayPal支付。
  3. 用户希望在结账时可选地添加运输保险。
  4. 用户希望在结账时选择不同的收货地址。
  5. 用户希望在订单成功创建后收到短信通知。

用例是一种用于定义功能范围的工具，而用户故事则记录了用户在工作过程中所做的事情或需要完成的任务，最终促成需求的产生。我们可以结合这两种需求捕获方法来识别正确的需求。具体步骤如下：首先，与业务相关方沟通，将业务目标识别为用例。然后，聚焦于某个特定用例，与一线用户沟通，识别该用例下的用户故事。由于用户故事的识别是由用例驱动的，因此最终得出的需求将与业务目标保持一致。

Use case and user stories

Visual Paradigm 提供了你在 敏捷软件开发中所需的一切工具，包括 UML 用例图工具, （敏捷）用户故事, 冲刺, 故事板以及 线框图用于用户体验设计，任务管理工具，等等

参考文献

  1. 用例图 – 统一建模语言（UML）
  2. 什么是用例图？
  3. 创建一个UML用例图
  4. 用例图的最佳实践与示例
  5. 用例图模板
  6. 在Visual Paradigm中描述用例（UML）
  7. 用例图
  8. 如何绘制用例图？

Leave a Reply