用户故事和用例场景之间有什么区别，目的是什么？
问问题
5575 次
2 回答
5
用例更像是一份合同，而用例是一种规划工具。因此，用例通常比用户故事更长寿，因为它们（应该）作为具体反映构建系统的文档。
用户故事由客户/利益相关者/客户/用户编写。用户故事不是很详细，并且相对容易解释。
用例在结构上更正式，通常由团队中的某个人——需求工程师/产品经理编写。它们通常更详细，将交互分解为各个步骤，并清楚地识别前置条件和后置条件，例如失败条件和成功条件。
虽然一个用例可以涵盖许多场景——成功和失败；验证错误；子用例和扩展——用户故事的范围更有限，通常描述一个场景。
另请参阅Wikipedia 上的 User_story#Comparing_with_use_cases以及用户故事应用一书中的“哪些用例不是”一章。
最后，根据 Allistair Cockburn 的说法……
用户故事是 1990 年代使用的“功能”的同义词，是要构建的内容的标记，其细粒度足以适应现代迭代/冲刺时期。
用例提供了要构建的内容的上下文视图，用于将组织绑定在一起等。
于 2012-11-23T07:46:55.980 回答
4
“用户故事之于用例，就像瞪羚之于凉亭。” -- 科伯恩
用户故事（与需求相反）是描述系统需要为某些用户做的事情的简短意图陈述。这是敏捷团队用来理解和传达客户需求的主要技术。这当然是一个方便的结构，而小的用户故事帮助我们推动了敏捷开发的极端工具主义。
用例是在复杂系统中表达系统行为的传统方式。用例是用 UML 表示需求的主要方式。它们在那里以及有关该主题的各种文本中都得到了很好的描述。用例可用于规范和分析。当感兴趣的系统又由其他子系统组成时，它们特别有用。
我推荐的书：
- 敏捷软件需求（Dean Leffingwell）
- 编写有效的用例 (Alistair Cockburn)
于 2012-12-06T10:44:33.690 回答