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