《软件需求第15课软件需求验证ppt课件.ppt》由会员分享，可在线阅读，更多相关《软件需求第15课软件需求验证ppt课件.ppt（35页珍藏版）》请在三一办公上搜索。
1、1,软 件 需 求,哈尔滨工程大学计算机科学与技术学院海量数据挖掘及网络数据集成研究组 王念滨 教授 博导,2,第 15 章 软件需求验证,3,本课主要讨论问题,2 需求验证方法,3 问题的修正,4 需求验证实践,1 需求验证概述,4,本课主要讨论问题,2 需求验证方法,3 问题的修正,4 需求验证实践,1 需求验证概述,5,1 需求验证概述,需求验证是软件需求的最后一个环节。,6,1 需求验证概述,需求验证的目标、手段,目标：需求验证的目标是尽可能发现存在的错误，以减少因为需求错误而带来的工作量问题。 主要手段：需求评审（ Review） 实践：不要在需求评审时以不错为目标，也就是说不要在需
2、求评审时对提出的问题带着争辩或者辩护的心态。而是要以发现错误为目标和目的。鼓励参与者提出问题并讨论。 如果你的需求验证结束时，各方都夸奖你做得好，没有什么问题？那只有两种结果：你做得太好了！评审白做了。实践表明，第1种情况基本不可能发生，属于小概率事件。,7,需求验证的含义,1 需求验证概述,验证包含两层含义：验证（Validation）、确认（Verification）,需求验证：以正确的方式建立了需求 需求集是正确的、完备（用户认定的）的和一致的； 技术上是可解决的； 它们在现实世界中的满足是可行的和可验证的。,需求确认：建立的需求是正确的 每一条需求都是符合用户原意的,需求验证就是确保以
3、准确的形式建立需求（需求验证），得到足以作为软件创建基础的需求；需求验证也是确保得到内容语义正确的需求（需求确认），得到能够准确反映用户意图的需求。,8,1 需求验证概述,验证普遍存在在需求获取中：获得的用户需求是否正确和充分的支持业务需求？在需求分析中：建立的分析模型是否正确的反映了问题域特性和需求？细化的系统需求是否充分和正确的支持用户需求？在需求规格说明中：需求规格说明文档是否组织良好、书写正确？需求规格说明文档内的需求是否充分和正确的反映了涉众的意图？需求规格说明文档是否可以作为后续开发工作（设计、实现、测试等等）的基础？需求验证是专指在需求规格说明完成之后，对需求规格说明文档进行的验
4、证活动,需求验证的行为模式,9,1 需求验证概述,需求验证的活动,编写SRS,需求（验证）,需求获取,需求分析,需求定义,需求规格说明书,确定问题,修正,需求验证是一个迭代过程，需要多次反复。,图 需求验证活动流图,10,1 需求验证概述,需求验证的活动,编写SRS,需求（验证）,需求获取,需求分析,需求定义,需求规格说明书,确定问题,修正,实践：实际上，在需求规格说明写作或完成时，一般SRS 小组都会开展多次大型的自查会，将需求定义、需求 获取、需求分析的参与人员集中或分组，让SRS撰写 人对所撰写的内容向大家宣讲一次，然后开展讨论， 目的是获得需求相关参与人员对撰写内容的认可。,11,本课
5、主要讨论问题,2 需求验证方法,3 问题的修正,4 需求验证实践,1 需求验证概述,12,2 需求验证方法,需求验证的主要手段和方法是Review，该词通常被翻译为“评审”。一些专家认为该词的含义应该更接近于“复查”，也就是“再看一遍”的意思。因为汉语“评审”一词往往具有考察“需求是否通过？好不好”的意思。很容易在组织和实践中产生偏差。 按照一书的意思。根据评审的正式化程度可以将评审分为6个等级。,13,2 需求验证方法,三种相对正式的评审方法,审查、小组审查、走查的主要区别,注：过程改进小组（EPG/SEPG）,14,2 需求验证方法,走查：走查带有“遍历”的意思。通常是SRS作者按照文档的
6、页码顺序相参加 评审的人员介绍文档的内容。然后大家随时发表意见。 一般实际工作中，将工作产品分发给许多其它的开发人员粗略看一看 和走过场似地检查一遍（walkthrough）。审查和小组审查方式比较接近，区别在于小组审查没有审查严格。 正式评审内容需要记录在案，它包括确定材料、评审员、评审小组对产品是否完整或是否需要进一步工作的判定，以及对所发现的错误和所提出的问题的总结。正式评审小组的成员对评审的质量负责，而开发者则最终对他们所开发的产品的质量负责。,一般审查1-2次，小组审查按照小组的阶段情况分阶段进行审查。走查按照要求应该多次进行，但实际工作中一般走查都没有进行，因为大家都在写文档，但应
7、该让专职人员考核该工作。,三种相对正式的评审方法,15,2 需求验证方法,三种相对不正式的评审方法,结对编程,结对编程与评审有什么关系？其实结对编程是一种广义的概念，它包括结对分析、结对设计、结对编码，甚至还包括结对测试等。对于需求开发而言，也可以采取结对分析的方法来提高质量。例如，在需求开发项目中，为了更好地加强需求人员之间的沟通，要求每位参加获取、分析的人员邀请一位同事参与，保证绝大多数需求都至少由2个人共同完成。通过这种方式，使需求质量大大提高。当然问题是人力资源投入增大了。,16,2 需求验证方法,三种相对不正式的评审方法,同级轮查,如果说前述四种方式都和组织有关系的话，同级轮查则可以
8、认为是个人级的评审方法。简单地说，就是需求人员之间私下进行交叉的复查。一般是两位需求人员之间交换文档产物，互相提出意见和建议。或者多位需求人员之间交叉交换文档产物，互相提出意见和建议。 尽管这些活动是私下进行的，一般企业都会鼓励这种方式，有助于建立企业的良好的评审文化。有的企业将轮查作为制度制定，实践表明，这种方式如果能够得到员工的认可，将会大大提高各类工作效率。,17,2 需求验证方法,三种相对不正式的评审方法,临时评审,临时评审通常是与个人的工作习惯有关。最常见、最简单的临时评审是在沟通的过程中。由信息的接受者向信息的传达者做简要的、概括性的回顾（陈述），以期达到共识。例如： 在用户访谈中
9、，一定要对每次访谈的内容进行概括，让用户对你的理解、记录的信息进行即时的验证。 在向开发团队交流时，对介绍的与需求相关的信息，应该建议开发人员对听到的、理解的内容进行简单的复述，以便对阐述的信息进行验证。,18,2 需求验证方法,关于评审一般原则由作者之外的其他人来检查产品问题的方法是主要的静态分析手段原则上，每一条需求都应该进行评审,19,2 需求验证方法,评审参与人员,审查人员,20,2 需求验证方法,评审过程,21,2 需求验证方法,评审过程,规划（Planning）：作者和调解者协同对审查进行规划，以决定谁该参加审查，审查员在召开审查会之前应收到什么材料并且需要召开几次审查会等相关问题
10、。,22,总体会议（overview meeting）：总体会议可以为审查员提供了解会议的信息，包括他们要审查的材料的背景，作者所作的假设和作者的特定审查目标。,2 需求验证方法,评审过程,23,准备（Preparation）：在正式审查的准备阶段，每个审查员以典型缺陷（defect）清单为指导，检查产品可能出现的错误，并提出问题。,2 需求验证方法,评审过程,24,审查会议（Inspection meeting）: 在审查会进行过程中，读者通过软件需求规格说明指导审查小组，一次解释一个需求。当审查员提出可能的错误或其它问题时，记录员就记录这些内容，其形式可以成为需求作者的工作项列表。会议的目
11、的是尽可能多地发现需求规格说明中的重大缺陷。,2 需求验证方法,评审过程,25,2 需求验证方法,评审过程,重写（rework）：几乎每一个质量控制活动都可能发现一些需求缺陷。因此，作者必须在审查会之后，安排一段时间用于重写文档。,26,跟踪（follow-up）: 这是审查工作的最后一步，调解者或指派人单独重审由作者重写的需求规格说明。重审确保了所有提出的问题都能得到解决，并且正确修改了需求的错误。重审结束了审查的全过程并且可以使调解者做出判断：是否已满足审查的退出标准。,2 需求验证方法,评审过程,27,2 需求验证方法,需求验证的要点：思想、方法、语言、人员、内容,（1）思想 需求验证是
12、为了发现错误，而不是维护错误。代价昂贵的需求验证工作不是为了验证需求文档无错，而是帮助开发组尽早发现错误、找到错误。避免因问题被延误到后期而付出惨痛的代价。,（2）方法 实际工作中，软件开发团队中开展评审的价值仍然未得到认可，因此大家在需求评审中总是处于防御地位。在团队中推行临时评审、同级复查等方法，使创建团队评审制度的基础和保障。,28,2 需求验证方法,需求验证的要点：思想、方法、语言、人员、内容,（3）语言 在需求评审会中大家应该以“建议者、协作者”身份、角色出现在评审会上。说话注意语气，不要将自己变为高高在上的评价者、评判人。,不同态度下的表述方式,29,2 需求验证方法,需求验证的要
13、点：思想、方法、语言、人员、内容,（4）人员 要开好评审会，选择合适的参与者非常重要。要点在于合适，而不是越大越好。 人员选择的实际经验 同级：不要一开评审会就请领导，很多人连“当着别人的面被指出问题”都受不了，更何况是当着领导的面。 请相关的人：要邀请直接相关的人员参加，一方面可以保证参与者对评审内容熟悉，另外一方面可以保证参与者关注评审过程。,30,2 需求验证方法,需求验证的要点：思想、方法、语言、人员、内容,（5）内容 需要检查的内容一般都很多。不要一次都拿出来评审。对于具体的项目、团队而言，不同检查项的意义是不同的。应该根据以往主要的问题，例如歧义比较多、完整性比较差的地方对照缺陷检查表进行剪裁。一般一次控制在10条内。,31,2 需求验证方法,需求验证检查方法,32,图需求评审的检查清单,33,本课主要讨论问题,2 需求验证方法,3 问题的修正,4 需求验证实践,1 需求验证概述,34,3 问题的修正,需求澄清（Requirements Clarification）理解偏差：重新进行分析工作分析遗漏：重新分析和文档化这部分信息表达不当：重新以合适的方式表达缺失需求重新执行需求获取等一系列工作需求冲突协商解决不切实际的期望项目调整与需求协商,35,本课主要讨论问题,2 需求验证方法,3 问题的修正,4 需求验证实践,1 需求验证概述,
