软件需求第15课软件需求验证ppt课件

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撰写 人对所撰写的内容向大家宣讲一次，然后开展讨论， 目的是获得需求相关参与人员对撰写内容的认可

5、,11,本课主要讨论问题,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 需求验证方法,需求验证的要点

12、：思想、方法、语言、人员、内容,1）思想 需求验证是为了发现错误，而不是维护错误。代价昂贵的 需求验证工作不是为了验证需求文档无错，而是帮助开发组尽 早发现错误、找到错误。避免因问题被延误到后期而付出惨痛 的代价,2）方法 实际工作中，软件开发团队中开展评审的价值仍然未得到 认可，因此大家在需求评审中总是处于防御地位。在团队中推行 临时评审、同级复查等方法，使创建团队评审制度的基础和保障,28,2 需求验证方法,需求验证的要点：思想、方法、语言、人员、内容,3）语言 在需求评审会中大家应该以“建议者、协作者”身份、角色 出现在评审会上。说话注意语气，不要将自己变为高高在上的评 价者、评判人,不

13、同态度下的表述方式,29,2 需求验证方法,需求验证的要点：思想、方法、语言、人员、内容,4）人员 要开好评审会，选择合适的参与者非常重要。要点在于合适，而不是越大越好。 人员选择的实际经验 同级：不要一开评审会就请领导，很多人连“当着别人的面被指出问题”都受不了，更何况是当着领导的面。 请相关的人：要邀请直接相关的人员参加，一方面可以保证参与者对评审内容熟悉，另外一方面可以保证参与者关注评审过程,30,2 需求验证方法,需求验证的要点：思想、方法、语言、人员、内容,5）内容 需要检查的内容一般都很多。不要一次都拿出来评审。对于具体的项目、团队而言，不同检查项的意义是不同的。应该根据以往主要的问题，例如歧义比较多、完整性比较差的地方对照缺陷检查表进行剪裁。一般一次控制在10条内,31,2 需求验证方法,需求验证检查方法,32,图 需求评审的检查清单,33,本课主要讨论问题,2 需求验证方法,3 问