Requirements 101: User Stories vs. Use Cases

原文：http://www.stellman-greene.com/2009/05/03/requirements-101-user-stories-vs-use-cases/

我反复思考这个问题：

“用户故事跟用例的区别是什么？”-Ron K.

在进入正题之前，让我们先讨论一下用户故事的起源。我喜欢它，因为它是敏捷开发改变编程世界的例子。

程序员习惯于直接进入项目，开始编码。不论何时，那些讨厌的用户开始告诉我们他们的需求，我们会打断他们，然后说，“别担心，我懂了，我知道你需要什么”。使用敏捷开发人员说”我知道你需要什么“是一个坑，程序员，尤其是好的程序员容易掉进去。整个项目过程中，我们认为我们了解用户的需求，最终交付给用户一个不想要的软件。敏捷开发人员意识到：如果不想陷入编码-修复的困境，如果开发人员必须开始工作，理解项目中用户的需求！这就是我认为用户故事是敏捷潮流带来的最有用的工具之一的原因。一个用户故事，或者叫做场景（scenario），表达用户的一个非常明确的需求。它通常用几句话表达出来。大部分用户故事用用户的语言进行表述，所以任何用户都应该能够阅读用户故事，并且很快的理解含义。很多时候，用户故事写在带序号的卡片上。尽管我已经把他们放在word或者excel文档，或者wiki上。（根据特定项目而定）

用例与用户故事类似，因为它描述的也是用户和软件之间的一次特定的交互。当我教人编写项目需求时，我经常说用例是一种”貌似简单的工具“，它能帮助我们找到并记下用户与软件交互的所有方式。

观察那些定义，我清楚的知道大家为什么会困惑于用例跟用户故事有什么不同这个问题。如果看最后两段，看起来像同样的事情说了两次。但是，尽管用例跟用户故事很的相似，他们之间有重要的区别。他们用作不同的目的，而且我认为在一个运转良好的软件工程中，两者都有用武之地。

我认为理解用例和用户故事差别的最简单方式就是看个例子。很幸运，我有一个这样的例子，我认为可以帮助我们搞清他们的区别。

在我们的第一本书, Applied Software Project Management，Jenny 和我花费大量时间讨论怎么发展用例，怎么用他们建造更好的软件。作为一个例子，我们展示了一个大家都应该很熟悉的用例：文字处理程序的搜索替换功能。一个文字编辑器的搜索和替换功能。比较描述搜索替换功能的用例和用户故事让我们更容易发现他们的不同。

我们可以很容易的获得很多用户故事的例子。用户故事可以有很多种不同的格式（尽管如果你在找用户故事模板，一个3*5英寸的卡片应该是一个好的起点）所以一个搜索和替换的用户故事应该长什么样子？我尝试写了一个：

（写用户故事的时候，我更喜欢用he或者she，而不是无性别的词。我认为通人格化一些，使用户故事中的人更容易联系起来。这也让我写起来更像聊天的口吻，这让用户故事更加的友好，也更容易理解。）
现在，如果你对用户故事不熟悉，你可能自己在想，“等一下，我的文字处理软件的搜过替换功能比那做的更多”。这没有问题。一个典型的用户故事有足够的信息帮助用户理解软件需要完成的工作。但是这并不以为着它需要完整的描述软件工作的方式。在这，我并不想试着教授写一个有效的用户故事。我强烈建议读一下Mike Cohn’s excellent articles and posts aboout user stories. （Mkie,是一个资深的软件开发人员，对我们最新的书提供帮助。他有一些很棒的关于敏捷的故事）
所以一个描述搜过和替换功能的用例长什么样子？这里就是我和Jenny建立的用例，用它来展示用例怎么工作：

 

