User Story，译为“用户情景”，在敏捷软件过程Scrum中，用来表达需求模块。而对于熟悉UML的人员而言，使用Use Case，译为“用例”，多年来专业软件开发团队都用以表达需求模块。

  User Story与Use Case有什么差异？这些差异背后又体现出了哪些开发思想的不同？本文对这两者有价值的差异点进行探讨。

  一、User Story与Use Case形式上的差异

  表1：形式上的差异

  Use Case有2种维度来描述，即图形维度（用例图）和文字维度（用例规约）。User Story一般使用文字维度来表述，所谓文字维度，并不是说不可以图文并茂，而是无需特意使用建模工具建模。

  二、用例规约要点

  图1：用例规约示例

  用例规约要点如下：

  事件流以Actor参与者或“系统”作为主语，使用主动语句； 谨记用例是“黑盒”。描述语句只能描述Actor可以看见的交互，而不能描述软件内部的情况（打开数据库连接对象、执行SQL语句等等）； 在“其它”字段，尽可能把此功能块的“非功能需求”也都应详细描述

  三、用户情景要点

 图3：用户情景示例（摘自微软文章）

 每个用户情景都会有一个测试工程师负责其质量，测试工程师会为情景设计两个测试计划：一个是“验收测试计划”，另一个是“功能测试计划”。验收测试是黑盒测试，其目的在于验证用户故事是否按照设计预想的那样被实现。这里需要注意的是，在着手实现一个用户故事之前，准备好这样的验收测试步骤（当然，这样的验收测试不一定全部是自动化的）并且将其集成到用户故事文档中去是一个必要的步骤。验收测试的编写并且通过，需要被纳入用户故事“完成”的标准中去。如果没有经过这样的一个步骤，用户情景就不能被签字认可。相对而言，功能测试计划是一个更为详细的计划，测试工程师需要针对不同的代码路径以及不同用户输入情况进行测试，从而保证软件在各种情况下都能正常工作。

  四、深层次的思考
     Use Case有2种维度来描述，即图形维度（用例图）和文字维度（用例规约）。用例图很难表达非功能需求，而在用例规约中描述。但不少团队在项目进度紧急时，往往会忽略功能以外的需求，这会导致团队重功能而轻性能。

 用户情景在字段上，描述的信息和用例规约基本是一致的。最重要的区别，在于两个测试计划，强调了对开发出的模块的质量要求。更加符合迭代增量式的开发思想。

  结语：
     用例技术可以很好的与MSF / RUP等迭代增量式的开发过程整合。而User Story则更加强调在频繁交付时的质量门槛，值得推广。