用例（需求用例）概念：使用案例、用况
以明确需求为目的，描述用户使用产品（系统）的典型情节。用例简单通俗，能让用户也能参与；强调了用户的目标和观点：谁使用系统？典型场景？目的？强调以用户为中心。
用例是系统提供的功能块，换句话来说用例演示了人们如何使用系统。通过用例观察系统，能够将系统实现与系统目标分开，有助于了解最重要的部分（满足用户要求和期望），而不会沉浸于实现细节。
通过用例用户可以看到系统提供的功能，先确定系统范围再深入开展项目工作。
用例特点
1.站在用户角度、而不是实现角度；
2.无须披露系统特征和实现细节；
3.一个用例只代表了系统的一个单一的目标；
4.描述使用，而不是罗列规则。
Jacobson（雅各布森）给出的需求用例编写10大建议
1.用例是短文
2.用例可以是一个情节，包含动作和交互
3.用例可以是一组情节，描述不同情节下的行为（这种书写格式可以在任何时候描述有变体的行为，例如黑盒需求，业务流程，系统设计说明）
4.用例里不要有系统设计
5.用例里不要有界面设计
6.用例里不要有特性列表
7.用例里不要有测试
8.用例应该描述行为需求
9.用例的主情节不要超过九步（可以在适当的层次上得到子目标和移除设计说明）
10.用例的最大价值不在于主情节，而是在于备选行为（主情节可能只占用例长度的四分之一到十分之一）
用例由设计者和用户共同完成
1.浅显易懂（用户能够理解的语言）
2.不包含系统特征（不要扼杀设计可能性）
3.描述理想情况（无须考虑异常情况）
用户故事（User Story）和用例的区别
User story定义：
从用户或客户的角度来描述其希望得到的有价值功能，只是需求描述，而不是详细的需求规范。
User story格式：
英文：As a <Role>, I want to <Activity>, so that <Business Value>
中文：作为一个<角色>，我想要<活动>，以便于<商业价值>
1.从顺序上，我们是先有User story，然后有各个场景下的User case；
2.从内容上，User story 关心在什么场景下完成了什么， User case 关心通过什么样的步骤如何完成了一个具体目标；
3.从价值上，用户故事是基于用户目标根本需求的挖掘，用例则是基于系统功能范围分解成许多小的系统功能陈述。
需求用例与测试用例的区别
1.需求用例：面向需求，明确需求
2.测试用例：面向实现，保证实现
用例一般包含哪些内容
输入垃圾、输出垃圾
交互设计师最讨厌的事情，就是猜测别人原型的逻辑；
若输入的需求是垃圾，那么输出的产品形态一定有问题。
目前，互联网产品设计≈界面交互设计。产品在给出需求时，往往是粗略的产品原型+需求文档。这样的需求对于设计师是有害的，本质上设计师的作用就是给出多样化的解决方案，但是面对产品原型，更多时间交互或UI都在美化界面样式及细节问题。而忽略了用户任务路径，其实用户完成一项任务时，我们可以提供多种方案。
什么是好的需求？
来自交互设计师的 仰望
1.用例应该是文字（使用文字描述用例即可）
2.规则/逻辑应该是表格（例如：数据字典、权限表、规则等）
3.抽象关系才能用图（例如：流程图一定是抽象的）
但真实情况是：设计师往往要反推需求
用例，对交互设计的意义
1.UI设计基于用户任务展开；
2.优秀的用例，本身就是一份用户任务清单；
3.所谓优秀用例，就是颗粒度合适。
面对需求，我们要学会拆分
分子项目：对实体的增、删、改、查
特殊原子项目：与规则相关的数据项目（属性/权限配置等）
例子：
老板一句话（故事）要抽象分解为这三部分：
老板：我要一只鸡
产品：我要替老板把毛拔了
设计：我要把鸡拆解为鸡翅
用户：最终需要的是鸡米花（拆散为颗粒）
总结
1.用例是站在用户角度描述需求的一种形式；
2.产品/交互设计师，希望得到抽象输入，并不一定需要原型；
3.要学会区分用户故事（User story）和用例（User case）；
4.用例的输出建议：分子项目+特殊的原子项目；
5.用例最大的作用，就是让需求易于理解、便于回顾。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
