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

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