详细设计评审检查表模板

详细设计说明书评审检查表

详细设计检查表
# 检查项是/否/不适用否不适用清晰性、完整性 1 是否清晰的描述了单元设计信息，包括数据流程、控制流程、接口？ 2 3 4 5 6 7 8 9 文档结构是否清晰、组织是否合理？文档结构是否便于维护和修改？设计是否易于理解？每个单元模块是否都有相应的标识? 是否对单元模块的目的和功能进行了描述？每个单元模块的输入/输出是否进行了描述? 是否说明了用于实现该单元模块的算法？是否提供了一致的错误处理机制?
10 系统结构是否合理、清晰？ 11 各子系统、模块之间的关系是否描述得清楚? 12 系统的设计是否考虑了系统的可扩展性? 13 设计是否考虑了重用性? 14 重用构件是否进行了标识? 15 是否说明了重用模块的获得方式和相关的文档? 16 系统的设计是否考虑了系统的易移植性? 17 设计是否使用标准的技术，避免使用怪异的、不易理解的方式和方法? 18 是否列出了所有的调用？ 19 对变量、指针和常量进行了定义和初始化吗？ 20 设计能实现特定的需求和目标吗？ 21 是否对程序的注释进行了设计？ 22 是否对程序的限制和约束进行了说明？ 23 所有设计是否是可测试的？一致性、正确性 24 文档是否符合项目标准？ 25 是否用要求的方法或工具进行设计的？ 26 数据元素的名称在整个单元中保持一致吗？ 27 所有的设计接口相互间是一致的吗？ 28 是否存在逻辑上的问题？ 29 是否对各种情况都进行了处理？（如大于、等于、小于0，switch/case情况） 30 是否为开发和维护代码提供了充分的基础？ 31 所有的设计单元都可追溯回需求吗？接口 32 参数的数量、类型和顺序是否匹配？ 33 是否正确的定义了输入输出数据？ 34 是否清晰的描述了传递参数的顺序？ 35 是否识别了传递参数的机制？可维护性、可靠性设计单元是否具有高内聚度低耦合度？（即该单元的变化不会对本单元造成不可预料 36 的影响，对其他单元的影响达到最小） 37 设计的复杂度已经最小了吗？

建筑设计专业中期检查表模板范文

建筑设计专业中期检查表模板范文一、基本信息。

学生姓名：[你的名字]学号：[具体学号]专业：建筑设计。

指导教师：[导师名字]（一）项目概述。

1. 项目名称：[项目的酷炫名字]2. 项目简介。

嗨，导师！我这个项目呢，就像是在打造一个梦想中的城市小角落。

想象一下，在一个繁忙的都市里，有那么一块地方，就像世外桃源一样。

我设计的这个建筑啊，它既有现代建筑的简洁线条，又融入了一些传统元素，就像是把过去和现在完美地融合在一起，像是一场穿越时空的建筑之旅呢。

它的功能也很丰富，有居住的部分，也有休闲娱乐的空间，是一个能让人们在忙碌生活中找到宁静和乐趣的地方。

（二）项目进展。

# 1. 设计理念发展。

最初的想法是怎么来的呢？其实很简单，就是我在逛街的时候，看到那些千篇一律的建筑，就想搞点不一样的。

我就想啊，如果我能把大自然的元素融入到建筑里，那该多酷啊。

比如说，像树叶的脉络一样的建筑线条，或者像蜂巢一样的空间结构。

然后我就开始各种查资料，从古老的建筑书籍到现代的建筑杂志，我就像一个探险家在寻找宝藏一样。

现在呢，我的设计理念就更成熟了，不仅仅是简单的自然元素的堆砌，而是要让建筑和周围的环境产生一种对话，就像两个老朋友在聊天一样和谐。

# 2. 方案设计。

功能布局：我在功能布局上可是费了不少心思呢。

居住区域我设计得很温馨，卧室的采光那是相当好，早上一睁眼就能看到阳光洒进来，就像被大自然轻轻唤醒一样。

休闲娱乐区域就更有趣了，有一个露天的小花园，里面种满了各种各样的花草，还有一个小小的泳池，夏天的时候在那里泡着，感觉自己就像个度假的小富豪。

公共区域呢，我把它设计得很开阔，大家可以在那里聊天、聚会，就像一个大家庭一样其乐融融。

流线组织：流线就像是建筑的血管一样重要。

我设计的流线非常清晰，从入口到各个功能区就像走迷宫一样有趣，但又不会迷路。

人们在建筑里行走的时候，就像是在探索一个神秘的城堡，每走一步都有新的发现。

比如说，从客厅到卧室的走廊上，我设计了一些小的展示空间，可以放一些艺术作品或者家庭照片，这样人们在走的时候还能欣赏一下美好的东西。

详细设计评审检查表模板

