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

在敏捷软件开发中，我们经常会遇到两个术语——用例和用户故事。 这些是任何开发人员或非开发人员经常使用的一些最常用的术语。 此外，对于那些没有任何开发背景知识的人来说，互换使用这些术语也很常见。

用例和用户故事在许多方面彼此不同。 他们有不同的目标要实现。 尽管它们可能具有相似的功能，但概念却截然不同。

查看免费课程以提高自己的技能

在本文中，我们将通过示例讨论用例与用户故事，并解释用户故事与用例的区别。 我们还将研究这两种方法的必要性以及它们重叠的原因。

什么是用例？

用例反映了实现所需产品目标所涉及的过程。 系统的需求有助于推导出产品。 它用作将使用它的参与者（或用户）的产品描述。 用技术术语来说，它是系统和参与者之间通过描述进行的交互。

用例的一些关键要素：-

• 参与者：与系统交互的一个人或一群人
• 目标：开发用例的最终结果
• 系统：实现目标所涉及的所有步骤

用例带有因果关系，其中包括向最终用户描述产品功能或特性的某些事件。 它在与系统交互时提供了对用户行为的详细了解。

产品团队利用用例来设计、测试和开发产品。 它可以帮助他们概述应如何设计用户帮助手册的要求。 除此之外，他们还能够消除错误。

用例是对利益相关者或最终用户的产品的详细描述。

用例示例

让我们以为满足客户的服装和配饰交付要求而创建的服装品牌应用程序为例。 客户浏览应用程序，选择最合适的商品，然后下订单。 下订单时，他们可以在线付款或在交货后付款。 经客户确认后，他们会收到确认邮件或“已下订单”的通知。

然后准备、包装订单并将其运送到指定地址。 在这种情况下，应用程序必须在与双方（客户和零售商）通信的同时接收订单和处理付款选项。 这里：

• 该系统是——一个电子商务应用程序
• 主要参与者是——客户
• 场景是——浏览应用程序

在这里，您可以了解客户和零售商如何与应用程序交互并期望获得预期的结果。 一些基本用例描述是：-

• 用户选择一个项目。
• 付款和运输信息
• 确认订单和结帐
• 订单倒计时或跟踪
• 账单信息

让我们转向用户故事，了解用户故事与用例有何不同。

什么是用户故事？

用户故事是对用户的产品的简短描述，在整个过程中为他们提供指导。 每个用户故事都是从客户的角度用易于理解的语言编写的。 用户故事侧重于用户希望从平台获得什么以及系统应该为他们提供什么。

然后，开发团队将给出的语句的用户合并到软件中，并进行一些固定。 用户故事包括通过软件在整个过程中发生的交互。 三个 C 涉及用户故事，这是 Ron Jeffries 提出的一个概念。 这些都是-

• 卡片：用户故事应该写成卡片，这意味着包含所有必要信息的简短故事。
• 对话：用户故事应该是客户和开发人员之间通过软件进行的对话。
• 确认：这意味着客户确认在结果到达之前应该实施的某些条件。系统应该能够正确执行它。

除了用户故事的这三个 C 之外，它还关注一个更重要的目的：投资。 它代表

• 独立于其他项目
• 面议：进一步发展的空间
• 有价值的：对用户的描述
• 可估计的：执行适当计划的用户故事
• 小：工作日3-5天内完成工作
• 可测试的：检查过程的价值或有效性的机制

用户故事示例

用户故事表达如下：

“作为一个（角色），我（想要），（那样）。”

• As a (persona)——应用程序或软件为之构建的人。 它应该强调最终用户。
• 我（想要）——在这里，描述的是意图，而不是特征。 它应该描述用户的目标，而不是应用程序或 UI 的一部分。
• （这样）- 这描述了应用程序的整体利益或更大的图景。 最终用户将体验到的整体利益是什么？

下面是一些用户故事的例子

• 作为 Elie，我想将我的信用卡链接到我的个人资料，这样我就可以不用现金轻松支付租金。
• 作为一名经理，我想组织我的工作，这样我就能更有掌控感。

用户故事的结构可能不同，但意图应该是相同的。

为什么我们需要用例和用户故事？

我们的系统中同时需要用例和用户故事有一些原因。 让我们深入研究用户故事和用例背后的目的：-

我们需要用例来——

• 管理工作范围
• 促进最终用户和开发人员之间的沟通
• 建立所有要求
• 可视化系统架构
• 概述我们可以与系统交互的结构

我们需要用户故事来——

• 创建简化的流程
• 制定可实现的小目标
• 让技术用户和非技术用户保持在同一页面上
• 定义全过程

检查我们的美国 - 数据科学计划

用例和用户故事的区别

让我们看一下用例和用户故事之间的区别，以了解是什么使两者截然不同：-

1. 通过牢记利益相关者的意图，为产品团队开发用例。 它概述了团队制作所需软件的成就结构。 用例往往比用户故事更详细。
   用户故事更简单，更以用户为中心。 它突出了用户的日常琐事，这就是为什么用户故事中使用的语言是可以理解的，并且完全从利益相关者的角度来看。
2. 如前所述，用例比用户故事更直接。 但是，这两种方法都经过简化且易于理解。
3. 用户故事故意留下一些改进的余地。 因此，它需要包含更多详细信息。
   相比之下，用例是中肯的，突出了开发人员需要遵循的所有步骤。
4. 用户故事是在用例之前开发的，主要是通过交互形成的。

阅读我们的热门美国 - 数据科学文章

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

用户故事用于产品开发，方法更倾向于客户。 如前所述，用户故事有意为通过开发人员和用户之间的对话进行改进留出空间。 它在流程的开始就设定了目标，他们负责提高效率。 开发人员在创建用户故事时可以牢记这些要点。

然而，用例用于记录过程。 它包含实现最终目标的所有过程要求。 用例描绘了现有系统的更大图景。 它涉及简单的开发过程的直截了当的要点。

通过 upGrad 提升你的职业生涯

合适的高等教育可以对所有有抱负的开发人员和数据科学家产生重大影响。 如果您正在寻找提高技能和证书的机会，upGrad 的数据科学执行 PG 计划可能是一个很好的选择。 通过本课程，学习者可以很好地接触技术世界。 WES 和分析研究所认识到这门课程的价值，该课程是在行业领先专业人士的专业知识下策划的。

结论

敏捷软件开发围绕着开发迭代、方法和技术来整合用户观点。 正因为如此，需求在不断增加。 每个行业都专注于将用例和用户故事开发到他们的系统中，以便每个结果都以客户为中心，从而提高客户满意度。