想象一下，尝试描述您的产品需要执行的所有操作，而不会迷失在技术细节或无休止的功能列表中。这就是 Ivar Jacobson 在 20 世纪 80 年代引入用例时着手解决的问题。他没有担心系统内部如何工作，而是从外部描述它，就好像它是一个“黑匣子”，重点关注它对与之交互的人和系统的作用。这使开发人员能够更清晰、一致地捕获需求，为我们今天所依赖的使用故事铺平道路。
在本视频中，Syntagm Ltd 用户体验策略师兼创始人 William Hudson 介绍了用例，并解释了 Ivar Jacobson 如何创建它们来连接需求和实施。
Ivar 最初的用例术语是瑞典语单词 用例，直译为“用例”。然而，这在英语中是一个尴尬的短语，所以他将其缩写为“use case”。软件开发社区迅速采用了他的方法，并且 在敏捷流行之前，它成为指定系统的主要方法 世纪之交左右（正如您在顶部的图表中看到的那样）。
图表和叙述：用例的两个部分
用例分为两部分：
-
用例图：参与者及其相关用例的概述。
-
用例叙述：每个用例的参与者和系统之间的交互的描述。
在此视频中，William 展示了这两个部分，并解释了这些图如何成为统一建模语言 (UML) 的一部分。
用例图
以下是用例的基本概念，如视频所示。请注意， 演员 是与系统交互的任何东西，包括其他系统。演员们采取 角色。不幸的是，在传统的软件开发中， 角色不是以用户为中心的。它们几乎没有告诉我们执行它们的人的需求和行为。在交互式系统中，我们看到诸如客户、经理或用户之类的无信息角色。但你来这里是为了解决这个问题！
用例图的基本组件是参与者、刺激和响应以及系统。
© 交互设计基金会，CC BY-SA 4.0
这些图表对于提供系统功能的总体总结非常有用。然而，它们包含 没有时间或顺序的因素，这可能是一个缺点。通常的做法是 将较早或更常见的用例放在图表顶部。您在视频中看到的示例就是这种情况：
这个简单的用例图显示了客户和乘客角色如何与航班预订平台交互。按照惯例，时间会沿着页面向下流动，但情况并非总是如此。
© 交互设计基金会，CC BY-SA 4.0
尽管角色很少告诉我们用户的需求，但它们可能很重要。在上面的例子中，一个人可能扮演两个不同的角色，或者这些角色可能由不同的人扮演。这是登机时的一个重要区别。
用例叙述
用例叙述没有标准格式，但 Jacobson 指定了以下元素：
-
姓名：用例的描述性名称。
-
演员：与系统交互的实体（用户或其他系统）。
-
目标：演员想通过这种互动达到什么目的。
-
前提条件：在启动用例之前必须满足的任何条件。
-
基本流程：参与者和系统之间交互的典型序列。
-
替代流程：基本流程的变化，涵盖例外情况和其他可能性。
-
后置条件：用例完成后系统的状态。
这是一个简单的例子：
-
姓名： 在线预订座位
-
演员： 乘客;预订平台
-
目标： 在现有航班预订中选择并预订座位。
-
基本流程：
-
乘客登录预订平台并打开预订。
-
系统显示航班详细信息和可用座位。
-
乘客选择首选座位。
-
系统会根据座位分配更新预订。
-
系统确认预订更新。
-
-
替代流程： 所选座位不可用——系统通知乘客并要求他们选择另一个座位。
如果您不是程序员，前置条件和后置条件可能听起来很可怕。但它们只是事物 用例必须如此才能成功（先决条件） 和 一旦用例完成，这必须为真（后置条件）。这些对于以用户为中心的设计和用户体验非常有用，因为您可能需要在交互之前和之后向用户显示条件。考虑上面示例的前置条件和后置条件：
前提条件
-
乘客必须在指定航班上预订一个或多个座位。
-
该航班必须开放在线预订座位。
-
必须有可预订的座位。
后置条件
虽然上面的例子被简化了， 基本的和替代的流程叙述实际上会很长。还有一个问题是，如果乘客是不同的人，是否应该允许乘客预订他们购买的座位。解决此类问题的敏捷方法会将其留到最后一刻，称为 “及时设计”， 但如果这是一个早期的设计决策，那么大量的努力和混乱就可以避免。
将使用故事中的细节与过程的阶段相匹配
关于所有使用故事（包括用例）的最后一点是，适当的详细程度根据您在流程中所处的位置而变化。在设计的早期阶段，使用故事 不应包含详细的交互，例如那些带有界面组件的。因此，您应该写“Sandra 提供了她旅程的出站日期”，而不是“Sandra 从弹出日历中选择了她旅程的出站日期”。您可以说太早进入实施细节， “不成熟的设计。” 虽然后期阶段需要实施细节， 如果你做得太早，它们会分散你的注意力并限制你。此外，如果您提供工作原型，您通常会发现它比用散文描述交互细节更有效。
带走
用例标志着设计人员和开发人员如何开始捕获系统应该做什么的重要一步。 它们使得以结构化方式描述系统行为成为可能，即使它们并不总是基于研究的用户需求或行为。
您现在已经了解了如何表达用例 视觉上，在图表中， 和 在文字上，在叙述中。叙述通常描述“阳光灿烂的日子”流程，一切都按预期进行， 但替代流程，例如异常、决策和边缘情况，对于捕获也同样重要。
从用例中得到的另一个教训是：正确的详细程度取决于您在流程中所处的位置。过早提供太多细节会限制您的选择并导致“过早的设计”。让您的使用故事保持在适当的细节水平，并且 你将保持灵活性和创造力 同时仍然提供结构。
英雄图片：© 交互设计基金会，CC BY-SA 4.0