用例建模 - 绘制用例图

练习材料: Asg-RH.pdf

1、如何识别、组织需求

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

2、按需求组织生产

需求组织，建议采用 TAPD 需求组织形式：

ID	Title	Est	Iter	Imp
10101	find hotel	2	1	5
10102	find city	2	3	5
10103	find on map	10	2	3
10104	GIS API learning	5	1	3
10111	make order	3	1	5

• 正确编写 Backlog
  • 详细需求请使用文档，需求组织的目标就是建立可合理分解、易于理解、方便迭代实现的 Backlog
  • 如何计算故事点（用例点）
    • 教程 “我们怎样编写产品 backlog” 建立使用人日估计
    • 人日计算依赖经验，常用估算人日依据
      • 页面数（部件数）
      • 报表数
      • API接口数
    • 使用真实数据才能正确估算工作量
      • 模拟数据至少离投产有50%工作量
• 如何决定迭代内容
  • 教程 “我们怎样制定 sprint 计划”
  • 保持轻量，只安排 1-2 个迭代任务的需求
  • 通过“燃尽表”控制进度

2、课堂练习

使用上述练习材料，在 30 分钟以内按材料练习要要求绘制 UML 用例图。

3、作业

1、简答题

1. 用例的概念
2. 用例和场景的关系？什么是主场景或 happy path？
3. 用例有哪些形式？
4. 对于复杂业务，为什么编制完整用例非常难？
5. 什么是用例图？
6. 用例图的基本符号与元素？
7. 用例图的画法与步骤
8. 用例图给利益相关人与开发者的价值有哪些？

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

• 选择2-3个你熟悉的类似业务的在线服务系统（或移动 APP），如定旅馆（携程、去哪儿等）、定电影票、背单词APP等，分别绘制它们用例图。并满足以下要求：
  • 请使用用户的视角，描述用户目标或系统提供的服务
  • 粒度达到子用例级别，并用 include 和 exclude 关联它们
  • 请用色彩标注出你认为创新（区别于竞争对手的）用例或子用例
  • 尽可能识别外部系统和服务
• 然后，回答下列问题：
  1. 为什么相似系统的用例图是相似的？
  2. 如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术
  3. 如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用
  4. 请使用 SCRUM 方法，选择一个用例图，编制某定旅馆开发的需求（backlog）开发计划表
  5. 根据任务4，参考 使用用例点估算软件成本，给出项目用例点的估算

参考资料

• 经典参考书：编写有效用例(中文版、英文版)