第2讲-需求评审
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
规模复杂性测试性质量和可靠性安全性17需求评审过程通过高级审查了解外部因素后其次对需求进行更细致的测经常使用检查列表进行检查需求规格说明原始需求文档检查列表尝试理解讨论评审修订18需求评审过程检查项检查结果说明是否覆盖了用户提出的所有需求项用词是否清晰语义是否存在有歧义的地方是否清楚地描述了软件系统需要做什么及不做什么是否描述了软件使用的目标环境包括软硬件环境是否对需求项进行了合理的编号需求项是否前后一致彼此不冲突是否清楚地说明了系统的每个输入输出的格式以及输入输出之间的对应关系是否清晰地描述了软件的性能要求需求的优先级是否合理分配是否描述了各种约束条件10是否na是否na是否na是否na是否na是否na是否na是否na是否na是否na需求规格说明检查表一个例子19需求评审过程对照需求和检查表逐条检查判断找到用户的原始素材对照包括用户提供的材料调研记录用户沟通记录等完整性检查系统允许的输入与预期输出可测性20需求评审过程对照需求和检查表逐条检查判断续检查需求的关注重点和实现先后顺序是否清晰描述优先级检查对系统的约束是否完整描述可测性21需求用词问题总是每一种所有没有从不如此肯定的描述测试员需要确认尝试找违法的例子当然因此明显显然必然这些话意图诱使接受假定情况
这些是不确定的说法，不可测试。如果在产品说明 书出现，必须要求进一步指明含义
（已）处理、进行、拒绝、忽略、消除
这些说法可能会隐藏大量需要说明的功能
如果...那么...（没有否则）
缺少配套的否则，想一想，“如果”没有发生会怎 样呢？
22
序 号 1 2 3 4 5 6 7 8 9 10 检查项 是否覆盖了用户提出的所有需求项 用词是否清晰，语义是否存在有歧义的地方 是否清楚地描述了软件系统需要做什么及不做什么 是否描述了软件使用的目标环境，包括软硬件环境 是否对需求项进行了合理的编号 需求项是否前后一致、彼此不冲突 检查结果 是[]否[]NA[] 是[]否[]NA[] 是[]否[]NA[] 是[]否[]NA[] 是[]否[]NA[] 是[]否[]NA[] 说明
13
测试人员在需求评审中作用
需求评审归为静态测试范畴，包含了文档评审和技术评审 双重内容，通常通过正式的评审会议来进行。而测试人员 主要起着评审员的作用，检查需求定义是否合理和清楚。
明确自己的角色和责任 熟悉评审内容，为评审做好准备
针对问题阐述观点，而非针对个人
从客户角度想问题，多问几个为什么 在会前或会后提出自己建设性的意见 对发现的问题跟踪到底 针对需求文档等报告问题
当然、因此、明显、显然、必然
这些话意图诱使接受假定情况。不要中了圈套。
某些、有时、常常、通常、经常、大多、几乎
这些话太过模糊。“有时”发生作用的功能无法测 试
等等、诸如此类、依此类推
以这样的词结束的功能清单无法测试。功能清单要 绝对或者解释明确
21
需求用词问题
良好、迅速、廉价、高效、小、稳定
19
需求评审过程
对照需求和检查表，逐条检查判断（续）
检查性能是否得到清晰的描述（完整性） 检查需求的关注重点和实现先后顺序是否清晰描 述（优先级） 检查对系统的约束是否完整描述（可测性）
20
需求用词问题
总是、每一种、所有、没有、从不
如此肯定的描述，测试员需要确认，尝试找违法的 例子
10
需求缺陷
软件缺陷并不只是在编程阶段才产生，需求和设计阶段同 样会产生缺陷。
误解
其他
软件复杂性、文 编码 档不足、进度 压力或普通低级 错误
说明书
没写，不全面 经常改，没有 很好沟通
设计
随意、易变、沟通不足
为什么软件需求定义中存在很多缺陷最多？
11
需求评审重要性的直观描述
12
需求评审重要性表现方面
软件测试
需求评审
内 容
软件评审的方法与技术
产品需求评审
2
软件评审的方法与技术
1.什么是评审 2.评审的方法 3.评审会议 4.评审的技术
3
什么是评审
软件评审是对软件元素或者项目状态的一种评估手段，以 确定其是否与计划的结果保持一致，并使其得到改进。 产品需求审查是软件开发重要环节之一，也是测试活动之 一，即静态测试——需求验证。借助需求审查保证用户需 求在市场/产品需求文档及其相关文档中得到准确、完整、 无歧义的反映，并使各类开发人员在需求理解上达成一致。
14
需求评审的标准
正确性 完备性
易理解性
一致性
可行性
易修改性 易测试性 易追溯性
15
需求评审过程
首先，对产品说明书进行高级审查，找出根本性 的问题、疏忽或遗漏之处
假设自己是客户 研究现有的标准和规范
• 公司惯用语和约定 • 行业要求 • 政府标准 • 图形用户界面 • 安全标准
是否清楚地说明了系统的每个输入、输出的格式，以及 是[]否[]NA[] 输入输出之间的对应关系 是否清晰地描述了软件的性能要求 需求的优先级是否合理分配 是否描述了各种约束条件 是[]否[]NA[] 是[]否[]NA[] 是[]否[]NA[]
18
需求评审过程
对照需求和检查表，逐条检查判断
找到用户的原始素材对照，包括用户提供的材料 、调研记录、用户沟通记录等（完整性） 检查用词问题（明确性、易理解）详细 检查需求规格说明书对需求的覆盖是否准确（必 要性） 检查软件使用环境的描述是否清楚（完整性） 检查需求编号是否正确（可修改性） 检查需求是否自相矛盾（一致性） 检查系统允许的输入与预期输出（可测性）
审查和测试类似软件
• 审查经竞争产品注意：规模、复杂性、测试性、质 量和可靠性、安全性
16
需求评审过程
通过高级审查了解外 部因素后，其次，对 需求进行更细致的测 试 经常使用检查列表进 行检查
需求规格说明 原始需求文档
尝试理解
检查列表
讨论、评审、修订
17
需求评审过程
需求规格说明检查表一个例子
发现需求定义中的问题，尽早发现缺陷，降低劣质成本。
保证软件需求的可测试性。
与市场、产品、开发等相关人员在需求理解上认识一致， 以免后期的争吵。
通过需求评审，更好的理解产品的功能性与非功能性需求 ，为制定测试计划打下基础。
确定测试目标与范围。虽然此后需求会发生变更，但能得 到有效控制，降低测试风险。
可靠性。人们借助检查表以确认被检查对象的所有质量特征
均得到满足，避免遗漏任何项目。
效率。检查表归纳了所有检查要点，比起冗长的文档，使用
检查表具有更高的工作效率。
8
产品需求评审
1.需求评审的重要性 2.测试人员在需求评审中作用 3.需求评审的标准 4.如何对需求进行评审
9
问题
为什么在测试计划中谈需求评审？
会议纪要
结果分析
流程改进建议
修正问题
No
跟踪
满足执行要求?
6
Yes
总结报告
评审会议角色
主持人 内审员
作者
列席人员
技术专业人员
记录员
7
评审的技术
检查表、场景分析、头脑风暴和工具等
检查表（checklist）是一种常用的的质量保证手段，也是正式 技术评审的必要工具，评审过程往往由检查表驱动。一份精 心设计的检查表，对于提高评审效率、改进评审质量具有很 大帮助。
技术评审 文档评审 管理（流程）评审
4
评审方法
最不正式的
最正式的
临时评审
轮查
走查
互为评审 同行评审
审查
Random review, Pass-round, Walkthrough, Peer review, Inspection
5
评审会议流程
达到评审会议 标准?
Yes
计划
全面纵览
准备
评审
问题记录
这些是不确定的说法，不可测试。如果在产品说明 书出现，必须要求进一步指明含义
（已）处理、进行、拒绝、忽略、消除
这些说法可能会隐藏大量需要说明的功能
如果...那么...（没有否则）
缺少配套的否则，想一想，“如果”没有发生会怎 样呢？
22
序 号 1 2 3 4 5 6 7 8 9 10 检查项 是否覆盖了用户提出的所有需求项 用词是否清晰，语义是否存在有歧义的地方 是否清楚地描述了软件系统需要做什么及不做什么 是否描述了软件使用的目标环境，包括软硬件环境 是否对需求项进行了合理的编号 需求项是否前后一致、彼此不冲突 检查结果 是[]否[]NA[] 是[]否[]NA[] 是[]否[]NA[] 是[]否[]NA[] 是[]否[]NA[] 是[]否[]NA[] 说明
13
测试人员在需求评审中作用
需求评审归为静态测试范畴，包含了文档评审和技术评审 双重内容，通常通过正式的评审会议来进行。而测试人员 主要起着评审员的作用，检查需求定义是否合理和清楚。
明确自己的角色和责任 熟悉评审内容，为评审做好准备
针对问题阐述观点，而非针对个人
从客户角度想问题，多问几个为什么 在会前或会后提出自己建设性的意见 对发现的问题跟踪到底 针对需求文档等报告问题
当然、因此、明显、显然、必然
这些话意图诱使接受假定情况。不要中了圈套。
某些、有时、常常、通常、经常、大多、几乎
这些话太过模糊。“有时”发生作用的功能无法测 试
等等、诸如此类、依此类推
以这样的词结束的功能清单无法测试。功能清单要 绝对或者解释明确
21
需求用词问题
良好、迅速、廉价、高效、小、稳定
19
需求评审过程
对照需求和检查表，逐条检查判断（续）
检查性能是否得到清晰的描述（完整性） 检查需求的关注重点和实现先后顺序是否清晰描 述（优先级） 检查对系统的约束是否完整描述（可测性）
20
需求用词问题
总是、每一种、所有、没有、从不
如此肯定的描述，测试员需要确认，尝试找违法的 例子
10
需求缺陷
软件缺陷并不只是在编程阶段才产生，需求和设计阶段同 样会产生缺陷。
误解
其他
软件复杂性、文 编码 档不足、进度 压力或普通低级 错误
说明书
没写，不全面 经常改，没有 很好沟通
设计
随意、易变、沟通不足
为什么软件需求定义中存在很多缺陷最多？
11
需求评审重要性的直观描述
12
需求评审重要性表现方面
软件测试
需求评审
内 容
软件评审的方法与技术
产品需求评审
2
软件评审的方法与技术
1.什么是评审 2.评审的方法 3.评审会议 4.评审的技术
3
什么是评审
软件评审是对软件元素或者项目状态的一种评估手段，以 确定其是否与计划的结果保持一致，并使其得到改进。 产品需求审查是软件开发重要环节之一，也是测试活动之 一，即静态测试——需求验证。借助需求审查保证用户需 求在市场/产品需求文档及其相关文档中得到准确、完整、 无歧义的反映，并使各类开发人员在需求理解上达成一致。
14
需求评审的标准
正确性 完备性
易理解性
一致性
可行性
易修改性 易测试性 易追溯性
15
需求评审过程
首先，对产品说明书进行高级审查，找出根本性 的问题、疏忽或遗漏之处
假设自己是客户 研究现有的标准和规范
• 公司惯用语和约定 • 行业要求 • 政府标准 • 图形用户界面 • 安全标准
是否清楚地说明了系统的每个输入、输出的格式，以及 是[]否[]NA[] 输入输出之间的对应关系 是否清晰地描述了软件的性能要求 需求的优先级是否合理分配 是否描述了各种约束条件 是[]否[]NA[] 是[]否[]NA[] 是[]否[]NA[]
18
需求评审过程
对照需求和检查表，逐条检查判断
找到用户的原始素材对照，包括用户提供的材料 、调研记录、用户沟通记录等（完整性） 检查用词问题（明确性、易理解）详细 检查需求规格说明书对需求的覆盖是否准确（必 要性） 检查软件使用环境的描述是否清楚（完整性） 检查需求编号是否正确（可修改性） 检查需求是否自相矛盾（一致性） 检查系统允许的输入与预期输出（可测性）
审查和测试类似软件
• 审查经竞争产品注意：规模、复杂性、测试性、质 量和可靠性、安全性
16
需求评审过程
通过高级审查了解外 部因素后，其次，对 需求进行更细致的测 试 经常使用检查列表进 行检查
需求规格说明 原始需求文档
尝试理解
检查列表
讨论、评审、修订
17
需求评审过程
需求规格说明检查表一个例子
发现需求定义中的问题，尽早发现缺陷，降低劣质成本。
保证软件需求的可测试性。
与市场、产品、开发等相关人员在需求理解上认识一致， 以免后期的争吵。
通过需求评审，更好的理解产品的功能性与非功能性需求 ，为制定测试计划打下基础。
确定测试目标与范围。虽然此后需求会发生变更，但能得 到有效控制，降低测试风险。
可靠性。人们借助检查表以确认被检查对象的所有质量特征
均得到满足，避免遗漏任何项目。
效率。检查表归纳了所有检查要点，比起冗长的文档，使用
检查表具有更高的工作效率。
8
产品需求评审
1.需求评审的重要性 2.测试人员在需求评审中作用 3.需求评审的标准 4.如何对需求进行评审
9
问题
为什么在测试计划中谈需求评审？
会议纪要
结果分析
流程改进建议
修正问题
No
跟踪
满足执行要求?
6
Yes
总结报告
评审会议角色
主持人 内审员
作者
列席人员
技术专业人员
记录员
7
评审的技术
检查表、场景分析、头脑风暴和工具等
检查表（checklist）是一种常用的的质量保证手段，也是正式 技术评审的必要工具，评审过程往往由检查表驱动。一份精 心设计的检查表，对于提高评审效率、改进评审质量具有很 大帮助。
技术评审 文档评审 管理（流程）评审
4
评审方法
最不正式的
最正式的
临时评审
轮查
走查
互为评审 同行评审
审查
Random review, Pass-round, Walkthrough, Peer review, Inspection
5
评审会议流程
达到评审会议 标准?
Yes
计划
全面纵览
准备
评审
问题记录