对“用例”，“用户案例”和“使用场景”之间的区别是否有一个准确但简单易懂的定义？

有很多解释，但是现在，我看不到一个或两个句子就能解释其中的差异。

（例如，http：//c2.com/cgi-bin/wiki？UserStoryAndUseCaseComparison很长且很难获取，充满讨论）

一个用户故事是一个更正规，更友好的较小版本使用案例，减去UML图; 它通常用于迭代方案中。

甲使用场景是拉成一步一步的过程，有时伴有的流程图的使用案例。

对我而言，用户案例和用例之间的最大区别是：

• 一个用户故事是一个轻量级的，可以在卡片上写（为了作为，我想）文件。用户故事不能捕获所有细节，而是对讨论的非正式支持。
• 一个用例是一个重量级的文件，需要一个Word文档。它描述了步骤和/或动作的“正常流程”以及详细的“替代流程”。用例捕获了所有细节，这是一个正式的规范。

根据使用场景的 Scott W. Ambler的介绍，这些工件看起来像用例的流程：

一个使用场景，或场景的简称，描述了一个真实世界的例子，说明一个或一个以上的人或组织与系统进行交互。它们描述了交互过程中发生的步骤，事件和/或动作。使用场景可能非常详细，可以准确地指示某人如何使用用户界面，或者可以在较高层次上描述关键业务操作，而不能指示其执行方式。

坦白地说，即使阅读了本段（最后一句话可能是最重要的）后，与用例流程的区别也不是很清楚：

可以想象，用例和场景之间存在一些差异。首先，用例通常是指一般参与者，例如客户，而场景通常是指参与者的示例，例如约翰·史密斯和萨莉·琼斯。没有什么可以阻止您编写通用方案，但是通常最好个性化方案以提高其可理解性。其次，使用场景描述了一条逻辑路径，而用例通常描述了若干路径（基本过程以及任何适当的替代路径）。第三，在基于UP的流程中，用例通常被保留为正式文档，而场景在不再需要后通常被丢弃。

我可能是错的，但是使用场景听起来确实像用例流程，但是以敏捷的方式进行了重新命名。

这些东西都没有确切的定义。各个公司之间以及各个系统之间的差异都很大（或很大）。

最好的选择是找到一个适合您当前项目的示例，然后按照它进行操作。

如果要创建新系统，则可以为自己喜欢的任何系统找到不同类型的用例的定义-只需选择似乎最能传达您意图的模式即可。

不要挂在名字上。

用户故事总是非正式的，描述用户的需求。用例可以是正式的或非正式的，并描述系统行为。

可能会有“技术”用户案例，用例并非如此。

完成后，通常会丢弃用户故事。在产品生命周期中可能会维护用例。

范围也不同。用户故事的范围通常较小，因此，一个用例包含多个用户故事。在新的用户故事或用例的更新版本中，描述了对现有系统的更改要求。

用户案例和用例之间的相似之处在于，它们都用于计划和调度。

用户案例分解为可以单独分配给开发人员的任务时，与用例场景相比，粒度可能会（也可能不会）更加细化，并且在范围上受到限制。用户故事是关于用户的需求-用户使用系统的目标或结果。

用户故事的示例包括：

1. 我是客户，我想在线支付我的帐户余额-一个非常高级的视图
2. 我是一名客户，我想更新我存储的信用信息的有效期限-一个非常精细的视图。

在最高抽象层次上，用例听起来很相似-客户更新卡的有效期-但此处是功能说明，而不是目标说明。

在定义用例场景的粒度时，它们将更多地涉及功能和过程。

用例主要场景的后置条件应与用户案例中所述的结果相同-客户的信用卡到期年份已更新。

用例场景以文本或流程流程图（不一定是UML或BPM）来逐步描述。我使用标准的跨功能流程图，以使未受过培训的用例使用者清楚易用。

最重要的是，用户故事描述了需求和结果（系统需要交付的内容），而用例则描述了实现目标所需的参与者之间的互动-以及可能出问题的（扩展，替代或错误方案）（用户如何与之交互）系统实现了这一目标）

对于对此主题的深入讨论，建议您阅读Alistair Cockburn网站上的http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison。由于他是《敏捷宣言》的签署人，因此他是创造用户故事的人，并且在过去的几十年中一直被视为用例专家，我认为他是获取更多信息的绝佳来源。

_{快速临时注意：这篇文章需要改进，以更好地回答问题，例如1）其他细节应包括在参考文献中2）某些引用可能3）英语的整体正确性4）叙述的整体质量5）等。我会回到它。随时自己改善它。}

查看它们的模板可以对这些术语之间的差异提供有价值的见解。

用例

有多个用例模板。我发现3快速搜索后：1，2，3。他们（有时含糊其词）的共同点是：

1. 用例名称/标题
2. 说明 -描述范围的一些简短文字。
3. 演员/主要演员 -与该特定用例进行交互的人员。
4. 前提条件 -该用例在开始其生命周期之前可以假定为正确的任何条件。
5. 成功场景 -描述发生的事件的正确流程的步骤序列。

