第16章.需求验证.pptVIP

第16章.需求验证 主要内容 验证与确认 需求验证 需求验证方法 问题修正 需求验证的实践调查 1. 验证与确认——概念 需求验证：以正确的方式建立需求 需求集是正确的、完备的和一致的； 技术上是可解决的； 它们在现实世界中的满足是可行的和可验证的。 需求确认：建立的需求是正确的 每一条需求都是符合用户原意的 系统验证：正确的建立系统 系统能够在预期的环境中正确的执行设定的功能。 系统确认：建立的系统是正确的 建立的系统是符合系统需求和系统设计的 1. 验证与确认——软件工程的验证与确认 主要内容 验证与确认 需求验证 需求验证方法 问题修正 需求验证的实践调查 2. 需求验证——概念 验证普遍存在 获得的用户需求是否正确和充分的支持业务需求？ 建立的分析模型是否正确的反映了问题域特性和需求？细化的系统需求是否充分和正确的支持用户需求？ 需求规格说明文档是否组织良好、书写正确？需求规格说明文档内的需求是否充分和正确的反映了涉众的意图？需求规格说明文档是否可以作为后续开发工作（设计、实现、测试等等）的基础？ 需求验证是专指在需求规格说明完成之后，对需求规格说明文档进行的验证活动 2. 需求验证——活动 主要内容 验证与确认 需求验证 需求验证方法 评审 原型与模拟 开发测试用例 用户手册编制 利用跟踪关系 自动化分析 问题修正 需求验证的实践调查 3.1 评审 由作者之外的其他人来检查产品问题的方法 是主要的静态分析手段 原则上，每一条需求都应该进行评审 3.1 评审——参与人员 3.1 评审——过程 3.1 评审——检查方法 检查方法 描述 自由方法（Ad-hoc） 没有为检查人员提供系统化的引导 检查清单（Checklist-Based） 以通用的检查清单来引导检查过程 缺陷（Defect-Based） 用于需求文档，根据缺陷的分类来组织和检查场景 功能点（Function Point-Based） 按照功能点来组织和检查场景 视角（Perspective-Based） 按照不同涉众类型的视角来组织和检查场景 场景（Scenario-Based） 对每一个场景，都利用一系列的问题或者细节要求，来引导检查过程。缺陷、功能点、视角都是场景方法的一个特例。 逐步提升（Stepwise Abstraction） 净室软件开发中的一种方法。阅读者描述一些独立代码段的功能，然后将描述的范围逐步扩大，描述的功能抽象逐步提高，直至阅读人员描述了整个评审物件 3.1 评审——类型 3.2 原型与模拟 涉及到复杂的动态行为时 成本较高 3.3 开发测试用例 如果无法为某条需求定义完备的测试用例，那么它可能就存在着模糊、信息遗漏、不正确等缺陷 例外 排斥性需求（Exclusive Requirements） 这种需求要求特定的行为绝对不会发生，例如需求可能会要求系统故障不能导致数据库的崩溃 全局性非功能性需求（Global Non-Functional Requirements） 例如可靠性、可用性等，对这些需求的测试往往都是大数据集的处理 开发系统测试用例 （1）以需求为线索，开发测试用例套件； （2）使用测试技术确定输入/输出数据，开发测试用例。 测试用例套件 基于用例描述，可以为销售处理确定测试用例套件 测试用例套件 覆盖流程 TUS1 正常流程 3a 3b 5-8a TUS2 正常流程 1a 9a 11a TUS3 正常流程 5-8b 建立测试用 主要是基于规格的技术，设计测试场景的输入与输出数据 ID 输入 预期输出 商品信息 特价 赠品 支付 TUS1-1 无商品 无 无 无 不做任何处理，关闭销售任务 TUS1-2 商品1（1、1(双)、35）商品2（2、1(双)、50） 无 无 TUS1-3 商品1（1、1(双)、35）商品2（2、1(双)、50） 无 无 85 无找零，系统行为满足后置条件 TUS1-4 商品1（1、1(双)、35）商品2（2、1(双)、50） 商品1特价20 ? 100 找零30，系统行为满足后置条件 TUS1-5 商品1（1、1(双)、35）商品2（2、1(双)、50） 总额特价50以上0.8折 ? 100 找零31，系统行为满足后置条件 TUS1-6 商品1（1、1(双)、35）商品2（2、1(双)、60） 商品1特价20总额特价50以上0.8折 100 找零32，系统行为满足后置条件 …… …… 3.4 用户手册编制 验证功能需求 对软件系统功能和实现的描述 验证项目范围 对系统没有实现的功能的描述 验证异常流程需求 问题和故障的解决 验证环境与约束需求 系统的安装和启动 3.5利用跟踪关系 业务需求?用户需求?系统需求 如果业务需求和用户需求没有得到后项需求（用户需求和系