作者：Alexandra Matz和Panagiotis Germanakos

"用例"是商业界广泛使用的术语。利益相关者在不同的上下文中引用用例：业务分析师在他们的报告中描述"用例"，政客们声称决策或项目有或没有"用例"。每次人们赋予术语不同的含义时，外汇返现，

在公司里，"用例"通常是可以作为产品或产品的一部分实现的商业案例、过程或场景的同义词。当我们在用户体验（UX）的上下文中谈论"用例"时，我们指的是用户和系统之间可能的交互的文档。用户体验中的用例是用户研究和用户体验设计的重要工具。在以设计为导向的开发过程中，他们通过表达一系列的步骤和交互来展示系统的目的和目标以及相关的用户角色，这些步骤和交互都指向一个特定的、共同的目标。

现在，所有的重点都放在用户体验上，国内云服务器，为什么除了用户体验专业人士之外的任何人都会处理用例？答案是，用例可以在设计阶段之后广泛而持续地使用，特别是在开发和质量保证中，具有各种好处：

用例在描述用户和系统交互的方式上是技术独立的。因此，我们可以明确区分参与者、他们与系统的交互以及信息流。这使得跨职能团队能够协作地评估、讨论和验证用例，而无需编写一行代码。一个详细的、经过验证的用例是一个理想的参考点，它为团队提供了关于如何设计、开发和测试应用程序交互的明确指导。因此，用例对用户体验、开发和质量保证同样有价值。

为了提供一个可行的、理想的和高质量的产品，设计产品不仅要考虑成功案例，而且要考虑可能的失败案例和用户交互中的可选流程，这一点非常重要。在用例中，这些可以很容易地记录下来，而不需要深入到每一个细节。在第二步中，在创建了主要的成功用例之后，返利平台，产品团队可以考虑替代用例的细节，并根据复杂性为这些场景创建单独的用例。

因此，产品架构师和开发人员收到了一份详细的文档，人工智能工作，并在必要和可能的交互基础上达成一致。这提供了一个很好的概述和对必须构建什么和可能需要构建什么的见解。

用例很少是独立的。除了可选择的流程和失败案例外，父用例和子用例以及其他相关的案例在用例工作中出现，以完成更大的图景。

最常见的情况是由一个父用例和多个子用例、失败案例等组成的用例层次结构在发展。但是，其他产品团队可能创建的相关用例也可以记录在层次结构中。这可能是因为不同的用户角色跨业务场景甚至产品执行相同的任务，因此这些用例可以在多个用例层次结构中重用，甚至跨业务场景甚至产品。

用例层次结构有助于开发团队在进入实现之前了解系统功能阶段。清晰和结构化的交互可以用在架构设计和待办事项规划中，因为用例更容易分解成可管理的包和待办事项。此外，它使项目团队能够做出更准确的时间和成本估算，并改进设计、开发和测试的资源分配。

用例的一个好处是，您可以在每个交互步骤中包括UI数据，无论是针对用户还是系统端。为了使用例技术独立，易于阅读，并且所有产品团队成员都能理解，用例显示了哪些数据元素必须出现在屏幕上。即使不是数据字典格式，云产品，它也表达了用户的输入和输出。

数据库架构师和开发人员可以根据这些信息为UI开发进行数据绑定，无需反复迭代或讨论哪些数据字段应该出现在UI上。

由于用例可以被所有产品团队成员创建和理解，因此它也是用户帮助专家勾勒出可能的术语问题和关注点的理想媒介。根据业务场景的复杂性，用例中的一些用例或操作可能需要以更辅助的方式进行记录。一方面，这提高了用例的质量，另一方面，它确保了在设计和开发过程中无缝地包含用户辅助专业知识。

用例基于来自访谈和观察的用户研究信息，并考虑到最终用户。因此，用例也是创建可用性测试的测试脚本、质量保证的测试场景以及展示产品的演示脚本的理想基础。

除了用户/系统交互步骤之外，每个用例都明确定义了用户是谁，以及交互目标和触发器是什么。结合可用性研究目标和需要测试的关键元素，已经有了一个非常好的测试脚本指南。

深入到质量保证，已实现软件产品的模块集成或场景测试也将受益于用例。定义相关的测试数据和质量标准更容易、更快，因为用例代表了与系统的清晰的逐步交互，为建立测试场景奠定了良好的基础。

最后，在创建真实的产品演示时，用例也是一种资产。通过适当的示例数据，演示将基于并代表有效的最终用户场景。