用例的概念 用例是站在用户的角度，描述了系统完成客户目标作形成的动作序列，这一序列动作对特定参与者产生一个有价值的可见结果。
用例和场景的关系？什么是主场景或 happy path？ 每一个用例提供了一个或多个场景,该场景说明了系统是如何和最终用户或其他系统互动,也就是谁可以用系统做什么,从而获得一个明确的业务目标. 主场景是指主执行者完成了目标,所有项目相关人员的利益都被满足
用例有哪些形式？
摘要：简洁的一段式概要，通常用于主成功场景。在早期需求分析过程中，为快速了解主题和范围，通常花费少量时间快速编写。非正式形式：非正式的段落格式，用几个段落覆盖不同的场景。详述：详细编写所有步骤和各种变化，同时具有补充部分，如前置条件和成功保证。确 定并以摘要形式编写大量用例后，在第一次需求讨论中，详细地编写其中少量的具有重要架构意义和高价值的用例。对于复杂业务，为什么编制完整用例非常难？ 因为对于复杂业务，设计到的场景会非常多，场景之间的相互关联也会使得用例建模变得复杂。同时，用例建模也需要对场景非常熟悉，需要对场景之间的相互关系有一定的了解，对于建模者的建模能力要求也更高，因此编制完整用例便变得非常难。
什么是用例图？ 用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。用例图是系统的蓝图。用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
用例图的基本符号与元素？
参与者(Actor)——与应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。
用例(Use Case)——用例就是外部可见的系统功能，对系统提供的服务进行描述。用椭圆表示。
子系统(Subsystem)——用来展示系统的一部分功能，这部分功能联系紧密。
用例图的画法与步骤确定研讨的系统
使用用例图 System框 表示一个待研究的系统识别 Actors
识别使用系统的主要参与者（primary actors）/角色(roles)识别系统依赖的外部系统识别用例（服务）
识别用户级别用例（user goal level）识别子功能级别的用例（sub function level）建立 Actor 和 Use Cases 之间的关联
使用 无方向连线，表示两间之间是双向交互的协议 用例图给利益相关人与开发者的价值有哪些？ 对于利益相关人： 可以直观看到系统的结果和用户的功能体验，保证系统按照用户的需求进行设计。用例能够根据需要对复杂程度和形式化程序进行增减调节，即能够响应用户（利益相关人)提出的需求，而用例图则使得这种调节更加便利，可以通过修改图形间的关系实现。 对于开发者来说： 用例图是设计者设计过程的结论与参考，设计者与开发者之间的交流工具，开发者开发过程的蓝图。用例图使得开发者能够更明确地获得需求，更好地理解需求。用例图可以指导开发和测试，同时可以在整个过程中对其他工作流起到指导作用。选择2-3个你熟悉的类似业务的在线服务系统（或移动 APP），如定旅馆（携程、去哪儿等）、定电影票、背单词APP等，分别绘制它们用例图。并满足以下要求：
请使用用户的视角，描述用户目标或系统提供的服务粒度达到子用例级别，并用 include 和 exclude 关联它们请用色彩标注出你认为创新（区别于竞争对手的）用例或子用例尽可能识别外部系统和服务定旅馆系统
背单词App
