用例（英语：use case），或译使用案例、用况，是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。编写用例时要避免使用技术术语，而应该用最终用户或者领域专家的语言。用例一般是由软件开发者和最终用户共同创作的。
场景是actors和系统之间特定的一系列动作和绘画，是用例的实例。一个用例是一些场景的集合。
主场景（基本流）对应系统的主要的交互，通常是“成功”的场景。主场景是最常用的，能直接地实现用户目标的流程。
主成功场景或happy path是用例从触发事件开始，一步一步执行，最终满足用例利益的步骤集合 主成功场景应该包括以下信息：
两个执行者之间的交互。如，用户提交了订单。
为保证主成功场景得以继续的确认。如，系统确认用户密码。
主成功场景推进过程中的内部变化。如，系统扣除用户账户余额。
Brief ：简洁的一段式概要，通常用于主成功场景。在早期需求分析过程中，为快速了解主题和范围，通常花费少量时间快速编写。
Casual：非正式的段落格式；覆盖多个场景的几个段落；在早期需求分析过程中，快速了解主题和范围。
Fully：所有的步骤和变化都写得很详细，有支持部分，如先决条件和成功保证。
场景多而且用例比较复杂
用例图是描述系统与其他外部系统以及用户之间交互的图形，即用例图描述了谁将使用系统，用户希望以什么方式与系统交互。用例图确定系统中所包含的参与者、用例和两者之间的对应关系， 它描述的是关于系统功能的一个概述， 描述软件应具备哪些功能模块以及这些模块之间的调用关系。
1.参与者：表示的是一个系统用户，也就是与应用程序进行交互的用户、组织或者外部系统。
2.用例：表示的是对系统提供的功能、服务的一种描述。
用例之间的关系
1.扩展关系 表示在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例，原有的用例叫做基础用例，相当于为基础用例提供一个附加功能。
2.包含关系 表示用例可以简单地包含其他用例所具有的行为，并把它所包含的用例行为作为自身行为的一部分。
3.泛化关系 泛化指的是一个父用例可以被特化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。
确定参与者
识别使用系统的主要参与者
识别系统依赖的外部系统
识别用例
识别用户级别用例
识别子功能级别的用例
建立 Actor 和 Use Cases 之间的关联
主要的作用有三个：（1）获取需求；（2）指导测试；（3）还可在整个过程中的其它工作流起到指导作用。
1.为什么相似系统的用例图是相似的？
因为逻辑相似，子系统也相似。
2.如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术
不同时代对预定的酒店的需求不同。可以让筛选算法与时俱进，满足一些不同的主流要求。且用户会需要更加优秀、好用、有参考价值的评价系统，也需要随时更新。而不同地区的消费特点不同，旅游胜地和普通城市用户对于酒店预订的需求有差别，可以在用例图上突出一些特点。
3.如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用
利用创新点在图中的位置来判断。位于较高的父级作用比较大，处于子类或者是被包括的关系作用相对较小。
订电影票：
IDNAMEIMPESTHOW TO DEMO1注册202用手机号接收验证码注册2登录152利用手机号和密码登录3订票205根据所需的电影场次、位置订票4支付253利用支付宝、微信支付5评论203出票后即可写评论
用例事务计算UC权重1注册2简单2登录2简单3订票5一般4 支付3简单5评论3简单
