《软件需求分析》第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） 例如可靠性、可用性等，对这些需求的测试往往都是大数据集的处理 3.4 用户手册编制 验证功能需求 对软件系统功能和实现的描述 验证项目范围 对系统没有实现的功能的描述 验证异常流程需求 问题和故障的解决 验证环境与约束需求 系统的安装和启动 3.5利用跟踪关系 业务需求?用户需求?系统需求 如果业务需求和用户需求没有得到后项需求（用户需求和系统需求）的充分支持，那么软件需求规格说明文档就存在不完备的缺陷。 系统需求?用户需求?业务需求 如果不能依据跟踪关系找到一条系统需求的前项用户需求和前项业务需求，那么该需求就属于非必要的需求。 3.6自动化分析 主要内容 验证与确认 需求验证 需求验证方法 问题修正 需求验证的实践调查 4. 问题修正 需求澄清（Requirements Clarification） 理解偏差：重新进行分析工作 分析遗漏：重新分析和文档化这部分信息 表达不当：重新以合适的方式表达 缺失需求 重新执行需求获取等一系列工作 需求冲突 协商解决 不切实际的期望 项目调整与需求协商 主要内容 验证与确认 需求验证 需求验证方法 问题修正 需求验证的实践调查 5. 需求验证的实践调查 需求验证是重要的 需求验证是容易被忽视的 需求验证的方法是多样的 评审和原型最为广泛 客户对线索（Threads）和场景（Scenarios）表现出了最大的兴趣 技术人员、领域专家、客户以及用户是最合适的评审者 实例分析 需求虽然写好了也定稿了，但是并没有得到最终确认就开始了软件开发工作。这种现象主要是由于业务小组和技术小组沟通不全面造成的，在双方就某一问题产生分歧的情况下，没有一个能出来拍板的人决定（有权利决定的领导不参与开发和需求编写）。所以整个项目的开发