软件需求工程 课件 第8章 需求验证.pptx

第8章需求验证;目录;8-1;需求验证包含的活动;8-2;;8-3;需求评审就是技术评审，由非软件开发人员对软件系统的进行检查以发现该系统所存在的问题。

技术评审又可根据评审的方法划分为以下两处：

1.非正式评审：由开发人员描述产品并征求意见，包括把工作产品分发给许多其他有关人员粗略地看一看或走过场地检查。非正式评审的好处是能培养其他人对产品的认识，并可获得一些非结构化的反馈信息。它的不足之处是不够系统化和不彻底，或者在实施过程中不具有一致性，并且该评审不需要记录,完全可以根据个人爱好进行。

2.正式评审：是正式技术评审中最好的类型，应该包含一个由不同背景的审查人员组成的小组。这些审查人员首先阅读需求规格说明文档,把其中的问题记录下来,然后转送给软件开发人员。正式评审有正规的审查过程，审查人员有严格的分工和职责。;8-3-1审查人员的确定和分工;审查过程中每个步骤的工作内容简要说明如下。首先,在进入筹备阶段之前,调解员可建立一些进入审查的标准,根据这些标准判断能否进行正式审查。建立这些标准需根据项目的实际情况决定。例如,下面是一些关于需求规格说明文档进入审查的参考标准：

文档符合标准模板。

文档已经过拼写检查和语法检查。

作者已经检查了文档在版面安排上所存在的错误。

所有未解决的问题都已做出标记(待确定)。

包括了文档中使用到的术语词汇表。

当软件需求规格说明文档满足审查标准时，

就可决定进入正式审查的筹备阶段。

如右图所示：

;需求评审的工作：评审需求规格说明的内容。

通常，问题审查清单列举的问题可考虑如下：

1）需求是否完整？即评审人员是否知道有任何遗漏的需求或在单个需求措施中有无遗漏的信息。

2）需求是否一致？即不同的需求间是否存在冲突，特别是不同层次间的需求如目标需求与功能或性能需求是否一致。

3）需求是否可理解？即所有文档的读者是否理解需求的意思。

4）需求是否明确？即该需求是否有不同的解释。

5）需求是否可实现？即该需求的实现会给开发工作带来什么样的技术风险等。

6）需求是否可跟踪？即一个需??是否包含或涉及其他相关需求，以及这些需求为什么会被包含或被涉及。

7）需求是否易于修改？即软件需求将来需进行增加或修改时，是否会引起一系列变动等。

8）需求规格说明文档是否完整?即文档是否符合某一标准,如国家、军队或公司内;

;8-4;8-4;定义测试用例;8-5;8-5;8-6;8-6;8-7;8-7;静态表示需求模型又可具体归纳为以下几种方式：

列表可视化：使用表格方式来描述需求信息，以辅助需求获取和需求描述等工作。

关系可视化：使用一组节点符号以及关系连线表示组件或系统之间的关系。

序列可视化:使用可视化技术表达系统之间,或者用户和系统之间的操作顺序,这部分工作和传统的流程图、状态图等类似。

层次可视化：用于表达系统、系统部件间的层次分解关系，典型的方式是基于目标的建模方法。

定量（quantitative）分析可视化：使用饼状图、柱状图及不同颜色和形状等符号表示需求中的相关数据、程度等。;需求动画利用图形符号的动态变化来展示需求模型中的动态内容,模拟目标软件的执行过程，有益于用户更好地理解和验证需求模型。表达系统的动态行为，即利用图形符号或图像动态地表示需求模型中的动态行为。

很多研究工作尝试为不同的需求建模方法以及工具提供需求动画功能，这些工具按其自动化程度可粗略归纳为如下两类:

一部分工具的动画生产过程自动化程度较高。

另一部分工具是使用现实世界的图形和图像作为动画执行元素，用需求模型来驱动这些动画元素的执行。这些工具生成的动画便于非专业的用户理解,能够很好地促进用户和开发人员的交流。;综上所述，基于需求动画的需求检验过程可归纳为图8-2所示的过程。第1步是从用户获取原始需求信息，生成最初的需求文档（或需求规格说明)；第2步是基于需求文档建立需求模型；第3步是形式化验证需求模型的正确性；第4步是基于需求模型建立需求动画；第5步是向用户演示需求动画，获取用户反馈信息。当用户提出修改意见后，重复第2一5步的过程。;为了较好地发挥需求动画的作用，通过研究和分析现有的相关工作,总结出在实现需求动画的过程中需要注意如下几点：

1）为了使需求模型能与动画较好地衔接，在选择需求建模方法和语言的同时，还需研究需求动画的特点,使得该建模方法和语言既能独立用于建模,又能用于描述动画执行所需要的关键信息，增强需求模型和动画描述模型（用于控制动画实际运行的模型)的同构性。

2）需求动画的自动化程度是决定需求动画方法应用推广的关键因素，可能需要建立一套从需求模型到动画描述模型的转换规则，提高转换过程的自动化程度，同时