是否所有的构架原则在子程序中得到了实现? 是否定义了技术与工作的标准，如编码规范等？所有的接口（外部和内部）是否在子程序级完整得到描述? 该项工作的计划与实际成本是否合理？该项工作的计划与实际进度是否合理？
序号
1 2 3 4 5 6 7 8 9 10 11 12 13 建议: 表述是否清晰? 参数定义是否合理? 算法是否表述清晰? 公用类设计是否合理?
详细设计评审检查表检查项
内容是否完整,是否覆盖所有功能点，模块?
不适用优秀参数传递是否实际合理，表述清晰? 是否满足性能需求? 后续工作人员是否可以据此进行工作?

PCBA产品设计DFM检查表范例

布局
影响到后续装配和调测。
立式安装的元器件（二极管、电阻）存在碰撞隐患的是
13
布局
否有在管脚上套热缩套管。
板级之间涉及到的绝缘问题，需要检查元件是否存在短
14
布局路接触等隐患，元件是否有点胶固定竖立要求？是否有
增加铁氟龙的要求？
为保证电气绝缘，散热器等金属器件的底部（PCB表
15
布局
层）不能设计走线，或走线有做绝缘处理（绿油不能作为有效绝缘），与散热器同电位的走线除外。如不能满
件长边平行于V-CUT的，焊盘到V-CUT距离大于
53
分板
4mm，器件长边垂直于V-CUT的，焊盘到V-CUT距离
大于3mm。
54 元件成型是否有需要辅助工装才能成型的元件
需拔针的插针插座，PCB对应的拔针位置焊盘必须取消 55 元件成型。
56 元件成型组合端子必须前加工组装后才能插件、波峰焊
是否需要经过二次高温，标签能否承受，如有，提出评 84 贴BARCODE 估 85 特殊标识是否有特殊标记要求，如有，SOP重点说明
1.选用串口烧录的，记录烧录器、烧录线配件型号，并
做好备件管理；
86
单板烧录/测 2.串口烧录，必须做可操作性、软件稳定性验证；
试
3.选用测试点烧录的，必须做烧录工装可操作性，工装
PCBA产品设计DFM检查表
单板编码：
单板型号&版本：
试产日期：
序号
检查项目
内容
检查结果（OK/NG/无关）
NG项改进措施
1
BOM BOM物料用量、位号、规格是否与实际一致
2
BOM
BOM物料属性是否与实际一致（SMT料，DIP料，结构料）

概要设计说明书检查表

▢是▢否
是否设计已经可以支持本文档中遗留的TBD有可能带来的变更
▢是▢否
是否所有的TBD的影响都已经被评估了
▢是▢否
是否仍存在可能不可行的设计部分
▢是▢否
是否已记录设计时的权衡考虑该文件是否包括了权衡选择的标准和不选择其它方案的原因
▢是▢否
依从性
依从性该文档是否遵守了该项目的文档编写标准
▢是▢否
一致性
▢是▢否
是否所有的界面都提供了所要求的信息
▢是▢否
是否已说明内部各界面之间的关系
▢是▢否
界面的数量和复杂程度是否已减少到最小
▢是▢否
操作界面的设计是否有为用户考虑（例如：词汇、使用信息和进入的简易）
▢是▢否
可维护性
该设计是否是模块化的
▢是▢否
这些模块具有高内聚度和低耦合度
▢是▢否
是否已经对继承设计、代码或先前选择工具的使用进行了详细说明
▢是▢否
性能
主要性能参数是否已复（例如：输入输出检查）
▢是▢否
是否已考虑非正常情况
▢是▢否
是否所有的错误情况都被完整和准确地说明
▢是▢否
该设计是否满足该系统进行集成时所遵守的约定
▢是▢否
易测性
是否能够对该套系统进行测试、演示、分析或检查来说明它是满足需求的
▢是▢否
是否已描述最低级别数据元素是否已详细说明取值范围
▢是▢否
功能性
是否对每一下级模块进行了概要算法说明
▢是▢否
所选择的设计和算法能否满足所有的需求
▢是▢否
接口
操作界面的设计是否有为用户考虑（例如：词汇、使用信息和进入的简易）
▢是▢否
是否已描述界面的功能特性

产品详细设计评审检查表-模板

详细设计和总体设计之间是否存在冲突？
每一个模块的关键算法、关键数据结构是否清楚？
各模块之间的接口是否清晰？
设计是否是可实现的？
设计是否有遗漏和缺陷？
可读性检查
设计说明是否通俗易懂？
设计中，关键部分是否使用图表加以说明？
是否提供软件设计图（类图，序列图，状态图…）
是否提供数据结构设计图(数据库设计，XML结构设计，文件格式设计)
设计实现的瓶颈
依赖型检查
是否使用或依赖于第三方的产品？
第三方产品是否可以由不同的提供商替换？
设计中涉及到关键技术是否成熟？
其他问题
××产品详细设计评审检查表
【内容】
评审人员根据此表认真审核《产品详细设计规格说明书》。
如果是合同项目，可能还需要用户审核，视具体情况而定。
【裁剪原则】
此部分内容不允许裁剪。
评委名称
评委日期
YYYY-MM-DD
评审结论
合格不合格TBD待完成NA不适用
详细设计检查表
结论
基本检查
详细设计是否覆盖了所有的总体设计条目？
是否提供样例代码，说明如何使用？
可用性检查
设计中的命名是否与现有系统冲突
是否存在不合理的设计结构（例如包耦合：不应交叉耦合，层，包不应依赖于子系统，仅应依赖于其它包或接口）
设计是否与某些现有规范存在冲突？（编码规范，设计规范，J2EE规范….）
设计实现的复杂程度

