软件需求工程第三章　需求获取.pptVIP

-*- 用例驱动的软件开发生命周期 -*- 用例 什么是 “用例”? 场景 什么是“场景”? 用例 vs. 场景 场景类型 场景的表示方法 用例驱动的软件开发方法 开发用例 用例模板 -*- 用例的开发 1. 确定待开发系统的范畴和边界 确定涉众 确定问题 使用面谈或者其他技术 -*- 用例的开发 2. 确定角色 谁和系统交互? 谁使用系统? 使用系统目的? 充当的角色? 谁安装系统? 谁启动或者关闭系统? 谁维护系统? 谁向系统获取/提供信息? 可以对角色进行通用化 -*- 用例的开发 3. 确定用例 确定角色的目标 为什么该角色使用系统? 确定角色为了达到目标要做的任务 什么样的交互可以满足角色的目标? 选择合适的用例名称 动-名结构 不用包含特定情形的数据 不与组织结构、格式、实现相关联 生成简单描述（依据叙述格式） -*- 用例的开发 4. 确定前提条件 启动本用例应满足的条件 5. 确定后置条件 完成本用例后所满足的条件 -*- 用例的开发 5. 定义主场景 当系统正常运行时的情形 6. 定义辅助场景 (可选/异常) 可选场景：其他可能的路径 异常场景：出错情形 -*- 用例图（用例之间关系） 7. Structure use case diagram Identify commonalities and specify included use cases Identify variants and specify extended use cases -*- 用例 什么是 “用例”? 场景 什么是“场景”? 用例 vs. 场景 场景类型 场景的表示方法 用例驱动的软件开发方法 开发用例 用例模板 -*- 用例模板 有不同形式的用例模板，通常包含如下内容: 标识: 可以在其他地方应用的唯一标识 名字: 清晰表述用户任务 作者: 发现用例的人 目标: 简单描述从用户角度期望的输出 前提条件: 在启动本用例前应满足的条件 后置条件: 完成此用例后的状态 -*- 用例模板 主角色: 初始化用例 参加人(辅助角色): 用例中涉及到的其他角色 相关联的需求: 与本用例向关联的功能性和非功能性需求标识 相关联的用例，并指明相互之间的关系 事件描述 (场景) 不同的用例描述方式 叙述式, 单栏式, 多栏式 -*- 用例模板：叙述式 -*- 用例模板：单栏式 -*- 用例模板：多栏式 -*- Example 用例模板：内容 -*- §3.3 需求获取技术 已经介绍5种需求获取技术 分析已有系统 面谈 头脑风暴 原型系统 用例 -*- 选择需求获取技术 初始阶段: 获得初始需求 面谈 调查问卷 观察 审查文档 跟进阶段: 理解需求 面谈 用例和场景 头脑风暴 精化阶段 原型 故事板 …….. -*- 结束需求获取 -*- 对获取需求的检查列表 是否每个需求都必要? 是否每个需求都和系统目标一致? 是否需求之间相互冲突? 是否采用合适的抽象层次来描述每个需求? 是否每个需求都有意义? 是否每个需求都是在范围内且无二义性? 是否每个需求都可以测试? -*- 何时结束需求获取？ 如果用户再也想不到更多的用例, 如果用户提出的新用例，其功能可以从已经定义的用例中派生出来 如果用户不断重复在前面讨论中已经提到的问题 如果所提到的新特征、功能、用户需求都超出系统边界范围 如果提出的新需求都是低优先级的 如果用户提出的系统能力不是当前系统应包含的，而是今后产品应包含的 -*- 需求获取的输出 需求获取记录 问题域的描述 已经解决的问题列表 (需求) 任何客户对系统结构和行为提出的约束条件 通常是未处理的、非结构化的，同时可能还包含无关的信息 通常作为临时文档，但是对于审查和追踪非常有用！ -*- 第三章总结 需求启动的任务和应生成的文档 需求获取的任务、目标、内容、输出和信息源 需求获取技术（相关概念、过程、适用条件） 分析已有文档 面谈 头脑风暴 原型系统 (种类) 用例（两个概念：用例和场景） 何时结束需求获取？ -*- -*- §3.2 需求获取的任务 需求获取的信息源（从哪里获取需求？） 各种涉众：客户、用户、经理、领域专家、开发人员、市场人员、律师、…… 已经存在的系统 已经有的文档 竞争系统 关于用户接口的文档 相关的（行业）标准、政策、协议、法律文件等 … -*- 如何获取需求？ 需求获取技术 传统技术 其他技术 阅读已有文档 分析数据 面谈 调研/ 调查问卷 会议 头脑风暴 联合应用设计 (JAD) 原型系统 用例 -*- 第三章 需求获取 §3.1 需求启动 §3.2 需求获取的任务 §3.3 需求获取技术 -*- §3.3 需求获取技术 分析已有系统 面谈 头脑风暴 原型系统 用例 -*- 分析已有系