用例是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动。
摘要 摘要用例有很少的句子组成来总结的用例。它十分适合在电子表格中计划软件开发。一个摘要用例能够简单插入电子表格的单元格中并且用表格中的其它列记述业务优先级，技术复杂度，版本号等。
非正式 一个非正式的用例由文本段落组成，包括了上面提到的那些列，用总结或故事的形式详细的描述了用例。
完整正式 一个完整正式或者复杂的用例是一个以包含了不同部分的长模板为基础的正规的文档。该用例在下面的用例模板部分进行讨论。
复杂的业务中场景数量比较多而且之间的关联非常复杂。在前期的考虑中，很难不遗漏一些业务条件和需求，并且这些条件和需求在开发中还可能会发生变化。所以对于复杂业务，直接编制完整的用例非常困难。
用例图是用户与系统交互的最简表示形式，展现了用户和与他相关的用例之间的关系。通过用例图，人们可以获知系统不同种类的用户和用例。用例图也经常和其他图表配合使用。
参与者：表示与您的应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。
用例: 用例就是外部可见的系统功能，对系统提供的服务进行描述。 用椭圆表示。
子系统：用来展示系统的一部分功能，这部分功能联系紧密。
关系：表示参与者与用例之间的通信，任何一方都可发送或接受消息。虚线箭头。
泛化：就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。箭头指向指向消息接收方。
包含：包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤；箭头指向 父用例。
扩展：扩展关系是指 用例功能的延伸，相当于为基础用例提供一个附加功能。箭头指向分解出来的功能用例。
依赖：表示源用例依赖于目标用例。箭头指向基础用例。
项目：用依赖关系把某个用例依赖到项目上。箭头指向被依赖项。
用例图包含六个元素，分别是：参与者 (Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系 (Generalization)。
一．参与者（Actor）：确定参与者
二、用例（Use Case） ：识别用例
三、确定用例间的关系
1．关联关系（Association）
２．包含关系（Include）
３．扩展关系（Extend）
４．泛化关系（Generalization）
对于利益相关人：
可以直观看到系统的结果和用户的功能体验，保证系统按照用户的需求进行设计。用例能够根据需要对复杂程度和形式化程序进行增减调节，而用例图则使得这种调节更加便利。对于开发者来说：
用例图是设计者设计过程的结论与参考，设计者与开发者之间的交流工具，开发者开发过程的蓝图。用例图使得开发者能够更明确地获得需求，更好地理解需求。然后，回答下列问题：
1、为什么相似系统的用例图是相似的？相似系统面对的参与者和用例是相似的，用例之间的关系也是同构的。用户预期的功能都是相似的，即不同的同类系统一定具有一致基本功能以及带有自己特色的扩展功能。所以体现在用例图上也是相似的。
2、如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术不同时代对预定的酒店的需求不同。有关订旅馆的目的：比如旅游、出差等，应该提供不同的筛选服务以及推荐。
3、如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用对创新的用例进行高亮标注。可以方便开发人员和投资方快速找到核心竞争力及可能带来的结果。
4、请使用 SCRUM 方法，选择一个用例图，编制某定旅馆开发的需求（backlog）开发计划表 IDNameImpsEstDemo1注册用户303绑定手机/社交账号进行注册2搜索旅馆205根据地域/价格对旅馆进行搜索3预定旅馆405线上预定选好的旅馆的房间4支付订单354支付预定的订单5评价旅馆152完成住宿后对旅馆进行评价留言 5、根据任务4，参考 使用用例点估算软件成本，给出项目用例点的估算 ID用例事务计算原因UC比重1注册用户42常规功能简单2搜索旅馆35需要高性能，并且其他API协助复杂3预定旅馆34数据同步复杂4支付订单24数据同步平均5评价旅馆12简单的留言功能简单