需求验证的方法及特点课件

1、 第五章需 求 验 证金陵科技学院 软件工程学院 目 录5.1 需求的验证及过程5.2 需求验证的方法及特点5.2 需求验证的方法及特点 5.2.1 需求评审1.正式与非正式技术评审2.需求审查过程3.进入和退出审查的标准4.需求审查清单5.需求评审的困难5.2 需求验证的方法5.2.1 需求评审1.正式与非正式技术评审非正式评审的方法包括把工作产品分发给许多其它的开发人员粗略看一看，走过场似地检查一遍。5.2 需求验证的方法5.2.1 需求评审1.正式与非正式技术评审正式技术评审，叫作审查（inspection）（Ebenau and Strauss 1994; Gilb andGraham

2、 1993）。正式评审内容需要。正式评审小组的成员对评审的质量负责，而开发者则最终对他们所开发的产品的质量负责。如果认为没有时间详细审查每个方面，那么可以使用简单的风险分析模型，来区分需求文档哪些部分是需要详细审查的，哪些不重要部分只要用非正式评审就能满足质量要求。5.2 需求验证的方法5.2.1 需求评审2.需求审查过程参与评审的人员参与评审的人员，包括产品的开发者，以及可能的同组成员，包括先前产品的开发者或正在评审的项目的规格说明编写者，包括要根据正在审查的文档来开展工作的人们。很可能参与评审的人员包括一个开发人员、一个测试人员、一个项目经理和一个用户文档编写人员。他们的工作基础都是软件需

3、求规格说明。这些审查人员将会发现不同类型的问题。审查组中的审查人员应限制在7个人左右或者更少。5.2 需求验证的方法5.2.1 需求评审2.需求审查过程审查每个成员扮演的角色 作者：作者创建或维护正在被审查的产品。 调解者：调解者（moderator）或者审查主持者所做的是与作者一起为审查制订计划协调各种活动，并且推进审查会的进行。 读者：读者的角色由审查员扮演。 记录员：记录员或书记员用标准化的形式记录在审查会中提出的问题和缺陷。记录员必须仔细审查所写的材料以确保记录的正确性。5.2 需求验证的方法5.2.1 需求评审2.需求审查过程评审过程 规划（Planning）：作者和调解者协同对审查

4、进行规划，以决定谁该参加审查，审查员在召开审查会之前应收到什么材料并且需要召开几次审查会。 总体会议（overview meeting）：总体会议可以为审查员提供了解会议的信息，包括他们要审查的材料的背景，作者所作的假设和作者的特定审查目标。 5.2 需求验证的方法5.2.1 需求评审2.需求审查过程评审过程 准备（Preparation）：在正式审查的准备阶段，每个审查员以典型缺陷为清单，检查产品可能出现的错误并提出问题。审查会议（Inspection meeting）：在审查会进行过程中，读者通过软件需求规格说明指导审查小组一次解释一个需求。当审查员提出可能的错误或其它问题时记录员就记录这

5、些内容，其形式可以成为需求作者的工作项列表。会议的目的是尽可能多地发现需求规格说明中的重大缺陷。5.2 需求验证的方法5.2.1 需求评审2.需求审查过程 重写(rework):几乎每一个质量控制活动都可能发现一些需求缺陷。因此作者必须在审查会之后安排一段时间重写文档。 重审(follow-up):这是审查工作的最后一步调解者或指派人单独重审由作者重写的需求规格说明。重审确保了所有提出的问题都能得到解决，并且正确修改了需求的错误。重审结束了审查的全过程，并且可以使调解者做出判断是否已满足审查的退出标准。5.2 需求验证的方法5.2.1 需求评审3.进入和退出审查的标准一般，需求文档进入审查的标