详细设计说明书检查表

▢是▢否
是否所有的设计决定都能追溯到权衡考虑
▢是▢否
单元需求是否都能上溯到更高级别的文档更高级别文档的需求是否已经在单元中体现
▢是▢否
承建单位（盖章）：
负责人：
日期：
建设单位（盖章）：
项目经理：
日期：
监理机构（盖章）：
监理工程师：
日期：
是所有的逻辑都能被测试
▢是▢否
是否已描述测试程序、测试数据集和测试结果
▢是▢否
是否能够对每个单元进行测试、演示、分析或检查来说明它们是满足需求的。
▢是▢否
该设计是否包含检查点来帮助测试（例如：有条件的编译代码和数据声明测试）
▢是▢否
可追溯性
是否设计的每一部分都能追溯到其它项目文档的需求，也能追溯到更高级别文档的需求
可维护性
这些模块具有高内聚度和低耦合度
▢是▢否
性能
是否该单元的所有约束例如过程时间和规模都被详细说明
▢是▢否
可靠性
初始化是否使用到缺省值，缺省值是否正确
▢是▢否
是否在内存访问的时候执行了边界检查（例如：数组、数据结构、指针等）来确保只是改变了目标存储位置
▢是▢否
是否执行输入、输出、接口和结果的错误检查
▢是▢否
是否对所有错误情况都发出有意义的信息
▢是▢否
对特殊情况返回的代码是否和已规定的全局定义的返回代码相匹配
▢是▢否
是否考虑到意外事件
▢是▢否
易测性
是否能够对每个单元进行测试、演示、分析或检查来说明它们是满足需求的。
▢是▢否
该设计是否包含检查点来帮助测试（例如：有条件的编译代码和数据声明测试）
▢是▢否
▢是▢否
接口

施工组织设计中期检查表范文

施工组织设计中期检查表范文一、工程基本信息。

工程名称：[具体工程名称]工程地点：[详细地点]建设单位：[建设单位名称]施工单位：[施工单位名称]二、检查日期。

[年/月/日]三、检查小组成员。

[组长姓名]、[成员姓名1]、[成员姓名2]……四、检查内容及结果。

# （一）工程进度。

1. 计划进度对比。

按照施工组织设计的初始计划，到目前这个阶段，我们应该已经完成[具体的进度节点，比如基础工程的混凝土浇筑]。

实际情况呢，基础工程的混凝土浇筑确实已经顺利完成，而且还比计划提前了两天呢。

这就像是跑步比赛，本来计划着匀速前进，结果一不小心还超了点速，这可得给施工团队点个赞。

在接下来的[下一阶段工程，比如主体结构一层的钢筋绑扎]进度方面，虽然整体上还在按计划推进，但是在一些细节部分，比如钢筋的运输和堆放，由于场地的临时调整，稍微有点耽误。

这就好比是本来一路畅通的自驾游，突然遇到了一段在修路的路段，得绕个小弯儿。

不过施工团队已经及时调整了方案，应该能够很快赶上进度。

2. 关键工序进度控制。

对于本工程的关键工序，像[列举关键工序，如深基坑支护]，目前进展得非常顺利。

深基坑支护工程就像给整个工程打地基的“保镖”，这个“保镖”的工作做得很扎实。

施工单位在这方面投入了足够的人力和物力，按照设计要求严格施工，每一个支护桩都打得稳稳当当的，就像一个个忠诚的卫士守护着未来的大楼根基。

但是在[另一个关键工序，如大型设备的安装基础施工]方面，遇到了一些地质方面的小问题。

地下的土质比预想的要复杂一些，有点像打开一个神秘的宝盒，结果发现里面的东西和说明书不太一样。

不过施工单位及时请来了地质专家进行会诊，重新调整了基础的施工方案，目前已经重新回到了正常的进度轨道上。

# （二）工程质量。

1. 材料质量。

在材料的选用上，施工单位基本都是按照施工组织设计的要求来做的。

就拿钢材来说吧，进场的钢材都有合格的质量证明文件，就像每个人都带着自己的身份证一样，而且还经过了严格的抽样检测。

设计内审检查表

