软件需求用例分析-张恂.PPT

(c) taijiusecase_1.0 软件需求用例分析 自我介绍 资深软件工程顾问和教练 软件需求和用例分析专家 1998 开始研究 UML、Use Case、RUP 2003 统一用例方法 2006 太极建模口诀 他们行，你也能行 - 用例 UML 应用 省级税务系统 证券公司核心客服系统 全国范围的保险核心业务系统 制造业电子商务、贸易系统 电信级帐务、计费系统 企业级呼叫中心系统 人力资源服务核心业务系统 大型互联网门户网站 … 演讲大纲-Part 1 需求难题 什么是需求？ 常见的需求问题 如何破解需求难题？ 演讲大纲-Part 2 用例基础 软件需求的组成 什么是用例？ 用例的组成 用例的价值 用例与特性、用户故事和非功能需求的区别与联系? 演讲大纲-Part 3 用例建模 太极建模口诀 用例建模的步骤 用例图 用例模版 宠物店用例模型案例 需求用例分析的技巧和建议 太极建模 Part1 需求难题 什么是需求？ 常见的需求问题 如何破解需求难题？ 什么是需求？ 需求 需求的定义 IEEE 97 用户解决问题或达到目标所需的条件或能力。 系统或其部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力。 A. Davis 93 从系统外部能发现的，系统所具有的满足于用户的特点、功能及属性等。 UML 系统的一个期望特性、属性或行为。 需求是软件开发的上游 需求关系到所有人 * 常见的需求现象-1 用户提出的需求不完整、不准确。 需求经常变化，工作没完没了。 开发后期才发现误解了需求，开发人员被迫大量加班，修修补补。 功能都实现了，但由于性能、使用方面的问题导致用户不满。 常见的需求现象-2 客户的许多增强要求未及早提出，导致软件后期维护费用陡升。 测试效果差，测试人员不明白软件要做什么 勉强交付了客户并不满意的产品 … 常见的需求问题 需求不完整，太粗略，遗漏关键信息。 频繁、大量的需求变更|变化 用户不积极参与 模棱两可、含糊的需求 “锦上添花”的需求 忽略了用户分类 … 低质量需求的后果 遗漏需求 项目计划、估算错误 影响进度 需求不准 返工 增加成本 需求错误的成本 各阶段修复需求错误的成本比（Boehm 1998）: 需求 (0.5-1) 设计 (2.5) 编码 (5) 单元测试 (10) 验收测试 (25) 维护 (100) 需求错误的影响 据国外研究统计 软件项目中 40% 到 60% 的问题都是在需求分析阶段埋下的隐患。 返工开销占开发总费用的 40% ，而 70-80%的返工是由需求方面的错误所导致的。 解决之道 – 需求工程 科学的 系统的 规范的 经济的 人本的 需求工程的价值 目标 – 高质量的需求 软件开发的本质 – 确定性|不确定性 难题 – 预测需求变化 需求变化 – 合理的原因 用户不了解自己的需求 用户不是 IT 专家 没有实物，需求很抽象，空想。 需求本身易变 市场变化 技术变化 竞争变化 … 需求变化 – 不合理的原因 客户沟通问题 理解错误 业务不清、不熟悉 需求文档质量不高 缺乏预见性 遗漏关键信息 需求分析技能、技术缺陷 需求管理缺陷 变更控制 … Part1 小结 Part 2 用例基础 软件需求的组成 ? 什么是用例？ 用例与其他需求的比较 用例的价值? 软件需求的种类 业务需求、业务规则 特性|特征 用例（功能）需求 质量属性 外部接口（协议） 各种约束 解决方案约束（对设计、实现的限制） 数据需求 软件需求 – 功能|非功能 FR（Functional Requirements） 1）系统输入到输出的映射及其组合； 2）系统外部可见的行为需求。 与用户任务、目标、用例、服务、特性相关 一般可通过描述系统的输入、输出、功能、系统的属性和系统环境的属性来完整地描述软件需求。 NFR（Non-Functional Requirements） 质量属性 业务规则 约束（对解决方案自由度的限制） 约束源包括：经济、行政、技术、环境（标准、法律、安全）、进度、资源、战略、业务运作、合同等等。 NFR-软件|系统质量属性 有效性 效率|性能 灵活性 完整性 互操作性 可靠性 健壮性 易用性 可用性 可维护性 可移植性 可重用性 可测试性 … FURPS+ (Grady 1992)/1 功能（Functionality） 特性集、能力、通用性、安全性等等。 易用性（Usability） 人性因素、美学、一致性、文档等等。 可靠性（Reliability） 失效频度/严重性、可恢复性、可预测性、精确性、MTBF 等等。 FURPS+/2 性能（Performance） 速度、效率、资源使用、吞吐量、应答时间等等 可支持性（Supportabil