6、准有：文档符合标准模板，文档已经做过拼写检查和语法检查，作者已经检查了文档在版面安排上所存在的错误，已经获得了审查员所需要的先前或参考文档，例如系统需求规格说明，在文档中打印了行序号以方便在审查中对特定位置的查阅，所有未解决的问题都被标记为TBD待确定，包括文档中使用到的术语词汇表。一般，需求文档退出审查的标准有：已经明确阐述了审查员提出的所有问题，已经正确修改了文档，修订过的文档已经进行了拼写检查和语法检查，所有TBD的问题已经全部解决或者已经记录下每个待确定问题的解决过程、目标、日期和提出问题的人，文档已经登记入项目的配置管理系统，已将审查过的资料送到有关收集处5.2 需求验证的方法5.2

7、.1 需求评审4.需求审查清单（对应图片模糊化处理，不用看到上面具体内容） 为了使审查员警惕审查的产品中的习惯性错误，需对所创建的每一类型的需求文档建立一份清单。清单可以提醒审查员以前经常发生的需求问题。5.2 需求验证的方法5.2.1 需求评审5.需求评审的困难需求评审可能存在各种困难。大型的需求文档，需要庞大的审查小组，需要确保每个参与者都是为了寻找错误，而不是为了解软件需求规格说明中的内容，或者为了维护行政上的位置。需要理解审查员如客户、开发者或测试者所代表的观点，并且委婉地拒绝以相同的观点看待问题的参与者。需要把审查组分成若干小组并行地审查软件需求规格说明，并把发现的错误集中起来，剔除

8、重复的部分。有时审查员在地域上的分散，也造成需求评审的困难。5.2 需求验证的方法5.2.2 原型法首先，确定合适原型，准备需求验证。接着，将需求验证涉及的复杂过程或场景定义出来，以辅助需求验证过程的开展。最后，根据已定义过程和场景，按照原型执行过程，发现需求的缺陷、问题并记录，以待后续修正。5.2 需求验证的方法5.2.3 测试用例开发1.需求测试举例：“Android点餐系统”的开发组是如何使用用户场景分析法，把“点餐下单”功能的需求规格说明、分析模型和早期创建的测试用例结合在一起的5.2 需求验证的方法5.2.3 测试用例开发1.需求测试举例：“Android点餐系统”的开发组是如何使用

9、用户场景分析法，把“点餐下单”功能的需求规格说明、分析模型和早期创建的测试用例结合在一起的。1）需求规格说明文档中这样描述：用户打开Android点餐系统客户端，登录帐号后进行网上点餐，选择菜品、座位，确定后提交订单，下单完成。5.2 需求验证的方法5.2.3 测试用例开发2）分析模型：例如，建模用户点餐下单顺序图，如图5.2.1：5.2 需求验证的方法5.2.3 测试用例开发1.需求测试举例3）用户场景描述：第一步:确定基本流和备选流基本流:用户打开客户端登录帐号选择菜品选择座位选择菜品数量下单生成订单备选流1：账户不存在；备选流2：账户密码错误；备选流3：座位已满； 备选流4：菜品数量不足

10、； 备选流5：菜品已卖完；5.2 需求验证的方法5.2.3 测试用例开发1.需求测试举例3）用户场景描述：第二步:根据基本流和备选流确定场景场景1 成功下单：基本流；场景2 帐号不存在：基本流，备选流1；场景3 帐号密码错误：基本流，备选流2； 场景4座位已满：基本流，备选流3；场景5菜品数量不足：基本流，备选流4；场景6菜品已卖完：基本流，备选流5； 5.2 需求验证的方法5.2.3 测试用例开发1.需求测试举例3）用户场景描述：第三步：对每个场景生成相应的测试用例对于这6个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面是一种通用格式，其中各行代表各个测

11、试用例，各列代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果，如表5.2.1所示。 5.2 需求验证的方法5.2.3 测试用例开发1.需求测试举例3）用户场景描述：第三步：对每个场景生成相应的测试用例测试用例ID场景/条件帐号密码座位可选数量菜品数量预期结果1场景1：成功下单VVVV下单成功2场景2：帐号不存在1n/an/an/a提示帐号不存在3场景3：帐号密码错误（帐号正确，密码错误）V1n/an/a提示帐号密码错误，返回基本流步骤24场景4：座位已满vv1n/a提示座位已满5场景5