(6)查：设计开发输出信息。（图纸、产品特性、产品使用说明书等）
设计开发输出输出文件被批准的证据。
都符合要求。
标准/文件
条款号
检查内容和方法
检查记录
备注
7.3.4设计和开发评审
1.是否按照设计和开发策划设置的评审点进行系统的评审?各评审点的内容和参加人员是否符合策划的安排?
2.对各评审点和评审是否达到:
标准/文件
条款号
检查内容和方法
检查记录
备注
7.3.7设计和开发更改的控制
1.当需要更改设计时,是否及时予以识别并进行更改?实施更改前是否得到了批准?
2.对某些设计和开发的重要更改是否经过评审、验证和确认?评审是否包括评价(如零部件)更改对产品组成部分和已交付产品的影响?
3.更改记录是否包括更改的评审结果及必要措施?
条款号
检查内容和方法
检查记录
备注
7.3.3设计和开发输出
1.设计和开发输出文件有哪些?是否以能够对输入进行验证的方式提出?
2.设计和开发输出文件在发放前是否得到批准?
3.设计和开发输出文件是否满足如下要求:
满足输入要求?
给出采购/生产和服务提供的适当信息?
包含或引用产品接受准则?
规定产品安全和正常使用所必需的产品特点(如操作/贮存、/维修和处置的要求).
技术部
标准/文件
条款号
检查内容和方法
检查记录
备注
7.3.2设计和开发输入
1.设计和开发是否形成了文件?文件的内容应包括:
产品的适宜性要求(如性能和功能,感官特性)?
法律法规和标准要求.
适用时以前类似设计提供的信息?
所必需的其他要求(如使用条件及限制、材料、零件要求、需开发的材料、工艺要求等)?

施工组织设计中期检查表范文

施工组织设计中期检查表范文一、工程基本信息。

工程名称：[具体工程名称]工程地点：[详细地点]建设单位：[建设单位名称]施工单位：[施工单位名称]二、检查日期。

[年/月/日]三、检查人员。

[检查人员姓名]四、检查内容及情况。

# （一）工程进度。

1. 计划与实际对比。

按照施工组织设计的初始计划，到目前这个阶段，[主体结构施工/基础工程等某个关键部分]应该已经完成了[X]%。

实际一瞅呢，还真不错，已经完成了差不多[X]%，就像一个努力奔跑的选手，虽然有点小差距，但基本还是在赛道上紧紧跟着计划的步伐呢。

不过在[具体分项工程，如某楼层的砌墙工程]这里，稍微有点小拖后腿。

原本计划这部分早就该完工了，可实际只完成了[X]%，就像跑步的时候不小心被鞋带绊了一下。

经过了解啊，原来是[说明原因，比如材料供应不及时，部分工人被临时抽调去处理紧急情况等]。

不过施工方已经采取了措施，比如[加快材料采购、调回工人等具体措施]，看起来就像是给这个小毛病开了个药方，正在努力让工程进度重新跑起来。

2. 关键线路上的工作。

关键线路就像是这个工程的主动脉，关乎着整个工程的生死存亡。

目前来看，在关键线路上的工作大部分进展顺利，就像心脏跳动得很规律。

像[关键工作名称，如深基坑的支护工程]已经按照计划完成了关键节点，这就像给整个工程打了一针强心剂，让我们对后续的工程充满信心。

但是呢，其中有个小插曲，[某个关键工序]因为[天气/设计变更等原因]耽误了几天。

不过施工团队反应很迅速，马上调整了工作计划，增加了[设备/人力等资源]，把失去的时间一点点追回来，这就像在赛道上摔倒后迅速爬起来继续冲刺的运动员，精神可嘉啊。

# （二）工程质量。

1. 原材料质量。

施工就像做饭，原材料就是食材，食材不好，做出来的饭肯定也不香。

所以我们对原材料质量进行了严格检查。

目前来看，大部分原材料质量还是很靠谱的，就像超市里精挑细选的新鲜食材。

像钢筋，那是一根一根检查的，都符合设计要求，强度、规格啥的都没毛病，就像一群纪律严明的士兵，站得笔直。

设计信息检查表(1.0版)

150
系统测试是否符合产品要求，验证结果是否符合要求
151
性能测试是否符合设计要求，测试结果是否符合设计要求
编制：审核：复核：批准：
设计信息检查表（表五）
顾客或厂内零件号□手工样件□工程样件□小批量编号：BG-QR-06-06/1
问题
是
否
所要求的意见/措施
负责人
备注
E.测试/验证类
152
使用现有的检验技术，是否有些规定要求不能被评价？
问题
是
否
所要求的意见/措施
负责人
备注
48
先遣的材料供方是否在顾客批准的名单中？
49
是否要求材料供方对每一批货提供检验证明？
50
是否已明确材料特性所要求的检验？如果是，则：
51
·特性将在厂内进行检验吗？
52
·具备试验设备吗？
53
·为保证准确结果，需要培训吗？
54
将使用外部试验室吗？
55
所有被使用的试验室得到认可吗（如要求）？
81
将使用外部试验室吗？
82
所有被使用的试验室得到认可吗（如要求）？
83
是否解决了实验室发现问题和用户反馈问题？
84
是否已考虑以下材料要求
85
对于影响配合、功能和耐久性的尺寸是否已明确？（与结构）
86
可制造性，工艺是否合理？是否满足批量生产？
87
此板卡与外部设备连接是否可通用
88
相关程序是否与软件系统兼容性
9
如果是，是由横向职能小组完成的吗？
10
是否对所有规定的试验、方法、设备和接受准则有一个清楚的定义和了解？
11
是否已选择特殊特性？