6. 扩展 -偏离成功方案流程时的应用程序流程：

   1. 备用流量 -正确流量的其他选项
   2. 异常流 -发生错误时的事件流

7. 成功保证（又名发布条件）-一切完成后的申请状态

可以包括的其他一些点是Level，Minimal Guarantees，Trigger等。

上面是所谓的完整用例。您可以通过仅使用最重要的要点来使用临时用例来简化用例的创建，例如：

1. 标题
2. 演员
3. 事件顺序

用例是由Ivar Jacobson在80年代后期和90年代初创建并推广的。后来，其他人也为他的工作做出了贡献（其中之一是Alistair Cockburn，他是《撰写有效用例》的作者）。要套用Martin Fowler的用例可以利用文字和UML图，但其最大的价值在于在它的文本。当它们不大且不易阅读时，它们是最好的。

用户故事 _{（又称功能）}

用户故事-描述特定功能的小故事。关于如何编写用户故事，有一个常见的模式：

作为 特定类型的用户 ，出于某种原因，
我想做 一些事情 。

另外，用户故事可以具有接受标准。

如您所见，该模板比用例小得多。用户故事通常与软件开发的scrum / agile / xp区域相关。它们应写在表面的小区域（如便签纸）和/或Scrum板上。在那里（通常）给定点值，该点值近似需要在该用户故事^ref中投入多少精力。

Bill Wake开发了INVEST助记符来描述一个良好的用户故事应具备的质量，我将在他的网站上借用Martin Fowler的简短摘要：

独立的：故事可以以任何顺序交付
面议：故事的内容由程序员和客户在开发过程中共同创建。
有价值：该功能被软件的客户或用户视为有价值。
可估计的：程序员可以为构建故事提供合理的估计。
小：可以在较短的时间内（通常是个人工作日）来构建故事。当然，您应该能够在一个迭代中构建多个故事。
可测试的：您应该能够编写测试来验证该故事的软件是否正常运行。

使用场景

使用场景遵循GWT模式，即Give-When-Then，如下所示：

场景：标题
给出：一个特定的事实
和：另一个特定的事实（可能是可选的）
时间：某事件发生
然后：某事件发生

使用方案与行为驱动开发相关。听起来与测试非常相似。Martin Fowler在他的博客文章中提供了一些使用场景背后的历史和推理。这是重要的部分：

在开始您在此场景中指定的行为之前，给定的部分描述了世界的状况。您可以将其视为测试的前提条件。
在当部分是行为，你指定。
最后，随后的部分描述了由于指定行为而导致的预期更改。

使用方案可用于为您的应用程序编写测试。引用马丁文章的最后一段：

尽管Given-When-Then风格是BDD的症状，但是在编写测​​试或示例说明时，基本思想非常普遍。Meszaros将模式描述为“四阶段测试”。他的四个阶段是设置（给定），锻炼（何时），验证（然后）和拆卸。比尔·韦克（Bill Wake）提出了“安排，行动，断言”这一表述。

进一步研究的参考文献：

Wikipedia页面上的用例，用户案例，使用场景
Martin Fowler的用例，用户案例，使用场景的博客

我不熟悉“用户故事”，但是几年前我对它进行了研究：

用例是一项主要任务。
用户方案是任务执行的各种方式。因此，每个用例都有一个或多个场景。用例是抽象的，用户场景是该抽象任务的所有可能实例的目录。

因此：
用例A：用户使用ID和密码进行身份验证。

场景：
1.识别ID，密码正确。（“晴天”情况）
2.识别ID，密码不正确。
3.识别ID，第三次输入密码错误。
4.无法识别ID。

我一直认为用例是一种以叙事方式为客户定义需求的方式。与上述内容类似，如果客户说“但是如果他们在系统关闭时尝试在午夜到一个午夜之间登录呢？”，我们发现了身份验证任务的另一种情况以及一些其他要求。

用户故事是从客户的角度来看的，有时它是不正确的或不完整的。它可能不考虑性能，错误处理，也可能不考虑后端。

从开发人员的角度来看，一个用例。它是准确而完整的。它应该满足客户的所有要求。

“用例”和“用户故事”在表示客户的“需求”的意义上是相同的。

用例是在每种情况下使用系统的方式，通常表示为参与者与系统之间或系统之间的交互。

用户故事是创建计算机辅助工具的过程中的起点，该工具将使最终用户能够完成工作，通常以一个简单的句子开始，即使用“谁，什么，为什么”（“作为用户关闭应用程序，我要提示您保存自上次保存以来发生的任何更改，以便我可以保留有用的工作并丢弃错误的工作。”）。然后，需要将用户故事培养成开发人员用于构建应用程序的用例，并由测试人员进行测试。

从QA测试人员的角度来看，他们不是在测试“用户故事”，而是在测试“用例”，这意味着他们正在测试软件功能。

使用场景的目的是捕获与系统实现目标的用户交互的本质，而不必深入探讨系统操作或实际设计的细节。重点是用户，而不是系统。

...用例还包括有关系统将执行的操作的声明，而“使用场景”将避免这种讨论。

您尚未确定如何实现它。

从产品艺术网站。