[架构之路-205]- 常见的需求分析技术：用户故事User Story（用户需求）、用例User Case（系统需求、产品需求）、场景Senario（内部执行流程）区别[通俗易懂]

“用户故事和用例是一样的吗?”

人们经常会问这个问题，关于敏捷团队应该实践使用故事还是用例的争论已经持续多年了。

用户故事和用例是一回事吗? 如果不是，哪一个更好?你应该使用哪一个?或者两者都使用?

虽然用户故事和用例之间有一些相似之处，但用户故事和用例是不可互换的;

用户场景和用例都标识用户，它们都描述了目标，但是它们服务于不同的目的。

用户场景集中于您所描述的结果和好处，而用例可以更细粒度地描述系统将如何运行。

用例在敏捷中有一席之地吗?或者它们可以相互结合使用吗?

很多人混淆了用户案例和故事，但实际上它们是不同的概念。

他们可能有一些类似的功能：例如，收集有关用户需求和目标的信息。

但它们是为不同的目的而设计的。

本文详细讨论了这两个概念以及它们的不同之处。

文章还强调了这两个概念对企业的用法和实用性。

本文旨在为读者提供帮助，并帮助他们深入了解该主题。

什么是用户故事？

用户故事是对用户需求的简单描述。

这些故事是从最终用户的角度编写的。用于用户故事的语言非常非正式且易于理解。

用技术术语来说，它是从最终用户的角度对功能的描述。这个故事用于敏捷软件开发。它帮助产品团队识别他们的用户和需求。它还有助于将所有复杂性分解为简单易懂的单词。

用户故事也是记录用户需求的一种简单方法。它有助于确定一些重要的问题。诸如功能的人物，内容和原因之类的问题。所有这些描述都是为了将​​重点从写作转移到讨论功能上。它可以帮助简化整个过程并提高效率。

用户故事示例

作为用户，我想将信用卡链接到我的个人资料，以便我可以更快、更轻松且无需现金支付租金。

作为服务提供商，我想在应用程序中添加我的车辆照片，以便吸引更多用户。

作为用户，我希望显示几辆可用的车辆，以便我可以选择最适合我的选项。

什么是用例？

你有没有觉得你想象的产品和你开发的产品有很大的不同？或者最终版本中缺少您想要的功能。许多产品人员可以与这些问题联系起来。这有助于理解为什么企业首先需要一个用例。

简单来说，用例是对使用特定流程的人将如何实现目标的描述。

用技术术语来说，它是对系统和参与者之间交互的描述。

此过程的产品是一个文档，其中包含用户为实现目标而遵循的所有步骤。 

例如，您是一位计划制作门的木匠。此场景的用例将包括木匠为实现目标而采取的所有步骤。

整个文档将有助于研究该过程的缺陷和错误。

产品团队在各种情况下使用用例。它用于设计、测试和开发。此过程还有助于制定用户帮助手册应如何设计的粗略大纲。通过这个过程，错误和其他缺陷也被最小化。

用例的整个过程都有一定的关键术语。这些术语是整个过程的基础，并提供了支柱。

1. 参与者：这是与系统交互的人或一群人。他们是系统的用户。
2. 目标：这是设计用例的结果。它通常是这个过程的最终结果。
3. 系统：这包括为实现既定目标而遵循的所有步骤。

这三个基本术语并不适用于所有情况。每个项目、模型和环境的复杂性都不同。对于复杂的产品，在用例中使用了许多其他术语。其中一些条款是：

1. 利益相关者：对用例结果感兴趣的所有各方。它不必只是用户。
2. 触发器：是用例开始的所有事件。
3. 前提条件：它是案件发生所必需的所有因素的组合。

从技术角度来看，用例是对开发人员指南的详细描述。它提供了开发人员需要在系统中包含的内容的想法。这也给了开发人员一种工作方向感。

同样重要的是要注意，在创建用例时，您不应该只涵盖理想场景，还应该准备替代路径：

• 主要成功场景 [基本流程] – 没有任何问题的用例。
• 替代路径 [替代流程] – 这些路径是主题的变体。当系统级别出现问题时会发生这些异常。

用例示例

用例名称：下订单

参与者：

• 购物者
• 履行系统
• 计费系统

基本用例描述： 

1. 用户选择要租用的物品
2. 用户提供付款和运输信息
3. 用户订购商品
4. 系统以确认订单和用户可以用来检查车辆的租用号码作为响应。 
5. 该系统还将为用户提供剩余租用时间的倒计时。 
6. 用户可能已经拥有该公司的帐户，其中包含帐单信息。

替代流程是：

1. 用户选择要租用的物品
2. 用户提供付款和运输信息
3. 用户改变主意并选择另一辆车
4. 用户删除购物车
5. 用户选择新项目
6. 用户下单
7. 系统以确认订单和用户可以用来检查车辆的租用号码作为响应。 

1. 该系统还将为用户提供剩余租用时间的倒计时。 
2. 用户可能已经拥有该公司的帐户，其中包含帐单信息。

用户故事与用例之间的区别

用户关注与技术关注

起草用户故事以解释用户的需求。它突出了用户在日常生活中面临的一个问题。

该草案的语言非常简单。它的开发是为了让所有利益相关者保持在同一页面上。

另一方面，用例仅为产品团队开发。它让团队了解软件应该实现的目标。它还强调了开发人员制作软件需要遵循的所有步骤。出于这个原因，用例包含比用户故事更多的细节。

一般与深入

用户故事是许多用户与软件交互的简化形式。

用例与用户故事相关是非常具体的。它们描述了任何系统的特定用户操作。

简短与详细

用户故事遗漏了很多细节。这是因为它提供了讨论和改进的空间。用户故事的这一方面是经过深思熟虑的。这鼓励利益相关者发起讨论并改进产品。另一方面，用例是特定的。它们详细描述了开发人员将遵循的所有步骤。通常没有讨论的余地。

用例是在用户案例之前开发的。在大多数情况下，它们是由用户交互开发的。一个用户故事可以产生多个用例。所有这些用例的组合产生了详细的文档。本文档描述了所有软件和用户之间的交互。

用户故事和用例的相似之处

两种方法之间最大的相似之处在于关键组件。

用户故事具有用户角色、目标等组件。

用例也具有类似的概念。它包括参与者、前置条件和其他条款。因此，这两个概念在解决问题的方式上变得相似。

何时使用用户故事与用例？

用户故事在产品开发中有很多用途。它们在用例之前用于开始以客户为中心的对话。这种对话意味着客户模型有更大的改进空间。它有助于为整个概念提供清晰度。用户故事确保没有无用的细节进入整个过程。这也确保了从流程开始就设定目标。因此，用户故事提高了效率。

有几个地方可以使用用例。它们可用于记录当前系统的过程。通常，当现有系统更新时，它们会带来很多技术问题。用例有助于理解现有系统的大局。因此，可以在进行任何更改之前避免问题。

用例的另一个用途是开发新系统。它有助于提供开发人员需要遵循的所有步骤的详细描述。它还有助于定义用户目标和简化开发过程。

汇总：

 用户故事User Story =》 用例User Case =》 场景Senario

用户故事User Story： 站在终端用户角度，提出了终端用户自身的愿望、期望。

用例User Case：站在参与这的角度，展现系统为参与者能够提供的功能和服务。

场景Senario：站在系统的角度，阐述系统在不同的场景下，展现不同的执行过程和步骤。

今天的文章[架构之路-205]- 常见的需求分析技术：用户故事User Story（用户需求）、用例User Case（系统需求、产品需求）、场景Senario（内部执行流程）区别[通俗易懂]分享到此就结束了，感谢您的阅读。