(CEN)第八章需求验证与确认全解

第八章需求验证与评审软件需求验证与评审概述软件需求评审过程软件需求评审问题与困难如何做好软件需求评审8.1软件需求验证与评审概述在需求开发阶段发现的一个错误，平均仅需要花30分钟修复，但是在系统测试时发现的错误需要花5~17个小时来修复。一、需求验证概述１、需求验证的活动如下：软件需求规格说明正确描述了预期的系统行为和特征。从系统需求或其它来源中得到软件需求。需求是完整的和高质量的。所有对需求的看法是一致的。需求为继续进行产品设计、构造和测试提供了足够的基础。２、需求验证的目的需求符合需求陈述（requirementstatement）的良好特征（完整的、正确的、灵活的、必要的、具有优先级的、无二义行及可验证的）。符合需求规格说明的良好特性（完整的、一致的、易修改的、可跟踪的）。只能验证那些已编写成文档的需求，而那些存在于用户或开发者思维中的没有表露的、含蓄的需求则不予验证。二、需求验证概述例：一个来自四个用户代表的软件需求规格说明的评审工作正在进行。一个用户提出了一个灾难性的问题：它将使需求做重大更改。会后，需求分析员和项目经理很恼火，因为在前两个月的定义需求会议上，该用户也在场，但她却没有提出这一问题。经过一些调查之后才发现该用户已经反复提出了这个问题，但都被忽略了。在评审过程中，当许多用户一致认为这是一个严重的问题时，分析员和项目经理意识到，他们再也不能忽略这一问题了。需求评审即技术评审。需求文档的评审是一项精益求精的技术，它可以发现那些二义性的或不确定的需求、那些由于定义不清而不能作为设计基础的需求，还有那些实际上是设计规格说明的所谓的“需求”。技术评审分为正式评审和非正式评审。（１）正式评审：遵循预先定义好的一系列步骤过程。正式评审内容需要记录在案，它包括确定材料、评审员、评审小组对产品是否完整或是否需要进一步工作的判定，以及对所发现的错误和所提出的问题的总结。正式评审小组的成员对评审的质量负责，而开发者则最终对他们所开发的产品的质量负责。正式技术评审的最好类型叫作审查。（２）非正式评审非正式评审的方法包括:把工作产品分发给许多其它的开发人员粗略看看,或者走过场似地检查一遍(walkthrough)，执行者描述产品，且征求意见。非正式评审对于培养其他人对产品的认识并获得反馈是有利的，但非正式评审是非系统化的，不彻底的。非正式评审不需要记录备案。非正式评审可以根据个人爱好的方式进行评审。８．２软件需求评审过程一、软件需求评审计划确定评审范围和评估对象确定评审参与者（审查组中的审查人员应限制在7个人左右或者更少，但不要少于4人）确定评审时间确定评审议程和所需要的信息二、评审参与人员一般由以下人员组成：审查参与者必须代表以下几个方面的观点：a.产品的开发者及其可能的同组成员。b.先前产品的开发者或正在评审的项目的规格说明编写者。c.客户或者用户代表。这类人群可以保证需求规格说明能正确和完整地描述他们的需求。d.要根据正在审查的文档来开展工作的人们。包括设计人员，测试人员和项目经理。审查组中的审查人员应限制在7个人左右或者更少。审查中每个成员扮演的角色：作者：创建和编写正在被审查的SRS的人。系统分析员只能听取其他审查员得评论并做解释回答，不能参与讨论。调解者：审查的调解人与主持人，一般为项目总负责人。与作者一起制定审查计划，协调审查期间各种活动。读者：审查人员。审查SRS的内容，并提出问题以及自己的理解。记录员：以标准的形式与格式记录在审查中提出的问题和缺陷。记录员组长作者用户代表技术人员三、需求评审过程１、根据如下因素调整审查速度：•一页中的文字数量•规格说明的复杂性•待审查的材料对项目成功的重要程度•以前的审查数据•软件需求规格说明作者的经验水平２、评审过程（１）理解评审流程（２）理解评审员的角色作者（介绍员）调解者（主持者）读者（评审员）记录员（３）指定协调员（４）评审（保持简短）（５）确定问题，而不是解决问题规划(Planning)：由作者和调节者对审查进行规划，决定所有参与人员，审查人员应该收到的材料，日程如何安排。总体会议(OverviewMeeting)：为审查员提供了解会议的信息：待审查的材料背景，作者所作的假设和审查目标。准备(Preparation)：每个审查员以典型缺陷(defect)审查清单为指导，检查SRS中可能出现的问题，并且提出问题。审查会议(InspectionMeeting)：在会议过程中，读者通过SRS来指导审查小组，一次解释一次需求。当审查员提出可能的错误或其它的错误时，记录员须记录下这些内容。会议的目的是尽可能发现SRS中的重要缺陷和错误。重定、重写(Rework)：当发现SRS中出现问题时，应在会后安排时间重写与修改。重审(FollowUp)：审查的最后一步，重新审查重写的SRS，确保提出的所有问题都得到解决，退出审查。３、进入和退出审查的标准（１）SRS进入审查的标准：•文档符合标准模板。•文档已经做过拼写检查和语法检查。•作者已经检查了文档在版面安排上所存在的错误。•已经获得了审查员所需要的先前或参考文档，例如系统需求规格说明。•在文档中打印了行序号以方便在审查中对特定位置的查阅。•所有未解决的问题都被标记为TBD（待确定）。•包括了文档中使用到的术语词汇表。(2)关于需求文档的退出标准：•已经明确阐述了审查员提出的所有问题。•已经正确修改了文档。•修订过的文档已经进行了拼写检查和语法检查。•所有TBD的问题已经全部解决，或者已经记录下每个待确定问题的解决过程，目标日期和提出问题的人。•文档已经登记入项目的配置管理系统。•检查是否已将审查过的资料送到有关收集处。4、需求审查清单为了使审查员警惕他们所审查的产品中的习惯性错误，对你的公司所创建的每一类型的需求文档建立一份清单。这些清单可以提醒审查员以前经常发生的需求问题。研究结果表明：赋予审查员特定的查错责任，向他们提供结构化思维过程或情节以帮助他们寻找特定类型的错误，这比仅仅向审查员发放一份清单所产生的效果要好得多（１）组织和完整性•所有对其它需求的内部交叉引用是否正确？•所有需求的编写在细节上是否都一致或者合适？•需求是否能为设计提供足够的基础？•是否包括了每个需求的实现优先级？•是否定义了所有外部硬件、软件和通信接口？•是否定义了功能需求内在的算法？•软件需求规格说明中是否包括了所有客户代表或系统的需求？•是否在需求中遗漏了必要的信息？如果有的话，就把它们标记为待确定的问题。•是否记录了所有可能的错误条件所产生的系统行为？（２）正确性•是否有需求与其它需求相冲突或重复？•是否简明、简洁、无二义性地表达每个需求的？•是否每个需求都能通过测试、演示、审查得以验证或分析？•是否每个需求都在项目的范围内？•是否每个需求都没有内容上和语法上的错误？•在现有的资源限制内，是否能实现所有的需求？•是否任一个特定的错误信息都具有唯一性和明确的意义（３）可行性•需求定义是否使软件的设计、实现、操作和维护都可行？•所规定的模式、数值方法和算法是否对待解问题合适？是否能够在相应的限制条件下实现？•是否能够达到关于质量的要求？（４）易修改性：•对需求定义的描述是否易于修改？例如是否采用良好的结构和交叉引用表等等？•是否有冗余的信息？是否一个需求被定义多次？（５）健壮性：是否有容错的需求？（６）易理解性：•是否每一个需求都只有一种解释？•功能性需求是不是以模块方式描述的，是否明确地标识出其功能？•是否使用了形式化或半形式化的语言？•语言是否有歧义性？•需求定义是否只包含了必要的实现细节而不包含不必要的实现细节？是否过分细致了？•需求定义是否足够清楚和明确使其已能够作为开发设计规约和功能性测试数据基础？•需求定义的描述是否将对程序的需求和所提供的其它信息分离开来?（７）易测试性和可验证性：•需求是否可以验证？•是否对每一个需求都指定了验证过程？•数学函数的定义是否使用了精确定义的语法和语法符号？（８）完备性：•规定的需求定义所应该包含的所有内容？•需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有需求？•功能性需求是否覆盖了所有非正常情况的处理？•是否已对各种操作模式（如正常、非正常、有干扰等）下的环境条件都作规定？•是否识别出了所有与时间因素有关的功能？它们的时间准则是否都明了？时间准则的最大、最小执行时间是否都定义了？•是否识别定义了在将来可能会变化的需求？•是否定义了系统的所有输入？•是否标识清楚了系统输入的来源？•是否识别了系统的输出？•是否说明了系统输入、输出的类型？•是否说明了系统输入、输出的值域、单位、格式等？•是否说明了如何进行系统输入的合法性检查？•是否定义了系统输入、输出的精度？•在不同负载情况下，系统的生产率如何？•在不同的情况下，系统的响应时间如何？•系统对软件、硬件或电源故障必须作什么样的反应？•是否充分定义了关于人机界面的需求？（９）一致性：•各个需求之间是否一致？是否有冲突和矛盾•所规定的模型、算法和数值方法是否相容？•是否使用了标准术语和定义形式？•需求是否与其软硬件操作环境相容？•是否说明了软件对其系统和环境的影响？•是否说明了环境对软件的影响？（１０）质量属性•是否合理地确定了性能目标？•是否合理地确定了安全与保密方面的考虑？•在确定了合理的折衷情况下，是否详实地记录了其它相关的质量属性？使用实例文档审查清单：•使用实例是否是独立的分散任务？•使用实例的目标或价值度量是否明确？•使用实例给操作者带来的益处是否明确？•使用实例是否处于抽象级别上，而不具有详细的情节？•使用实例中是否不包含设计和实现的细节？•是否记录了所有可能的可选过程？•是否记录了所有可能的例外条件？•是否存在一些普通的动作序列可以分解成独立的使用实例？•是否简明书写、无二义性和完整地记录了每个过程的对话？•使用实例中的每个操作和步骤是否都与所执行的任务相关？•使用实例中定义的每个过程是否都可行？•使用实例中定义的每个过程是否都可验证？８．３软件需求评审问题与困难一、几个案例案例一某领域专家A先生就某企业的成本管理系统做用户需求报告的评审工作，在评审会开始时间不长，就被在场的企业的一位副总B先生打断，认为A先生提出的方案不适合本企业，A先生提出的管理改进方案在企业中无法实施。该副总提完意见后，与会的用户方人员纷纷跟随B先生的提出了他们的反对意见，致使评审会无法再进行下去，最终该报告被用户否决。案例二某软件公司内部举行产品的需求评审会，主要是公司内部的领域专家参加，在评审会开始后不久，某领域专家就对需求报告中的某个具体问题提出了自己的不同意见，于是，与会人员纷纷就该问题发表自己的意见，大家争执不下，结果，致使会议出现了混乱状况，主持人无法控制局面，会议大大超出了计划评审时间。案例三某软件公司为某公司A做业务流程管理系统的需求评审会，当项目组人员在会议上宣读多达上百页的需求报告时，用户明确提出听不懂，致使会议不得不改日进行。案例四某软件公司在用户处开完物资管理系统的需求评审会后，与会人员离开会议室时，纷纷摇头，认为本次会议没有多少实际效果，完全是在走过场。案例五某软件公司在公司内部举行产品的需求评审会时，需求报告的执笔人与产品策划主要策划人员的想法差别很大，致使需求评审会没有必要继续进行下去。二、需求评审中常见的问题是：需求报告很长，短时间内评审者根本就不能把需求报告读懂，想清楚；没有作好前期准备工作，需求评审的效率很低;需求评审的节奏无法控制；找不到合格的评审员，与会的评审员无法提出深入的问题；……1)大型的需求文档2)庞大的审查小组用以下的方法处理庞大的审查小组：•确保每个参与者都是为了寻找错误，而不是为了解软件需求规格说明中的内容或者为了维护行政上的位置。如果一些参与者只是想大概了解审查的内容，那么就邀请他们去参加总体会议，而不是参加审查会。•理解审查员所代表的观点（例如客户、开发者或测试者），并且委婉地拒绝以相同的观点看待问题的参与者