基于UML 20掌握面向对象的分析和设计1.ppt

Mastering Object-Oriented Analysis and Design with UML 2.0 需求分析 内容提要 内容提要 软件需求 软件需求 软件需求 没有不变的需求，世上的软件都改动过3次以上，唯一一个只改动过两次的软件的拥有者已经死了，死在去修改需求的路上 软件需求 软件需求 优秀的团队遇到糟糕的需求 用户参与不足 用户需求扩展 有歧义的需求 镀金问题 过于抽象的需求 忽略了某类用户 不准确的计划 软件需求 优秀需求的特点 完整性 正确性 可行性 必要性 有优先次序 无歧义 可验证性 软件需求 前景与范围文档的模板 1.业务需求 背景 业务机遇 业务目标与成功标准 客户与市场需求 业务风险 2.解决方案的前景 前景声明 主要特征 假设与依赖 3.范围与限制 第一版本的范围 各后续版本的范围 限制与排除 4.业务背景 涉及简介 项目优先级 操作环境 软件需求 获取客户的需求 需求的来源 与潜在用户进行交谈和讨论 描述现有产品或竞争产品的文档 系统需求规格说明 现有系统的问题报告和改进要求 市场调查和用户问卷调查 观察用户如何工作 用户工作的情景分析 事件和响应 区分用户 使用产品的频率 用户在应用领域的经验和使用计算机系统的技能 所用到的产品功能 为支持业务过程所进行的工作 访问权限和安全级别 软件需求 聆听客户的需求 需求获取讨论会 建立基本规则 按时开始和结束会议 中途休息之后要尽快进入状态 一次只进行一种谈话 期望每个人都为讨论会做出自己的贡献 要关注对问题而不是对人的评论和批评 使用活动挂图来捕获以后再考虑的一些条目 时间盒讨论 保持较小的团队规模并找到合适的参与者 确保每个人都积极地参与讨论 将客户的意见归类 业务需求、用例或场景、业务规则、功能性需求、持量属性、外部接口需求、数据定义以及解决思路等等 软件需求 寻找遗漏的需求 将高层的需求分解得足够细，让用户的真正需求显露出来。避免使用不精确和模糊的词语，包括：支持、使能够、允许、处理和管理 务必让所有的用户都提出他们的意见。确保每个用例都至少有一个确定的执行者 跟踪系统需求、用例、事件-响应表以及业务规则，直至其详细的功能性需求，确保需求分析员推导出了所有必需的功能 检查边界值，查找被遗漏的需求 用多种方法表达需求信息 包括复杂的布尔逻辑的需求常常是不完整的 CRUDL矩阵 软件需求 如何判断需求获取是否已完成 如果用户想不出更多的用例时，因为用户往往是按重要性递减的顺序来确定用例 如果用户提出新的用例，而已经从其他用例中推导出了这一用例的相关功能性需求 如果用户只是重复他们在以前的讨论中已经提过的问题 如果被提出的新特性、用户需求或功能性需求都在范围之外 如果被提出的新需求优先级都很低 如果用户提出的新功能都是可以“在产品生命周期的某个时刻”加入，而不“属于我们当前正在讨论的特定产品” 为项目列出一个清单，列出需要考虑的标准功能需求，例如：记录错误日志、备份与恢复、访问安全、报告、打印、预览功能以及设置用户偏好等。然后定期对照这张清单比较已定义的功能是。如果没有发现差异，工作也许已经完成了。 内容提要 需求整理 需求整理的方法 用例法 用户故事 产品特性 IEEE … 需求整理 需求整理 需求整理 Demo: 查看“课程注册系统”的问题描述： 需求整理 用例模型 Actor用来描述系统的使用者，即系统为其带来利益的对象 use case是一套操作序列的集合，为Actor提供一种可见的结果 需求整理 用例模型 用例模型通过Use Cases描述了系统的功能性需求，不适合捕获非功能性需求 对于非功能性需求部分形成文字在“补充规约”的部分加以记录 需求整理 用例模型的用处 沟通、交流 定义 确认 需求整理 用例图 需求整理 用例规约(RUP格式) 名称 概述 事件流 关联 活动图 用例图 特殊需求 前置条件 后置条件 其它图 需求整理 用例规约(Alistair Cockburn版) 名称 范围 涉众与利益 主执行者 层次 前景条件、触发事件和保证 主成功场景和步骤 扩展 可变情况 需求整理 范围 列出每一个用例的设计范围，对最重要的范围使用专用的名称。 企业。 在陈述主执行者的目标时，我们将讨论整个组织或企业的行为 系统。 这是我们将负责建立的硬件或软件部分。系统之外是将与系统进行交互的所有的硬件、软件和人员。 子系统。 已经打开主系统，并打算讨论它的某一部分是如何工作的。 需求整理 层次 三个命名的目标层次 用户目标级(蓝色，海平面 ) 概要层次(白色，云朵 ，风筝 ) 子功能(靛青色/黑色，海平面以下