项目设计评审检查表

设计评审检查单
项目名称评审人
项目经理评审日期
合格不合格未检查不适用
共计
结论
统计结果
0
0
0
0
0
序号概要设计
检查内容
1 设计方案是否满足产品需求与用户需求的功能、性能及安全性等所有要求？
2 设计方案的架构设计是否简单而清晰？ 3 是否尽可能避免了模块（或子系统）间的相关性？
4 是否对处理流程、总体结构与模块、功能与模块的关系进行了清楚的描述？
5 是否对数据结构了清晰描述？对内部模块间接口进行了清楚描述？
7 如果有移植的需求，那么设计中是否对移植性作了充分的考虑？ 8 如果采用数据库技术，数据库设计是否与其了他设计内容一致？ 9 是否详细考虑了编码时的代码复用问题？ 10 设计方案是否考虑了软件的扩展性与维护性？ 11 是否规定了设计与编码时的命名规则？ 12 是否进行了出错信息与出错处理的设计？详细设计 13 界面设计是否布置合理、版面美观、内容协调？
14 如果采用面向对象的设计方法，是否对对象模型进行了清楚表述？
检查情况
15 如果采用面向结构化的设计方法，是否对模块结构关系进行了清楚表述？
16 每个对象（或模块）的数据结构、处理逻辑都进行了必要的描述？
17
对重要的用户使用场景是否用动态模型（表述系统如何响应特定事件）进行描述？
评审人意见补充信息

详细设计评审表模板

详细设计评审表模板
工程负责人: 评审时间：
:评审流程
1、由公司领导、各部门相关人员、主审人、评审专家、工程负责人、软件测试人员组成一个评审小组,通过阅读和讨论详细设计的内容,
对详细设计进行评审.
2、工程负责人提前把概要设计说明书、详细设计说明书等文档分发给评审小组成员,作为评审依据,小组成员在充分阅读这些材料之后,
进入下一步.
3、召开详细设计评审会.在会上,首先由该工程的系统分析员介绍总体设计思想,包括需求概述和软件结构,然后由各个模块的具体设计者
分别对模块设计进行说明,在此过程中,小组成员可以提出问题,展开讨论,审查是否有错误存在.
4、在讨论结束后,由工程负责人整理出一份?详细设计评审报告?.
5、假设发现错误较多,或发现重大错误,那么在改正之后,再次组织详细设计评审.
详细设计评审.doc
第1页共2页
工程名称: 主审人：
详细设计评审.doc
主审人的总结意见和签字:
第2页共2页。

设计评审检查表

设计评审检查表
评审日期：No.
风险评估：
改正方法
改正计划
项目组评审意见：
生产部评审意见：
品质部评审意见：
工程部评审意见：
市场部评审意见：
计划部评审意见：
中央研究院：
改善的结果
评审结论：
通过不通过
总工/副总评审意见：签名：Leabharlann 总经理评审意见：签名：
第2页共2页
一、设计资料的制订：
特殊特性清单
DFMEA表
产品规格书
材料表
样品控制计划表
PFMEA
物料技术要求
小试控制计划
工艺文件
技术图纸
工艺流程图
中试控制计划
试产前控制计划
量产控制计划
二、新增设备/工装/模具
新增设备/工装
新增量具检验设备
新增模具
三、验证报告
四、小/中试产品合格率
五、生产过程记录
不完善事项：
第1页共2页
设计评审检查表
评审日期：编制人：No.
产品名称
设计人员
产品规格
评审人员
数量
（中/小试）数量：(试产)数量：（批量）数量：
评审依据：
客户要求：
其它：
评审项目名称：
项目目标：
评审阶段
评审内容
评审资料编号
备注
样品试作前评审
样品制作后评审
小试前评审
小试后评审
中试前评审
中试后评审
试产前评审
批量生产前评审
批量生产后评审

测试设计评审检查表

