Ch07——中文.pptVIP

软件工程，实践者的研究方法, 6/e 第七章需求工程 需求工程-I 起始—询问一系列问题，以便构造 … 问题的基本认识 方案需求方 期望方案的本质 客户和开发人员之间初步交流和合作的效果 导出—从所有的共利益者获取需求 （elicit：导出/引起） 精化—构造了一个分析模型，识别了数据、方法与行为需求 协商—在一个对于开发者和客户都比较现实的系统上达成一致 需求工程-II 规范—可以是下列任何一个（或多个) 一个书面文档 一组形式化模型 一个形式化数学方法 一组用户场景 (用户案例) 一个原型 验证—一个评审机制,寻找 内容或解释中的错误 当需要更清晰化的领域 缺失信息 不一致性 (当构造大的产品和系统时) 冲突或非现实的需求 (难以实现的) 需求 需求管理 起始 识别共利益者 “你认为还需要和其他什么人谈” 识别多种观点 协同工作 首次提问 谁是这项工作的最初提出者? 谁将使用这个解决方案? 成功的解决方案将带来什么样的经济效益？ 存在别的解决方案吗? 导出需求 会议由软件工程师和客户共同举办和参与 制定筹备和参与会议的议程 建议拟定一个会议议程 由一个“主持人” (可以是一个客户，一个开发人员或者是其他外人) 主持会议。 使用某种 “定义机制” (可以是工作表，活动挂图，不干胶贴纸或电子公告牌，聊天室或虚拟论坛） 目标是 识别问题 提出解决问题的方案要素 协商不同的方法，且 初步刻画需求问题的解决方案 导出需求 质量功能部署 功能部署 确定 (客户感知)系统所需的每个功能的价值。 信息部署 系统必须使用和产生的数据对象和事件 任务部署 检查了系统的动态行为 价值分析 用于确定三个部署（需求）中的相对优先级 导出工作产品 需求和可行性描述 系统或产品范围的界限说明 参与导出需求的客户、用户和其他共同利益者的列表 系统的技术环境说明 需求列表 (按照功能加以组织)以及每个需求适用的领域限制。 一系列使用场景，有助于深入了解系统或产品爱不同运行环境下的使用 任何能够更好地定义需求的原型。 所有参与导出需求的人员需要评审这些工作产品。 用例 一个用户场景集合，描述了一个系统的使用线索 每个场景通过一个“参与者”的视角来描述—与软件系统以某种方式交互的一个人/设备 每个场景需要回答下面几个问题: 谁是主要参与者，次要参与者? 参与者的目标是什么? 故事开始前有什么前提条件? 参与者完成的主要工作或功能是什么? 按照故事所描述的，可能还需要考虑哪些扩充? 参与者的交互中可能会有哪些变化(alternative交互流程)? 参与者将获得，产生和改变哪些系统信息(状态变更)? 参与者必须通知系统外部环境的改变吗？ 参与者希望从系统获取什么信息？ 参与者希望得知意料之外的变更吗？ 用例图 构造分析模型 分析模型元素 基于场景的元素 功能性的—processing narratives for software functions（活动图） 用例—descriptions of the interaction between an “actor” and the system 基于类的元素 Implied by scenarios 行为元素 状态图 基于流的元素 Data flow diagram 类图 状态图 分析模式 协商需求 识别系统或子系统关键的共利益者 参与协商人员名单 确定每个共利益者 “赢”的条件 “赢”的条件并不总是显式的 协商 面向那些可以双赢的需求 确认需求-I 每个需求都和系统/产品的整体目标一致吗? 所有的需求都已经在恰当的抽象层上说明了吗? 需求是真正需要的，还是另外加上去的，有可能不是系统目标所必需的特性吗？ 每个需求都有界定且无歧义吗？ 每个需求都有归属吗？即每个需求都标记了一个来源 (通常是一个特定的个人)? 有需求和其他需求冲突吗? 确认需求——II 在系统或产品所处的技术环境下，每个需求都能够实现吗？ 当需求被实现后，是否所有的需求都可被测试？ 需求模型恰当地反映了将要构建系统的信息、功能和行为吗？ 需求是否已经使用合适的方法“分割”，能够逐步地揭示详细的系统信息？ 已经使用需求模式简化需求模型吗？所有的模式都已经被恰当地确认了吗？所有的模式都和客户的需求一致吗？ These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman Associates, Inc.,