软件需求工程 课件 第8、9章 需求验证、需求管理

第8章需求验证

目录需求验证的目的和任务需求验证的内容和方法需求评审需求可视化8-18-28-38-48-58-68-7编制用户使用手册草案解释需求模型需求测试8-1需求验证的目的和任务需求验证包含的活动需求验证的目的：确保需求规格说明具有良好的特性（如完整性，正确性等）。软件需求规格证明是否正确描述了目标系统的行为和特征；从其它来源中（包括硬件的系统需求规格说明书）得到软件需求；需求是完整的和高质量的；所有人对需求的看法是一致的；需求验证的任务：要求各方人员从不同的技术角度对需求规格说明文档做出综合性评价。在收集需求并且编写成需求规格说明文档后进行需求验证并不仅是一个独立的阶段,而且某些验证活动,如对渐增式软件需求规格说明的评审工作,将在需求获取、分析和定义需求规格说明的整个过程中反复进行。8-1需求验证的目的和任务8-2需求验证的内容和方法为了确保软件开发成功和降低开发成本,就必须严格验证软件需求。一般来说,应该从下述4个方面进行验证：1.一致性2.完整性3.现实性4.有效性

一般还可根据软件系统的特点和用户的要求(如嵌入式系统等)增加一些检验内容，如软件的可信特性，即安全性、可靠性、正确性以及系统的活性等。8-2需求验证的内容和方法需求验证的内容需求验证的方法目前验证需求的方法除形式化方法外，主要靠人工技术审查和验证软件需求规格说明。8-3需求评审需求评审就是技术评审，由非软件开发人员对软件系统的进行检查以发现该系统所存在的问题。技术评审又可根据评审的方法划分为以下两处：1.非正式评审：由开发人员描述产品并征求意见，包括把工作产品分发给许多其他有关人员粗略地看一看或走过场地检查。非正式评审的好处是能培养其他人对产品的认识，并可获得一些非结构化的反馈信息。它的不足之处是不够系统化和不彻底，或者在实施过程中不具有一致性，并且该评审不需要记录,完全可以根据个人爱好进行。2.正式评审：是正式技术评审中最好的类型，应该包含一个由不同背景的审查人员组成的小组。这些审查人员首先阅读需求规格说明文档,把其中的问题记录下来,然后转送给软件开发人员。正式评审有正规的审查过程，审查人员有严格的分工和职责。8-3需求评审需求评审的定义8-3-1审查人员的确定和分工正式评审中,应由具有不同背景的人组成一个小组对需求规格说明文档进行评审。为提高审查的有效性，审查人员必须由如下4个方面的人组成：1.从事软件系统需求开发的相关人员。2.具有编写需求规格说明经验和知识的人员，以及具有评审工作经验的领域专家等。3.客户或同户代表，他们可以保证需求规格说明能正确地和完整的描述他们的需求。4.将依据需求规格说明开展工作的软件开发人员，如设计人员，测试人员，项目经理等。审查人员在审查中所起的作用可分类如下:1.作者，这些人通常为系统分析员。2.调解员，通常为项目总负责人。3.读者，主要由审查人员扮演。4.记录员。8-3需求评审审查过程中每个步骤的工作内容简要说明如下。首先,在进入筹备阶段之前,调解员可建立一些进入审查的标准,根据这些标准判断能否进行正式审查。建立这些标准需根据项目的实际情况决定。例如,下面是一些关于需求规格说明文档进入审查的参考标准：文档符合标准模板。文档已经过拼写检查和语法检查。作者已经检查了文档在版面安排上所存在的错误。所有未解决的问题都已做出标记(待确定)。包括了文档中使用到的术语词汇表。当软件需求规格说明文档满足审查标准时，就可决定进入正式审查的筹备阶段。如右图所示：8-3-2正式的审查过程8-3需求评审需求评审的工作：评审需求规格说明的内容。通常，问题审查清单列举的问题可考虑如下：1）需求是否完整？即评审人员是否知道有任何遗漏的需求或在单个需求措施中有无遗漏的信息。2）需求是否一致？即不同的需求间是否存在冲突，特别是不同层次间的需求如目标需求与功能或性能需求是否一致。3）需求是否可理解？即所有文档的读者是否理解需求的意思。4）需求是否明确？即该需求是否有不同的解释。5）需求是否可实现？即该需求的实现会给开发工作带来什么样的技术风险等。6）需求是否可跟踪？即一个需求是否包含或涉及其他相关需求，以及这些需求为什么会被包含或被涉及。7）需求是否易于修改？即软件需求将来需进行增加或修改时，是否会引起一系列变动等。8）需求规格说明文档是否完整?即文档是否符合某一标准,如国家、军队或公司内8-3-3审查的内容8-3需求评审需求评审工作也面临着许多困难，一些常见的困难说明如下：开发人员最重要的是后面的开发工作，从而导致需求评审成为“走过场”;需求评审的工作量大,对于一个大型的复杂系统，其需求规格说明往往有几百页，要审查这样的需求规格说明是十分可怕的。过大的评审小组。同一个用户界面的设计，不同的人就有不同的看法，导致意见不一致。对于上述这些困难，往往要根据实际情况给予解决。例如，可在强调评审工作重要性的基础上，采取解释与说明的方式，采用多人分段审查的方式，以及采取分组方式等。8-3-4需求评审面临的困难8-3需求评审8-4需求测试8-4需求测试为需求设计测试用例可以确认需求而不能确认系统。即使没有对实际系统使用测试用例,但通过设计测试用例就可以解释需求的许多问题,如果在部分需求稳定时就开始设计测试用例,则可以及早发现问题,并以较少的费用解决这些问题。需求测试可以使用如下方法：1.以功能需求为基础，视其为黑盒子，编写关于该功能或黑盒子的测试用例。2.这些用例可以明确在特定条件下运行的任务。由于无法描述系统的响应,故测试中将会发现一些模糊的和二义性的需求。需求测试的方法

