软件需求工程-北京大学软件与微电子学院

第六章软件需求验证周立新博士北京大学软件与微电子学院课程提纲1.软件需求基本理论和概念2.软件需求工程过程3.软件需求获取4.软件需求分析5.软件需求规格说明6.软件需求验证7.软件需求管理8.软件需求实现9.软件需求工程新进展10.软件需求开发与需求管理工具内容提要•软件的质量属性分析•需求质量验证•需求评审•需求测试1.软件的质量属性分析•软件质量属性(或质量因素)的特性是系统非功能（也叫非行为）部分的需求。这些特性包括：–产品的易用程度如何，–执行速度如何，–可靠性如何，–当发生异常情况时，系统如何处理等。•质量属性区分：–一种属性分类的方法是把在运行时可识别的特性与那些不可识别的特性区分开；–另一种方法是把对用户很重要的可见特性与对开发者和维护者很重要的不可见特性区分开。那些对开发者具有重要意义的属性使产品易于更改、验证，并易于移植到新的平台上，从而可以间接地满足客户的需要。软件质量属性列表对用户最重要的属性：对开发者最重要的属性：可用性（availability）可维护性(maintainability）高效性(efficiency)可移植性(portability)灵活性(flexibility)可重用性(reusability)完整性(integrity)可测试性(testability)互操作性(interoperability)可靠性(reliability)健壮性(robustness)Relationshipsamongselectedqualityattributes2.需求质量验证•需求验证是需求开发的第四部分（其余三个为获取、分析和编写规格说明），所包括的活动是为了确定以下几方面的内容：–软件需求规格说明正确描述了预期的系统行为和特征。–从系统需求或其它来源中得到软件需求。–需求是完整的和高质量的。–所有对需求的看法是一致的。–需求为继续进行产品设计、构造和测试提供了足够的基础。•需求验证确保了需求符合需求陈述（requirementstatement）的良好特征（完整的、正确的、灵活的、必要的、具有优先级的、无二义性及可验证的）并且符合需求规格说明的良好特性（完整的、一致的、易修改的、可跟踪的）。当然，你只能验证那些已编写成文档的需求，而那些存在于用户或开发者思维中的没有表露的、含蓄的需求则不予验证。需求质量验证•在收集需求并编写成需求文档后，你所进行的需求验证并不仅仅是一个独立的阶段。一些验证活动，例如对渐增型软件需求规格说明的反复评审，将贯穿着反复获取需求、分析和编写规格说明的整个过程。其它的验证步骤，例如软件需求规格说明的正式审查，是在正式确定软件需求规格说明基线之前对需求分析质量进行的最后一次有用的质量过滤。当你的项目计划或实际工作中的独立任务破坏了结构性时，就要结合进行需求验证活动，并且为随后出现的返工预先安排一段时间，这通常会在质量控制活动之后进行。需求质量验证•有时，项目的参与者不愿意在评审和测试软件需求规格说明上花费时间。虽然在计划安排中插入一段时间来提高需求质量似乎相应地把交付日期延迟了一段时间，但是这种想法是建立在假设验证需求上的投资将不产生效果的基础上的。实际上，这种投资可以减少返工并加快系统测试，从而真正缩短了开发时间。需求质量验证Validation•Answerthequestion“DoIbuildtherightthing?”•Requirementsvalidationisdoneeitheragainstreal-worlduserneedsorhighlevelrequirementsspecificationsVerification•Answerthequestion“DoIbuildwhatIwasgoingtobuild?”•Requirementsverificationisdonetypicallyagainstlowerlevelrequirements,designand/ortestprocedures需求评审•由一些非软件开发人员进行产品检查以发现产品所存在的问题，这就是技术评审。需求文档的评审是一项精益求精的技术，它可以发现那些二义性的或不确定的需求，那些由于定义不清而不能作为设计基础的需求，还有那些实际上是设计规格说明的所谓的“需求”。•需求评审也为风险承担者们提供了在特定问题上达成共识的方法。需求评审方法•非正式评审的方法包括把工作产品分发给许多其它的开发人员粗略看一看和走过场似地检查一遍（walkthrough）。•正式技术评审的最好类型叫作审查（Inspection）。正式评审内容需要记录在案，它包括确定材料、评审员、评审小组对产品是否完整或是否需要进一步工作的判定，以及对所发现的错误和所提出的问题的总结。正式评审小组的成员对评审的质量负责，而开发者则最终对他们所开发的产品的质量负责。•如果你对提高软件的质量持有认真的态度，那么就审查所编写需求文档的每一行。SoftwareRequirementReview•Informalreview–Peerdeskcheck–Passaround,suchasthroughemail–Walkthrough•Formalreviews–Faganinspection-usedbymanyorganizationasaneffectivewaytoimprovesoftwarequalityPeerReview需求审查过程1.参与者①产品的开发者及其可能的同组成员——编写需求文档的分析员提供这方面观点。②先前产品的开发者或正在评审的项目的规格说明编写者。③要根据正在审查的文档来开展工作的人们----对于一个软件需求规格说明，你可能需要包括一个开发人员、一个测试人员、一个项目经理和一个用户文档编写人员，他们的工作基础都是软件需求规格说明。这些审查人员将会发现不同类型的问题。–审查组中的审查人员应限制在7个人左右或者更少。需求审查过程2.审查中每个成员扮演的角色–作者。作者创建或维护正在被审查的产品。–调解者。调解者（moderator）或者审查主持者所做的是：与作者一起为审查制订计划，协调各种活动，并且推进审查会的进行。–读者。读者的角色由审查员扮演。–记录员。记录员，或书记员，用标准化的形式记录在审查会中提出的问题和缺陷。记录员必须仔细审查所写的材料以确保记录的正确性。需求审查过程3.审查阶段–规划（Planning）。作者和调解者协同对审查进行规划，以决定谁该参加审查，审查员在召开审查会之前应收到什么材料并且需要召开几次审查会。–总体会议（overviewmeeting）。总体会议可以为审查员提供了解会议的信息，包括他们要审查的材料的背景，作者所作的假设和作者的特定审查目标。–准备（Preparation）。在正式审查的准备阶段，每个审查员以典型缺陷（defect）清单（在本章的后面部分介绍）为指导，检查产品可能出现的错误，并提出问题。需求审查过程3.审查阶段–审查会议（Inspectionmeeting）。在审查会进行过程中，读者通过软件需求规格说明指导审查小组，一次解释一个需求。当审查员提出可能的错误或其它问题时，记录员就记录这些内容，其形式可以成为需求作者的工作项列表。会议的目的是尽可能多地发现需求规格说明中的重大缺陷。–重写（rework）。我所观察到的几乎每一个质量控制活动都可能发现一些需求缺陷。因此，作者必须在审查会之后，安排一段时间用于重写文档。–重审（follow-up）。这是审查工作的最后一步，调解者或指派人单独重审由作者重写的需求规格说明。重审确保了所有提出的问题都能得到解决，并且正确修改了需求的错误。重审结束了审查的全过程并且可以使调解者做出判断：是否已满足审查的退出标准。需求审查过程4.进入和退出审查的标准a)一些关于需求文档的进入审查的标准：•文档符合标准模板。•文档已经做过拼写检查和语法检查。•作者已经检查了文档在版面安排上所存在的错误。•已经获得了审查员所需要的先前或参考文档，例如系统需求规格说明。•在文档中打印了行序号以方便在审查中对特定位置的查阅。•所有未解决的问题都被标记为TBD（待确定）。•包括了文档中使用到的术语词汇表。需求审查过程4.进入和退出审查的标准b)一些关于需求文档的退出标准：•已经明确阐述了审查员提出的所有问题。•已经正确修改了文档。•修订过的文档已经进行了拼写检查和语法检查。•所有TBD的问题已经全部解决，或者已经记录下每个待确定问题的解决过程，目标日期和提出问题的人。•文档已经登记入项目的配置管理系统。•检查是否已将审查过的资料送到有关收集处。需求审查过程5.需求审查清单–为了使审查员警惕他们所审查的产品中的习惯性错误，对你的公司所创建的每一类型的需求文档建立一份清单。–这些清单可以提醒审查员以前经常发生的需求问题。需求评审的困难•大型的需求文档•庞大的审查小组–确保每个参与者都是为了寻找错误，而不是为了解软件需求规格说明中的内容或者为了维护行政上的位置。–理解审查员所代表的观点（例如客户、开发者或测试者），并且委婉地拒绝以相同的观点看待问题的参与者。–把审查组分成若干小组并行地审查软件需求规格说明，并把他们发现的错误集中起来，剔除重复的部分。•审查员在地域上的分散需求测试•通过阅读软件需求规格说明，通常很难想像在特定环境下的系统行为。•以功能需求为基础或者从使用实例派生出来的测试用例可以使项目参与者看清系统的行为。虽然没有在运行系统上执行测试用例，但是设计测试用例的简单动作可以解释需求的许多问题。•如果你在部分需求稳定时就开始开发测试用例，那么就可以及早发现问题并以较少的费用解决这些问题。•编写关于黑盒子或功能上的测试用例可以明确在特定条件下系统运行的任务。因为你无法描述可能的系统响应，在你面前将会出现一些模糊的和二义性的需求。•当分析员、开发人员和客户通过测试用例进行研究时，他们将对产品如何运行的问题有更清晰的认识。需求测试•在开发过程的早期阶段，可以从使用实例中获得概念上的功能测试用例。然后，你就可以利用测试用例来验证文本需求规格说明和分析模型（例如对话图）并评价原型。这些基于模仿使用的测试用例可以作为客户验收测试的基础。•在正式的系统测试中，可以把它们详述成测试用例和过程。•在客户定义他们验收的标准时，你询问客户的基本问题是：“如果开发出你们所期望的软件，你是怎么来判断开发出的软件是你真正所需要的？”如果他们不能回答关于每个特性或使用实例的这种问题，他们就必须澄清需求。需求测试的含义最初对你来说可能看起来比较抽象。可以用一个例子把这个概念描述得更清楚，所以让我们看一下“化学制品跟踪系统”的开发组是如何把需求规格说明、分析模型和早期创建的测试用例结合在一起。下面列出了与请求化学制品这一任务相关的一个业务需求、使用实例、功能需求、部分对话图和一个测试用例。1.业务需求，该系统的一个主要业务动机可以用如下的需求来描述：“化学制品跟踪系统”通过鼓励重复使用公司中可用的那些化学制品容器以降低购买费用。2.使用实例，与这个业务需求相一致的一个使用实例是“请求一种化学制品”，它包括允许用户请求化学制品仓库中已有的化学制品的路径。3.功能需求，以下是关于让用户选择可用的化学制品的一些功能，而不是向外部供应商发送订单：如果请求化学制品仓库中的容器，系统将显示可用容器的列表，用户就可以选择一个容器或要求向外部供应商订购一个新容器。4.对话图（dialogmap），图14-6描述了“请求一种化学制品”使用实例中关于这一功能的部分对话图。5.测试用例（testcase），由于这个使用实例有许多可能的执行路径，所以你可以想出许多测试用例来阐明普通过程、可选过程和例外。需求测试