-
简答题
-
用例的概念
-
用例是一个相关的成功和失败场景的集合，描述了一个角色使用系统完成目标。
-
-
用例和场景的关系？什么是主场景或 happy path？
-
一个用例表示一个场景的集合：主场景，加上零个或更多的可选场景。
-
主场景对应主要的系统交互，通常是“成功”场景。
-
-
用例有哪些形式？
-
简要（Brief）：简单的一段式摘要，通常是主要的成功案例。在早期需求分析期间，快速了解主题和范围。 创建可能只需几分钟。
-
简便格式（Casual）：非正式段落格式。多个段落覆盖各种场景。
-
完整（Fully）：所有的步骤和变化都写得很详细，并有辅助的部分，如前提条件和成功保证。
-
-
对于复杂业务，为什么编制完整用例非常难？
-
复杂业务涉及的场景数量会变得很多，场景之间也有各种关联，业务流程复杂，用例的编写需要对这些场景熟悉。
-
-
什么是用例图？
-
用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。用例图是系统的蓝图。用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
-
-
用例图的基本符号与元素？
-
参与者（Actor）
-
用例（Use Case）
-
系统边界（System Boundary）
-
关系（Communication）
-
关联（Association）
-
泛化（Inheritance）
-
包含（Include）
-
扩展（Extend）
-
-
-
用例图的画法与步骤
-
确定研讨的系统
-
使用用例图 System框 表示一个待研究的系统
-
正确命名系统或子系统，例如 Reserve Hotel。
-
千万不要将研究的系统的名称起的太泛，如“网上商店”。正确的姿势是“网上书店”，以避免业务空泛问题
-
-
识别 Actors
-
识别使用系统的主要参与者（primary actors）/角色(roles)
-
使用用例图 actor符号 表示，通常放在系统的左边
-
企业应用可以通过企业组织架构，业务角色与职责识别
-
互联网应用则必须通过市场分析，确定受众范围
-
千万不要用“用户”代表系统使用者，以避免过于通用导致缺乏用户体验。例如，你的系统服务对象是程序员，但你必须明白 c/c++ 程序员、java 程序员、 PHP 程序员之间的相同与不同
-
-
识别系统依赖的外部系统
-
使用用例图 Neighboursystem框 表示用例依赖的外部系统、服务、设备，并使用构造型（Stereotype）识别
-
<<system>> 例如：Account System（财务系统），教务系统
-
<<service>> 例如：第三方身份认证、地理信息服务、短信服务等第三方在线服务
-
<<device>> 或 <<sensor>> 例如：GPS 等等
-
-
要将一些专业功能赋予专业系统。对于 Reserve Hotel 系统，除了订单配送、支付、销售账单由其他专业系统完成外，房源管理都应由独立系统完成，以确保系统的简洁与专业。大而全的软件是软件失败的主要因素之一
-
-
-
识别用例（服务）
-
识别用户级别用例（user goal level）
-
以主要参与者目标驱动
-
收集主要参与者的业务事件
-
必须满足以下准则
-
boss test
-
EBP test
-
Size Test
-
-
manage 用例。特指管理一些事物的 CRUD 操作，例如管理文件、管理用户等
-
-
识别子功能级别的用例（sub function level）
-
子用例特征
-
业务复用。例如：现金支付
-
复杂业务分解。将业务分解为若干步，便于交互设计与迭代实现
-
强调技术或业务创新。例如：“识别人脸”，尽管从用户角度是单步操作，但背后涉及技术解决方案是比较复杂的
-
-
正确使用用例与子用例之间的关系
-
<<include>> 表示子用例是父用例的一部分，通常强调离开这个特性，父用例无法达成目标或失去意义！
-
<<extend>> 表示子用例是父用例的可选场景或技术特征。
-
<<include>> 箭头指向子用例；<<extend>> 箭头指向父用例。箭头表示的依赖关系！
-
-
-
-
建立 Actor 和 Use Cases 之间的关联
-
请使用 无方向连线，表示两间之间是双向交互的协议
-
-
-
用例图给利益相关人与开发者的价值有哪些？
-
明确系统的业务范围、服务对象（角色）、外部系统与设备
-
帮助识别技术风险，提前实施关键技术原型公关与学习
-
易于评估项目工作量，合理规划迭代周期，规划人力需要
-
-
-
建模练习题（用例模型）
-
选择2-3个你熟悉的类似业务的在线服务系统（或移动 APP），如定旅馆（携程、去哪儿等）、定电影票、背单词APP等，分别绘制它们用例图。
-
然后，回答下列问题：
-
为什么相似系统的用例图是相似的？
这是因为用例图由参与者、用例，边界以及它们之间的关系构成的用于描述系统功能的视图。
-
如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术。
提供民俗预订服务，结合用户出租房屋的功能，使旅行者与本地人都能使用并获益。
-
如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用
用例图中对创新用例使用某种颜色进行高亮标记。
-
请使用 SCRUM 方法，选择一个用例图，编制某定旅馆开发的需求（backlog）开发计划表
ID Name Imp Est How to demo Notes 1 搜索房源 50 4 通过地图、条件等让用户筛选房源 通过谷歌地图API划定范围 2 查看行程 30 4 查看所有行程，并对已预订的行程作出修改、评价等行为 需要与房源的退订策略匹配 3 生成订单 50 10 根据所选的房源、日期等信息生成订单 生成后可跳转支付界面，同时将通知房东 4 支付订单 80 2 根据订单金额支付订单 调用用户所选支付手段的API 5 信息管理 50 2 用户可更改个人信息 身份证、护照等信息需核实 -
根据任务4，参考 使用用例点估算软件成本，给出项目用例点的估算
用例 事务 计算 原因 UC权重 搜索房源 2 4 搜索条件多，包括模糊搜索 平均 查看行程 2 2 简单 生成订单 3 4 需要与房源确认信息 平均 支付订单 3 2 调用API 简单 信息管理 2 1 简单
-
-
相关文章：