用户故事与用例究竟是用哪一个比较好？ 哪一个更适合我的项目？

作为业务分析师，您可能在职业生涯中遇到过这些问题。 有时答案很明确，有时可能没有明确的答案。 您必须做出最好的猜测并继续前进。 在讨论答案之前，首先让我们理解一下它们的定义。

什么是用例(Use Cases) ?

用例以用户与系统交互的形式表示需求。 用例的编写始终牢记特定的用户目标。 每个用例必须包含一个演员和动词。 例如，“在线买家”是演员，“将商品添加到购物车”是动词。

用例图表示解决方案所有功能的范围。 它遵循统一建模语言(UML) 表示法。 用例图由构成系统的几个用例组成。

什么是用户故事(User Stories)?

用户故事是一个业务分析工件，也是用户或角色驱动的。它以用户（或系统）在解决方案中想要的能力的形式描述业务需求。它还必须说明为什么需要该能力以及该能力的好处是什么。但它没有任何强制格式。

用户故事是（产品/项目）待办事项的一部分。反过来，积压工作以线性方式包含用户故事/任务（需求）。 Backlog 的优先级通常从高到低排列，当优先级相同时，还会有一个排名。当它被其中的任务/故事的业务价值优先排序时，它被称为托管积压。在许多项目中，用户故事也可视化地表示为用户故事地图，这是积压工作的结构化可视化。用户故事地图是从线性积压转换到可视化工作板上的用户故事地图。

每个概念本身就是一个详细的主题。对于本文的上下文，我将仅在介绍性级别进行限制。现在让我们看看用户故事和用例之间的差异和相似之处。

用例和用例的区别

1. 正式与非正式：

用例的表示形式有些正式。该构造具有特定元素，例如主要和次要用户、每个条件、后置条件、主要替代和异常流等。

用户故事本质上是非正式的。业务分析师协作编写它。用户故事是用自然语言编写的。敏捷实践表明用户故事有角色、能力、好处和接受标准。

2. 瀑布与敏捷：

用例通常用于遵循瀑布方法的项目中。当需求非常明确时使用它们，从而能够进行设计、开发和测试。而用户故事与产品和项目的敏捷世界息息相关。当需求变化更大时，它们最适合。它们用于迭代地定义需求。

3. 用户和系统交互与最终用户驱动：

用户案例更多地强调参与者及其与系统的交互及其相互关系和依赖关系。而用户故事是最终用户驱动的，用于就用户需要什么以及该功能如何使用户受益达成一致。稍后开发 UX 和 UI 以及交互时会牢记这些需求。

4.详细级别与任何级别：

在用户故事的情况下，需求是迭代定义的，并在级别 1、2、3 等处定义，直到需求明确为止。而对于用例，没有这样的级别。用例已经处于最详细的级别。

5. 高度重视可追溯性与高度重视可接受性和测试：

用例非常强调结构以及从业务需求到其他用例的可追溯性。尽管用户故事非常强调测试将发生什么以及如何进行，但什么将定义给定用户故事的接受度。

用例和用例之间的相似之处

1. 两者都代表陈述要求的方式：

好吧，这听起来可能微不足道，但重点是，这两种方法都是非常有用且经过验证的捕获需求的方法。对于业务分析师来说，这两者都是一个很好的需求分析和文档工具。没有一个比另一个更重的事情。只是在某些情况下每一个都更有用。

2. 让利益相关者和 业务分析师 都能够提出问题

两者都使团队能够向某个方向提出问题，并帮助 业务分析师 走向清晰。用例或用户故事的构造或模板元素是使业务分析师能够向利益相关者提出特定问题的简单线索。
问题或启发活动会带来更多信息，您将进一步了解利益相关者的需求。因此，用例和用户故事都有助于发现参与者、动词、步骤、结果等。

3. 两者都是动词或动作导向的：

用户故事和用例是面向行动的。它们代表步骤或主动声音，并迫使或使业务分析师能够捕获用户交互和系统响应。

4. 两者都牢记用户焦点：

最后但并非最不重要的一点是，用户故事似乎更关注用户。但是，用例和用户故事在业务分析工作中都有自己的位置。这两者都确实将用户焦点放在了脑海中。