用例是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。通俗的讲，用例是文本形式的情节描述，用以说明某参与者使用系统以实现某些目标。
场景是参与者和系统之间的一系列特定的活动与交互，也被称作是用例的实例。主场景或happy path也被称为“理想路径”场景，它描述了满足涉众关注点的典型成功路径，通常不包括任何条件或分支。
用例的三种常见形式：
摘要：简介的一段式概要，通常用于主场景。非正式：非正式的段落格式，用几个段落覆盖不同场景。详述：详细编写所有步骤及各种变化，同时具有补充部分，如前置条件与成功保证。复杂业务活动包含很多用例与场景，功能业务逻辑十分复杂，无法保证用例的完整性、逻辑性，需要建立用例的人对场景和过程十分熟悉。因此编制完整用例便非常难。
用例图（英语：use case diagram）是用户与系统交互的最简表示形式，用以描述用例名称和参与者及其之间的关系。通过用例图，人们可以获知系统不同种类的用户和用例。用例图也经常和其他图表配合使用。
用例图包含6个基本元素：参与者（Actor）、用例（Use Case）、泛化关系（Generalization）、扩展关系（Extend）、包含关系（Include）和关联关系（Association）
参与者(Actor)：表示的是一个系统用户，也就是与应用程序进行交互的用户、组织或者外部系统。 2、用例(Use Case)：表示的是对系统提供的功能、服务的一种描述。 3、用例之间的关系： 包含关系(Include)：表示用例可以简单地包含其他用例所具有的行为，并把它所包含的用例行为作为自身行为的一部分。在UML中常用带箭头的虚线表示，箭头指向被包含的用例。 泛化关系(Generalization)：泛化指的是一个父用例可以被特化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。在UML中用空心三角箭头的实线表示，箭头指向父用例。 关联关系(Association)：表示的是参与者与用例之间的关系。在UML中常用一条直线，或者是一条带箭头的线条来表示，箭头指向信息接收方 扩展/延伸关系(Extend)：表示在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例，原有的用例叫做基础用例，相当于为基础用例提供一个附加功能。在UML中用带箭头的虚线表示，箭头指向基础用例。确定系统边界
确定参与者
谁将使用该系统的主要功能。谁将需要该系统的支持以完成其工作。谁将需要维护、管理该系统，以及保持该系统处于工作状态。系统需要处理哪些硬件设备。与该系统那个交互的是什么系统。谁或什么系统对本系统产生的结果感兴趣。 识别用例 特定参与者希望系统提供什么功能。系统是否存储和检索信息，如果是，由哪个参与者触发。当系统改变状态时，是否通知参与者。是否存在影响系统的外部事件。哪个参与者通知系统这些事件。 确定用例间的关系 用例除了与参与者发生关系外，还可以具有系统中的多个关系，这些关系包括包含关系、扩展关系和泛化关系。应用这些关系的目的是为了从系统中抽取出公共行为和其变体。因为相似系统有着相似的用户，用户也有相似的用例，系统的功能基本一致，用例间关系区别也不大，所以用例图也是相似的。
可以根据不同时代、不同地区产品的用例图，利用更先进的技术创新业务，或提供更完善的服务。例如使用大数据分析用户的订单，了解用户喜好，针对性的推荐旅馆。
如果创新点是包含很多字节点的父节点，说明创新思路的比重较大，如果是子节点说明比重较小。