12、：菜品数量不足vv1n/a提示菜品数量不足，显示剩余量6场景6： 菜品已卖完vvv1提示菜品已卖完，请选择其他菜品5.2 需求验证的方法5.2.3 测试用例开发1.需求测试举例3）用户场景描述：第四步：设计测试数据一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据，如表5.2.2所示 5.2 需求验证的方法5.2.3 测试用例开发1.需求测试举例3）用户场景描述：第四步：设计测试数据测试用例ID场景/条件帐号密码座位可选数量菜品数量预期结果实际结果XD1场景1：成功

13、下单Test001111112010下单成功，座位可选减少一位，菜品可点数量减少3份下单成功，座位可选减少一位，菜品可点数量减少3份XD2场景2：帐号不存在Testn/an/an/a提示帐号不存在提示帐号不存在XD3场景3：帐号密码错误（帐号正确，密码错误）Test00123456n/an/a提示帐号密码错误，返回基本流步骤2提示帐号密码错误，返回基本流步骤2XD4场景4：座位已满Test001111110n/a提示座位已满座位不可选XD5场景5：菜品数量不足Test00111111101提示菜品数量不足，显示剩余量显示菜品数量，不能输入大于菜品剩余量的数字XD6场景6： 菜品已卖完Test0

14、0111111100提示菜品已卖完，请选择其他菜品显示菜品数量为0，不能输入菜品数量5.2 需求验证的方法5.2.3 测试用例开发通过测试用例，可以验证需求，并发现需求的缺陷和问题。 5.2 需求验证的方法5.2.4 编制用户手册一般情况下，用户手册是在系统实现完成准备交付用户使用前编写，是为了帮助用户更好地使用系统，解决可能由于系统环境、配置、安装、功能操作不熟悉等原因带来的问题。但是，如果采用编制用户手册的方法来验证需求，则用户手册编制的工作可以在需求工程阶段就开始。5.2 需求验证的方法5.2.5 需求跟踪需求的发展是有前后联系的，需求之间具有可跟踪关系。如果根据系统需求，不能找到前项用

15、户需求和前项业务需求，那么，跟踪关系不存在，也就说明了该系统需求属于非必要需求，或者也可能发现该系统需求根本没存在的必要。同理，如果业务需求不能发现后项用户需求或后项系统需求的跟踪关系，那么说明该业务需求在需求逐步细化的过程中丢失了，也就发现了软件需求规格说明书的不完整性。5.2 需求验证的方法5.2.6 自动化分析自动化分析方法，一般采用形式化语言检查软件需求规格说明书存在的问题。但是由于形式化语言本身对客户具有难理解的特性，所以使用较少，到目前为止，还没有自动化需求验证方法，也没有成熟的、识别并诊断与需求不符的错误数据的方法。如果软件需求规格说明书的问题、缺陷、漏洞、不完整性、不统一性等诸

16、多问题，可以被自动分析后发现，对于人类在需求工程期间的任务将是一个巨大的进步。目前有研究者在这方面努力，以期取得较好的效果。例如已经有一些自动化工具和系统化方法能部分支持需求定义内在的一致性和完备性检查 , 使得软件需求的质量在一定程度上得到了保证, 但需求定义是否准确地反映用户需求的验证在目前还主要依赖于文档评审和原型示范等技术, 缺乏行之有效的系统化方法。5.2 需求验证的方法5.2.7其他方法目前研究需求验证的其他方法也有一些。有博士论文研究网络式软件需求验证的形式化方法，能有效的刻画用户需求的功能属性和非功能属性，有利于提高需求分析阶段的正确性和完整性，降低软件中因为用户需求的不正确而带来的错误以及资源的损失，提高软件开发的效率。有论文提出一个支持需求验证的过程模型(RVPM), 进行形式化描述, 并论述了需求验证过程的几个关键过程和策略。有基于有向