第六七章　需求验证需求管理.ppt

* 建议的需求状态表 状态值 定 义 已建议 该需求已被有权提出需求的人建议 已批准 该需求已被分析，估计了其对项目余下部分的影响（包括成本和对项目其余部分的干扰），已用一个确定的产品版本号或创建编号分配到相关的基线中，软件开发团队已同意实现该项需求 已设计 与该需求对应的设计元素已经创建并且已被审查 已实现 已实现需求代码的设计、编写和单元测试 已验证 使用所选择的方法已验证了实现的需求，例如测试和检测，审查该需求跟踪与测试用例相符。该需求现在被认为完成 已提交 已经移交到用户，用于beta测试 已删除 计划的需求已从基线中删除，但包括一个原因说明和做出删除决定的人员 已拒绝 计划的需求已经确定不用 第七章总结 需求管理的含义 需求管理包含哪4个部分，每个部分的简单过程如何？ 需求基线的含义 可能的需求状态有哪些？ * * * * * * * * * * * * * * * * * * * * * * * * * * * * * -*- 模型检测 模型检测是有限状态并发系统的形式化确认/验证方法。 系统的规范被表示为时态/时序逻辑公式, 利用高效的符号化算法检查系统定义的模型，检测规范是否成立。 大规模状态空间通常可以在数分钟内遍历完。 该技术已经被用于许多复杂的工业系统。 -*- 系统的模型验证是验证过程的基本部分。 模型验证的目标 实例验证每个模型是自身一致的 是否存在系统的某些模型，实例验证他们是内部/外部一致的 实例验证模型准确反映系统相关者的现实需求 某些检测可能利用自动化工具实现 模型的解释和释义是有效的检测技术 逻辑分析: 模型验证 -*- 模型检测 -*- 测试 -*- 测试 测试 与运行和观测产品行为有关 可以被理解为动态确认/验证 系统执行测试数据，观测操作行为 需求规范 测试用例 软件测试 测试报告 -*- 缺陷测试 用于发现系统缺陷. 成功的缺陷测试能够发现系统中的缺陷的存在. 统计测试 用于反映用户输入的频率. 用于可靠性评估. 测试的类型 -*- 需求标识 相关需求 当测试与这些需求相关，则应该提及. 测试描述 测试的概要描述，为何成为一个目标需求测试. 需求问题 使得测试定义困难或不可能的问题描述. 评论与建议 发现的需求问题的解决建议. 需求测试记录表 -*- 系统需求 系统需求是一个整体. 当他们可能被某一功能性需求影响时，即使忽略采用的具体方法，存在最困难的需求验证。不能执行的测试，不能测试系统特性. 额外需求 存在超过特定行为的额外需求. 例如，一个需求可能说明：系统故障一定不会影响系统数据库，不可能彻底的测试这样一个需求. 某些非功能性需求 某些非功能性需求, （如可靠性需求）不能通过大规模测试集测试. 设计这样的测试集不会有助于需求验证. 难以测试困难的需求 原型/仿真系统 -*- 需求验证的原型可以实例证明需求，并帮助相关者发现问题。 验证原型应该是完备的、相当有效的、鲁棒性的. 应该可以将原型以同样方式用于需求系统中。 应该提供用户文档和培训。 原型/仿真 第六章总结 需求验证和确认的含义和目标 需求验证和需求确认的技术有哪些？ 需求审查 检查 走查 模型检测（一种形式化方法） 建立原型/仿真系统 测试 -*- 课程内容 §1. 软件需求的基本概念 §2. 需求工程概述 §3. 需求获取 §4. 需求分析与建模 §5. 需求规范说明 §6. 需求验证 §7. 需求管理 §7. 需求管理 什么是需求管理? 需求管理活动 什么是需求管理? 需求管理 需求管理是组织和追踪需求; 需求管理具有如下特征 不仅仅是软件开发的前端活动 是贯穿整个软件生命周期 可以帮助尽早发现错误,进而节省开发经费 越复杂的系统越需要对需求进行管理 提出需求变更 分析变更影响 作决策 更新需求文档 更新研发计划 度量需求的易变性 定义版本识别策 识别需求文档版本 识别单个需求版本 定义所有可能的需求状态 记录每个需求的当前状态 报告所有需求的状态分布 定义需求之间的关联 定义需求到其他系统开发元素的关联 需求变更控制 需求版本控制 需求状态追踪 需求追踪 需求管理 需求基线 需求基线是开发团队在当前阶段达成统一认识的、要实现的功能性和非功能性需求集合。 基 线 达成共同理解 配置管理 变化控制过程 不同观点 没有正式的文档 总是在变化之中 需求管理活动 需求管理活动 定义需求基线（迅速制定需求文档的主体） 评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它 以一种可控制的方式将需求变更融入到项目中 使当前的项目计划与需求一致 需求管理活动 估计变更需求所产生影响并在此基础上协商新的承诺（约定） 让每项需求都能与其对应的设计、源代码和测试用例联系