Name	UC-8: Search and Replace
Summary	All occurrences of a search term are replaced with replacement text.
Rationale	While editing a document, many users find that there is text somewhere in the file being edited that needs to be replaced, but searching for it manually by looking through the entire document is time-consuming and ineffective. The search-and-replace function allows the user to find it automatically and replace it with specified text. Sometimes this term is repeated in many places and needs to be replaced. At other times, only the first occurrence should be replaced. The user may also wish to simply find the location of that text without replacing it.
Users	All users
Preconditions	A document is loaded and being edited.
Basic Course of Events	1.    The user indicates that the software is to perform a search-and-replace in the document. 2.    The software responds by requesting the search term and the replacement text. 3.    The user inputs the search term and replacement text and indicates that all occurrences are to be replaced. 4.    The software replaces all occurrences of the search term with the replacement text.
Alternative Paths	1.    In Step 3, the user indicates that only the first occurrence is to be replaced. In this case, the software finds the first occurrence of the search term in the document being edited and replaces it with the replacement text. The postcondition state is identical, except only the first occurrence is replaced, and the replacement text is highlighted. 2.    In Step 3, the user indicates that the software is only to search and not replace, and does not specify replacement text. In this case, the software highlights the first occurrence of the search term and the use case ends. 3.    The user may decide to abort the search-and-replace operation at any time during Steps 1, 2, or 3. In this case, the software returns to the precondition state.
Postconditions	All occurrences of the search term have been replaced with the replacement text.

现在，如果我是一个建造文字处理程序的开发者，我已经能够编写实现特定用例的搜过替换功能。（弄清：有很多不同的用例格式；Jenny和我用这个用例模板因为他把我们认为有效用例应该具备的内容作了最大精简。

这里是一些关于用例的我认为有趣的事情。当你通读我们的用例的例子的时候，你是否想起notepad或者word的替换对话框，或者textDdit的查找对话框？如果这样，再看一下用例的例子。其中没有任何像window，buttonc,click,field,checkbox之类的词。全是关于用户操作和软件相应的内容。有很多种不同的方式来构造实现用例的软件。你是否用过vi的搜索替换功能？emacs中的呢？他们在用户接口上有很大不同。谁知道有如此多的方式来实现搜多和替换？但是如果将他们跟这个用例做比较，他们全都符合相同的基本事件流程

所以现在我们已经看完了用例和用户故事的例子，他们的区别是什么？这里是我想到的几点主要区别

l   用户故事是关于需求的。当你写用户故事的时候，你描述的是原始的用户需求。它是用户需要每天做的工作。如果你不为他们编写软件，这个需求将一直存在。

l   用例是关于你将加入到软件已满足他们需求的行为。一个需要构建可用软件的开发者应该能偶阅读用例，并且了解软件需要做的事情。一般来说有很多细节并且描述开发人员为达到用户需求需要的任何事情。这就是为什么需要大量细节，清晰，无歧义。

l   用户故事容易被用户读懂。当你编写用户故事，你关注的是用用户的语言，写出所有人都能理解的内容。我们都知道，开发者比用户有更多的耐心来谈论他们构建的软件的细节，这也是为什么用户故事需要简介。一个用户故事需要表达用几句话表达完整的宪法。（这也是为什么适合吧它放进带索引的卡片：不知怎么回事，这让用户故事更清晰，自包含，并且与其他的用户故事独立。）

l   用例描述了软件和用户（或可能是其他系统）之间的一个复杂的交互。当你做用例分析，你所做的是设计一个满足用户需求的功能上的解决方案。它需要时开发者能实现的东西。可能一个用户故事会产生若干个用例。并且，当你结合所有的用例到一个用例文档。你最终会产生一个你规划构建的软件和用户之间的所有交互的完整描述。并且，如果你的软件必须和多个系统交互，你可能最终把哪些其他的系统当做用例的actor。

 

一旦你理解了用例和用户故事的不同，你可能开始发现在项目中他们可以提供的不同意图。并且，如果你只用用户故事，或者只用用例，在你的下一个项目中你可能尝试同事使用他们两个。