定义测试用例为了定义测试用例，可以通过提问的方式，比如：1）什么样的用例可以用来检查需求？这定义了测试用例将从何处来。2）需求本身包含的信息足够定义一个测试用例吗？如果不是，那么为找到其他的信息还需检查哪些其他需求;如果是的话,则表明需求间可能存在依赖性。这对于可跟踪性来说是重要的。3）可以用一个测试用例检查需求吗？还是需要若干个测试用例？如果需要多个测试用例，则意味着一个需求描述中包含多个要求。8-4需求测试8-5编制用户使用手册草案8-5编制用户使用手册草案编制用户使用手册的好处在编制该手册的过程中，可强化对需求的仔细分析，帮助揭示与系统的实际使用相关的问题，即系统的可用性问题未被掩盖。可以帮助阐明用户界面设计问题，从而促使软件开发人员一开始就站在用户的角度来设计用户界面，并及早考虑人-机交互中的接口问题。编制用户使用手册的要求在编制用户使用手册草案时应以最终用户能理解的方式解释在需求中描述的系统功能，应尽可能采用用户能理解的术语书写要描述的功能，并告诉他们应该怎样使用这些功能。需求文档上述的需求验证（包括形式化方法）完成后，由开发人员与用户（或需求方）双方共同签署软件需求规格说明文档，这个文档定义了软件开发的基准需求。8-6解释需求模型8-6解释需求模型用自然语言解释需求模型的好处通常需求模型(或分析模型)是用图形或形式化语言和符号表示的。用自然语言解释需求模型的好处：有利于评审人员理解和评审需求规格说明；有助于发现模型中的一些错误。在用自然语言解释解释者来说，他们不用尽力说明模型或者提供理由，但他们要熟悉被说明系统的类型；应避免语言的生硬和呆板,特别是不能把不存在的信息加入需求模型中。8-7需求可视化8-7需求可视化软件需求验证的问题形式化验证方法的好处是严格和自动化,能够高效地获得可靠的验证结果。非形式化方法或人工方法一般直观性较好而且简单,易于被开发人员掌握和操作,便于用户参与验证过程。但由于参与者的主观性,导致验证过程不够严密且随意性较大,难以保证验证结果的正确性和完整性需求可视化的定义需求可视化指使用图形，图像或者图片等技术，使一些不可见的对象、表达或者抽象概念变成可见的符号。静态表示需求模型又可具体归纳为以下几种方式：列表可视化：使用表格方式来描述需求信息，以辅助需求获取和需求描述等工作。关系可视化：使用一组节点符号以及关系连线表示组件或系统之间的关系。序列可视化:

使用可视化技术表达系统之间,或者用户和系统之间的操作顺序,这部分工作和传统的流程图、状态图等类似。层次可视化：用于表达系统、系统部件间的层次分解关系，典型的方式是基于目标的建模方法。定量（quantitative）分析可视化：使用饼状图、柱状图及不同颜色和形状等符号表示需求中的相关数据、程度等。8-7需求可视化静态表示需求模型可视化的研究从表达技术和表达内容上大致综合为两类：一类是利用各种图形符号静态地表示需求模型,一类是使用动态的需求动画(requirementanimation)动态地表示需求模型。需求动画利用图形符号的动态变化来展示需求模型中的动态内容,模拟目标软件的执行过程，有益于用户更好地理解和验证需求模型。表达系统的动态行为，即利用图形符号或图像动态地表示需求模型中的动态行为。很多研究工作尝试为不同的需求建模方法以及工具提供需求动画功能，这些工具按其自动化程度可粗略归纳为如下两类:一部分工具的动画生产过程自动化程度较高。另一部分工具是使用现实世界的图形和图像作为动画执行元素，用需求模型来驱动这些动画元素的执行。这些工具生成的动画便于非专业的用户理解,能够很好地促进用户和开发人员的交流。8-7需求可视化动态表示需求模型综上所述，基于需求动画的需求检验过程可归纳为图8-2所示的过程。第1步是从用户获取原始需求信息，生成最初的需求文档（或需求规格说明)；第2步是基于需求文档建立需求模型；第3步是形式化验证需求模型的正确性；第4步是基于需求模型建立需求动画；第5步是向用户演示需求动画，获取用户反馈信息。当用户提出修改意见后，重复第2一5步的过程。8-7需求可视化基于需求动画的需求检验过程为了较好地发挥需求动画的作用，通过研究和分析现有的相关工作,总结出在实现需求动画的过程中需要注意如下几点：1）为了使需求模型能与动画较好地衔接，在选择需求建模方法和语言的同时，还需研究需求动画的特点,使得该建模方法和语言既能独立用于建模,又能用于描述动画执行所需要的关键信息，增强需求模型和动画描述模型（用于控制动画实际运行的模型)的同构性。2）需求动画的自动化程度是决定需求动画方法应用推广的关键因素，可能需要建立一套从需求模型到动画描述模型的转换规则，提高转换过程的自动化程度，同时保证模型转换的正确性。3）需求动画的目的：以直观的方式向不同知识背景的用户准确地表达需求中的复杂行为。8-7需求可视化实现需求动画的关键点第9章需求管理需求管理的定义管理内容所谓需求管理就是为有效地控制和管理需求更改等所进行的一系列活动。主要任务：开发人员在与提出更改的请求者（用户）协商的基础上，评估需求变更带来的潜在影响及可能的成本及费用；然后实施更改，以及有效地管理需求规格说明文档和跟踪更改需求的状态。1）控制对基准需求规格说明的变动。2）保持项目计划与需求一致。3）控制单个需求的更改和需求规格说明文档的更改。4）管理需求和需求间的联系，以及需求与设计和实现等方面的依赖关系。5）跟踪需求更改的状态，控制多个需求同时更改的复杂性。需求管理

