用例与用户故事：差异

什么是用例？

你有没有觉得成品与你最初想象的有很大不同？ 或者最终版本没有您正在寻找的功能。 这些事故很常见，了解它们可以更容易理解为什么公司甚至首先需要用例。

用例可以描述为对某人如何通过使用特定过程来实现目标的解释。 从技术上讲，它描述了系统及其参与者如何交互。 包含用户为实现目标而采取的所有操作的文档是此过程的结果。

产品团队在各种情况下都会使用用例。 它应用于开发、测试和设计。 此过程有助于为用户手册的结构创建基本蓝图。 通过这种方法，错误和其他缺陷也减少了。

在整个用例过程中使用了一些重要的术语。 这些原则是整个过程的框架和支柱。

• 目标：参与者是与系统交互的任何人或任何事物。 他们是系统的用户。
• 系统：旨在获得此结果的用例。 它经常是这个过程的结果。
• 计划：这包括为达到预期效果而采取的每个步骤。

这三个基本概念并不总是适用。 每个项目、模型和情况都有独特的复杂程度。 在一个用例中，许多附加短语用于复杂项目。 此类术语包括：

• 利益相关者：所有利益相关者都对用例的结果感兴趣。 用户不需要参与。
• 触发器：使用例启动的事件是触发器。
• 先决条件：这些是案件发生必须同时满足的所有条件。

用例从技术角度全面解释了开发者的规则。 它提供了系统开发人员应包含的一般概念。 此外，它为创作者提供了方向感。

查看我们与软件开发相关的免费课程。

什么是用户故事？

用户希望完成的结果或目标的对象、内容和原因是用户故事的重点。 这是可以为客户增加价值的最低劳动量。 从最终用户的角度来看，它通常写在索引卡上。

用户故事的创建尽可能简单明了，以使团队和利益相关者不必解释多种技术语言。 但这并不意味着编写用户故事很简单。 一行中有很多数据。 团队还必须在创建用户故事和编译所有产品需求之前定义和开发他们的用户角色。

探索我们流行的软件工程课程

三C理论

高效用户故事的三个关键要素是 3C。 用户故事实践的共同发明者 Ron Jeffries 提出了这个想法。 如今，当我们谈论用户故事时，我们通常指的是由这三个因素组成的那种用户故事。

牌

卡片用于编写用户故事。 每个用户故事卡片上都会出现一个简短的短语，其中包含足够的文字来提醒故事的主题。

对话

在整个软件开发项目中，通过客户和开发团队之间的持续对话来发现和细化需求。 利益相关者会议将发现并记录重要的决定和建议。

确认

确认有时可以称为用户故事的接受标准。 在需求讨论期间，客户就他们想要什么以及工作软件将被接受或拒绝的条件和标准向分析师提出建议。 定义的案例被写为证据。 请注意，确认侧重于确认相应用户故事工作的正确性。 它不是集成测试。

探索我们的软件开发免费课程

用例与用户故事：差异

在这里，我们讨论用例和用户故事之间的区别。 这将帮助您更好地了解它们的工作方式以及如何使用它们。

技术与用户焦点

用户的需求体现在用户故事中。 它提请注意用户每天遇到的挑战。 该草案的语言直截了当，旨在保持所有相关方之间的一致性。 另一方面，用例仅为产品团队开发。 它让团队了解软件应该做什么。 它还概述了程序员开发软件必须采取的每个步骤。 因此，用例比用户故事要详细得多。

基础与深入

用户故事是对有多少用户使用软件的简明总结。 与用户故事相比，用例非常具体。 他们详细说明了任何系统的独特用户行为。

急需的软件开发技能

简要与详细

用户故事遗漏了大量信息。 这是因为它留下了改进和讨论的空间。 用户故事的这一特征是经过深思熟虑的。 这促使利益相关者进行对话并增强产品。 相反，用例是特殊的。 他们深入探讨了开发人员可能采取的每一步。 一般来说，没有讨论的余地。

在开发用户案例之前，会创建用户故事。 它们通常是通过用户参与产生的。 多个用例可以来自一个用户故事。 当这些用例中的每一个被集成时，就会创建一个完整的文档。 本文档描述了所有软件如何与用户交互。

上述几点可以总结为这三点，以帮助您了解用户故事与用例有何不同。

• 指定的用户故事可能不像用例那样被广泛记录。
• 用户故事中有意省略了许多关键细节。 用户故事的形成是为了在 Scrum 会议中开始对话。
• 更短的步骤以获得更定期的反馈，而不是像在用例中那样预先制定更彻底的需求

用例与用户故事：相似之处

既然我们在了解两者之间的差异，那么我们也必须对它们之间的相似之处有所了解，这样我们才能在选择时做出正确的决定。 如果我们考虑到这两种策略中的关键因素：

• 用户故事包括目标、接受标准和用户角色。
• 用例涉及可比较的组件，例如参与者、事件流和后置条件。

那么你应该使用哪一个呢？

现在您知道了用例和用户故事之间的区别，您需要了解何时使用哪一个。 本质上，这一切都取决于任务有多大。 如果项目不是特别复杂，用户故事可能就足够了。 如果项目很复杂并且有很多依赖项，用例可能更合适。

许多团队发现同时使用用户故事和用例是最有效的操作方式。 团队可以同时使用两者来从两全其美中受益。 首先，他们以整个团队和所有利益相关者都能理解的简单术语来布置他们的 Sprint。 然后，团队通过增加用户故事来开发用例。 这为他们提供了结构和独创性，以及简单性和细节。 在项目中同时使用用户故事和用例的团队有更好的重点和明确的期望。

阅读我们与软件开发相关的热门文章

结论

在这个阶段你知道用例和用户故事的目标。 一个产品的成功就是基于这些想法。 如果您想正确了解用户故事与用例的区别，利物浦商学院的 upGrad MBA将帮助您详细了解该概念。 该课程将帮助您成为该领域的佼佼者之一。 参加本课程将为您提供了解用户故事和用例概念所需的所有方面的培训，以及它们的具体实施以获得最佳结果。