软件工程教学课件chapter-05教学材料.pptVIP

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. * 第5章 理解需求 * 起始 确认利益相关者 “你认为我还应该和谁交谈” 识别多重观点 协同合作 首次提问 谁是这项工作的最初的请求者？ 谁将使用该解决方案 成功的解决方案将带来什么样的经济效益? 对于这个解决方案你还需要其他资源吗？ * 导出需求 会议由软件工程师和利益相关者共同举办和参与 制定筹备和参与会议的规则 建议拟定一个会议议程 由一个“调解人”（可以是客户，开发人员或其他人）控制会议 采用“方案论证手段”（可以是工作表、活动挂图、不干胶贴纸或电子公告牌、聊天室或虚拟论坛）。 目的是 识别问题 提出问题解决方案 协商不同的方法 确定一套解决需求问题的初步方案 * 导出需求 导出需求 召开会议 列出工能、类 列出约束等 形式地划分优先级？ 非形式地划分需求的优先级 使用QFD划分需求的优先级 生成用例 绘制用例图 完成模版 编写场景 确定参与者 * 质量功能部署 功能部署决定系统所需的每一个功能的“价值”（由客户感知） 信息部署确定数据对象和事件 任务部署检查系统行为 价值分析决定需求的相对优先权 * 导出工作产品 要求和可行性陈述。 系统或产品范围的界限说明。 参与需求导出的客户、用户和其他利益相关者的名单。 系统技术环境的说明。 需求列表（最好按照功能加以组织）以及每个需求使用的领域限制。 一系列使用场景，有助于深入了解系统或产品在不同运行环境下的使用。 任何能够更好地定义需求的原型。 * 构建需求模型 分析模型的元素 基于场景的元素 功能说明——处理软件功能的描述 用例——描述“参与者”和系统之间的交互作用 基于类的元素 由场景暗示 行为元素 状态图 面向数据流元素 数据流图 * 用例 一组用户场景，描述系统的线程使用 从“参与者”的点-视角来描述每一个场景——人或设备以某种方式与软件交互 每一个场景回答以下问题： 谁是主要参与者、次要参与者？ 参与者的目标是什么？ 故事开始前有什么前提条件？ 参与者完成的主要工作或功能是什么？ 按照故事所描述的还可能需要考虑什么异常？ 参与者的交互中有什么可能的变化？ 参与者将获得、产生或改变哪些系统信息？ 参与者必须通知系统有关外部环境的改变吗？ 参与者希望从系统获取什么信息？ * 用例图 房主 安装/接触系统 通过因特网访问系统 报警事件的响应 遇到错误条件 重新配置传感器以及相关的系统特性 传感器 系统管理员 * 类图 从SafeHome 系统… 传感器 * 状态图 Reading Commands System status = “ready” Display msg = “enter cmd” Display status = steady Entry/subsystems ready Do: poll user input panel Do: read user input Do: interpret user input State name State variables State activities 状态名 状态变量 状态活动 读指令 * 分析模式 模式名称： 捕获模式本质的描述符。 目的： 描述该模式实现了或代表什么。 动机： 说明怎样用模式解决问题的一个场景。 影响环境： 对外部问题（影响）的描述，即能够影响如何使用模式，并当应用该模式时，影响即将被解决的外部问题。 解决方案：对如何应用模式来解决强调结构和行为问题的描述。 效果： 解决了发生在应用模式时和应用过程中存在权衡的问题。 设计： 通过使用已知的设计模式讨论如何实现该分析模式。 已知应用: 在实际系统中使用的例子。 相关模式：与命名模式有关的一个或更多分析模式，因为(1) 与命名模式共同使用；(2) 在结构上，与命名模式相似；(3) 是命名模式的一个变化。 * 协商需求 确定关键的利益相关者 是即将参与协商的人 确定每个利益相关者“赢”的条件 赢的条件并不总是显而易见的 协商 致力于导致“双赢”的一组需求 * 确认需求- I 每项需求都和系统或产品的整体目标一致吗？ 所有的需求都已经在相应的抽象层上说明了吗？换句话说，是否有一些需求是在技术细节过多的层次上提出的，并不适合当前的阶段。 需求是真正必须的，还是另外加上去的，有可能不是系统目标所必须的特性吗？ 每项需求都有界定且无歧义吗？ 每项需求都有归属权吗？换句话说，是否每个需求都标记了来源（通常是一个