《第6章需求验证（2）》
n本节主要学习以下内容：
² 需求评审的方法；
² 审查人员的确定和分工；
² 审查的内容；需求测试的过程；
² 编写用户使用手册草案；
² 解释需求模型。
本节重点
需求评审的方法、人员分工、审查内容。
本节难点
需求评审的方法、人员分工、审查内容。
授课课时
2课时
教法建议
首先介绍需求评审的概念，然后介绍评审的方式和内容。
回顾上节课的主要内容。
本节主要讲解需求评审的相关概念和方法。
内容：
需求评审就是技术评审。是由非软件开发人员对软件系统的进行检查以发现该系统所存在的问题。
需求评审分类:非正式评审，正式评审。
审查的内容
需求评审的工作就是评审需求规格说明的内容。
审查清单列举的问题
(1) 需求是否完整？ (2)需求是否一致？
(3)需求是否可理解？ (4)需求是否明确？
(5)需求是否可实现？ (6)需求是否可跟踪？
(7)需求是否易于修改？ (8)需求规格说明文档是否完整
[详细讲解，并举例说明]
内容：
审查人员的组成
从事软件系统需求开发的相关人员；
具有编写需求规格说明经验和知识的人员，以及具有评审工作经验的领域专家等；
客户或同户代表，他们可以保证需求规格说明能正确地和完整的描述他们的需求；
将依据需求规格说明开展工作的软件开发人员，如设计人员，测试人员，项目经理等。
评审人员的分工
作者，这些人通常为系统分析员；
调解员，通常为项目总负责人；
读者，主要由审查人员扮演；
记录员。
[详细讲解，并举例说明]
内容：
规划（Planning）：作者和调解者协同对审查进行规划，以决定谁该参加审查，审查员在召开审查会之前应收到什么材料并且需要召开几次审查会等相关问题。
总体会议（overview meeting）：总体会议可以为审查员提供了解会议的信息，包括他们要审查的材料的背景，作者所作的假设和作者的特定审查目标。
准备（Preparation）：在正式审查的准备阶段，每个审查员以典型缺陷（defect）清单为指导，检查产品可能出现的错误，并提出问题。
审查会议（Inspection meeting）: 在审查会进行过程中，读者通过软件需求规格说明指导审查小组，一次解释一个需求。当审查员提出可能的错误或其它问题时，记录员就记录这些内容，其形式可以成为需求作者的工作项列表。会议的目的是尽可能多地发现需求规格说明中的重大缺陷。
重写（rework）：几乎每一个质量控制活动都可能发现一些需求缺陷。因此，作者必须在审查会之后，安排一段时间用于重写文档。
跟踪（follow-up）: 这是审查工作的最后一步，调解者或指派人单独重审由作者重写的需求规格说明。重审确保了所有提出的问题都能得到解决，并且正确修改了需求的错误。重审结束了审查的全过程并且可以使调解者做出判断：是否已满足审查的退出标准。
[详细讲解，并举例说明]
内容：
为需求设计测试用例的目的:确认需求而不能确认系统。
方法
以功能需求为基础，并视其为黑盒子，然后编写关于该功能或黑盒子的测试用例。
可以从用例中获得概念上的功能测试用例，然后利用测试用例来验证需求规格说明和需求模型。
[详细讲解，并举例说明]
内容：
好处:在编制该手册的过程中，可强化对需求的仔细分析，帮助揭示与系统的实际使用相关的问题，即系统的可用性问题未被掩盖。可以帮助阐明用户界面设计问题，从而促使软件开发人员一开始就站在用户的角度来设计用户界面，并及早考虑人-机交互中的接口问题。
要求:此时编制的用户使用手册并不要求全面，主要是用简单易懂的语言描述出所有对用户可见的功能。
[详细讲解，并举例说明]
内容：
用自然语言解释需求模型的好处
有利于评审人员理解和评审需求规格说明；
有助于发现模型中的一些错误。
要点:在用自然语言解释的过程中，应避免语言的生硬和呆板，特别是不能把不存在的信息加入到需求模型中。
[详细讲解，并举例说明]
本节学习了以下主要内容：
2. 审查人员的确定和分工；
3. 审查的内容；需求测试的过程；
4. 编写用户使用手册草案；
5. 解释需求模型。
考核点1：需求评审的方法、内容、人员分工
作业：思考团队分工和测试评审安排。
（注：在此写上个人在授课过程中所遇到的教案中所没有涉及到的特殊问题及其解决方法或解决方案，也可以总结自己的授课体会，课程体系、教材的不足等。）
授课教师（签名）： 授课时间： 授课班级：
