用例，或使用案例、用况，是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。用例一般是由软件开发者和最终用户共同创作的。
场景，或用例场景指用户实际应用场景的过程，通过各种动作组合起来，是实例化的用例，从一个用例可以实例化出多个用例场景。 简单讲，用例就是对全部用例场景的抽象，用例场景就是从用例中实例化出来的一组活动。
主场景对应于主要系统交互，通常是“成功”场景，最常用、最直接地实现用户目标的场景。
Happy path是一个没有异常或错误条件的默认场景。它让执行成果的能继续运行到最后，从而生成积极的响应。
摘要：简洁的一段式概要，通常用于主场景。在早期需求分析过程中，为快速了解主题和范围，通常花费少量时间编写。 非正式：非正式的段落格式，用几个段落覆盖不同的场景。 详述：详细编写所有步骤和各种变化，同时具有补充部分，如前置条件和成功保证。确定并以摘要形式编写大量用例后，在第一次需求讨论中，详细地编写其中少量的具有重要架构意义和高价值的用例。
复杂业务编制完整用例非常难的原因有：
由于业务复杂、需求多且杂，用例下的场景会非常多且复杂。随着时间更迭，开发过程中需求会发生变化，用例场景不仅会越来越多，并且也会相应产生变化。很难完整地考虑到所有的场景情况，并且有些业务难以使用用例抽象描述出来。用例间的关系在多个用例之间是很复杂的，有些用例关系难以理清。用例图是指由参与者(Actor)、用例(Use Case)，边界以及它们之间的关系构成的用于描述系统功能的视图。用例图(User Case)是外部用户(被称为参与者)所能观察到的系统功能的模型图。用例图是系统的蓝图。用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
参与者(Actor)：一个小人，表示一个系统用户，也就是与应用程序进行交互的用户、组织或者外部系统。
用例(Use Case)：一个圆框，表示对系统提供的功能、服务的一种用例描述。
包含关系：虚线箭头加上《include》标志，箭头方向指向被包含者。表示用例可以简单地包含其他用例所具有的行为，并把它所包含的用例行为作为自身行为的一部分。
拓展、延伸关系：虚线箭头加上《extends》，箭头方向指向基础用例。表示在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例，原有的用例叫做基础用例，相当于为基础用例提供一个附加功能。
泛化关系：实线空心三角箭头，箭头方向指向父用例。表示一个父用例可以被特化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。
关联关系：一条直实线。表示参与者与用例之间的关系。
携程酒店： 猫眼电影：
答：因为相似系统的参与者、用例、边界以及他们之间关系都是相似的，也无流程也是相似的，而用例图基本由这些因素决定，因此他们最终得到的用例图也是相似的。
答：创新业务与技术可以用特殊标记标志出来。在相似用例进行对比，展现、突出创新业务和技术。
答：创新思路可以在用例图中用醒目的颜色标注，这样可以帮助开发者快速定位该创新点，并查看其在整个系统中的位置。如果该创新点位于主用例上则很重要，反之则重要性有所下降。