12 测试人员是否掌握测试工具及是否具备相关的专业知识？
说明：（责任人对确定为“否”的检查项给出必要说明）
第 1 页/共 1 页
测试设计评审检查表
表格编号：项目编号-阶段/文档类别代号-两位顺序号
项目名称：
序号
检查项
结果
1 测试人员是否明确软件需求规格说明书的内容？
2 测试人员对项目本身及涉及的行业知识是否已经了解？
3 测试大纲是否含盖了所有的测试内容？
4 主要模块的测试用例是否已经设计完成？
5 正面功能测试（测试基本功能是否能够正常使用）用例是否正确？关联测试（一个组件由于测试发生变化，其它相关组件是否正确改变）用例是
6 否正确？极限/边界值测试（测试最大最小值，包括最大值、最大值+-1、最小值、最小
7 值+-1）用例是否正确？错误/反面测试（测试非法输入、非法命令、非法操作程序处理是否正确）用例
8 是否正确？
9 是否设计系统容错方面的测试用例？
10 性能测试用例是否合理、有效？
Байду номын сангаас
11 测试工具（或自动化程序）针对系统本身是否可行？

概要设计说明书评审检查表

26 是否所有接口都提供了要求的类型、数量和质量信息？ 27 是否对接口的数量和复杂度进行了权衡，使接口的数量少并且复杂程度可以接受？
28 用户接口是否进行了描述?
29 用户接口是否模块化，并且修改时不影响其他程序?
可维护性、可靠性
30 设计是模块化的吗？
31 模块具有高内聚度低耦合度吗？
32 设计中是否提供了对错误的检测和恢复的设计？
一致性
19 在整个设计中，是否对数据元素、程序、功能的命名保持一致？
20 设计是否反应了真实的运行环境，包括软件和硬件？ 21 对模块的说明是否与软件需求文档中的功能要求相一致？
22 是否所有的设计元素都可追踪回需求？
接口
23 是否对接口的功能特征进行了描述？
24 接口是否便于问题的解决？ 25 是否所有的接口间相互一致，并和其他模块及需求相一致？
概要设计说明书评审检查表概要设计评审概要设计说明书概要设计说明书实例系统概要设计说明书概要设计软件概要设计说明书概要设计说明书模板概要设计模板5a0件概要设计系统概要设计
概要设计检查表
#
检查项
清晰性
1 文档结构是否清晰、组织是否合理？
2 文档结构是否便于维护和修改？
3 设计是否易于理解？
4 各模块之间的关系否描述的清楚？
12 是否对共享和存储数据的管理和使用进行了明确的描述？
13 是否说明了数据结构与系统模块之间的关系？
14 此设计是否能为详细设计提供充分的基础？
15 是否每个设计都是可测试的或以别的方式可以确定的？
16 设计是否考虑到未来的扩充性？
17 设计的系统是否易于维护？
18 是否对性能参数进行了说明?（如，实施约束、内存大小、速度要求等）

软件设计评审检查表

测试计划检查表
Y: 是 TBD:不确定 N: 不是 NA:不适用
检查项
Y/TBD/N/NA
完整性
该测试计划是否详细说明测试的大体方法和策略？
该测试计划是否详细说明所有测试活动的顺序？
该测试计划是否描述了将使用的软硬件系统环境?
该测试计划是否描述了测试活动中断和恢复的条件/情形？
该测试计划是否为所有测试定义了成功标准？
是否详细说明了参数的度量单位、取值范围、正确度和精度？
共享数据区域及其存取规定的映射是否一致？
可维护性
单元是否具有高内聚度和低耦合度（例如：对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小）？
性能
是否该单元的所有约束例（如过程时间和规模）都被详细说明？
可靠性
初始化是否使用到缺省值，缺省值是否正确？
包括了数据流、控制流和接口的单元设计是否已清晰的说明？
完整性
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）?
是否已列出该单元的调用？
依从性
该文档是否遵循了该项目已文档化的标准？
是否采用了所要求的方法和工具来进行单元设计？
该测试计划是否充分地描述了被测试的功能？
该测试计划是否明确地描述了不被测试的功能？
该测试计划是否充分地描述了测试基线？
对于阶段交付，该测试计划是否有在每一阶段建立测试基线给下一阶段使用？
该测试计划是否定义了足够和正确的衰退测试？
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档？
一致性
是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序？

产品详细设计评审检查表-模板

××产品详细设计评审检查表
【内容】
●评审人员根据此表认真审核《产品详细设计规格说明书》。

●如果是合同项目，可能还需要用户审核，视具体情况而定。

【裁剪原则】
此部分内容不允许裁剪。

评委名称
评委日期YYYY-MM-DD
评审结论合格不合格 TBD 待完成 NA 不适用详细设计检查表结论
基本检查详细设计是否覆盖了所有的总体设计条目？
详细设计和总体设计之间是否存在冲突？每一个模块的关键算法、关键数据结构是否清楚？
各模块之间的接口是否清晰？
设计是否是可实现的？
设计是否有遗漏和缺陷？
可读性检查设计说明是否通俗易懂？
设计中，关键部分是否使用图表加以说明？是否提供软件设计图（类图，序列图，状态图…）
是否提供数据结构设计图(数据库设计，XML结构设计，文件格式设计)
是否提供样例代码，说明如何使用？
可用性检查设计中的命名是否与
现有系统冲突
是否存在不合理的设计结构（例如包耦合：不应交叉耦合，下层中的包不应依赖于上层中的包，依赖关系不得跳层，包不应依赖于子系统，仅应依赖于其它包或接口）
设计是否与某些现有规范存在冲突？（编码规范，设计规范，J2EE 规范….）
设计实现的复杂程度设计实现的瓶颈
依赖型检查是否使用或依赖于第三方的产品？
第三方产品是否可以由不同的提供商替换？
设计中涉及到关键技术是否成熟？
其他问题。

