《第6章需求验证（1）》
n本节主要学习以下内容：
² 了解需求验证的目的和任务；
² 掌握需求规格说明的撰写方法；
² 掌握需求评审的过程及内容。
本节重点
需求验证的相关概念和任务，需求评审的过程和内容。
本节难点
需求评审的过程和内容。
授课课时
2课时
教法建议
首先介绍需求验证的重要性，然后介绍需求验证中的各种概念，再次介绍需求验证中采取的各种方法。
回顾上节课的主要内容。
本节主要讲解需求验证的相关概念和验证方法。
内容：
需求验证的目的就是要确保需求规格说明具有良好的特性（如完整性，正确性等）。
n 需求验证包含的活动
1. 软件需求规格证明是否正确描述了目标系统的行为和特征；
2. 从其它来源中（包括硬件的系统需求规格说明书）得到软件需求；
3. 需求是完整的和高质量的；
4. 所有人对需求的看法是一致的；
5. 需求为进一步的软件开发和测试提供了足够的基础。
n 重要性
发现和修复需求规格说明书存在的问题，并避免在软件系统设计和实现时出现返工。
n 任务
要求各方人员从不同的技术角度对需求规格说明文档做出综合性评价。
[详细讲解，并举例说明]
内容：
n 内容
1.一致性
2.完整性
3.现实性
4.有效性
n 方法
目前验证需求的方法除形式化方法外，主要靠人工技术审查和验证软件需求规格说明。
需求验证的主要手段和方法是Review，该词通常被翻译为“评审”。一些专家认为该词的含义应该更接近于“复查”，也就是“再看一遍”的意思。因为汉语“评审”一词往往具有考察“需求是否通过？好不好”的意思。很容易在组
织和实践中产生偏差。
按照<<软件同级评审>>一书的意思。根据评审的正式化程度可以将评审分为6个等级。
三种相对正式的评审方法
走查：走查带有“遍历”的意思。通常是SRS作者按照文档的页码顺序相参加评审的人员介绍文档的内容。然后大家随时发表意见。一般实际工作中，将工作产品分发给许多其它的开发人员粗略看一看和走过场似地检查一遍（walkthrough）。
审查和小组审查方式比较接近，区别在于小组审查没有审查严格。
正式评审内容需要记录在案，它包括确定材料、评审员、评审小组对产品是否完整或是否需要进一步工作的判定，以及对所发现的错误和所提出的问题的总结。正式评审小组的成员对评审的质量负责，而开发者则最终对他们所开发的产品的质量负责。
一般审查1-2次，小组审查按照小组的阶段情况分阶段进行审查。走查按照要求应该多次进行，但实际工作中一般走查都没有进行，因为大家都在写文档，但应该让专职人员考核该工作。
[详细讲解，并举例说明]
本节学习了以下主要内容：
2. 掌握需求规格说明的撰写方法；
3. 掌握需求评审的过程及内容。
考核点1：需求验证的目的和任务
作业：思考需求分析说明书。
（注：在此写上个人在授课过程中所遇到的教案中所没有涉及到的特殊问题及其解决方法或解决方案，也可以总结自己的授课体会，课程体系、教材的不足等。）
授课教师（签名）： 授课时间： 授课班级：