目录需求变更控制需求规格说明文档的版本控制需求变更状态的跟踪需求跟踪9-19-29-39-49-1需求变更控制9-1需求变更控制需求变更的内容主要涉及两个方面：一方面是需求变更只对软件系统内部产生影响,例如一个需求变更可能只影响某个功能需求，而不影响其他需求。另一方面是在原有软件需求的基础上提出扩充软件系统功能的需求，就是扩展需求。1.控制项目范围的扩展变更控制策略与需求变更的过程和标准相关。这些策略描述了变更以何种形式提出、分析和处理。以下提供一些有用的和可供参考的策略：1）建立所有需求变更所应遵循的过程（包括变更步骤）。按此过程，当一个变更需求在过程中某一步被拒绝后，则其后的步骤将不再予以考虑。2)

对于未获批准的变更，除进行可行性论证外，不应再做其后的工作。3）对所提出的多个变更请求，应由项目变更小组委员会决定实现哪些变更，以及先后次序。4）项目开发人员和用户应该能了解已变更需求的情况。5)

不准随意删除和修改与需求变更请求和实现相关的原始文档。6）每一个实施后的变更必须与一个经核准的变更请求相对应。2.建立变更控制的策略9-1需求变更控制3.变更控制的步骤实施变更控制的步骤如图9-1所示。此图是用流程图的形式来描述的。变更控制的步骤中，每步的工作任务明确，各步间是相互依赖的。各步的具体任务：1）变更控制的启动。启动的条件是通过合适的渠道接受一个合法的变更请求。2）确定角色与责任。3）影响分析与评估。评估变更请求的技术可行性、代价和资源限制等，提供对变更请求的准确理解，帮助做出信息量充分的变更批准决策。4）实施变更。当需求变更请求被采纳后，开始对涉及的软件系统实施更新。5）验证。主要是通过检查来确保更新后的需求规格说明的正确性。6）变更控制的结束。9-2需求规格说明文档的版本控制软件需求版本控制是需求管理的一个必要方面，也是容易忽视和出错的方面。需求规格说明的每一个版本必须统一确定，并保证开发人员必须知道和得到新的需求规格说明版本。为了有效地实施版本控制，可以遵循如下的版本控制策略:1）专人修改。2）版本应该包括修改版本的历史情况。3）根据修改工作量的大小手工标记需求规格说明版本的每一次修改。4）每个版本的需求规格说明必须是独立说明的，以避免新旧版本的混淆。9-2需求规格说明文档的版本控制版本控制策略9-3需求变更状态的跟踪9-3需求变更状态的跟踪对于一个大型而复杂的软件系统的需求规格说明，可能会面临多个需求变更的情况。为了便于管理和控制需求变更，对于一个变更请求可用状态图来描述其在不同时间所处的状态，以使各类人员知道更改的进度。图9-2表示一个需求变更请求所对应的状态图，其中方框表示需求变更状态。为了便于管理和控制需求变更，可建立一个如表9-1所示的数据库或文件来记录需求变更请求。需求变更请求状态9-4需求跟踪需求跟踪的定义所谓需求跟踪是指编制每个需求与系统元素之间联系（即可跟踪信息）的文档，其中,系统元素包括:其他需求、体系结构、设计部件、测试文档等。9-4需求跟踪9-4-1可跟踪信息分类软件需求与系统元素之间的联系有很多，为简单起见，此处根据需求系统元素之间联系的类型把可跟踪性信息粗略分为如下几类:(1)需求—源可跟踪性(2)需求—理由可跟踪性(3)需求—需求可跟踪性(4)需求—体系结构可跟踪性(5)需求—设计可跟踪性(6)需求—用户界面可跟踪性9-4需求跟踪9-4-2需求跟踪技术有两种技术可用于维护可跟踪信息：需求跟踪表和可跟踪性表。需求跟踪表（需求跟踪能力矩阵）表示需求和系统元素之间联系的最普遍的方式是使用需求跟踪表。表9-2是一张有n个需求和m个系统元素的需求跟踪表，需求沿水平方向给出，系统元素沿垂直方向给出，两者之间的关系