评审检查单-用户需求检查单、详细设计检查单、概要设计检查单
项目计划检查单
项目计划检查单
源文件表格：
项目计划检查单
项目名称
项目编号
审核日期
审核员
原始文档/版本
序号
检查内容
是否（√）
备注
1
完整性 (CP)，Completeness
1.1
计划是否清晰的阐述了项目的目标、目的？
1.2
计划是否说明了在不同涉众、参与者间交流项目目标、目的的机制？
1.3
项目的组织结构和职责分配是否完整？
1.4
每个组织单元和任务包的资源分配是否完整？
1.5
每个任务包的时间进度、里程碑是否完整？
1.6
项目的组织结构、资源分配、里程碑是否没有冗余？
1.7
项目范围中是否清晰说明了哪些需求可以延迟实现？
1.8
项目的风险是否充分说明并制定了有效的缓解措施？
1.9
对每个已识别的风险是否指定了负责人？
1.10
是否说明了项目选择的生命周期模型，并对选择的理由进行了说明？
1.11
项目选择的生命周期模型是否有文档化的说明或引用相关文档？
1.12
是否识别了项目过程中软件产品和适用的评审需求？
1.13
是否制定了评审计划，评审计划是否在Project计划中有反映？
2
一致性(CS)，Consistency
2.1
项目的许可偏差率是否定义?
2.2
组织标准软件过程中不是否本项目的内容是否进行了明确说明?
2.3
是否所有里程碑点的工作产品或提交产品都在Project中定义了检查点？
2.4
已经识别的风险是否都与项目的范围相关？
3
正确性(CT)，Correctness
3.1
项目的资源分配、进度、里程碑是否与类似项目的估计值和实际结果具有相关性？
3.2
项目的资源分配、进度、里程碑计划是否有相关的支持信息进行说明？
3.3
计划的详细程度和精度是否合适？
3.4
项目的进度和里程碑是否进行了充分的分析，以发现是否存在冲突、不必要的差距？
4
描述清晰性(DC)，Documentation/Clarity
4.1
项目计划及各个部分的目的是否达到？
4.2
项目术语是否前后一致，是否对于所有读者都易于理解？
4.3
项目资源分配、进度、里程碑是否清晰、没有歧义？
4.4
组织级关于项目计划的文档风格、模板是否得到遵守？
4.5
项目计划到各个子计划文档的引用和超级连接是否正确？
5
接口(IF)，Interface
5.1
项目的外部依赖是否已经识别并记录？
5.2
不同小组间的沟通需求、接口是否清晰说明？
5.3
外部小组提供的工作产品在接收、使用前要走怎样的审批流程是否进行了说明？
6
详细程度(LD)，Level of Detail
6.1
计划是否为所有读者提供了足够详细的信息，以使读者理解项目计划？
6.2
是否存在没有确定的时间进度、没有决定的事项？
6.3
是否存在多余的内容或位置放错的内容？
6.4
项目的WBS分解的是否足够细？
7
可维护性(MN)，Maintainability
7.1
计划文档的组织形式是否满足活的、动态的要求？
7.2
计划的组织形式是否考虑了易于变更、更新？
8
标准(ST)，Standards
8.1
计划必须的部分和引用的其它必须文档是否完整？
8.2
计划内容是否符合组织的相关要求？
8.3
是否按照项目计划规程确定了项目里程碑?
备注
1、模板中未设计到的问题项，可根据实际情况添加内容。
意见汇总
序号
意见内容
1
2
3
4
配置管理计划检查单
项目名称
项目编号
审核日期
审核员
原始文档/版本
序号
检查内容
是否（√）
备注
1
完整性 (CP)，Completeness
1.1
项目的配置管理计划是否包括组织级配置管理计划模板的主要章节？
1.2
是否不同阶段的配置项都在配置管理计划中列出？
1.3
变更控制委员会的组成、变更管理过程是否进行了定义？
1.4
从CM角度看项目的风险是否都已经识别、文档化、制定了缓解措施？
1.5
配置管理计划中引用、连接的文档是否都可获得？
2
一致性(CS)，Consistency
2.1
配置项的命名约定是否得到遵守？
2.2
是否对版本管理过程进行了描述？
3
描述清晰性(DC)，Documentation/Clarity
3.1
项目术语是否前后一致，是否对于所有读者都易于理解？
3.2
是否识别出了随产品发布的配置项？
4
详细程度(LD)，Level of Detail
4.1
配置管理计划是否按照模板和标准为项目组成员提供了足够的信息，使其理解自己在项目过程中应该担任的角色和应该做的与配置管理有关的活动？
5
可维护性(MN)，Maintainability
5.1
配置管理计划是否在版本控制之下，是否保持最新状态？
5.2
是否定期进行检查以确保配置项的正确性和完整性？
6
功能(FN)，Functionality
6.1
程序代码是否实现了设计的算法？
6.2
程序代码是否可以满足功能需求？
7
标准(ST)，Standards
7.1
配置管理计划是否遵照组织级的配置管理计划模板？
8
可追踪性(TR)，Traceability
8.1
不同配置项之间是否建立了高层次的追踪关系？
8.2
缺陷是否可以追踪到配置项？
备注
1、模板中未设计到的问题项，可根据实际情况添加内容。
意见汇总
序号
意见内容
1
2
3
用户需求说明书检查单
项目名称
项目编号
审核日期
审核员
原始文档/版本
序号
检查内容
是否（√）
备注
1
完整性 (CP)，Completeness
1.1
需求是否完整地进行了说明？（说明了相关内容，但可以容忍暂时的不完整性）
1.2
是否捕获并且识别了暂时不完整的需求？
1.3
是否进行了可行性分析并进行了文档化说明？
1.4
对于不能实现需求的影响是否进行了文档化说明？
1.5
有关硬件、软件、操作人员、操作程序方面的安全问题是否进行了说明？
1.6
系统的功能需求、外部接口、性能要求是否按照需要的实现日期进行了优先级排列?
2
一致性(CS)，Consistency
2.1
需求是否一致地进行了描述？系统需求之间没有冲突？
3
描述清晰性(DC)，Documentation/Clarity
3.1
系统的目标是否已经定义？
3.2
系统需求是否以与实现无关的方式进行描述？
3.3
需求使用的术语是否与用户的术语习惯一致？以用户容易理解的方式描述需求？
3.4
系统的需求是否清晰、不存在歧义？
4
功能(FN)，Functionality
4.1
系统的功能是否清晰地、无歧义的加以描述？
4.2
功能对于满足用户的需求是否是必要的和足够的？
5
接口(IF)，Interface
5.1
外部接口是否已经清晰的定义？
5.2
内部接口是否已经清晰的定义？
5.3
接口是否必须、足够、相互之间一致？
6
可维护性(MN)，Maintainability
6.1
是否定义了系统可维护性方面的需求？
6.2
需求是否以送藕合的方式进行书写，当改变一个需求时对其它需求的影响最小化？
7
性能(PF)，Performance
7.1
系统性能的要求和边界条件是否列出？
7.2
对于每一个性能需求，定义了满足需求的大概指标、定义了不满足此需求的影响？
8
可靠性(RL)，Reliability
8.1
可靠性方面的需求是否已经列出？
8.2
是否列出了错误检测、报告、恢复方面的需求？
8.3
是否对系统以外事件进行了考虑并定义了出现意外事件时期望的响应？
8.4
是否对系统功能的使用顺序的假设进行了描述？
8.5
可靠性需求是否足以从硬件、软件、使用人员、使用过程等方面说明了系统的可靠性能力？
9
标准(ST)，Standards
9.1
用户需求文档是否符合项目的文档标准？
10
可测试性(TL)，Testability
10.1
系统的需求是否可以被测试、演示、分析、检查以证明它可以满足用户的需求？
10.2
需求是否准确的被描述，以支持定义系统测试通过/失败的标准，定义测试需求？
11
可追踪性(TR)，Traceability
11.1
是否所有的需求、约束都可以追溯到系统的目标？
11.2
每个需求是否以可以爱其它文档中唯一引用的方式进行了说明？
11.3
是否所有的需求都可以分配到硬件、软件、操作人员及操作过程？
备注
1、模板中未设计到的问题项，可根据实际情况添加内容。
意见汇总
序号
意见内容
1
2
3
软件需求规格说明书检查单
项目名称
项目编号
审核日期
审核员
原始文档/版本
序号
检查内容
是否（√）
备注
1
完整性 (CP)，Completeness
1.1
系统的特性、假设、约束是否被完整的列出？
1.2
是否所有的需求和约束都被指定了优先级？
1.3
分配需求优先级的标准是否已经定义？
1.4
每个交付版本或阶段性实现的需求是否明确说明？
1.5
系统安装部署（打包、现场准备、用户培训等）的需求是否已经说明？
1.6
是否已经指定了系统的开发语言、开发环境、运行环境？
2
一致性(CS)，Consistency
2.1
系统需求之间是否相一致？
2.2
系统需求是否与用户需求说明书中的需求一致？
2.3
系统需求是否与实际的运行环境一致？（例如，硬件环境、网络带宽鞥）
2.4
系统需求是否与用户需求、立项报告等更高层文档中的需求保持一致？
3
数据使用(DA)，Data Usage
3.1
系统内部数据的类型、单位、准确度、范围、限制、临界值是否定义？
3.2
数据对象和他们的组成部分是否被定义？
3.3
共享数据及其管理方式是否被定义？使用共享数据的功能是否被清晰的列出？
3.4
共享数据是否有其它特殊的一致性要求？操作共享数据的类型和频率是否进行了说明？
3.5
共享数据的访问模式（例如，随机访问、顺序访问)是否已经说明？
4
描述清晰性(DC)，Documentation/Clarity
4.1
需求中使用的术语是否与用户的术语一致？
4.2
系统的需求是否清晰、没有歧义？
4.3
是否对每个功能进行了功能总体描述？
4.4
是否对每个功能的操作模式、状态、概念进行了总体描述？
4.5
系统的软件环境、硬件环境是否进行了说明？
4.6
影响系统实现的假设是否已经清晰的说明？
4.7
每个需求是否都说明了输入、输出、处理？
5
功能(FN)，Functionality
5.1
是否所有的功能都是必要的？这些功能是否可以满足拥护对系统的目标、目的？
5.2
每个需求的输入是否是必要的？这些输入是否足够满足功能的需求？
5.3
每个功能如何把输入转换为输出是否清楚的进行了说明？
6
接口(IF)，Interface
6.1
系统的对外接口、内部接口是否必须并且足够？
6.2
一个功能的输出是否被作为另外一个功能的输入使用或者通过外部接口传递给其它外部系统？
6.3
硬件、软件、人员、系统之间的接口需求是否说明？
6.4
用户界面显示的内容、格式、限制是否进行了文档化描述？
6.5
是否对所有的数据元素都进行了充分的描述？
6.6
系统内部软件功能之间数据流是否进行了说明？
6.7
跨程序模块边界的数据元素是否被识别？
7
详细程度(LD)，Level of Detail
7.1
软件需求是否不包括不必要的设计说明？
7.2
是否所有的待定事项都得到了解决？
7.3
接口是否描述的足够详细，可以开始设计工作？
7.4
系统的功能需求是否描述地足够详细，可以开始设计工作？
7.5
系统的性能需求是否描述地足够详细，可以开始设计工作？
7.6
每个功能输入、输出的精度、范围、类型、单位、频率、吞吐量是否都进行了说明？
8
可维护性(MN)，Maintainability
8.1
系统需求是否是松藕合的？（改变一个功能不会对系统产生不可预料的影响）
8.2
需求是否最小化设计的复杂度？
8.3
系统可维护性的需求是否都分配给了功能？
8.4
是否充分考虑了可重用组件？这些重用对设计和集成的影响是否进行了分析说明？
8.5
系统可移植性的需求是否都分配给了功能？
9
性能(PF)，Performance
9.1
是否所有的性能需求都分配给了功能？
9.2
系统资源和性能的边界条件是否都已经定义？是否说明了管理这些资源和性能边界的手段？
10
可靠性(RL)，Reliability
10.1
系统的质量指标是否通过可测量的需求或定义了优先级的设计目标进行了说明？
10.2
系统可靠性的需求是否都分配给功能需求？
10.3
系统可用性的需求是否都分配给了功能？
10.4
系统安全性的需求是否都分配给了功能？
10.4
是否充分考虑了意外事件？这些事件的期望响应是否已经定义？
10.6
是否充分考虑了错误检查和恢复机制？
11
标准(ST)，Standards
11.1
详细设计文档是否符合项目的文档标准？
12
可测试性(TL)，Testability
12.1
系统的需求是否可以被测试、演示、分析、检查以证明它可以满足用户的需求？
12.2
每个需求是否都是具体的、无歧义的、可测试的？
12.3
系统的总体接收标准是否确定？是否定义了明确的通过/失败标准？
12.4
每个需求的测试方法（测试、演示、分析、检查）是否进行了说明？
13
可追踪性(TR)，Traceability
13.1
功能、结构、约束是否都可以追踪到需求？反之亦然？
13.2
系统的需求是否都已经分配到系统的功能或功能集合？
13.3
系统的直接设计目标和实现约束、间接设计目标和实现约束是否说明并且定义了优先级？
13.4
每个需求是否适当的描述，使后续的文档可以唯一的引用这些需求？
备注
1、模板中未设计到的问题项，可根据实际情况添加内容。
意见汇总
序号
意见内容
1
2
3
4
概要设计检查单
项目名称
项目编号
审核日期
审核员
原始文档/版本
序号
检查内容
是否（√）
备注
1
完整性 (CP)，Completeness
1.1
概要设计文档中的所有待确定事项（To Be Specified）都得到了解决，既不存在待定事项。
1.2
概要设计是否支持需求分析文档中的待定需求？
1.3
是否对所有的待定事项（TBD，To Be Done）的影响进行了评估？
1.4
是否针对设计中的可能不可行部分制定了风险管理计划（在项目风险管理计划中增加了相应的风险）？
1.5
设计文档中是否包含了设计方案选择的研究？是否包括了设计方案选择的标准并说明了不选择其它可选方案的原因？
1.6
设计文档是否包含了实际模型？
2
一致性(CS)，Consistency
2.1
设计是否反映了系统的实际运行环境？包括硬件、软件、支持软件？
3
正确性(CT)，Correctness
3.1
设计从时间进度、预算、技术上是否可行？
3.2
设计文档中是否包括错误、遗漏、不完整的逻辑？
4
数据使用(DA)，Data Usage
4.1
设计文档是否说明了所有复合数据元素的概念视图？
4.2
是否所有的数据结构都进行了定义？是否存在没有用的数据结构定义？
4.3
是否对共享数据或文件的管理和设计进行了清晰的说明？
5
描述清晰性(DC)，Documentation/Clarity
5.1
系统的架构（包括数据流、控制流、接口）是否清晰的展示？
5.2
是否适当地从不同角度一致的描述了系统架构设计（例如，从静态结构和动态结构两个方面进行描述）？
5.3
是否在文档中记录了设计的假设、约束、决策、依赖？
6
功能(FN)，Functionality
6.1
对于每一个模块是否定义了抽象的实现方式或算法？
6.2
设计及算法是否可以满足系统的所有需求？
7
接口(IF)，Interface
7.1
所有的接口是否相互一致?是否与其它模块一致?是否与需求一致?
7.2
是否说明了内部不同功能间的数据流？
8
详细程度(LD)，Level of Detail
8.1
是否所有可能的状态、情况都进行了考虑？
8.2
概要设计是否足够详细，根据概要设计可以进行详细设计？
9
可维护性(MN)，Maintainability
9.1
设计是否模块化？
9.2
模块设计否决高内聚性、松藕合性？
9.3
是否说明了重用哪些设计、代码、辅助工具？
10
性能(PF)，Performance
10.1
是否对重要功能进行了性能模型设计和说明？
10.2
是否说明了具体的性能参数？（例如，响应时间、内存大小、输入/输出）
10.3
程序执行的关键路径是否已经识别并进行了分析？
11
可靠性(RL)，Reliability
11.1
设计是否满足系统完整性方面的要求？
12
标准(ST)，Standards
12.1
详细设计文档是否符合项目的文档标准？
13
可测试性(TL)，Testability
13.1
是否所有的单元设计可被测试、演示、分析、检查以确认其满足需求？
13.2
系统是否可以增量的集成、测试？
14
可追踪性(TR)，Traceability
14.1
设计的所有部分是否可以追踪到需求？
14.2
设计决策是否都可以追踪到方案选择？
14.3
继承的设计元素的历史情况是否进行了记录？
14.4
继承的设计元素相关的风险是否进行了识别和分析？
备注
1、模板中未设计到的问题项，可根据实际情况添加内容。
意见汇总
序号
意见内容
1
2
3
详细设计检查单
项目名称
项目编号
审核日期
审核员
原始文档/版本
序号
检查内容
是否（√）
备注
1
完整性 (CP)，Completeness
1.1
是否所有变量、指针、常量都进行了定义和初始化？
1.2
是否系统的所有单元都进行了详细说明？
1.3
程序单元的接收标准是否进行了说明？
1.4
单元实现的算法是否进行了定义？
1.5
本单元调用的其它单元都已经列出？
1.6
本单元继承的设计是否进行了说明，并一并列出了相关已知风险？
2
一致性(CS)，Consistency
2.1
数据元素的命名和使用是否在整个单元和单元接口中被一致的使用？
2.2
是否所有接口都进行了编码实现以保证互相之间的一致性？是否所有接口实现与概要设计一致？
2.3
详细设计是否与概要设计一起完整描述了被建系统？
2.4
是否所有数据元素、方法的命名和使用方式在整个系统中一致，并且与外部接口一致？
3
正确性(CT)，Correctness
3.1
是否有遗漏的逻辑？
3.2
是否所有应该使用常量的地方都使用了有意义的变量名？
3.3
是否所有的条件分支都进行了处理(大于、等于、小于, switch/case）？
3.4
是否所有的分支都正确声明，逻辑上没有颠倒？
4
数据使用(DA)，Data Usage
4.1
是否所有声明的变量和数据块都被实际使用？
4.2
是否所有的数据结构对于实现的单元都是局部的？
4.3
是否所有使用共享数据或文件的程序都考虑了其它程序也可能同时访问同样的数据或文件？
4.4
是否所有的逻辑单元、事件标志、同步标志都别定义和初始化？
4.5
是否最底层的数据元素都被描述？是否对有效数值范围进行了描述？
5
描述清晰性(DC)，Documentation/Clarity
5.1
是否所有的单元作用都进行了文档化描述？
5.2
是否单元设计（包括数据流、控制流、接口）被清晰的描述？
5.3
是否描述了单元的总体功能？
6
功能(FN)，Functionality
6.1
设计是否实现了定义的算法？
6.2
设计是否满足需求和目的？
6.3
是否所有的模块设计都满足概要设计中的功能性需求？
7
接口(IF)，Interface
7.1
接口方法的参数列表在数量、类型、顺序上是否匹配？
7.2
是否所有的输入参数、输出参数都正确定义和进行了有效性检查？
7.3
是否传递参数的顺序进行了清晰的说明？
7.4
是否传递参数的机制都确定了？
7.5
是否不同接口传递常量和变量的处理与设计一致？
7.6
单元传递的参数和控制标志、单元返回的参数和控制变量是否都进行了描述？
7.7
是否所有的参数都定义了度量单位、有效范围、精度？
7.8
共享数据是否在所有的程序中都一致进行处理？
7.9
接口的方法设计是否充分考虑了使用者的要求？(例如，词汇表、有用的消息、易于调用)
7.1
接口的设计是否有利于排除错误？
7.11
所有的接口是否相互一致?是否与其它模块一致?是否与需要和概要设计一致?
7.12
是否所有的接口都提供必须的类型、数量、质量的信息？
7.13
接口的数据和复杂度是否最小化？
8
详细程度(LD)，Level of Detail
8.1
是否模块的所有属性都被定义？
8.2
是否为程序开发和维护提供了足够的信息？
8.3
是否程序接口的所有功能特性都被定义？
8.4
接口设计是否为错误排除提供了足够信息？
9
可维护性(MN)，Maintainability
9.1
程序模块是否具有内部凝聚，外部松藕的特性？对程序代码的修改不会对本模块造成不可预见的错误，对其它外部模块的影响最先化？
9.2
程序代码是否简单？复杂性降低到最小？
9.3
单元设计是否清晰、易读、易修改?
10
性能(PF)，Performance
10.1
长时间运行的程序是否有提示窗口？
10.2
是否单元的所有的约束，例如处理时间、内存大小都别定义？
11
可靠性(RL)，Reliability
11.1
当变量使用默认值进行初始化时，默认值是否正确？
11.2
是否所有的内存操作都进行了边界检查，以确保只有正确的内存被修改？
12
是否对输入变量、输出变量、返回结果进行了必要的正确性检查？
12.1
是否对于所有的错误都提供了有意义的错误消息？
12.2
特殊情况下的程序返回代码是否与设计文档保持一致？
12.3
是否考虑了以外事件的处理？
12.4
设计是否考虑了错误检测和恢复？
12.5
是否对非正常条件进行了考虑？
12.6
是否所有的错误条件都被完整、正确的说明？
13
标准(ST)，Standards
13.1
详细设计文档是否符合项目的文档标准？
13.2
详细设计文档是否利用规定的工具和方法创建？
14
可测试性(TL)，Testability
14.1
是否所有的单元设计可被测试、演示、分析、检查以确认其满足需求？
14.2
设计是否包括用来帮助测试的检查点？ 例如，条件编译语句，数据确语句)
14.3
是否所有的逻辑都可以被测试？
14.4
测试驱动、测试数据、测试结果是否足以测试本单元？
15
可追踪性(TR)，Traceability
15.1
是否所有的设计都可以追踪到概要设计或其它文档中的需求？
15.2
是否所有的设计决策都可以追踪到方案选择？
15.3
是否对每一个单元的详细需求进行了定义？
15.4
是否所有的单元需求都可以追溯到概要设计？是否概要设计中的需求都可以追溯到单元设计？
备注
1、模板中未设计到的问题项，可根据实际情况添加内容。
意见汇总
序号
意见内容
1
2
3
程序代码检查单
项目名称
项目编号
审核日期
审核员
原始文档/版本
序号
检查内容
是否（√）
备注
1
完整性 (CP)，Completeness
1.1
是否所有设计功能都得到实现?
1.2
是否所有变量、指针、常量都进行了定义和初始化？
1.3
是否所有单元都提供了测试计划？单元测试的通过/失败标准是否进行了描述？
1.4
是否提供了单元测试结果？
1.5
是否每行代码都进行了至少一次测试？
2
一致性(CS)，Consistency
2.1
程序代码中的变量命名是否与设计一致？
2.2
是否所有接口都进行了编码实现以保证互相之间的一致性？是否所有接口实现与概要设计一致？
2.3
是否所有的单元都与详细设计一致以满足系统的需求？
3
正确性(CT)，Correctness
3.1
程序代码在逻辑上是否有遗漏的内容？
3.2
是否所有应该使用常量的地方都使用了有意义的变量名？
3.3
是否所有的条件分支都进行了处理(大于、等于、小于, switch/case）？
3.4
是否所有的分支都正确声明，逻辑上没有颠倒？
3.5
是否正确的进行了条件测试？
3.6
是否所有的IF/ELSE语句进行了正确的对齐？
3.7
嵌套的IF语句是否正确的进行了缩进？
4
数据使用(DA)，Data Usage
4.1
是否所有声明的变量都被实际使用？
4.2
是否所有使用共享数据或文件的程序都考虑了其它程序也可能同时访问同样的数据或文件？
4.3
是否所有的变量名称都与其用途一致？
4.4
是否所有的数据元素、标志位、指针都适当的进行了初始化？
5
描述清晰性(DC)，Documentation/Clarity
5.1
是否程序开头的注释与项目的程序开发规范一致并且内容完整？
5.2
程序的代码是否符合项目的编码规范？
5.3
单元代码的流程是否遵从设计文档中的流程？
5.4
程序是否有足够的注释？注释是否准确、有意义？程序注释的详细程度是否一致？
5.5
程序的逻辑是否易于理解？
6
功能(FN)，Functionality
6.1
程序代码是否实现了设计的算法？
6.2
程序代码是否可以满足功能需求？
7
接口(IF)，Interface
7.1
接口方法的参数列表在数量、类型、顺序上是否匹配？
7.2
是否所有的输入参数、输出参数都正确定义和进行了有效性检查？
7.3
是否所有传递的参数都进行了注释？
7.4
是否正确的向被调用模块传递了必须的参数？
7.5
向被调用模块提供的参数是否正确的设置了参数值？
7.6
单元退出是是否进行了正确的“清除”？
8
可维护性(MN)，Maintainability
8.1
程序模块是否具有内部凝聚，外部松藕的特性？对程序代码的修改不会对本模块造成不可预见的错误，对其它外部模块的影响最先化？
8.2
程序代码是否简单？复杂性降低到最小？
8.3
程序文件开头的注释是否符合项目的要求？（例如,包括目的、作者、环境、使用的非标准特性、修改历史、输入、输出、使用的文件、使用的数据结构、调用此单元的单元、被本单元调用的单元、解释性的说明)
8.4
程序代码是否清晰、易读、易修改?
9
性能(PF)，Performance
9.1
单元测试的结果是否表明程序的性能符合性能需求？
10
可靠性(RL)，Reliability
10.1
当变量使用默认值进行初始化时，默认值是否正确？
10.2
是否对输入变量、输出变量、返回结果进行了必要的正确性检查？
10.3
是否对于所有的错误都提供了有意义的错误消息？
10.4
特殊情况下的程序返回代码是否与设计文档保持一致？
11
标准(ST)，Standards
11.1
程序代码和测试计划是否符合项目的标准？
11.2
程序代码是否使用了项目规定的方法和工具进行开发？
12
可测试性(TL)，Testability
12.1
测试计划是否对测试设备和环境进行了说明？
12.2
测试驱动、测试数据、测试结果是否足以测试本单元？
12.3
是否所有的业务逻辑都可测试？
13
可追踪性(TR)，Traceability
13.1
单元需求需求是否可以追踪到概要设计文档？概要设计文档是否可以追踪到单元？
13.2
代码是否可以追踪到对应的设计或对应的需求？
备注
1、模板中未设计到的问题项，可根据实际情况添加内容。
意见汇总
序号
意见内容
1
2
3
测试计划检查单
项目名称
项目编号
审核日期
审核员
原始文档/版本
序号
检查内容
是否（√）
备注
1
完整性 (CP)，Completeness
1.1
测试计划是否定义了接收测试的总体的测试方案和策略？
1.2
测试计划是否清晰地定义了测试步骤？
1.3
测试计划是否描述了测试的硬件、软件测试环境？
1.4
测试计划是否说明了测试中断、恢复的条件？
1.5
测试计划是否对所有的测试都定义了通过/失败标准？
1.6
测试计划是否充分描述了被测试的功能？
1.7
测试计划是否清晰、明确的说明了不进行测试的功能？
1.8
测试计划是否定义了充分、适当的回归测试？
2
一致性(CS)，Consistency
2.1
测试的顺序是否与系统集成顺序一致？
2.2
测试计划是否与项目计划一致？
3
正确性(CT)，Correctness
3.1
测试的入口、出口准则是否现实？
3.2
测试硬件环境、软件环境的依赖关系是否定义？
4
详细程度(LD)，Level of Detail
4.1
测试案例覆盖率是否足以证明被测试的功能在预定的环境中运行正常？
4.2
测试案例是否包括了足够的合法和非法测试输入组合？
4.3
测试案例是否包括足够的默认输入数据？
4.4
测试案例是否测试了足够多的错误路径？
5
可维护性(MN)，Maintainability
5.1
测试计划是否包括关于在测试阶段对系统需求、设计、代码变更进行控制、合并的说明？
6
标准(ST)，Standards
6.1
测试计划是否列出了所有编写测试计划需要的规范、标准、文档？
6.2
需求是否以送藕合的方式进行书写，当改变一个需求时对其它需求的影响最小化？
7
可测试性(TL)，Testability
7.1
测试方式是否可行？
7.2
是否所有不可测试的需求都被识别出来，对为什么不可测试进行了说明？
7.3
测试设备、方法、工具的开发或采购计划是否制定并考虑了足够的提前量？
7.4
是否对每一个被测试的功能都制定了测试时间表？
7.5
测试需要的资源是否被识别和估算？
7.6
对于分多个版本交付的项目，是否对每一个版本的测试需求都进行了识别？
7.7
参加测试的人员的角色和职责是否都已经识别？
7.8
参加测试的人员在时间安排上是否存在冲突？
8
可追踪性(TR)，Traceability
8.1
测试需求是否可以追踪到软件需求？
8.2
测试的接收标准是否可以追溯到软件需求分析说明书？
8.3
测试案例是否验证系统的接口需求？
备注
1、模板中未设计到的问题项，可根据实际情况添加内容。
意见汇总
序号
意见内容
1
2
3
测试用例检查单
项目名称
项目编号
审核日期
审核员
原始文档/版本
序号
检查内容
是否（√）
备注
1
完整性 (CP)，Completeness
1.1
被测试的功能是否被充分描述?
1.2
被测试的功能是否是最新版本?
1.3
测试的目的是否被完整、准确的描述？
1.4
测试用例是否对被测试功能的所有相关需求进行了验证？
1.5
对测试用例的每一个步骤是否都描述了期望的相应和测试人员的操作指南？
1.6
是否对每个测试用例都定义了通过/失败的标准？
1.7
对被测试的功能是否充分说明了多条控制路径？
1.8
测试步骤是否最终可以得出成功/失败的结果？
1.9
测试用例是否能够表明系统在非法输入、冲突数据条件下的表现？
2
一致性(CS)，Consistency
2.1
测试过程的依赖关系是否已经识别？
3
正确性(CT)，Correctness
3.1
每个测试步骤可观测的结果是否与期望的程序行为一致？
3.2
测试输入数据及格式是否正确？
4
描述清晰性(DC)，Documentation/Clarity
4.1
测试用例的操作步骤是否清晰、显式的说明，以使测试按理可以容易执行？
4.2
测试按理的操作步骤是否是按照一步一步的方式进行描述，前后次序与实际应该执行的顺序一致？
4.3
系统初始化和测试步骤是否准确、无歧义的描述，是否每个步骤都作为单独的条目列出？
4.4
测试通过/失败的标准描述是否清晰、无歧义。
5
性能(PF)，Performance
5.1
如果一个性能标准与任何测试步骤相关，性能标准是否与操作指南一起被清晰的描述？
6
可靠性(RL)，Reliability
6.1
测试设备是否经过验证？测试软件是否经过验证？
6.2
测试的输入数据是否经过检验？
6.3
是否为验证软件的可靠性收集了足够的测试数据，这些测试数据是否进行了文档化？
7
可测试性(TL)，Testability
7.1
测试过程是否识别了测试需要的所有设备、软件、人员？
7.2
测试过程的执行是否最小化了开发组的支持？
7.3
测试过程是否与测试设备的能力一致？
7.4
测试的时间进度是否详细的进行了描述？
8
可追踪性(TR)，Traceability
8.1
测试用例是否列出了所有需要的规范、过程、手册？
8.2
系统需求与用例之间是否建立了跟踪关系？
备注
1、模板中未设计到的问题项，可根据实际情况添加内容。
意见汇总
序号
意见内容
1
2
3
以上就是关于《评审检查单-用户需求检查单、详细设计检查单、概要设计检查单》的全部内容，本文网址：https://www.7ca.cn/baike/24755.shtml，如对您有帮助可以分享给好友，谢谢。