软件设计与开发评审检查表

软件设计与开发评审检查表————————————————————————————————作者：————————————————————————————————日期:需求规格说明书检查表Y: 是 TBD: 不确定 N：不是 NA:不适用备注检查项Y/ＴBD/N／NA清晰性系统的目标是否已定义？是否对关键术语和缩略语进行定义和描述？所使用的术语是否和用户/客户使用的一致?需求的描述是否清晰，不含糊？是否有对整套系统进行功能概述？是否已详细说明了软件环境(共存的软件）和硬件环境 (特定的配置）？如果有会影响实施的假设情况,是否已经声明？是否已经对每个业务逻辑进行输入、输出以及过程的详细说明?完整性是否列出了系统所必须的依赖、假设以及约束？是否对每个提交物或阶段实施都进行了需求说明?需求说明书是否已包括了主要的质量属性,例如有效性、高效性、灵活性、完整性、互操作性、可靠性、健壮性、可用性、可维护性、可移植性、可重用性和可测试性。

依从性该文档是否遵守了该项目的文档编写标准？一致性需求说明是否存在直接相互矛盾的条目？本需求说明书是否与相关需求素材一致？可行性所描述的所有功能是否必要并充分地满足了客户/系统目标？需求说明书的描述的详细程度是否足以进行详细的设计？已知的限制（局限）是否已经详细说明？是否已确定每个需求的优先级别?可管理性是否将需求分别陈述，因此它们是独立的并且是可检查的?是否所有需求都可以回溯到相应的需求素材,反之亦然?是否已详细说明需求变更的过程?概要设计检查表Y：是ＴBD: 不确定 N：不是 NＡ:不适用检查项Y/TＢＤ/Ｎ／NA 清晰性是否所设计的架构,包括数据流，控制流和接口,被清楚地表达了?是否所有的假设、约束、策略及依赖都被记录在本文档了?是否定义了总体设计目标？完整性是否所有的以前的TBD（待确定条目）都已经被解决了?是否设计已经可以支持本文档中遗留的TBD有可能带来的变更？是否所有的TＢＤ的影响都已经被评估了？是否仍存在可能不可行的设计部分?是否已记录设计时的权衡考虑? 该文件是否包括了权衡选择的标准和不选择其它方案的原因?依从性是否遵守了项目的文档编写标准？一致性数据元素、流程和对象的命名和使用在整套系统和外部接口之间是否一致？该设计是否反映了实际操作环境(硬件、软件、支持软件）？可行性从进度、预算和技术角度上看该设计是否可行?是否存在错误的、缺少的或不完整的逻辑?数据使用所有复合数据元素、参数以及对象的概念是否都已文档化?是否还有任何需要的但还没有定义的数据结构，反之亦然？是否已描述最低级别数据元素？是否已详细说明取值范围？功能性是否对每一下级模块进行了概要算法说明？所选择的设计和算法能否满足所有的需求？接口操作界面的设计是否有为用户考虑(例如:词汇、使用信息和进入的简易）?是否已描述界面的功能特性?界面将有利于问题解决吗？是否所有界面都互相一致,与其它模块一致,以及和更高级别文档中的需求一致？是否所有的界面都提供了所要求的信息？是否已说明内部各界面之间的关系?界面的数量和复杂程度是否已减少到最小？可维护性该设计是否是模块化的？这些模块具有高内聚度和低耦合度？是否已经对继承设计、代码或先前选择工具的使用进行了详细说明？性能主要性能参数是否已被详细说明(例如:实时、速度要求、磁盘输入／输出接口等)?可靠性该设计能够提供错误检测和恢复(例如：输入输出检查)?是否已考虑非正常情况?是否所有的错误情况都被完整和准确地说明?该设计是否满足该系统进行集成时所遵守的约定？易测性是否能够对该套系统进行测试、演示、分析或检查来说明它是满足需求的？该套系统是否能用增量型的方法来集成和测试？可追溯性是否各部分的设计都能追溯到需求说明书的需求？是否所有的设计决策都能追溯到原来确定的权衡因素?所继承设计的已知风险是否已确定和分析？详细设计检查表Ｙ: 是 TBD: 不确定 N: 不是NA:不适用检查项Ｙ/TBＤ/N／NA 清晰性所有单元或过程的目的是否都已文档化?包括了数据流、控制流和接口的单元设计是否已清晰的说明？完整性是否已定义和初始化所有的变量、指针和常量?是否已描述单元的全部功能?是否已详细说明用来实现该单元的关键算法（例如:用自然语言或PDＬ)？是否已列出该单元的调用?依从性该文档是否遵循了该项目已文档化的标准？是否采用了所要求的方法和工具来进行单元设计?一致性数据元素的命名和使用在整个单元和单元接口之间是否一致?所有接口的设计是否互相一致并且和更高级别文档一致?正确性是否处理所有条件 (大于、等于、小于零、switch／case）?是否存在处理“ｃase ｎot found”的条件?是否正确地规定了分支(逻辑没有颠倒）？数据使用是否所有声明的数据都被实际使用到？是否所有该单元的数据结构都被详细说明？是否所有修改共享数据(或文件)的程序都考虑到了其它程序对该共享数据(或文件）的存取权限?是否所有逻辑单元、时间标志和同步标志都被定义和初始化？接口接口参数在数量、类型和顺序上是否匹配？是否所有的输入和输出都被正确定义和检查?是否传递参数序列都被清晰的描述？是否所有参数和控制标志由已描述的单元传递或返回？是否详细说明了参数的度量单位、取值范围、正确度和精度?共享数据区域及其存取规定的映射是否一致?可维护性单元是否具有高内聚度和低耦合度（例如:对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小）?性能是否该单元的所有约束例(如过程时间和规模）都被详细说明?可靠性初始化是否使用到缺省值,缺省值是否正确?是否在内存访问的时候执行了边界检查(例如:数组、数据结构、指针等）来确保只是改变了目标存储位置?是否执行输入、输出、接口和结果的错误检查?是否对所有错误情况都发出有意义的信息？对特殊情况返回的代码是否和已规定的全局定义的返回代码相匹配？是否考虑到意外事件？易测性是否能够对每个单元进行测试、演示、分析或检查来说明它们是满足需求的？该设计是否包含检查点来帮助测试(例如：有条件的编译代码和数据声明测试）？是否所有的逻辑都能被测试?是否已描述测试程序、测试数据集和测试结果?可追溯性是否设计的每一部分都能追溯到其它项目文档的需求，也能追溯到更高级别文档的需求?是否所有的设计决定都能追溯到权衡考虑?单元需求是否都能上溯到更高级别的文档？更高级别文档的需求是否已经在单元中体现?Y：是ＴBＤ: 不确定 N: 不是ＮA:不适用检查项Y/TBＤ/N/NA 完整性该测试计划是否详细说明测试的大体方法和策略？该测试计划是否详细说明所有测试活动的顺序？该测试计划是否描述了将使用的软硬件系统环境？该测试计划是否描述了测试活动中断和恢复的条件／情形?该测试计划是否为所有测试定义了成功标准？该测试计划是否充分地描述了被测试的功能？该测试计划是否明确地描述了不被测试的功能？该测试计划是否充分地描述了测试基线?对于阶段交付,该测试计划是否有在每一阶段建立测试基线给下一阶段使用？该测试计划是否定义了足够和正确的衰退测试？依从性该测试计划是否依从了与开发有关的所有说明书、标准和文档？一致性是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序？该测试计划是否和更高级别的测试计划文档一致?正确性该测试计划的进入和退出条件是否实现?是否所有必须的驱动程序和桩(sｔｕbs)都已被定义且可利用来测试指定的功能?详细级别/程度测试案例是否完整覆盖了所有功能，是否覆盖了被测试功能的正常执行情况？测试案例集是否覆盖了足够的非法和冲突的输入?测试案例集是否包括了足够的默认输入值的使用?测试案例集是否考虑到了足够数量的程序错误路径？易测性/可行性测试方法是否可行？是否所有被认为不可测的需求都被详细说明并说明原因?是否对获得测试软件、方法和工具分配了足够的时间并形成了进度计划?测试所要求的资源是否已经详细说明和估计?对于多次的构建(buildｓ),是否已在前一构建的基础上确定所有的需求?测试所包含的所有人员的角色和职责是否都已详细说明？在已计划的测试人员之间是否存在进度冲突？可追溯性测试是否有执行/演示在适当级别的文档所说明的需求？测试验收标准是否可追溯到更高级别的文档?开发阶段/测试阶段单元测试/承建方开发组集成测试/承建方开发组、测试组确认测试/承建方测试组系统测试/业主联合测试组软件需求分析无无完成确认测试计划完成系统测试计划软件概要设计无完成软件集成测试计划开始设计确认测试用例、编写确认测试说明开始设计系统测试用例、编写系统测试说明软件详细设计完成软件单元测试计划开始设计集成测试用例、编写集成测试说明软件编码编写软件单元测试说明、执行软件单元测试、编写软件单元测试报告软件测试无完成集成测试说明、执行集成测试、进行测试分析、编写软件集成测试报告完成软件确认测试说明、执行软件确认测试、进行测试分析、编写确认测试报告完成系统测试说明、执行系统测试、进行测试分析、编写系统测试报告。