需求验证 需求评审PPT学习课件

1,需求验证需求评审,2,案例,案例一某领域专家A先生就某企业的成本管理系统做用户需求报告的评审工作，在评审会开始时间不长，就被在场的某企业的一位副总B先生打断，认为A先生提出的方案不适合本企业，A先生提出的管理改进方案在企业中无法实施。该副总提完意见后，与会的用户方人员纷纷跟随B先生的提出了他们的反对意见，致使评审会无法再进行下去，最终该报告被用户否决。案例二某软件公司内部举行产品的需求评审会，主要是公司内部的相关领域的专家参加，在评审会开始后不久，某领域专家就对需求报告中的某个具体问题提出了自己的不同意见，于是，与会人员纷纷就该问题发表自己的意见，大家争执不下，结果，致使会议出现了混乱状况，主持人无法控制局面，会议大大超出了计划评审时间。,3,案例,案例三某软件公司为某公司A做业务流程管理系统的需求评审会，当项目组人员在会议上宣读多达上百页的需求报告时，用户明确提出听不懂，致使会议不得不改日进行。案例四某软件公司在用户处开完物资管理系统的需求评审会后，与会人员在离开会议室时纷纷摇头，认为本次会议没有多少实际效果，完全是在走过场。案例五某软件公司在公司内部举行产品的需求评审会时，需求报告的执笔人与产品策划的主要策划人员的想法差别很大，致使需求评审会没有必要继续进行下去。,4,问题出在哪里,需求报告很长，短时间内评审者根本就不能把需求报告读懂、想清楚；没有作好前期准备工作，需求评审的效率很低；需求评审的节奏无法控制；找不到合格的评审员，与会的评审员无法提出深入的问题；,5,那么究竟如何做好需求评审呢？,6,为防止错误而花费1美元将可以为你修补错误节省310美元。,7,需求缺陷,为什么软件需求定义中存在缺陷最多？,软件缺陷并不只是在编程阶段才产生，需求和设计阶段同样会产生缺陷。,8,需求评审重要性的直观描述,9,需求验证是需求开发的第四部分,需求验证所包括的活动是为了确定以下几方面的内容：软件需求规格说明正确描述了预期的系统行为和特征。从系统需求或其它来源中得到软件需求。需求是完整的和高质量的。所有对需求的看法是一致的。需求为继续进行产品设计、构造和测试提供了足够的基础。,10,需求验证确保:,需求符合需求陈述（requirementstatement）的良好特征（完整的、正确的、灵活的、必要的、具有优先级的、无二义行及可验证的）。符合需求规格说明的良好特性（完整的、一致的、易修改的、可跟踪的）。只能验证那些已编写成文档的需求。那些存在于用户或开发者思维中的没有表露的、含蓄的需求则不予验证。,11,需求评审,通常，总是由一些非软件开发人员进行产品检查以发现产品所存在的问题，这就是技术评审。需求文档的评审是一项精益求精的技术，它可以发现那些二义性的或不确定的需求、那些由于定义不清而不能作为设计基础的需求，还有那些实际上是设计规格说明的所谓的“需求”。评审类型：评审、检查、走查。使用不同的技术有助于你验证需求的正确性及其质量。将重点介绍两种最重要的验证技术：正式和非正式的需求评审。,12,正式评审,遵循预先定义好的一系列步骤过程。正式评审内容需要记录在案，它包括确定材料、评审员、评审小组对产品是否完整或是否需要进一步工作的判定，以及对所发现的错误和所提出的问题的总结。正式评审小组的成员对评审的质量负责，而开发者则最终对他们所开发的产品的质量负责。正式技术评审的最好类型叫作审查。,13,非正式评审,包括把工作产品分发给许多其它的开发人员粗略看一看和走过场似地检查一遍。同时执行者描述产品，且征求意见。非正式评审对于培养其他人对产品的认识并获得非结构化的反馈是有利的，但非正式评审是非系统化的，不彻底的，或者在实施过程中具有不一致性。非正式评审不需要记录备案。非正式评审可以根据个人爱好的方式进行评审,14,评审流程,评审流程是一个重复进行的循环过程：评审员提出问题讨论问题对问题进行确认确定缺陷（确定需要解决的地方），直到没有确定的问题时再继续下一步。,15,评审会议流程,达到评审会议标准?,Yes,计划,全面纵览,准备,修正问题,跟踪,问题记录,会议纪要,满足执行要求?,Yes,No,评审,结果分析,流程改进建议,16,审查过程,1.参与者审查参与者必须代表三个方面的观点：a.产品的开发者及其可能的同组成员。b.先前产品的开发者或正在评审的项目的规格说明编写者。c.要根据正在审查的文档来开展工作的人们。审查组中的审查人员应限制在7个人左右或者更少。,17,2.审查中每个成员扮演的角色,作者调解者读者记录员,18,评审会议角色,19,3.审查阶段,根据如下因素调整审查速度：一页中的文字数量规格说明的复杂性待审查的材料对项目成功的重要程度以前的审查数据软件需求规格说明作者的经验水平,20,审查过程阶段,规划总体会议准备审查会议重写重审,21,审查速度与发现的错误数量之间的关系,22,4.进入审查的标准,关于需求文档的进入审查的标准：文档符合标准模板。文档已经做过拼写检查和语法检查。作者已经检查了文档在版面安排上所存在的错误。已经获得了审查员所需要的先前或参考文档，例如系统需求规格说明。在文档中打印了行序号以方便在审查中对特定位置的查阅。所有未解决的问题都被标记为TBD（待确定）。包括了文档中使用到的术语词汇表。,23,退出审查的标准,关于需求文档的退出标准：已经明确阐述了审查员提出的所有问题。已经正确修改了文档。修订过的文档已经进行了拼写检查和语法检查。所有TBD的问题已经全部解决，或者已经记录下每个待确定问题的解决过程，目标日期和提出问题的人。文档已经登记入项目的配置管理系统。检查是否已将审查过的资料送到有关收集处。,24,需求评审的标准,正确性完备性易理解性一致性可行性易修改性易测试性易追溯性,25,需求评审过程,首先，对产品说明书进行高级审查，找出根本性的问题、疏忽或遗漏之处假设自己是客户研究现有的标准和规范公司惯用语和约定行业要求政府标准图形用户界面安全标准审查和测试类似软件审查经竞争产品注意：规模、复杂性、测试性、质量和可靠性、安全性,26,需求评审过程,通过高级审查了解外部因素后，其次，对需求进行更细致的测试经常使用检查列表进行检查,27,需求评审过程,需求规格说明检查表一个例子,28,需求评审过程,对照需求和检查表，逐条检查判断找到用户的原始素材对照，包括用户提供的材料、调研记录、用户沟通记录等（完整性）检查用词问题（明确性、易理解）详细检查需求规格说明书对需求的覆盖是否准确（必要性）检查软件使用环境的描述是否清楚（完整性）检查需求编号是否正确（可修改性）检查需求是否自相矛盾（一致性）检查系统允许的输入与预期输出（可测性）,29,需求评审过程,对照需求和检查表，逐条检查判断（续）检查性能是否得到清晰的描述（完整性）检查需求的关注重点和实现先后顺序是否清晰描述（优先级）检查对系统的约束是否完整描述（可测性）,30,需求用词问题,总是、每一种、所有、没有、从不如此肯定的描述，测试员需要确认，尝试找违法的例子当然、因此、明显、显然、必然这些话意图诱使接受假定情况。不要中了圈套。某些、有时、常常、通常、经常、大多、几乎这些话太过模糊。“有时”发生作用的功能无法测试等等、诸如此类、依此类推以这样的词结束的功能清单无法测试。功能清单要绝对或者解释明确,31,需求用词问题,良好、迅速、廉价、高效、小、稳定这些是不确定的说法，不可测试。如果在产品说明书出现，必须要求进一步指明含义（已）处理、进行、拒绝、忽略、消除这些说法可能会隐藏大量需要说明的功能如果.那么.（没有否则）缺少配套的否则，想一想，“如果”没有发生会怎样呢？,32,5.需求审查清单,为了使审查员警惕他们所审查的产品中的习惯性错误，对你的公司所创建的每一类型的需求文档建立一份清单。这些清单可以提醒审查员以前经常发生的需求问题。研究结果表明：赋予审查员特定的查错责任，向他们提供结构化思维过程或情节以帮助他们寻找特定类型的错误，这比仅仅向审查员发放一份清单所产生的效果要好得多。,33,软件需求规格说明的审查清单,组织和完整性：所有对其它需求的内部交叉引用是否正确？所有需求的编写在细节上是否都一致或者合适？需求是否能为设计提供足够的基础？是否包括了每个需求的实现优先级？是否定义了所有外部硬件、软件和通信接口？是否定义了功能需求内在的算法？软件需求规格说明中是否包括了所有客户代表或系统的需求？是否在需求中遗漏了必要的信息？如果有的话，就把它们标记为待确定的问题。是否记录了所有可能的错误条件所产生的系统行为？,34,正确性,是否有需求与其它需求相冲突或重复？是否简明、简洁、无二义性地表达每个需求的？是否每个需求都能通过测试、演示、审查得以验证或分析？是否每个需求都在项目的范围内？是否每个需求都没有内容上和语法上的错误？在现有的资源限制内，是否能实现所有的需求？是否任一个特定的错误信息都具有唯一性和明确的意义？,35,可行性：,需求定义是否使软件的设计、实现、操作和维护都可行？所规定的模式、数值方法和算法是否对待解问题合适？是否能够在相应的限制条件下实现？是否能够达到关于质量的要求？,36,易修改性：,对需求定义的描述是否易于修改？例如是否采用良好的结构和交叉引用表等等？是否有冗余的信息？是否一个需求被定义多次？,37,健壮性：,是否有容错的需求？,38,易理解性：,是否每一个需求都只有一种解释？功能性需求是不是以模块方式描述的，是否明确地标识出其功能？是否使用了形式化或半形式化的语言？语言是否有歧义性？需求定义是否只包含了必要的实现细节而不包含不必要的实现细节？是否过分细致了？需求定义是否足够清楚和明确使其已能够作为开发设计规约和功能性测试数据基础？需求定义的描述是否将对程序的需求和所提供的其它信息分离开来?,39,易测试性和可验证性：,需求是否可以验证？是否对每一个需求都指定了验证过程？数学函数的定义是否使用了精确定义的语法和语法符号？,40,兼容性：,界面需求是否使软硬件系统具有兼容性？,41,完备性：,需求定义是否包含了有关文件（指质量手册、质量计划以及其他有关文件）中所规定的需求定义所应该包含的所有内容？需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有需求？功能性需求是否覆盖了所有非正常情况的处理？是否已对各种操作模式（如正常、非正常、有干扰等）下的环境条件都作规定？是否识别出了所有与时间因素有关的功能？它们的时间准则是否都明了？时间准则的最大、最小执行时间是否都定义了？是否识别定义了在将来可能会变化的需求？是否定义了系统的所有输入？是否标识清楚了系统输入的来源？是否识别了系统的输出？是否说明了系统输入、输出的类型？是否说明了系统输入、输出的值域、单位、格式等？是否说明了如何进行系统输入的合法性检查？是否定义了系统输入、输出的精度？在不同负载情况下，系统的生产率如何？在不同的情况下，系统的响应时间如何？系统对软件、硬件或电源故障必须作什么样的反应？是否充分定义了关于人机界面的需求？,42,一致性：,各个需求之间是否一致？是否有冲突和矛盾所规定的模型、算法和数值方法是否相容？是否使用了标准术语和定义形式？需求是否与其软硬件操作环境相容？是否说明了软件对其系统和环境的影响？是否说明了环境对软件的影响？,43,质量属性,是否合理地确定了性能目标？是否合理地确定了安全与保密方面的考虑？在确定了合理的折衷情况下，是否详实地记录了其它相关的质量属性？,44,可跟踪性,是否每个需求都具有唯一性并且可以正确地识别它？是否可以根据高层需求（如系统需求或使用实例）跟踪到软件功能需求？,45,特殊的问题,是否所有的需求都是名副其实的需求而不是设计或实现方案？是否确定了对时间要求很高的功能并且定义了它们的时间标准？是否已经明确地阐述了国际化问题？,46,使用实例文档审查清单,使用实例是否是独立的分散任务？使用实例的目标或价值度量是否明确？使用实例给操作者带来的益处是否明确？使用实例是否处于抽象级别上，而不具有详细的情节？使用实例中是否不包含设计和实现的细节？是否记录了所有可能的可选过程？是否记录了所有可能的例外条件？是否存在一些普通的动作序列可以分解成独立的使用实例？是否简明书写、无二义性和完整地记录了每个过程的对话？使用实例中的每个操作和步骤是否都与所执行的任务相关？使用实例中定义的每个过程是否都可行？使用实例中定义的每个过程是否都可验证？,47,需求评审的困难,1)大型的需求文档2)庞大的审查小组用以下的方法处理庞大的审查小组：确保每个参与者都是为了寻找错误，而不是为了解软件需求规格说明中的内容或者为了维护行政上的位置。如果一些参与者只是想大概了解审查的内容，那么就邀请他们去参加总体会议，而不是参加审查会。理解审查员所代表的观点（例如客户、开发者或测试者），并且委婉地拒绝以相同的观点看待问题的参与者。在准备阶段，你可能要收集持有同样观点的反馈人的信息，但只要派其中的一个作为代表参加会议。把审查组分成若干小组并行地审查软件需求规格说明，并把他们发现的错误集中起来，剔除重复的部分。研究表明：多个审查小组比起单一的大组而言，可以发现需求文档中更多的错误。审查小组总是发现错误的不同子集，所以并行审查的结果是追加的，而不是冗余的。3)审查员在地域上的分散,48,测试需求,通过阅读软件需求规格说明，通常很难想像在特定环境下的系统行为。以功能需求为基础或者从使用实例派生