AI总结
笔记总结与重点分析
笔记总结
本笔记系统阐述了需求验证与确认的核心概念及实践方法。主要内容包括：验证与确认的四个层次定义（需求验证/确认、系统验证/确认）、需求验证的具体方法（评审/原型/测试用例等七种方法）、问题修正类型（澄清/缺失/冲突/期望调整），以及需求验证实践调查结论（评审原型最常用，四类人员最适合参与评审）。
重点/易考点分析 (名词解释)
什么是需求验证？
需求验证是指以正确的方式建立需求，确保需求集具备正确性、完备性、一致性，技术上可解决，现实满足可行且可验证。
需求确认与系统验证有何区别？
需求确认是建立符合用户原意的正确需求，系统验证是确保系统在预期环境中正确执行设定功能。
评审方法的特点是什么？
由作者之外的他人检查产品问题，作为主要静态分析手段，原则上每条需求都应进行评审。
开发测试用例方法有哪些例外情况？
排斥性需求（要求特定行为绝对不发生）和全局性非功能性需求（如可靠性、可用性等需要大数据测试）。
用户手册编制验证哪些方面？
验证功能需求（系统功能描述）、项目范围（未实现功能）、异常流程（问题解决）、环境约束（安装启动）。
利用跟踪关系的两种验证方向是什么？
业务需求→用户需求→系统需求方向验证需求完备性；系统需求→用户需求→业务需求方向验证需求必要性。
需求澄清包含哪些具体类型？
理解偏差需重新分析，分析遗漏需补充文档，表达不当需调整表述方式。
需求验证实践中最适合的评审者包括哪些角色？
技术人员、领域专家、客户和用户四类人员。 （我还没有掌握有关知识，此回答为大模型自动生成）
需求验证
验证与确认
验证与确认的概念
- 需求验证：以正确的方式建立需求
- 需求集是正确的、完备的和一致的；
- 技术上是可解决的；
- 它们在现实世界中的满足是可行的和可验证的。
- 需求确认：建立的需求是正确的
- 每一条需求都是符合用户原意的
- 系统验证：正确的建立系统
- 系统能够在预期的环境中正确的执行设定的功能。
- 系统确认：建立的系统是正确的
- 建立的系统是符合系统需求和系统设计的
需求验证
需求验证的概念
- 验证普遍存在
- 获得的用户需求是否正确和充分的支持业务需求？
- 建立的分析模型是否正确的反映了问题域特性和需求？
- 细化的系统需求是否充分和正确的支持用户需求？
- 需求规格说明文档是否组织良好、书写正确？需求规格说明文档内的需求是否充分和正确的反映了涉众的意图？需求规格说明文档是否可以作为后续开发工作（设计、实现、测试等等）的基础？
- 需求验证是专指在需求规格说明完成之后，对需求规格说明文档进行的验证活动
需求验证方法
评审
- 由作者之外的其他人来检查产品问题的方法
- 是主要的静态分析手段
- 原则上，每一条需求都应该进行评审
原型与模拟
- 涉及到复杂的动态行为时
- 成本较高
开发测试用例
- 如果无法为某条需求定义完备的测试用例，那么它可能就存在着模糊、信息遗漏、不正确等缺陷
- 例外
- 排斥性需求（Exclusive Requirements）
- 这种需求要求特定的行为绝对不会发生，例如需求可能会要求系统故障不能导致数据库的崩溃
- 全局性非功能性需求（Global Non-FunctionalRequirements）
- 例如可靠性、可用性等，对这些需求的测试往往都是大数据集的处理 的处理
- 排斥性需求（Exclusive Requirements）
用户手册编制
- 验证功能需求
- 对软件系统功能和实现的描述
- 验证项目范围
- 对系统没有实现的功能的描述
- 验证异常流程需求
- 问题和故障的解决
- 验证环境与约束需求
- 系统的安装和启动
利用跟踪关系
- 业务需求 → 用户需求 → 系统需求
- 如果业务需求和用户需求没有得到后项需求（用户需求和系统需求）的充分支持，那么软件需求规格说明文档就存在不完备的缺陷。
- 系统需求 → 用户需求 → 业务需求
- 如果不能依据跟踪关系找到一条系统需求的前项用户需求和前项业务需求，那么该需求就属于非必要的需求。
自动化分析
形式化语言描述的需求 -> 需求分理器-> 需求集 -> 需求分析器 -> 需求问题报告
问题修正
- 需求澄清（Requirements Clarification）
- 理解偏差：重新进行分析工作
- 分析遗漏：重新分析和文档化这部分信息
- 表达不当：重新以合适的方式表达
- 缺失需求
- 重新执行需求获取等一系列工作
- 需求冲突
- 协商解决
- 不切实际的期望
- 项目调整与需求协商
需求验证的实践调查
- 需求验证是重要的
- 需求验证是容易被忽视的
- 需求验证的方法是多样的
- 评审和原型最为广泛
- 客户对线索（Threads）和场景（Scenarios）表现出了最大的兴趣
- 技术人员、领域专家、客户以及用户是最合适的评审者