很多人混淆了用户案例和故事，但实际上它们是不同的概念。他们可能有一些类似的功能。例如，收集有关用户需求和目标的信息。但它们是为不同的目的而设计的。本文详细讨论了这两个概念以及它们的不同之处。文章还强调了这两个概念对企业的用法和实用性。本文旨在为读者提供帮助，并帮助他们深入了解该主题。
什么是用例？
你有没有觉得你想象的产品和你开发的产品有很大的不同？或者最终版本中缺少您想要的功能。许多产品人员可以与这些问题联系起来。这有助于理解为什么企业首先需要一个用例。
简单来说，用例是对使用特定流程的人将如何实现目标的描述。用技术术语来说，它是对系统和参与者之间交互的描述。此过程的产品是一个文档，其中包含用户为实现目标而遵循的所有步骤。
例如，您是一位计划制作门的木匠。此场景的用例将包括木匠为实现目标而采取的所有步骤。整个文档将有助于研究该过程的缺陷和错误。
产品团队在各种情况下使用用例。它用于设计、测试和开发。此过程还有助于制定用户帮助手册应如何设计的粗略大纲。通过这个过程，错误和其他缺陷也被最小化。
用例的整个过程都有一定的关键术语。这些术语是整个过程的基础，并提供了支柱。
- 参与者：这是与系统交互的人或一群人。他们是系统的用户。
- 目标：这是设计用例的结果。它通常是这个过程的最终结果。
- 系统：这包括为实现既定目标而遵循的所有步骤。
这三个基本术语并不适用于所有情况。每个项目、模型和环境的复杂性都不同。对于复杂的产品，在用例中使用了许多其他术语。其中一些条款是：
- 利益相关者：对用例结果感兴趣的所有各方。它不必只是用户。
- 触发器：是用例开始的所有事件。
- 前提条件：它是案件发生所必需的所有因素的组合。
从技术角度来看，用例是对开发人员指南的详细描述。它提供了开发人员需要在系统中包含的内容的想法。这也给了开发人员一种工作方向感。
同样重要的是要注意，在创建用例时，您不应该只涵盖理想场景，还应该准备替代路径：
- 主要成功场景 [基本流程] – 没有任何问题的用例。
- 替代路径 [替代流程] – 这些路径是主题的变体。当系统级别出现问题时会发生这些异常。
什么是用户故事？
在描述了用例之后，让我们继续讨论用户故事。
用户故事是对用户需求的简单描述。这些故事是从最终用户的角度编写的。用于用户故事的语言非常非正式且易于理解。
用技术术语来说，它是从最终用户的角度对功能的描述。这个故事用于敏捷软件开发。它帮助产品团队识别他们的用户和需求。它还有助于将所有复杂性分解为简单易懂的单词。
用户故事也是记录用户需求的一种简单方法。它有助于确定一些重要的问题。诸如功能的人物，内容和原因之类的问题。所有这些描述都是为了将重点从写作转移到讨论功能上。它可以帮助简化整个过程并提高效率。
用户故事有一个大纲很重要。首字母缩略词INVEST广泛用于此目的。它有助于检查是否已满足所有要求。
- 独立：不依赖其他项目
- 面议：留有进一步发展空间
- 有价值的：描述最终用户将获得的价值。
- 可估计的：应该对它们进行估计，以便制定适当的计划。
- 小：工作应该足够小，可以在 3-5 天内完成
- 可测试：一些检查流程价值传递的机制
既然已经详细描述了这两个概念，您可能会觉得它们是相同的。这两个概念之间的重叠从远处可见，但在附近不可见。尽管它们对产品团队的重要性是相同的。它们都是整个开发过程的重要组成部分。
为什么要创建用户故事？
用户故事是定义用户想要什么的简单方法。通过它可以清楚地解释产品。一个好的用户故事将帮助所有利益相关者理解产品的功能。它还有助于向客户介绍产品是什么。
用户故事可以帮助简化项目
这意味着一个更大的目标可以分成更小的可实现的目标。这有助于更有效地完成项目并减少时间浪费。较小的可实现目标意味着与您的目标几乎没有偏差。
让每个人都在同一个页面上
他们简单的语言意味着每个人都可以理解。技术和非技术成员都使用它作为交流的媒介。它还有助于吸引每个利益相关者。用户故事的性质引发了不同利益相关者之间的产品讨论。
提供目标感
通过明确定义产品的目的，用户故事为整个使命提供了目的。它还使开发团队更容易完成任务。由于用户故事，开发人员知道他们为什么要生产产品。这有助于增加动力。
帮助定义整个产品
它为开发团队提供了开箱即用的自由思考。然后，团队可以根据优先级组织不同的想法。优先级标准可能取决于用户价值和复杂性等因素。这意味着即使是疯狂的想法也不会被排除在流程之外。它们可以被赋予较低的优先级并进行相应的处理。
鼓励以用户为中心的方法
这种方法给最终用户很大的权力。这意味着一切都是从一开始就考虑到最终用户而设计的。让它成为原型、MVP或新功能，用户故事可帮助您将用户保持在焦点的中心。这些故事使产品团队与用户想要的东西保持一致。这些故事不断提醒我们满足用户需求。因此，由于用户故事，用户满意度最大化。
用户故事与用例的示例
让我们以电动汽车租赁应用为例。
想象一个应用程序，您可以在其中列出和租用大城市的所有电动汽车选项。用户的目标是选择并成功租用电动汽车。
用例示例
用例名称：下订单
演员：
- 购物者
- 履行系统
- 计费系统
基本用例描述：
- 用户选择要租用的物品
- 用户提供付款和运输信息
- 用户订购商品
- 系统以确认订单和用户可以用来检查车辆的租用号码作为响应。
- 该系统还将为用户提供剩余租用时间的倒计时。
- 用户可能已经拥有该公司的帐户，其中包含帐单信息。
替代流程是：
- 用户选择要租用的物品
- 用户提供付款和运输信息
- 用户改变主意并选择另一辆车
- 用户删除购物车
- 用户选择新项目
- 用户下单
- 系统以确认订单和用户可以用来检查车辆的租用号码作为响应。
- 该系统还将为用户提供剩余租用时间的倒计时。
- 用户可能已经拥有该公司的帐户，其中包含帐单信息。
用户故事示例
作为用户，我想将信用卡链接到我的个人资料，以便我可以更快、更轻松且无需现金支付租金。
作为服务提供商，我想在应用程序中添加我的车辆照片，以便吸引更多用户。
作为用户，我希望显示几辆可用的车辆，以便我可以选择最适合我的选项。
用户故事与用例之间的区别
用户关注与技术关注
起草用户故事以解释用户的需求。它突出了用户在日常生活中面临的一个问题。该草案的语言非常简单。它的开发是为了让所有利益相关者保持在同一页面上。另一方面，用例仅为产品团队开发。它让团队了解软件应该实现的目标。它还强调了开发人员制作软件需要遵循的所有步骤。出于这个原因，用例包含比用户故事更多的细节。
一般与深入
用户故事是许多用户与软件交互的简化形式。用例与用户故事相关是非常具体的。它们描述了任何系统的特定用户操作。
简短与详细
用户故事遗漏了很多细节。这是因为它提供了讨论和改进的空间。用户故事的这一方面是经过深思熟虑的。这鼓励利益相关者发起讨论并改进产品。另一方面，用例是特定的。它们详细描述了开发人员将遵循的所有步骤。通常没有讨论的余地。
用例是在用户案例之前开发的。在大多数情况下，它们是由用户交互开发的。一个用户故事可以产生多个用例。所有这些用例的组合产生了详细的文档。本文档描述了所有软件和用户之间的交互。
用户故事和用例的相似之处
两种方法之间最大的相似之处在于关键组件。用户故事具有用户角色、目标等组件。用例也具有类似的概念。它包括参与者、前置条件和其他条款。因此，这两个概念在解决问题的方式上变得相似。
何时使用用户故事与用例？
用户故事在产品开发中有很多用途。它们在用例之前用于开始以客户为中心的对话。这种对话意味着客户模型有更大的改进空间。它有助于为整个概念提供清晰度。用户故事确保没有无用的细节进入整个过程。这也确保了从流程开始就设定目标。因此，用户故事提高了效率。
有几个地方可以使用用例。它们可用于记录当前系统的过程。通常，当现有系统更新时，它们会带来很多技术问题。用例有助于理解现有系统的大局。因此，可以在进行任何更改之前避免问题。
用例的另一个用途是开发新系统。它有助于提供开发人员需要遵循的所有步骤的详细描述。它还有助于定义用户目标和简化开发过程。
包起来
到目前为止，您知道用户故事和用例的全部内容以及它们的用途。这些概念有助于成功的产品。
