1、简答题

用例的概念

用例是一系列相关的成功和失败场景的集合，这些场景描述了一个参与者使用一个系统来支持一个目标。用例是功能或行为需求，指示系统将做什么。就FURPS+需求类型而言，它们强调“F”，但也可以用于其他类型。

用例和场景的关系？什么是主场景或 happy path？

用例表示一组场景:主场景，加上零个或多个可选场景。 主场景对应于主要的系统交互，通常是“成功”场景。是最常用的，直接地实现用户目标的故事。

用例有哪些形式？

简洁模式(Brief (high level)） 简短的一段概要，通常是成功的主场景。 在早期的需求分析中，快速了解主题和范围。可能只需要几分钟来创建。简便格式（Casual） 非正式的段落格式。包含多种场景的多个段落。详细描述(Fully) 所有的步骤和变化都写得很详细，并有补充部分，如先决条件和成功的保证。 在以一种简短的格式确定并编写了许多用例之后，在第一个需求研讨会期间，会详细地编写一些(例如10%)具有体系结构重要性和高价值的用例。

对于复杂业务，为什么编制完整用例非常难？

复杂业务的需求多，导致扩展部分较多，即除了主成功场景外的其他场景或分支，包括成功和失败路径。用例的格式导致编制复杂业务的完整用例非常难，因为这需要花费大量的时间编写，而且这些用例没有增加或增加很少的价值，并会导致大量的返工。

什么是用例图？

用例图是系统上下文的绝佳图景，它能显示用例和参与者的名称及其关系，给出了一个很好的系统及其环境的上下文图。 a.它是一个很好的上下文图 b.显示系统的边界，它外面的东西，以及如何使用它。 c.它作为一种沟通工具，总结了系统及其参与者的行为。

用例图的基本符号与元素？

Actor 表示一个系统的用户，即与应用程序或系统进行交互的用户、组织或者外部系统。参与者用一个小人表示。 参与者包括三类:系统用户；其他系统。在当前项目范围之外，需要建立与其他系统的接口；一些可以运行的进程use case 外部可见的系统功能，表示对系统提供功能、服务的描述。用例用一个椭圆表示。 association 关联Association表示参与者与用例之间的关系。关联关系用一条直线表示，由参与者指向用例。 Include 较复杂的用例可以被分解为较小的用例，即该用例可以包含其他用例所具有的行为。包含关系使用带箭头的虚线表示，箭头指向被包含的用例。 extends 扩展Extend表示用例功能的延伸。把新的行为加入到基础的用例上，使得基础用例能够获得新的行为并能够提供新的附加功能。扩展关系使用带箭头的虚线表示，箭头指向基础用例。 system scope 确定系统的范围，边界是一个方框，用例在边界内，参与者在边界外

用例图的画法与步骤

需求识别步骤 确定研讨的系统 使用用例图 System框 表示一个待研究的系统正确命名系统或子系统，例如 Reserve Hotel。千万不要将研究的系统的名称起的太泛，如“网上商店”。正确的姿势是“网上书店”，以避免业务空泛问题 识别 Actors 识别使用系统的主要参与者（primary actors）/角色(roles) 使用用例图 actor符号 表示，通常放在系统的左边企业应用可以通过企业组织架构，业务角色与职责识别互联网应用则必须通过市场分析，确定受众范围千万不要用“用户”代表系统使用者，以避免过于通用导致缺乏用户体验。例如，你的系统服务对象是程序员，但你必须明白 c/c++ 程序员、java 程序员、 PHP 程序员之间的相同与不同 识别系统依赖的外部系统 使用用例图 Neighboursystem框 表示用例依赖的外部系统、服务、设备，并使用构造型（Stereotype）识别<> 例如：Account System（财务系统），教务系统<> 例如：第三方身份认证、地理信息服务、短信服务等第三方在线服务<> 或 <> 例如：GPS 等等要将一些专业功能赋予专业系统。对于 Reserve Hotel 系统，除了订单配送、支付、销售账单由其他专业系统完成外，房源管理都应由独立系统完成，以确保系统的简洁与专业。大而全的软件是软件失败的主要因素之一 识别用例（服务） 识别用户级别用例（user goal level）以主要参与者目标驱动收集主要参与者的业务事件必须满足以下准则 boss testEBP testSize Test manage 用例。特指管理一些事物的 CRUD 操作，例如管理文件、管理用户等识别子功能级别的用例（sub function level） 子用例特征 业务复用。例如：现金支付复杂业务分解。将业务分解为若干步，便于交互设计与迭代实现强调技术或业务创新。例如：“识别人脸”，尽管从用户角度是单步操作，但背后涉及技术解决方案是比较复杂的 正确使用用例与子用例之间的关系 <> 表示子用例是父用例的一部分，通常强调离开这个特性，父用例无法达成目标或失去意义！<> 表示子用例是父用例的可选场景或技术特征。<> 箭头指向子用例；<> 箭头指向父用例。箭头表示的依赖关系！ 建立 Actor 和 Use Cases 之间的关联 请使用 无方向连线，表示两间之间是双向交互的协议

用例图给利益相关人与开发者的价值有哪些？

2、建模练习题（用例模型）

选择2-3个你熟悉的类似业务的在线服务系统（或移动 APP），如定旅馆（携程、去哪儿等）、定电影票、背单词APP等，分别绘制它们用例图。并满足以下要求：

请使用用户的视角，描述用户目标或系统提供的服务粒度达到子用例级别，并用 include 和 exclude 关联它们请用色彩标注出你认为创新（区别于竞争对手的）用例或子用例尽可能识别外部系统和服务

背单词APP

电影订票APP

然后，回答下列问题：

为什么相似系统的用例图是相似的？ 因为相似的系统，其目标人群和提供的功能时相似的，也就是说 actor 和 scenery 类似，所以 use case 也类似，最终的用例图也是类似的。

如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术 如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术 可以对当前流行产品和目标用户进行调研，然后结合旧用例图，进行符合产品市场的改进，如在 ASG_RH 付款时需要 check out，但我们现在电子支付十分方便，可以更改为链接电子支付

如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用 在项目早期，通过对比当前用例图和其它类似产品的用例图，提炼类似产品的先进业务，技术和商业模式，改进当前用例图，对于别人产品用例图中不足的地方，如缺少的业务和落后的技术，进行创新。同时，从用户的角度进行考虑，发掘用户需求。

请使用 SCRUM 方法，选择一个用例图，编制某定旅馆开发的需求（backlog）开发计划表

IDNameImpEstIter1注册10212登陆10213查询酒店50514预定酒店50515订单管理40416支付4031 Name 是产品特性，或用例名，或子用例名。它通常是树型结构Imp 是特征的重要性，重要性评估维度很多，分为业务基础特征和创新业务特征。重要特征通常意味业务或技术价值，考虑优先完成或必须完成Est 工作量估计Iter n 预计从哪个迭代开始设计、编码该特征

---

根据任务4，参考 使用用例点估算软件成本，给出项目用例点的估算 IDName事务计算UC权重1注册32简单2登陆22简单3查询酒店44复杂4预定酒店43复杂5订单管理211=复杂6支付33平均