第8章 需求验证

2022/11/14
2
第8章 需求验证
8.1 需求验证的目的和任务 8.2 需求验证的内容和方法 8.3 需求评审 8.4 需求测试 8.5 编制用户使用手册草案 8.6 解释需求模型 8.7 需求可视化
2022/11/14
3
8.1需求验证的目的和任务
需求验证的目的就是要确保需求规格说明 具有良好的特性（如完整性，正确性等）。 需求验证包含的活动
具有评审工作经验的领域专家等； 3. 客户或同户代表，他们可以保证需求规格说明能
正确地和完整的描述他们的需求； 4. 将依据需求规格说明开展工作的软件开发人员，
如设计人员，测试人员，项目经理等。
2022/11/14
8
8.3需求评审
评审人员的分工
1. 作者，这些人通常为系统分析员； 2. 调解员，通常为项目总负责人； 3. 读者，主要由审查人员扮演； 4. 记录员。
用例
“请求一种化学制品” ，它包括允用户请求化学制品 仓库中已有的化学制品的路径。
请求者通过输入化学制品的ID号或从化学制品绘图工具 导入（import）化学结构来请求一种化学制品。系统则 通过向请求者提供来自化学制品仓库的一个新的或已用 过的化学制品容器或者让请求者向外部供应商发送订单 ，从而满足请求者的要求。
从DB40到DB70的导航是一个合法的系统行为，则可能是对 话图或可能是软件需求规格说明遗漏了用于执行测试用例的 需求。
29
29
测试需求-案例
测试用例
在这些例子中，分析员和测试人员在编写代码以前把需 求、分析模型和测试用例结合在一起来检测遗漏、错误 和不必要的需求。
收集需求并编写需求文档是软件项目设计成功的很好起 点。但还需要保证需求的正确性，使需求能体现出良好 需求说明的全部特性。
1. 有利于评审人员理解和评审需求规格说明； 2. 有助于发现模型中的一些错误。
要点 在用自然语言解释的过程中，应避免语言
的生硬和呆板，特别是不能把不存在的信息 加入到需求模型中。
2022/11/14
32
8.7需求可视化
软件需求检测和验证理论和技术
1. 形式化验证方法 2. 非形式化方法或人工方法 3. 将可视化技术与形式化需求验证方法相结合
大型的需求文档
审查一份几百页的软件需求规格说明是令人畏惧的 。
即使是一份中型的软件需求规格说明，审查员们可能会认 真地检查第一部分，一些意志坚定的人可以检查到中间部 分，但没有一个人可能检查到最后一部分。
在审查全部的文档之前，在开发软件需求规格说明 时，可以采用非正式的、渐增式的审查。
让一些审查员从文档不同位置开始检查，以确保认
评审员利用字处理软件在文档中插入评论。使用初始标记 让每个审查员都能看见先前审查员所写的评论。
基于Web的聊天工具可以进行实时的远程讨论。 基于Web的嵌入式协作软件工具。
就像软件开发技术公司所提供的Review也有助于进行远程 讨论。
18
18
8.3需求评审
如果不想通过审查会进行审查，那么你必须认 识到审查效率将下降约25%。
• 是否确定了对时间要求很高的功能并且定义了它们的时间标准？ • 是否已经明确地阐述了国际化问题？
13
8.3需求评审
需求评审面临的困难
1. 开发人员最重视的是后面的开发工作，从而导致 需求评审成为“走过场” ;
2. 需求评审的工作量大； 3. 过大的评审小组。
2022/11/14
14
8.3需求评审
24
测试需求-案例
测试用例
该用例有许多可能的执行路径，所以可以有许多测试用 例来阐明普通过程、可选过程和例外。
以下只是一个测试用例，该测试用例是以向用户显示化 学制品仓库中可用容器列表为基础的。该测试用例是从 该用户任务的用例说明和对话图中派生出来的：
在DB40对话框中，输入一个合法的化学制品ID号；化学 制品仓库中有两个这种化学制品的容器。此时出现了 DB50对话框，并带有两个容器号码。选择第二种容器。 关闭DB50，此时容器2被加入DB70对话框中当前化学制 品请求列表的底部。
把审查组分成若干小组并行审查软件需求规格说明，并把 他们发现的错误集中起来，剔除重复的部分。
审查小组总是发现错误的不同子集，所以并行审查的结果是 追加的，而不是冗余的。
17
17
8.3需求评审
审查员在地域上的分散
视频会议是一种有效的解决方案，但比起面对面的 会议，远程会议更难于进行调节。
在共享网络文件夹中的电子文件进行文档评审。
19
19
8.4 需求测试
为需求设计测试用例的目的 确认需求而不能确认系统。
方法
1. 以功能需求为基础，并视其为黑盒子，然后编写 关于该功能或黑盒子的测试用例。
2. 可以从用例中获得概念上的功能测试用例，然后 利用测试用例来验证需求规格说明和需求模型。
2022/11/14
20
8.4 需求测试
从使用实例中获得概念上的功能测试用例。然 后，利用测试用例来验证文本需求规格说明和 分析模型（例如对话图）并评价原型。
第8章 需求验证
1
第8章 需求验证
需求验证严格地说就是检验软件需求规格 说明，这是继需求分析之后需求开发的最后一 项活动。实际上需求分析和需求验证都包含发 现软件系统需求中的遗漏和错误的工作，只是 需求验证包含检测与软件系统相关的需求规格 说明等文档（如基准的需求规格说明），并使 得这些文档中不能再出现需求不完整或不一致 等问题。
正确性
• 是否有需求与其它需求相冲突或重复？ • 是否简明、简洁、无二义性地表达每个需求的？ • 是否每个需求都能通过测试、演示、审查得以验证或分析？ • 是否每个需求都在项目的范围内？
12
软件需求规格说明的审查清单
• 是否每个需求都没有内容上和语法上的错误？ • 在现有的资源限制内，是否能实现所有的需求？ • 是否任一个特定的错误信息都具有唯一性和明确的意义？
可视化
指使用图形，图像或者图片等技术，使一些不可 见的对象、表达或者抽象概念变成可见的符号。
2022/11/14
真检查其中每一页。如果你有足够的审查员，可以
分成几个小组分别审查材料的不同部分。
15
15
8.3需求评审
庞大的审查小组
可能许多项目参与者和客户都与需求有关系，然而 ，庞大的审查小组将导致难于安排会议，并且在审 查会上经常引发题外话，在许多问题上也难于达成 一致意见。
尝试用以下的方法处理庞大的审查小组：
如果能把早期的黑盒测试设计、非正式需求评审、软件 需求规格说明审查和其它需求验证技术相结合，将花比 以前更少的时间、更低的费用来构造质量更高的系统。
30
30
8.5 编制用户使用手册草案
好处
1. 在编制该手册的过程中，可强化对需求的仔细分 析，帮助揭示与系统的实际使用相关的问题，即 系统的可用性问题未被掩盖。
1. 软件需求规格证明是否正确描述了目标系统的行 为和特征；
2. 从其它来源中（包括硬件的系统需求规格说明书） 得到软件需求；
3. 需求是完整的和高质量的； 4. 所有人对需求的看法是一致的； 5. 需求为进一步的软件开发和测试提供了足够的基
础。
2022/11/14
4
8.1需求验证的目的和任务
重要性 发现和修复需求规格说明书存在的问题，
(7)需求是否易于修改？ (8)需求规格说明文档是
否完整？
2022/11/14
11
软件需求规格说明的审查清单
组织和完整性
• 所有对其它需求的内部交叉引用是否正确？ • 所有需求的编写在细节上是否都一致或者合适？ • 需求是否能为设计提供足够的基础？ • 是否包括了每个需求的实现优先级？ • 是否定义了所有外部硬件、软件和通信接口？ • 是否定义了功能需求内在的算法？ • 软件需求规格说明中是否包括了所有客户代表或系统的需求？ • 是否在需求中遗漏了必要的信息？如果有的话，就把它们标记为待确定的问题。 • 是否记录了所有可能的错误条件所产生的系统行为？
这些测试用例可以作为客户验收测试的基础。 在正式的系统测试中，可以把它们详述成测试 用例和过程。
案例：“化学制品跟踪系统”开发组如何把需 求规格说明、分析模型和早期创建的测试用例 结合在一起。
21
21
测试需求-案例
业务需求
“化学制品跟踪系统”通过鼓励重复使用公司中可用的 那些化学制品容器以降低购买费用。
2022/11/14
9
8.3需求评审
正式的审查过程
2022/11/14
10
8.3需求评审
审查的内容
需求评审的工作就是评审需求规格说明的 内容。
审查清单列举的问题
(1) 需求是否完整？
(2)需求是否一致？
(3)需求是否可理解？ (5)需求是否可实现？
(4)需求是否明确？ (6)需求是否可跟踪？
2. 可以帮助阐明用户界面设计问题，从而促使软件 开发人员一开始就站在用户的角度来设计用户界 面，并及早考虑人-机交互中的接口问题。
要求 此时编制的用户使用手册并不要求全面，
主要是用简单易懂的语言描述出所有对用户 可见的功能。
2022/11/14
31
8.6 解释需求模型
用自然语言解释需求模型的好处
26
26
测试需求-案例
27
27
测试需求-案例
测试用例
通过跟踪每个测试用例的可执行路径，可以发现不正确 和遗漏的需求，并在对话图中纠正错误，精化测试用例 。
例如，假设以这种方式执行完所有测试用例后，对话图 中从DB50到DB60之间标有“订购新容器”的导航线未 被加亮。可能有两种解释：
该导航是一个非法的系统行为。这条线必须从对话图中移去 ，并且如果软件需求规格说明中包含有这样过渡的需求，那 么也应该移去这一需求。
25
25
测试需求-案例
测试用例
根据理解，编写诸多这样测试用例后，把每个测试用例 映射到相应的功能需求上，以保证现有的需求集合可以 “执行”每个测试用例，并且至少使每个测试用例覆盖 每个功能需求。
下一步，用高亮度的笔跟踪对话图中每个测试用例的执 行路径，描绘上面的测试用例样本是如何跟踪进入对话 图的。
2022/11/14
6
8.3需求评审
需求评审 需求评审就是技术评审。是由非软件开发
人员对软件系统的进行检查以发现该系统所存 在的问题。 需求评审分类
非正式评审，正式评审。
2022/11/14
7
8.3需求评审
审查人员的组成
1. 从事软件系统需求开发的相关人员； 2. 具有编写需求规格说明经验和知识的人员，以及
该导航是合法的系统行为，但是遗漏了验证这一系统行为的 测试用例。
28
28
测试需求-案例
测试用例
例如：一个测试用例说明了用户可以采取一些措施从 DB40直接移到DB70。而对话图中没有包含这样的导航 线，所以测试用例不能以现有的需求来执行。因此，又 存在两种解释，要判断哪一个是对的：
从DB40到DB70的导航是一个非法的系统行为，所以测试用 例是错误的。
确保每个参与者都是为了寻找错误。
如果一些参与者只是想大概了解审查的内容，那么就邀请他 们去参加总体会议，而不是参加审查会。
16
16
8.3需求评审
庞大的审查小组
理解审查员所代表的观点（如客户、开发者或测试者）， 并委婉拒绝以相同观点看待问题的参与者。
在准备阶段，你可能要收集持有同样观点的反馈人的信息， 但只要派其中的一个作为代表参加会议。
并避免在软件系统设计和实现时出现返工。 任务
要求各方人员从不同的技术角度对需求规 格说明文档做出综合性评价。
2022/11/14
5
8.2 需求验证的内容和方法
内容
1. 一致性 2. 完整性 3. 现实性 4. 有效性
方法
目前验证需求的方法除形式化方法外， 主要靠人工技术审查和验证软件需求规格说 明。
22
22
测试需求-案例
功能需求
以下是关于让用户选择可用的化学制品的一些功能，而 不是向外部供应商发送订单： 如果请求化学制品仓库中的容器，系统将显示可用容器 的列表，用户就可以选择一个容器或要求向外部供应商 订购一个新容器。
对话图
23
23
测试需求-案例
“请求化学制品”用例的部分对话图
24
质量属性 • 是否合理地确定了性能目标？
• 是否合理地确定了安全与保密方面的考虑？ • 在确定了合理的折衷情况下，是否详实地记录了其它相关的质量属性？
可跟踪性 • 是否每个需求都具有唯一性并且可以正确地识别它？
• 是否可以根据高层需求（如系统需求或使用实例）跟踪到软件功能需求？
特殊的问题 • 是否所有的需求都是名副其实的需求而不是设计或实现方案？