5.2需求验证的方法及特点.ppt

主讲人：李尤丰 第五章 需 求 验 证 金陵科技学院 软件工程学院 目 录 5.1 需求的验证及过程5.2 需求验证的方法及特点 5.2 需求验证的方法及特点 5.2.1 需求评审 1.正式与非正式技术评审 2.需求审查过程 3.进入和退出审查的标准 4.需求审查清单 5.需求评审的困难 5.2 需求验证的方法5.2.1 需求评审 1.正式与非正式技术评审 非正式评审的方法包括把工作产品分发给许多其它的开发人员粗略看一看，走过场似地检查一遍。 5.2 需求验证的方法5.2.1 需求评审 1.正式与非正式技术评审 正式技术评审，叫作审查（inspection）（Ebenau and Strauss 1994; Gilb andGraham 1993）。正式评审内容需要。。。。 正式评审小组的成员对评审的质量负责，而开发者则最终对他们所开发的产品的质量负责。如果认为没有时间详细审查每个方面，那么可以使用简单的风险分析模型，来区分需求文档哪些部分是需要详细审查的，哪些不重要部分只要用非正式评审就能满足质量要求。 5.2 需求验证的方法5.2.1 需求评审 2.需求审查过程 参与评审的人员 参与评审的人员，包括产品的开发者，以及可能的同组成员，包括先前产品的开发者或正在评审的项目的规格说明编写者，包括要根据正在审查的文档来开展工作的人们。很可能参与评审的人员包括一个开发人员、一个测试人员、一个项目经理和一个用户文档编写人员。他们的工作基础都是软件需求规格说明。这些审查人员将会发现不同类型的问题。审查组中的审查人员应限制在7个人左右或者更少。 5.2 需求验证的方法5.2.1 需求评审 2.需求审查过程 审查每个成员扮演的角色 作者：作者创建或维护正在被审查的产品。 调解者：调解者（moderator）或者审查主持者所做的是与作者一起为审查制订计划协调各种活动，并且推进审查会的进行。 读者：读者的角色由审查员扮演。 记录员：记录员或书记员用标准化的形式记录在审查会中提出的问题和缺陷。记录员必须仔细审查所写的材料以确保记录的正确性。 5.2 需求验证的方法5.2.1 需求评审 2.需求审查过程 评审过程 规划（Planning）：作者和调解者协同对审查进行规划，以决定谁该参加审查，审查员在召开审查会之前应收到什么材料并且需要召开几次审查会。 总体会议（overview meeting）：总体会议可以为审查员提供了解会议的信息，包括他们要审查的材料的背景，作者所作的假设和作者的特定审查目标。 5.2 需求验证的方法5.2.1 需求评审 2.需求审查过程 评审过程 准备（Preparation）：在正式审查的准备阶段，每个审查员以典型缺陷为清单，检查产品可能出现的错误并提出问题。 审查会议（Inspection meeting）：在审查会进行过程中，读者通过软件需求规格说明指导审查小组一次解释一个需求。当审查员提出可能的错误或其它问题时记录员就记录这些内容，其形式可以成为需求作者的工作项列表。会议的目的是尽可能多地发现需求规格说明中的重大缺陷。 5.2 需求验证的方法 5.2.1 需求评审 2.需求审查过程 重写(rework):几乎每一个质量控制活动都可能发现一些需求缺陷。因此作者必须在审查会之后安排一段时间重写文档。 重审(follow-up):这是审查工作的最后一步调解者或指派人单独重审由作者重写的需求规格说明。重审确保了所有提出的问题都能得到解决，并且正确修改了需求的错误。重审结束了审查的全过程，并且可以使调解者做出判断是否已满足审查的退出标准。 5.2 需求验证的方法 5.2.1 需求评审 3.进入和退出审查的标准 一般，需求文档进入审查的标准有：文档符合标准模板，文档已经做过拼写检查和语法检查，作者已经检查了文档在版面安排上所存在的错误，已经获得了审查员所需要的先前或参考文档，例如系统需求规格说明，在文档中打印了行序号以方便在审查中对特定位置的查阅，所有未解决的问题都被标记为TBD待确定，包括文档中使用到的术语词汇表。 一般，需求文档退出审查的标准有：已经明确阐述了审查员提出的所有问题，已经正确修改了文档，修订过的文档已经进行了拼写检查和语法检查，所有TBD的问题已经全部解决 或者已经记录下每个待确定问题的解决过程、目标、日期和提出问题的人，文档已经登记入项目的配置管理系统，已将审查过的资料送到有关收集处 5.2 需求验证的方法 5.2.1 需求评审 4.需求审查清单（对应图片模糊化处理，不用看到上面具体内容） 为了使审查员警惕审查的产品中的习惯性错误，需对所创建的每一类型的需求