• 1. 软件需求用例分析张 恂 2011-3-17 www.zhangxun.com info@zhangxun.com
  • 2. 自我介绍资深软件工程顾问和教练 软件需求和用例分析专家 1998 开始研究 UML、Use Case、RUP 2003 统一用例方法 2006 太极建模口诀(c) www.zhangxun.comtaijiusecase_1.0
  • 3. 他们行,你也能行 - 用例 UML 应用省级税务系统 证券公司核心客服系统 全国范围的保险核心业务系统 制造业电子商务、贸易系统 电信级帐务、计费系统 企业级呼叫中心系统 人力资源服务核心业务系统 大型互联网门户网站 …(c) www.zhangxun.comtaijiusecase_1.0
  • 4. 演讲大纲-Part 1 需求难题什么是需求? 常见的需求问题 如何破解需求难题?(c) www.zhangxun.comtaijiusecase_1.0
  • 5. 演讲大纲-Part 2 用例基础软件需求的组成 什么是用例? 用例的组成 用例的价值 用例与特性、用户故事和非功能需求的区别与联系 (c) www.zhangxun.comtaijiusecase_1.0
  • 6. 演讲大纲-Part 3 用例建模太极建模口诀 用例建模的步骤 用例图 用例模版 宠物店用例模型案例 需求用例分析的技巧和建议(c) www.zhangxun.comtaijiusecase_1.0
  • 7. 太极建模由外而内,层次分明;动静结合,逐步求精。(c) www.zhangxun.comtaijiusecase_1.0
  • 8. Part1 需求难题什么是需求? 常见的需求问题 如何破解需求难题? (c) www.zhangxun.comtaijiusecase_1.0
  • 9. 什么是需求?Requirement(c) www.zhangxun.comtaijiusecase_1.0
  • 10. 需求WhatHow(c) www.zhangxun.comtaijiusecase_1.0
  • 11. 需求的定义IEEE 97 用户解决问题或达到目标所需的条件或能力。 系统或其部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力。 A. Davis 93 从系统外部能发现的,系统所具有的满足于用户的特点、功能及属性等。 UML 系统的一个期望特性、属性或行为。(c) www.zhangxun.comtaijiusecase_1.0
  • 12. 需求是软件开发的上游需求设计编码项目管理测试(c) www.zhangxun.comtaijiusecase_1.0
  • 13. 需求关系到所有人 *(c) www.zhangxun.comtaijiusecase_1.0
  • 14. 常见的需求现象-1用户提出的需求不完整、不准确。 需求经常变化,工作没完没了。 开发后期才发现误解了需求,开发人员被迫大量加班,修修补补。 功能都实现了,但由于性能、使用方面的问题导致用户不满。 (c) www.zhangxun.comtaijiusecase_1.0
  • 15. 常见的需求现象-2客户的许多增强要求未及早提出,导致软件后期维护费用陡升。 测试效果差,测试人员不明白软件要做什么 勉强交付了客户并不满意的产品 … (c) www.zhangxun.comtaijiusecase_1.0
  • 16. 常见的需求问题需求不完整,太粗略,遗漏关键信息。 频繁、大量的需求变更|变化 用户不积极参与 模棱两可、含糊的需求 “锦上添花”的需求 忽略了用户分类 …(c) www.zhangxun.comtaijiusecase_1.0
  • 17. 低质量需求的后果遗漏需求 项目计划、估算错误 影响进度 需求不准 返工 增加成本(c) www.zhangxun.comtaijiusecase_1.0
  • 18. 需求错误的成本 各阶段修复需求错误的成本比(Boehm 1998): 需求 (0.5-1) 设计 (2.5) 编码 (5) 单元测试 (10) 验收测试 (25) 维护 (100) (c) www.zhangxun.comtaijiusecase_1.0
  • 19. 需求错误的影响据国外研究统计 软件项目中 40% 到 60% 的问题都是在需求分析阶段埋下的隐患。 返工开销占开发总费用的 40% ,而 70-80%的返工是由需求方面的错误所导致的。(c) www.zhangxun.comtaijiusecase_1.0
  • 20. 解决之道 – 需求工程科学的 系统的 规范的 经济的 人本的(c) www.zhangxun.comtaijiusecase_1.0
  • 21. 成功的需求开发与管理 能为组织 带来 巨大 回报! 需求工程的价值(c) www.zhangxun.comtaijiusecase_1.0
  • 22. 目标 – 高质量的需求完整性 正确性 可行性 必要性 分级性 无多义性/准确性 可验证性 一致性 可扩展性 可跟踪性 可管理性 稳定性(c) www.zhangxun.comtaijiusecase_1.0
  • 23. 软件开发的本质 – 确定性|不确定性确定性不确定性(c) www.zhangxun.comtaijiusecase_1.0
  • 24. 难题 – 预测需求变化(c) www.zhangxun.comtaijiusecase_1.0
  • 25. 需求变化 – 合理的原因用户不了解自己的需求 用户不是 IT 专家 没有实物,需求很抽象,空想。 需求本身易变 市场变化 技术变化 竞争变化 … (c) www.zhangxun.comtaijiusecase_1.0
  • 26. 需求变化 – 不合理的原因客户沟通问题 理解错误 业务不清、不熟悉 需求文档质量不高 缺乏预见性 遗漏关键信息 需求分析技能、技术缺陷 需求管理缺陷 变更控制 …(c) www.zhangxun.comtaijiusecase_1.0
  • 27. Part1 小结(c) www.zhangxun.comtaijiusecase_1.0
  • 28. Part 2 用例基础软件需求的组成  什么是用例? 用例与其他需求的比较 用例的价值  (c) www.zhangxun.comtaijiusecase_1.0
  • 29. 软件需求的种类业务需求、业务规则 特性|特征 用例(功能)需求 质量属性 外部接口(协议) 各种约束 解决方案约束(对设计、实现的限制) 数据需求(c) www.zhangxun.comtaijiusecase_1.0
  • 30. 软件需求 – 功能|非功能功能 FR非功能 NFR(c) www.zhangxun.comtaijiusecase_1.0
  • 31. FR(Functional Requirements) 1)系统输入到输出的映射及其组合; 2)系统外部可见的行为需求。 与用户任务、目标、用例、服务、特性相关 一般可通过描述系统的输入、输出、功能、系统的属性和系统环境的属性来完整地描述软件需求。(c) www.zhangxun.comtaijiusecase_1.0
  • 32. NFR(Non-Functional Requirements)质量属性 业务规则 约束(对解决方案自由度的限制) 约束源包括:经济、行政、技术、环境(标准、法律、安全)、进度、资源、战略、业务运作、合同等等。(c) www.zhangxun.comtaijiusecase_1.0
  • 33. NFR-软件|系统质量属性有效性 效率|性能 灵活性 完整性 互操作性 可靠性 健壮性 易用性 可用性 可维护性 可移植性 可重用性 可测试性 …(c) www.zhangxun.comtaijiusecase_1.0
  • 34. FURPS+ (Grady 1992)/1 功能(Functionality) 特性集、能力、通用性、安全性等等。 易用性(Usability) 人性因素、美学、一致性、文档等等。 可靠性(Reliability) 失效频度/严重性、可恢复性、可预测性、精确性、MTBF 等等。 (c) www.zhangxun.comtaijiusecase_1.0
  • 35. FURPS+/2性能(Performance) 速度、效率、资源使用、吞吐量、应答时间等等 可支持性(Supportability) 可测试性、可扩展性、适应性、可维护性、兼容性、健壮性; 可配置性、可保养性、安装能力、本地化能力等等。 + 设计约束、实现、接口、物理要求等等。(c) www.zhangxun.comtaijiusecase_1.0
  • 36. 软件需求 – 高低高层 需求 低层 需求 (c) www.zhangxun.comtaijiusecase_1.0
  • 37. 需求金字塔(c) www.zhangxun.comtaijiusecase_1.0
  • 38. 软件需求 – PS问题域 Problem 解决域 Solution(c) www.zhangxun.comtaijiusecase_1.0
  • 39. 用户需要业务需要 工作任务 业务需求 (c) www.zhangxun.comtaijiusecase_1.0
  • 40. 用户任务(c) www.zhangxun.comtaijiusecase_1.0
  • 41. 特性(Feature)特征 概要需求 由系统提供的能直接满足干系者需要的、外部可见的服务。 逻辑上相关的功能需求的集合,给用户提供处理能力并满足业务需求。 对用户所期望的系统行为的高级表示(简称)。 对系统能力的非正式陈述,通常用于市场营销和产品定位。(c) www.zhangxun.comtaijiusecase_1.0
  • 42. 例/特性网店系统 可动态修改的购物车,容量最大 1000 件。 自动向客户发送订单动态消息 可在线支付 缺陷跟踪系统 可提供趋势图以便经理评估项目的状态 仓库管理系统 可动态提供所有存货的最新状态,最短每 5 分钟更新一次。(c) www.zhangxun.comtaijiusecase_1.0
  • 43. Part 2 用例基础软件需求的组成 什么是用例? 用例与其他需求的比较 用例的价值 (c) www.zhangxun.comtaijiusecase_1.0
  • 44. 什么是用例?针对某个特定的外部用角,系统通过与其交互而执行的,能够产生可观测的、有价值的结果的一个动作序列。(c) www.zhangxun.comtaijiusecase_1.0
  • 45. 用例的组成-1名称 简述 用角与干系者 层次 范围后态 前态 触发事件 (c) www.zhangxun.comtaijiusecase_1.0
  • 46. 用例的组成-2基本流 扩展流 扩展点用例图 业务规则 约束 UI 说明 变化点 …(c) www.zhangxun.comtaijiusecase_1.0
  • 47. 例/用例图(c) www.zhangxun.comtaijiusecase_1.0
  • 48. 下订单/简述顾客通过网店系统订购宠物,把选中的商品加入购物车; 登录后,下订单(含商品的种类、数量和价格,帐单地址、送货地址和信用卡等信息) 采取送货、信用卡支付方式。(c) www.zhangxun.comtaijiusecase_1.0
  • 49. 下订单/基本流/填写交易信息1. 系统显示该用户的缺省账单地址和送货地址,提供信用卡表单供用户填写。 2. 用户填写信用卡信息(卡类型、卡号和密码),并确认地址后提交。 3. 系统验证用户提交的交易信息(包括信用卡等)。 4. 系统显示完整的交易信息(包括用户已填写的信用卡信息)让用户确认。 5. 用户选择继续。(c) www.zhangxun.comtaijiusecase_1.0
  • 50. 下订单/扩展流/验证交易信息:填写交易信息/3 { // 验证 [变更送货地址] { 1. 系统显示空白的送货地址表单。 2. 用户输入新送货地址并提交。 3. 系统验证该送货地址。 RESUME } [信用卡信息无效] { … } }(c) www.zhangxun.comtaijiusecase_1.0
  • 51. Part 2 用例基础软件需求的组成 什么是用例? 用例与其他需求的比较  FR NFR 特性 用户故事 用例的价值 (c) www.zhangxun.comtaijiusecase_1.0
  • 52. 用例 vs FRFR Input 到 Output 的映射组合(用例) 通常描述比用例简单、笼统(简述、特性) 很多功能粒度小于用例,是用例的一些步骤。 用例 所有的用例名称都代表了一种功能 用例的主体是一种规范的、更为精确和细致的功能描述方法和形式 用例就是功能(大略的说法) 用例 = FR + NFR (c) www.zhangxun.comtaijiusecase_1.0
  • 53. 例/用例图(c) www.zhangxun.comtaijiusecase_1.0
  • 54. 用例 vs NFR用例 不是需求的全部 与每个用例有关的非功能(特殊)需求可以放在用例文本的格式模版中,与用例的动作功能描述形成互补。 NFR 在用例文本描述之外,制作一份单独的文档、表格或数据库,列举除了用例之外的所有其他软件需求(NFR、FURPS+、补充规约等) 。(c) www.zhangxun.comtaijiusecase_1.0
  • 55. 软件需求规约(SRS)(c) www.zhangxun.comtaijiusecase_1.0
  • 56. 软件需求的分类功能非功能特性XX用户故事XX用例XX(c) www.zhangxun.comtaijiusecase_1.0
  • 57. 用例 vs 特性特性 由系统提供的能直接满足干系者需要的、外部可见的服务。 通常是粗略、概要的功能描述 特性 = FR + NFR 用例 所有的用例名称都反映了一种功能特性 功能特性的详细行为描述 一个用例可包含、实现多个系统特性 功能特性与非功能特性的集合|容器。(c) www.zhangxun.comtaijiusecase_1.0
  • 58. 需求金字塔(c) www.zhangxun.comtaijiusecase_1.0
  • 59. 用户故事(User Story)主要在极限编程(XP)、Scrum 中使用 采用用户语言编写的简短需求描述(特性) 通常与验收测试(AT)配合使用 常用格式 As a , I want so that (c) www.zhangxun.comtaijiusecase_1.0
  • 60. 例/用户故事 1-3计算扣除额 工会费随工会而异,在每月的首次交付期内征取。系统自动计算扣除额,该数额显示在附表中。 透支转移支付 当交易导致客户账户透支时,从透支账户转移支付。 通知透支 当交易导致客户账户透支时,给客户发送电子邮件,说明交易情况和账户余额。 (c) www.zhangxun.comtaijiusecase_1.0
  • 61. 例/用户故事 4-5扣除会费 对于每个账户,合计所有的储蓄项目并减去扣除额,计算出余额。 生成交易报告 为每个账户生成一个交易报告,含交易日期、流水号、收款人及金额等。 引自 Ron Jeffries,《Extreme Programming Installed》 (c) www.zhangxun.comtaijiusecase_1.0
  • 62. 例/用例图-缴纳会费(c) www.zhangxun.comtaijiusecase_1.0
  • 63. 用例 vs 用户故事用户故事 轻型 类似于一段用例简述 许多用户故事的粒度 <= 用例,相当于用例基本流或扩展流中的步骤。 缺少足够的细节 用例 轻型 + 重型 细化的用户故事 可以包含多个用户故事(容器) 提供更完备的细节(c) www.zhangxun.comtaijiusecase_1.0
  • 64. Part 2 用例基础软件需求的组成 什么是用例? 用例与其他需求的比较 用例的价值 (c) www.zhangxun.comtaijiusecase_1.0
  • 65. 用例的价值以用户为中心 最重要的需求(功能) 图文并茂、繁简结合、形式灵活 全面的字段和信息 规范的模版 清晰的层次结构(c) www.zhangxun.comtaijiusecase_1.0
  • 66. 用例在软件开发中的核心地位 *(c) www.zhangxun.comtaijiusecase_1.0
  • 67. 用例驱动软件开发(c) www.zhangxun.comtaijiusecase_1.0
  • 68. Part 2 小结需求 = 用例 + NFR 系统特性、用户故事是粗略的需求。 用例既反映了系统需求的概要,又提供了大量的需求细节;用例 = FR + NFR。 用例是最重要的一种需求形式,消除需求不明确、不一致、不完整的重要手段和关键技术!(c) www.zhangxun.comtaijiusecase_1.0
  • 69. Part 3 用例建模太极建模口诀  需求工件 用例建模的步骤 宠物店用例模型 技巧和建议(c) www.zhangxun.comtaijiusecase_1.0
  • 70. 太极建模口诀由外而内, 层次分明; 动静结合, 逐步求精。(张恂 2006)(c) www.zhangxun.comtaijiusecase_1.0
  • 71. 太极建模口诀的用途应用领域 业务建模 需求建模 系统建模 架构设计 作用 指导设计、建模的流程、步骤 验证建模质量的全面性、正确性(c) www.zhangxun.comtaijiusecase_1.0
  • 72. 太极建模 - 1外部 内部(c) www.zhangxun.comtaijiusecase_1.0
  • 73. 由外而内-边界和范围外主内(以客户/用户为中心的设计) 自始至终抓住客户/用户目标 明确系统边界和讨论范围(c) www.zhangxun.comtaijiusecase_1.0
  • 74. 千层饼(c) www.zhangxun.comtaijiusecase_1.0
  • 75. 业务用例 vs. 软件用例(c) www.zhangxun.comtaijiusecase_1.0
  • 76. 宠物店/业务用例图(c) www.zhangxun.comtaijiusecase_1.0
  • 77. 宠物店/软件用例图(c) www.zhangxun.comtaijiusecase_1.0
  • 78. 太极建模 - 2高层 低层(c) www.zhangxun.comtaijiusecase_1.0
  • 79. 层次分明-软件架构(c) www.zhangxun.comtaijiusecase_1.0
  • 80. 需求金字塔(c) www.zhangxun.comtaijiusecase_1.0
  • 81. 用户目标|需求用例的层次(c) www.zhangxun.comtaijiusecase_1.0
  • 82. 用户目标层用例真正的用户目标 完成什么事情,让用户高兴? 粒度 通常 1 个主用角,一次性完成,< 几十分钟(c) www.zhangxun.comtaijiusecase_1.0
  • 83. 用例关系图-下订单(c) www.zhangxun.comtaijiusecase_1.0
  • 84. 太极建模 - 3动态 行为 静态 结构(c) www.zhangxun.comtaijiusecase_1.0
  • 85. 动静结合世界由物质组成,物质是运动的。 运动是绝对的,静止是相对的。 软件需求 = FR + NFR = 用例 + NFR UML(需求)模型 = 静态图 + 动态图 (c) www.zhangxun.comtaijiusecase_1.0
  • 86. 用例活动图-下订单(c) www.zhangxun.comtaijiusecase_1.0
  • 87. 领域类图-订单(c) www.zhangxun.comtaijiusecase_1.0
  • 88. 太极建模 - 4粗略 精细(c) www.zhangxun.comtaijiusecase_1.0
  • 89. 逐步求精精化(refine) 粗粒度  细粒度 用例简述 用例详述 业务需求分析  软件需求分析 系统分析  系统设计 OOA  OOD … (c) www.zhangxun.comtaijiusecase_1.0
  • 90. Part 3 用例建模太极建模口诀 需求工件  用例建模的步骤 宠物店用例模型 技巧和建议(c) www.zhangxun.comtaijiusecase_1.0
  • 91. 软件需求规约(SRS)(c) www.zhangxun.comtaijiusecase_1.0
  • 92. 软件需求工件 * (c) www.zhangxun.comtaijiusecase_1.0
  • 93. 需求工件-软件需求清单 *存放所有的软件需求,相当于需求目录,并对用例、特性等需求项根据风险、成本、价值等因素进行排序。编号需求类型简称/ 代码优先级需求全称概要说明用例高特性中约束低…(c) www.zhangxun.comtaijiusecase_1.0
  • 94. 软件需求集(c) www.zhangxun.comtaijiusecase_1.0
  • 95. Part 3 用例建模太极建模口诀 需求工件 用例建模的步骤  宠物店用例模型 技巧和建议(c) www.zhangxun.comtaijiusecase_1.0
  • 96. 用例分析流程提取用例 细化用例 优化模型(c) www.zhangxun.comtaijiusecase_1.0
  • 97. 用例的组成-1名称 简述 用角与干系者 层次 范围后态 前态 触发事件 (c) www.zhangxun.comtaijiusecase_1.0
  • 98. 用例的组成-2基本流 扩展流 扩展点用例图 业务规则 约束 UI 说明 变化点 …(c) www.zhangxun.comtaijiusecase_1.0
  • 99. 用例分析步骤/1-提取用例定义分析边界和范围 列出已知用角及其目标,绘制系统目标(用例边界)图。 {由外而内} 提取概要和用户目标层用例及其名称 {层次分明} 为每个用例编写简述 (c) www.zhangxun.comtaijiusecase_1.0
  • 100. 用例分析步骤/2-细化用例填写干系人责权利 填写后态和前态、触发事件 编写基本流 列出已知扩展条件,编写扩展处理步骤。 {逐步求精} 用 UML 动态图和静态图描述重点用例 {动静结合} 同时为用例配 UI 原型(c) www.zhangxun.comtaijiusecase_1.0
  • 101. 用例分析步骤/3-优化模型优化用例图 分解、合并用角,调整用角关系。 分解、合并用例,调整用例关系。 优化用例文本 (c) www.zhangxun.comtaijiusecase_1.0
  • 102. Part 3 用例建模/宠物店用例模型图形 系统概览图  系统目标图(用例边界) 用角关系图 用例关系图 文本 用例模版 文本用例(下订单)(c) www.zhangxun.comtaijiusecase_1.0
  • 103. 系统概览图(c) www.zhangxun.comtaijiusecase_1.0
  • 104. 系统目标(用例边界)图(c) www.zhangxun.comtaijiusecase_1.0
  • 105. 用例图技巧用例边界图的目的不是为了穷尽表示所有的用例。 在边界图中,一般不要放入低层次的用例,或描述其用例关系。 对于大量的用例,可以用包封装,或者放入概要层用例(或“管理…”类)用例中。 避免图中用例的数量或关系过多,模糊了重点。 (c) www.zhangxun.comtaijiusecase_1.0
  • 106. 用角关系图(c) www.zhangxun.comtaijiusecase_1.0
  • 107. 公共用例(c) www.zhangxun.comtaijiusecase_1.0
  • 108. 用例关系图-下订单(c) www.zhangxun.comtaijiusecase_1.0
  • 109. Part 3 用例建模/宠物店用例模型图形 系统概览图 系统目标图(用例边界) 用角关系图 用例关系图 文本 用例模版  文本用例(下订单)(c) www.zhangxun.comtaijiusecase_1.0
  • 110. 用例模版-1(c) www.zhangxun.comtaijiusecase_1.0
  • 111. 用例模版-2(c) www.zhangxun.comtaijiusecase_1.0
  • 112. 用例模版-3(c) www.zhangxun.comtaijiusecase_1.0
  • 113. 下订单/简述顾客通过网店系统订购宠物,把选中的商品加入购物车; 登录后,下订单(含商品的种类、数量和价格,帐单地址、送货地址和信用卡等信息); 采取送货、信用卡支付方式。(c) www.zhangxun.comtaijiusecase_1.0
  • 114. 下订单/干系者主用角:顾客(用户) 便捷、安全地订购宠物。 提供注册信息,信用卡、账单和送货地址。 提供商品种类和数量。 系统 提供购物车。 创建、验证、处理和保存订单。 调整系统状态。 提示出错信息。(c) www.zhangxun.comtaijiusecase_1.0
  • 115. 用例的主体(c) www.zhangxun.comtaijiusecase_1.0
  • 116. 下订单/后态最小保证 成功保证 保持用户状态为已登录。 保存了订单(包含用户名称、订单日期、商品名称、编号、数量、价格;用户信用卡信息、账单地址和送货地址)。 修改了商品存货(可售)数量。 清空了购物车。 失败保证 提示准确的出错信息(c) www.zhangxun.comtaijiusecase_1.0
  • 117. 下订单/前态前态 购物车非空 触发事件 用户选择结帐(c) www.zhangxun.comtaijiusecase_1.0
  • 118. 下订单/UI/购物车(c) www.zhangxun.comtaijiusecase_1.0
  • 119. 下订单/基本流清点商品 填写交易/支付信息 处理订单(c) www.zhangxun.comtaijiusecase_1.0
  • 120. 下订单/UI/确认购物清单(c) www.zhangxun.comtaijiusecase_1.0
  • 121. 下订单/基本流/清点商品1. 如用户尚未登录,CALL <登录->。 2. 系统显示购物汇总信息让用户确认。 3. 用户选择继续。 (c) www.zhangxun.comtaijiusecase_1.0
  • 122. 下订单/UI/填写支付信息(c) www.zhangxun.comtaijiusecase_1.0
  • 123. 下订单/UI/确认支付信息(c) www.zhangxun.comtaijiusecase_1.0
  • 124. 下订单/基本流/填写交易信息1. 系统显示该用户的缺省账单地址和送货地址,提供信用卡表单供用户填写。 2. 用户填写信用卡信息(卡类型、卡号和密码),并确认地址后提交。 3. 系统验证用户提交的交易信息(包括信用卡等)。 4. 系统显示完整的交易信息(包括用户已填写的信用卡信息)让用户确认。 5. 用户选择继续。(c) www.zhangxun.comtaijiusecase_1.0
  • 125. 下订单/UI/显示成功订单(c) www.zhangxun.comtaijiusecase_1.0
  • 126. 下订单/基本流/处理订单1. 系统创建新订单,并导入购物车中的内容。 2. 系统分配唯一的订单号,并在用户名下保存该订单,以便今后查询。 3. 系统根据订单中的所有条目,修改已订购商品的存货数量。 4. 系统清空购物车。 5. 系统显示订单成功的确认信息。(c) www.zhangxun.comtaijiusecase_1.0
  • 127. 下订单/扩展流/验证交易信息:填写交易信息/3 { // 验证 [变更送货地址] { 1. 系统显示空白的送货地址表单。 2. 用户输入新送货地址并提交。 3. 系统验证该送货地址。 RESUME } [信用卡信息无效] { … } }(c) www.zhangxun.comtaijiusecase_1.0
  • 128. Part 3 用例建模太极建模口诀 需求工件 用例建模的步骤 宠物店用例模型 小结:技巧和建议 (c) www.zhangxun.comtaijiusecase_1.0
  • 129. 用例建模技巧-1用例(动作内容)本身比用例关系更重要 内容重于形式 用例关系只是一种结构联系方式 注重意外、特殊情况的处理(扩展流) 建模的重点,项目开发的主要风险 系统可检测和处理的扩展条件 注意区分用例的范围和层次 加强用例的可读性 UI 原型有助于用例编写(c) www.zhangxun.comtaijiusecase_1.0
  • 130. 用例建模技巧-2从具象|具体逐步过渡到抽象,避免提前、过度泛化。 先具体,后抽象。 从用户角度出发,避免预先考虑设计和编程实现。 勿先入为主 勿脱离客户,随意作出假设和假定。 重要风险,不稳定的来源。 勿忘辅助、维护型用例。(c) www.zhangxun.comtaijiusecase_1.0
  • 131. 用例的本质-1(c) www.zhangxun.comtaijiusecase_1.0
  • 132. 什么是用例?(Cockburn)代表了系统干系者之间的一个行为契约。 描述了系统在响应主用角的某个请求时,在不同情况下所采取的各种行为和交互,展现了该主用角的目标如何成功实现或失败。 汇集了与实现该主用角目标相关的所有执行情节(scenarios)。 (c) www.zhangxun.comtaijiusecase_1.0
  • 133. 用例的本质-2(c) www.zhangxun.comtaijiusecase_1.0
  • 134. 用例 vs. 功能分解不同于、优于传统结构化功能分解 有效表达用户的任务目标层次 详细完整反映使用软件功能的实例和情节 交互行为序列 显著强调了用户和系统行为的特殊执行情况 扩展条件和各种约束 异常事件流 测例和 UI 设计的最佳来源(c) www.zhangxun.comtaijiusecase_1.0
  • 135. 太极建模口诀由外而内 系统边界 层次分明 用户目标,真正的用例! 动静结合 FR/UC + NFR 逐步求精 先图形,后文本。(c) www.zhangxun.comtaijiusecase_1.0
  • 136. 需求工程最佳实践-1明确构想和范围 确立需求开发过程 用户群分类 选定产品代表 建立用户核心队伍 建立用例模型 分析业务流程 明确质量属性(c) www.zhangxun.comtaijiusecase_1.0
  • 137. 需求工程最佳实践-2绘制 Context 图 尽早建立原型 分析可行性 明确优先级 建立可视化模型 编写术语/词汇表和数据字典 定期检查问题和风险清单 演进式开发 重用需求(c) www.zhangxun.comtaijiusecase_1.0
  • 138. 参考资源更多软件需求分析和用例建模学习资源 www.zhangxun.com/usecase OMG UML ® www.uml.org IBM RUP ® http://www-01.ibm.com/software/awdtools/rup/ Spring JPetStore www.springsource.org/download (c) www.zhangxun.comtaijiusecase_1.0
  • 139. 谢 谢!