软件设计与开发评审检查表
合集下载
QMS内审检查表(总表)
b)是否通过下列活动，评价是否需要采取措施，以消除产生不合格的原因，避免其再次发生或者在其他场合发生：
1）评审和分析不合格？
2）确定不合格的原因？
3）确定是否存在或可能发生类似的不合格？
c)是否实施所需的资源？
d)是否评审所采取的纠正措施的有效性？
e)需要时，是否更新在策划期间确定的风险和机遇？
f)需要时，是否变更质量管理体系？
g)纠正措施是否与不合格所产生的影响相适应？
组织是否保留成文信息，作为下列事项的证据：
a)不合格的性质以及随后所采取的措施？
b)纠正措施的结果？
10.3持续改进组织是否持续改进管理体系的适宜性、充分性和有效性？
组织是否考虑分析和评价以及管理评审的输出，以确定是否存在需求或机遇？这些需求或机遇是否应作为持续改进的一部份加以应对？。
IATF16949 APQP—含设计—表单
设计失效模式及后果分析框图/环境极限条件表
设计失效模式和后果分析
核 准
审 查
制 表
第 1 页，共 5 页 PPP-2-04A0-1
K C E 有 限 公 司
新 产 品 项 目 APQP 开 发 计 划 （续上页）
制定部门： 制定日期： 年 月 日
产品名称
产品编号
规格/型号
顾客名称
序
号
工 作 内 容 / 项 目
九、新产品开发的进度安排：
核 准
审 查
制 表
第 页共 页 PPP-2-01A0-3
XXX 有 限 公 司
新 产 品 制 造 可 行 性 报 告（续）
评估部门： 评估日期： 年 月 日
新产品名称
开发产品数量
新产品
规格/型号
顾 客 名 称
十、新产品的预计年产量、成本估算、价格预算：
十一、投资预算（包括：人员投资、设施/设备投资等）：
开发产品名称
开发产品数量
产品规格/型号
顾 客 名 称
提交顾客
批准的日期
提交顾客批准/
确认的数量
新产品项目
开发来源/依据
新 产 品 项 目 开 发 要 求 和 / 或 顾 客 要 求
申请开发的结论：
总经理（签名）：
批准日期：
备
注
核 准
审 查
制 表
PPP-2-02A0
XXX 有 限 公 司
多方论证小组成员及职责表
量具极差法分析表
量具稳定性分析报告
量具偏倚分析报告
量具线性分析报告
计数型量具小样法分析报告
55
初始过程能力研究（★）
X—R控制图
56
设计失效模式和后果分析
核 准
审 查
制 表
第 1 页，共 5 页 PPP-2-04A0-1
K C E 有 限 公 司
新 产 品 项 目 APQP 开 发 计 划 （续上页）
制定部门： 制定日期： 年 月 日
产品名称
产品编号
规格/型号
顾客名称
序
号
工 作 内 容 / 项 目
九、新产品开发的进度安排：
核 准
审 查
制 表
第 页共 页 PPP-2-01A0-3
XXX 有 限 公 司
新 产 品 制 造 可 行 性 报 告（续）
评估部门： 评估日期： 年 月 日
新产品名称
开发产品数量
新产品
规格/型号
顾 客 名 称
十、新产品的预计年产量、成本估算、价格预算：
十一、投资预算（包括：人员投资、设施/设备投资等）：
开发产品名称
开发产品数量
产品规格/型号
顾 客 名 称
提交顾客
批准的日期
提交顾客批准/
确认的数量
新产品项目
开发来源/依据
新 产 品 项 目 开 发 要 求 和 / 或 顾 客 要 求
申请开发的结论：
总经理（签名）：
批准日期：
备
注
核 准
审 查
制 表
PPP-2-02A0
XXX 有 限 公 司
多方论证小组成员及职责表
量具极差法分析表
量具稳定性分析报告
量具偏倚分析报告
量具线性分析报告
计数型量具小样法分析报告
55
初始过程能力研究（★）
X—R控制图
56
软件设计与开发评审检查表
是否在内存访问的时候执行了边界检查（例如: 数组、数据结构、指针等）来保证只是改变了目的存储位置？
是否执行输入、输出、接口和结果的错误检查？
是否对所有错误情况都发出故意义的信息？
对特殊情况返回的代码是否和已规定的全局定义的返回代码相匹配？
是否考虑到意外事件？
易测性
是否可以对每个单元进行测试、演示、分析或检查来说明它们是满足需求的？
该套系统是否能用增量型的方法来集成和测试？
可追溯性
是否各部分的设计都能追溯到需求说明书的需求？
是否所有的设计决策都能追溯到本来拟定的权衡因素?
所继承设计的已知风险是否已拟定和分析？
具体设计检查表
Y: 是 TBD: 不拟定 N: 不是 NA:不合用
检查项
Y/TBD/N/NA
清楚性
所有单元或过程的目的是否都已文档化？
一致性
数据元素的命名和使用在整个单元和单元接口之间是否一致？
所有接口的设计是否互相一致并且和更高级别文档一致？
对的性
是否解决所有条件 （大于、等于、小于零、switch/case）？ 是否存在解决“case not found”的条件？
是否对的地规定了分支（逻辑没有颠倒）？
数据使用
是否所有声明的数据都被实际使用到？
Y: 是 TBD: 不拟定 N: 不是 NA:不合用
备注
检查项
Y/TBD/N/NA
清楚性
系统的目的是否已定义？
是否对关键术语和缩略语进行定义和描述？
所使用的术语是否和用户/客户使用的一致？
需求的描述是否清楚, 不模糊？
是否有对整套系统进行功能概述？
是否已具体说明了软件环境 (共存的软件) 和硬件环境 (特定的配置)？
是否执行输入、输出、接口和结果的错误检查？
是否对所有错误情况都发出故意义的信息？
对特殊情况返回的代码是否和已规定的全局定义的返回代码相匹配？
是否考虑到意外事件？
易测性
是否可以对每个单元进行测试、演示、分析或检查来说明它们是满足需求的？
该套系统是否能用增量型的方法来集成和测试？
可追溯性
是否各部分的设计都能追溯到需求说明书的需求？
是否所有的设计决策都能追溯到本来拟定的权衡因素?
所继承设计的已知风险是否已拟定和分析？
具体设计检查表
Y: 是 TBD: 不拟定 N: 不是 NA:不合用
检查项
Y/TBD/N/NA
清楚性
所有单元或过程的目的是否都已文档化？
一致性
数据元素的命名和使用在整个单元和单元接口之间是否一致？
所有接口的设计是否互相一致并且和更高级别文档一致？
对的性
是否解决所有条件 （大于、等于、小于零、switch/case）？ 是否存在解决“case not found”的条件？
是否对的地规定了分支（逻辑没有颠倒）？
数据使用
是否所有声明的数据都被实际使用到？
Y: 是 TBD: 不拟定 N: 不是 NA:不合用
备注
检查项
Y/TBD/N/NA
清楚性
系统的目的是否已定义？
是否对关键术语和缩略语进行定义和描述？
所使用的术语是否和用户/客户使用的一致？
需求的描述是否清楚, 不模糊？
是否有对整套系统进行功能概述？
是否已具体说明了软件环境 (共存的软件) 和硬件环境 (特定的配置)？
GJB9001C研发部内部审核检查表
查光电探测载荷总成产品《研制方案》对关键因素和薄弱环节进行了识别，在《设计评审》中提出了控制建议，并在试制过程中进行验证
6.是否确定设计和开发的标准及规范
查见外来文件GJB 1362A-2007军工性进行分析
查《特性分析报告》中规定了微波传输设备、信息机处理主机、光电探测载荷总成的重要指标是信号处理模块
5.设计开发输出的方式是否在放行前得到批准
放行前均经过批准。
6.输出文件是否齐全，符合标准要求
产品规范、工艺总方案、工艺规程、使用手册、培训教材、交互式电子技术手册、通用质量特性设计报告、风险分析报告（含风险控制措施）
7.是否制定关重件（特性）项目明细表，有无在设计文件和工艺文件上作相应标识
查《关重件明细表》、工艺文件等
8.5.7关键过程
1.是否识别关键过程，并实施控制
关键过程在《关键过程管理规定》中体现控制要求，2015年研制过程中经过识别，无关键过程
2.关键过程的资源是否充分适宜
2015年研制过程中经过识别，无关键过程
8.5生产和服务提供
8.5.7关键过程
3.是否对关键过程进行规定
编制了《关键过程管理规定》
4.是否设置控制点并进行有效测量和控制
提供了关键过程检查记录空表单
6.2质量目标
部门质量目标的实现情况
注（判定）：√为符合；×为不符合，见不合格报告。
相关文件规定设置有生产过程控制点
5.是否建立有测量分析记录
查2017年X月生产及服务记录1份，检验记录中有测量分析记录
6.对重要特性是否进行百分之百检验
《检验规范》中规定产品重要特性的检验规则，要求符合GJB 179A-2005
7.是否运用统计技术
通过培训、对质量数据收集统计分析并加以应用
6.是否确定设计和开发的标准及规范
查见外来文件GJB 1362A-2007军工性进行分析
查《特性分析报告》中规定了微波传输设备、信息机处理主机、光电探测载荷总成的重要指标是信号处理模块
5.设计开发输出的方式是否在放行前得到批准
放行前均经过批准。
6.输出文件是否齐全，符合标准要求
产品规范、工艺总方案、工艺规程、使用手册、培训教材、交互式电子技术手册、通用质量特性设计报告、风险分析报告（含风险控制措施）
7.是否制定关重件（特性）项目明细表，有无在设计文件和工艺文件上作相应标识
查《关重件明细表》、工艺文件等
8.5.7关键过程
1.是否识别关键过程，并实施控制
关键过程在《关键过程管理规定》中体现控制要求，2015年研制过程中经过识别，无关键过程
2.关键过程的资源是否充分适宜
2015年研制过程中经过识别，无关键过程
8.5生产和服务提供
8.5.7关键过程
3.是否对关键过程进行规定
编制了《关键过程管理规定》
4.是否设置控制点并进行有效测量和控制
提供了关键过程检查记录空表单
6.2质量目标
部门质量目标的实现情况
注（判定）：√为符合；×为不符合，见不合格报告。
相关文件规定设置有生产过程控制点
5.是否建立有测量分析记录
查2017年X月生产及服务记录1份，检验记录中有测量分析记录
6.对重要特性是否进行百分之百检验
《检验规范》中规定产品重要特性的检验规则，要求符合GJB 179A-2005
7.是否运用统计技术
通过培训、对质量数据收集统计分析并加以应用
软件评审检查表
在体系结构设计中，是否清晰描述了数据流、控制流与接口？ 在体系结构设计中，是否清晰描述了数据流、控制流与接口？ 在设计说明书中是否描述了所有的假设、约束、决定与依赖？ 在设计说明书中是否描述了所有的假设、 约束、 决定与依赖？ 是否定义了目标？ 是否定义了目标？ 在合适时，是否有设计是多样的、一致的？ 在合适时，是否有设计是多样的、一致的？ 功能性 对每个子模块是否都做了简要描述并概略描述了采用的算法？ 对每个子模块是否都做了简要描述并概略描述了采用的算法？ 选择的设计或算法是否满足需求？ 选择的设计或算法是否满足需求？ 接口 所有接口的描述是否与需求文档一致？ 所有接口的描述是否与需求文档一致？ 在软件各个功能模块之间的数据流是否得到了明确描述？ 在软件各个功能模块之间的数据流是否得到了明确描述？ 是否对所有的元件之间的接口都进行了定义？ 是否对所有的元件之间的接口都进行了定义？ 是否接口的定义正确、 合理？ 是否接口的定义正确、 合理？ 是否所有的外部接口定义可以追索到需求？ 是否所有的外部接口定义可以追索到需求？ 细节 KLOC，FPA） 是 否 每 个 子 模 块 的 规 模 都 得 到 估 计 （ KLOC ， FPA ） 并 且是 合理 1 的？ 是否考虑了所有可能的状态和用例？ 2 是否考虑了所有可能的状态和用例？ 是否描述足够详细以至于可以开始详细设计阶段？ 3 是否描述足够详细以至于可以开始详细设计阶段？ 九 可维护性 设计是否高内聚、低耦合的？ 1 设计是否高内聚、低耦合的？ 2 设计是模块化的吗？ 设计是模块化的吗？ 设计是否采用了继承，是否描述了选择的工具？ 3 设计是否采用了继承，是否描述了选择的工具？
是[1]否[ ]免[ ] 是[ ]否[1]免[ ] 是[1]否[ ]免[ ] 是[1]否[ ]免[ ] 是[ ]否[ ]免[ ] 是[ ]否[1]免[ ] 是[ ]否[ ]免[1] 是[ ]否[ ]免[ ] 是[ ]否[ ]免[1] 是[ ]否[1]免[ ] 是[ ]否[1]免[ ] 是[ ]否[1]免[ ] 是[ ]否[1]免[ ] 是[ ]否[ ]免[ ] 是[ ]否[1]免[ 是[ ]否[1]免[ 是[ ]否[1]免[ 是[ ]否[ ]免[ 是[ ]否[1]免[ 是[1]否[ ]免[ 是[ ]否[1]免[ ] ] ] ] ] ] ]
ISO9001-2015审核要点8.3.4设计和开发控制【范本模板】
ISO9001-2015审核要点8.3。
4设计和开发控制 Post By：2016-10—7 11：51:00 [只看该作者]8.3。
4设计和开发控制组织应对设计和开发过程进行控制，以确保：a）规定拟获得的结果;b)实施评审活动，以评价设计和开发的结果满足要求的能力；c）实施验证活动，以确保设计和开发输出满足输入的要求;d）实施确认活动,以确保产品和服务能够满足规定的使用要求或预期用途要求；e）针对评审、验证和确认过程中确定的问题采取必要措施；f）保留这些活动的形成文件的信息。
注：设计和开发的评审、验证和确认具有不同目的。
根据组织的产品和服务的具体情况，可以单独或以任意组合进行。
标准理解:1、组织对对设计和开发过程进行控制以确保：a) 要实现的结果得到确定;（这是新的提法)b）实施评审，以评价设计和开发结果满足要求的能力;c）实施验证活动，以确保设计和开发的输出满足设计和开发输入的要求;验证活动可以包括：开展替代计算；将新设计与类似的经验验证的设计作比较；开展测试和鉴定;在发布前检查设计阶段文档d) 实施确认活动,以确保形成的产品和服务能够满足规定的应用或预期用途；确认活动可包括：营销适用；运行测试；预期的用户条件下的模拟和测试；部分模拟或测试（例如测试建筑物经受地震的能力）；提供反馈的最终用户测试（例如软件项目）e) 对评审或验证和确认活动中确定的问题采取必要的措施；(这是增加的内容,如评审、验证和确认活动发现了问题,应决定这些问题的解决措施。
应将这些措施的有效性作为下次评审的部分内容。
）f）保留这些活动的文件化信息.注：设计和开发的评审、验证和确认具有不同的目的，他们可以按适合组织的方式单独或任意组合进行。
(评审、验证和确认有可能在一个过程中完成。
如验证作为评审的一部分内容来进行,或验证和确认同时进行，则没有必要重复同一活动)2、评审、验证和确认活动对于控制设计和开发过程至关重要，因此，要有效实施这些活动。
软件评审检查表-计分
15
交互性要求
简易位，一致性;反馈性;容错性图形化.
人机交互简单、形象输入、输出方面的-致性对用户的操作及时作出皮馈;对可能出现的错误迸行检测、报告和处理.
15
软件性能
响应性要求
页面转焕的响应性 ;
载入时间的短时间要求
短时启动时间要求;
负裁指标明确化.
页面转换快捷;媒体装入时间简短;有确定的负载性能指标.
部署后是否可以正常使用.
5
运行环境
环境适用性.
运行环镜是否与软件愿景说明书一致
5
界面
界面布局
界面布局的合理性.
布局合理，层次清晰
2
界面美观设计
界面的美观性.
界面美观.
3
界画元素
界面元素的-致性.
窗口、菜单、图标、按钮等元素的-性.
5
功能要求
技术运用
技术运用的合理性;内容实现的正确性.
各种技术表现与具体内容结合 ，各种媒体使用协调;多媒体信息的呈现可控，链接准确、无死链.
100分
评审结论：
5ห้องสมุดไป่ตู้
稳定性要求
帮助机制的完备性;
错误处理机制完备性;
确认退出出机制的完备性.
每个操作都有联机帮助或提示;
联机帮助易读、易懂
处理用户可能出现的任何错误操作;
避免出现数据未保留而退出.
5
安全性要求
访问安全性，使用安全
性
用户身份管理和访问控制
数据安全性
10
软件文档
文档资料
完整性
规范性
软件过程文件目录
20
分数
软件产品评审表
评审时间：
评审人员：评审组长（），评审成员（）
交互性要求
简易位，一致性;反馈性;容错性图形化.
人机交互简单、形象输入、输出方面的-致性对用户的操作及时作出皮馈;对可能出现的错误迸行检测、报告和处理.
15
软件性能
响应性要求
页面转焕的响应性 ;
载入时间的短时间要求
短时启动时间要求;
负裁指标明确化.
页面转换快捷;媒体装入时间简短;有确定的负载性能指标.
部署后是否可以正常使用.
5
运行环境
环境适用性.
运行环镜是否与软件愿景说明书一致
5
界面
界面布局
界面布局的合理性.
布局合理，层次清晰
2
界面美观设计
界面的美观性.
界面美观.
3
界画元素
界面元素的-致性.
窗口、菜单、图标、按钮等元素的-性.
5
功能要求
技术运用
技术运用的合理性;内容实现的正确性.
各种技术表现与具体内容结合 ，各种媒体使用协调;多媒体信息的呈现可控，链接准确、无死链.
100分
评审结论：
5ห้องสมุดไป่ตู้
稳定性要求
帮助机制的完备性;
错误处理机制完备性;
确认退出出机制的完备性.
每个操作都有联机帮助或提示;
联机帮助易读、易懂
处理用户可能出现的任何错误操作;
避免出现数据未保留而退出.
5
安全性要求
访问安全性，使用安全
性
用户身份管理和访问控制
数据安全性
10
软件文档
文档资料
完整性
规范性
软件过程文件目录
20
分数
软件产品评审表
评审时间：
评审人员：评审组长（），评审成员（）
设计信息检查表(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
是否已选择特殊特性？
系统测试是否符合产品要求，验证结果是否符合要求
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
是否已选择特殊特性？
审核检查表(ISO9001_2008版)
e.是否保持教育、培训、技能和经历的适当记录？
6.3基础设施
1。是否规定确定、提供和维护所需的基础设施，适用时包括:
a。建筑物、工作场所和相关设施？
c.支持性服务（如运输或通讯）?
6.4工作环境
1。是否规定必须确定和管理所需的工作环境？
7.1产品实现的策划
1。是否对产品实现所需过程规定了策划和开发？
4。2.3文件控制
1.是否要控制QMS要求的文件，并有文件化的控制程序？
2。文件的控制是否确保：
a.文件发布前得到授权人审批？
b。必要时对文件进行评审、更新并再次批准？
c。确保文件的更改和现行修订状态得到识别？
d.确保在使用处可获得适用文件的版本?
e.确保文件清晰，易于识别？
f。对外来文件规定识别、控制分发的方法？
c。是否提供制定和评审质量目标的框架?
d.是否要求在组织内沟通和理解？
e。是否明确要在持续适宜性方面得到评审?
5。4.1质量目标
1.是否在各相关职能和层次上建立质量目标？
2。质量目标是否包括满足产品要求的内容？
3.质量目标是否可测量？
4.质量目标是否与质量方针一致？
5。4。2质量管理体系策划
a。是否提出最高管理者应确保对质量管理体系进行策划？
1.是否有不合格品控制的文件化程序,并对不合格品的控制/处置的有关职责和权限作出规定？
2.是否规定对不合格品的识别和控制？
3.是否通过下列途径处置不合格品：
a采取措施消除不合格？
b。经授权人员/顾客批准后让步放行或接受不合格品?
c.防止原预期的使用？
4。是否保持与不合格的性质、随后采取的措施、让步放行等适当的记录?
g.对作废文件规定处理方法或标识方法?
6.3基础设施
1。是否规定确定、提供和维护所需的基础设施，适用时包括:
a。建筑物、工作场所和相关设施？
c.支持性服务（如运输或通讯）?
6.4工作环境
1。是否规定必须确定和管理所需的工作环境？
7.1产品实现的策划
1。是否对产品实现所需过程规定了策划和开发？
4。2.3文件控制
1.是否要控制QMS要求的文件，并有文件化的控制程序？
2。文件的控制是否确保：
a.文件发布前得到授权人审批？
b。必要时对文件进行评审、更新并再次批准？
c。确保文件的更改和现行修订状态得到识别？
d.确保在使用处可获得适用文件的版本?
e.确保文件清晰，易于识别？
f。对外来文件规定识别、控制分发的方法？
c。是否提供制定和评审质量目标的框架?
d.是否要求在组织内沟通和理解？
e。是否明确要在持续适宜性方面得到评审?
5。4.1质量目标
1.是否在各相关职能和层次上建立质量目标？
2。质量目标是否包括满足产品要求的内容？
3.质量目标是否可测量？
4.质量目标是否与质量方针一致？
5。4。2质量管理体系策划
a。是否提出最高管理者应确保对质量管理体系进行策划？
1.是否有不合格品控制的文件化程序,并对不合格品的控制/处置的有关职责和权限作出规定？
2.是否规定对不合格品的识别和控制？
3.是否通过下列途径处置不合格品：
a采取措施消除不合格？
b。经授权人员/顾客批准后让步放行或接受不合格品?
c.防止原预期的使用？
4。是否保持与不合格的性质、随后采取的措施、让步放行等适当的记录?
g.对作废文件规定处理方法或标识方法?
软件过程检查表
1.过程检查要素表2.过程打分2.1.过程打分原则：1)过程打分占整个项目得分的30％，以30分为满分，最低分不低于9分。
2)不同的项目可以从标准软件过程中剪裁得到项目定义过程，因此各项目包含的软件过程是不同的，为了使软件过程数目不同的项目，仍以合理的方式进行过程打分，需对剪裁后的软件过程数目进行换算，从而不因剪裁而失分。
3)SQA人员对经剪裁的软件过程的检查内容和实施情况进行剪裁。
4)项目级的软件过程剪裁必须得到高级经理，质量管理部经理和项目SQA人员的检查和认可；检查内容和实施情况剪裁必须得到项目经理和受审计人员的认可。
5)软件过程检查打分的依据是“过程检查表”。
2.2.打分步骤：1)依据标准过程定义项目过程，得出项目过程数N。
2)每个项目过程的得分M＝30 / N。
3)采用“过程检查表”，对各个过程进行检查和打分。
4)定义“过程检查表”中的实际检查内容项个数为X，每项标准得分10分，因此每个“过程检查表”的最高得分A = 10X。
5)实际检查时，对“实施情况”一栏中每个条款进行打勾“”,因此实际每项得分Bj=（打勾条款数/ 该项实际检查总条款数）×10。
6)每个过程的实际得分Bi=∑1x Bj。
7)每个过程的换算得分B=Bi /A ×M。
8)若某个过程发生多次z，则该过程得分B=(∑1zB)/z 。
9)项目的过程得分C=∑1NB 。
10)为确保项目组的基本得分不低于9分，因此各过程打分不得低于9/N分，低于此分，以9/N分计算。
2.3.例子：某项目计划进行5个阶段的审计：计划过程，需求过程，设计过程，测试过程，计划跟踪和监督过程，其中计划跟踪和监督过程执行两次，其他各一次则每阶段得分M=30/5=6;第一次计划跟踪和监督过程检查项共15项，实际由于变更未发生检查了13项, 标准分为A=13×10＝130，实际检查得分Bi=123则该阶段得分B1=123/130 * 6=第二次计划跟踪和监督过程，实际检查了15项，标准分为15×10＝150；实际检查得分140。
设计开发内审检查表
1、查设计方案评审报告
项目名称：济南中科核技术研究院导视广告，评审内容：
1）设计开发方案是否符合客户的要求？ ■是 □否 □不适用
2）设计开发方案是否符合法律法规和标准规范要求？ ■是 □否□不适用
3）对比过去类似的设计开发方案，本次设计开发方案是否内容完整、正确？■是 □否 □不适用
4）设计开发方案对产品和项目提供的资料是否完整？■是 □否 □不适用
提供了“ ”项目的设计开发资料，确保后续产品和服务的提供。
符合
2
Q8.3.2
策划
查阅资料和
交流
依据业务部与顾客签订的合同要求制定了《设计和开发计划书》，包括设计开发阶段的划分及主要内容、设计开发人员、完成时间、负责人、内外部资源、依据的标准等。
项目名称： 。
项目起止日期： 。
项目设计开发的起止日期： 。
5）是否提供关于项目所需的明确信息？ ■是 □否 □不适用
6）对设计资料、方案的全面审查，设计开发方案和相关的文件资料是否齐全？ ■是 □否 □不适用
7）本次设计开发方案可行性，是否存在改进的空间？ □是 ■否 □不适用
设计开发方案评审结论： ■评审通过，□评审不通过。
需改进的地方：无。
是否需要根据本设计开发方案进行实验：□是 ■供了确认记录，时间： 。对设计开发进行了确认，认为满足客户的需求，公司的技术和广告牌制作能力已经符合要求，同意制作。
存在问题及建议：所用的材料质量不同，需要严格的控制其采购质量。
采取的措施：加强采购管理、供应商管理，优先选用经过验证的材料厂家。
确认人员：。
结论：设计满足顾客要求。
符合
6
Q8.3.6
变更
交流
查设计和开发的更改：经交流，此次设计和开发过程中没有涉及更改，部门负责人知晓若涉及更改则应按照标准8.3.2至8.3.5的要求进行控制。
项目名称：济南中科核技术研究院导视广告，评审内容：
1）设计开发方案是否符合客户的要求？ ■是 □否 □不适用
2）设计开发方案是否符合法律法规和标准规范要求？ ■是 □否□不适用
3）对比过去类似的设计开发方案，本次设计开发方案是否内容完整、正确？■是 □否 □不适用
4）设计开发方案对产品和项目提供的资料是否完整？■是 □否 □不适用
提供了“ ”项目的设计开发资料，确保后续产品和服务的提供。
符合
2
Q8.3.2
策划
查阅资料和
交流
依据业务部与顾客签订的合同要求制定了《设计和开发计划书》，包括设计开发阶段的划分及主要内容、设计开发人员、完成时间、负责人、内外部资源、依据的标准等。
项目名称： 。
项目起止日期： 。
项目设计开发的起止日期： 。
5）是否提供关于项目所需的明确信息？ ■是 □否 □不适用
6）对设计资料、方案的全面审查，设计开发方案和相关的文件资料是否齐全？ ■是 □否 □不适用
7）本次设计开发方案可行性，是否存在改进的空间？ □是 ■否 □不适用
设计开发方案评审结论： ■评审通过，□评审不通过。
需改进的地方：无。
是否需要根据本设计开发方案进行实验：□是 ■供了确认记录，时间： 。对设计开发进行了确认，认为满足客户的需求，公司的技术和广告牌制作能力已经符合要求，同意制作。
存在问题及建议：所用的材料质量不同，需要严格的控制其采购质量。
采取的措施：加强采购管理、供应商管理，优先选用经过验证的材料厂家。
确认人员：。
结论：设计满足顾客要求。
符合
6
Q8.3.6
变更
交流
查设计和开发的更改：经交流，此次设计和开发过程中没有涉及更改，部门负责人知晓若涉及更改则应按照标准8.3.2至8.3.5的要求进行控制。
软件设计评审检查表
测试计划检查表
Y: 是 TBD:不确定 N: 不是 NA:不适用
检查项
Y/TBD/N/NA
完整性
该测试计划是否详细说明测试的大体方法和策略？
该测试计划是否详细说明所有测试活动的顺序？
该测试计划是否描述了将使用的软硬件系统环境?
该测试计划是否描述了测试活动中断和恢复的条件/情形？
该测试计划是否为所有测试定义了成功标准？
是否详细说明了参数的度量单位、取值范围、正确度和精度？
共享数据区域及其存取规定的映射是否一致？
可维护性
单元是否具有高内聚度和低耦合度（例如：对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小）？
性能
是否该单元的所有约束例（如过程时间和规模）都被详细说明？
可靠性
初始化是否使用到缺省值，缺省值是否正确？
包括了数据流、控制流和接口的单元设计是否已清晰的说明？
完整性
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）?
是否已列出该单元的调用？
依从性
该文档是否遵循了该项目已文档化的标准？
是否采用了所要求的方法和工具来进行单元设计？
该测试计划是否充分地描述了被测试的功能？
该测试计划是否明确地描述了不被测试的功能？
该测试计划是否充分地描述了测试基线？
对于阶段交付，该测试计划是否有在每一阶段建立测试基线给下一阶段使用？
该测试计划是否定义了足够和正确的衰退测试？
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档？
一致性
是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序？
Y: 是 TBD:不确定 N: 不是 NA:不适用
检查项
Y/TBD/N/NA
完整性
该测试计划是否详细说明测试的大体方法和策略？
该测试计划是否详细说明所有测试活动的顺序？
该测试计划是否描述了将使用的软硬件系统环境?
该测试计划是否描述了测试活动中断和恢复的条件/情形？
该测试计划是否为所有测试定义了成功标准？
是否详细说明了参数的度量单位、取值范围、正确度和精度？
共享数据区域及其存取规定的映射是否一致？
可维护性
单元是否具有高内聚度和低耦合度（例如：对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小）？
性能
是否该单元的所有约束例（如过程时间和规模）都被详细说明？
可靠性
初始化是否使用到缺省值，缺省值是否正确？
包括了数据流、控制流和接口的单元设计是否已清晰的说明？
完整性
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）?
是否已列出该单元的调用？
依从性
该文档是否遵循了该项目已文档化的标准？
是否采用了所要求的方法和工具来进行单元设计？
该测试计划是否充分地描述了被测试的功能？
该测试计划是否明确地描述了不被测试的功能？
该测试计划是否充分地描述了测试基线？
对于阶段交付，该测试计划是否有在每一阶段建立测试基线给下一阶段使用？
该测试计划是否定义了足够和正确的衰退测试？
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档？
一致性
是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序？
2-VDA6.3检查表P1-P7 红皮
效检查、PPA-时间、软件版本）。 开发放行的方法应符合顾客要求，出现偏差情 -采购放行、供方批准和变更截止的期限
况时应与顾客澄清。 应计划与采购范围相关的活动，并与整体时间计划一致。 外 -将风险最小化的方法（QFD,FMEA:统计试验设计
包的过程和服务也是项目策划的一部分。
、例如：DOE、谢宁实验设计、田口实验设计)
最低要求
示例
对于要开发的产品，所有相关的要求都已经明确。 对于集成（嵌入式）软件的产 产品/过程开发
品来说，还需规定产品硬件与软件之间接 口的要求。对这些产品应执行要求管理 ⁻询价文件
措施。 组织必须明确与产品相关的顾客规定的要求、物流要求以及法律法规要 求 -合同文件
。
-要求规范（产品，过程）
组织必须考虑并应用产品和过程相关的以往经验的要求。 必须在内部要求、顾客 -顾客要求
是否详细策划了产
-详细的原型件/试生产计划
品和过 程开发的
-定期检查开发进度状态（评审）
活动？
-针对投资（设施，设备)的项目计划
-产品和过程开发所有阶段的物流策划，包括包装
-备件方案 产品开发
-可靠性试验、功能试验、试生产的详细策划
-开发阶段样件的截止日期 过程开发
-性能检测的时间、模具计划（脱模件）安排
FMEA）时， 应将落实生产任务的生产场所纳入进来。 在相关文件（FMEA等）中定 -防错原则 产品开发
义和识别的特殊特性，并采取措施保障确保 符合性。 总体计划必须包含针对组件 -检验计划
、总成、分总成、零部件、软件、和材料的 检测计划，还需考虑原型件和试生产
产品和过程开发计 阶段的制造过程。所有采购的产品 和过程应考虑在内。确保在供应链中落实产品
设计和开发策划内审检查表模板
设计和开发策划内审检查表模板（8.3.1,8.3.2）
编号
检查内容
1
设计和开发的目的
确保后续的产品和服务的提供
2
设计和开发过程要求
应建立、实施和保持适当的设计和开发过程
3
产品和制造过程的设计和开发，应着重于错误预防，而不是探测
4
应对设计和开发过程形成文件
5
应对产品的设计和开发进行控制。说明：控制的目的是确保设计和开发依据策划的方式进行，并在必要的时候进行策划更新
18
使用多方论证方法的方面
19
设计和开发的策划输出应及时更新。说明：这些更新是依据设计和开发的进展、客户的需求和期望的变化、产品要求及标准的更变、资源需求的要求等而进行的
20
设计和开发策划应确定的内容
设计和开发阶段。说明：可以根据产品的特点、过程复杂程度、组织的水平、历史经验、和顾客的要求等因素来划分设计和开发阶段
13
顾客和使用者参与设计和开发过程的需求
14
对后续产品和服务提供的要求
15
顾客和其他相关方期望的设计和开发过程的控制水平
16
证实已经满足设计和开发要求所需的成文信息
17
设计和开发策划要求
应确保设计和开发策划涵盖组织内部所有受影响的利益相关者及其（适当的）供应链。说明：采购、供应商和维护功能也许会作为利益相关方被包括
21
设计和开发的评审活动。说明：明确活动的方式、时机、参与人员等
22设Leabharlann 和开发的验证活动23设计和开发的确认活动。说明：设计和开发的评审、验证和确认具有各自明确的目的，根据产品和组织的具体情况，可以单独或一起进行并记录
24
设计和开发的职责
25
编号
检查内容
1
设计和开发的目的
确保后续的产品和服务的提供
2
设计和开发过程要求
应建立、实施和保持适当的设计和开发过程
3
产品和制造过程的设计和开发，应着重于错误预防，而不是探测
4
应对设计和开发过程形成文件
5
应对产品的设计和开发进行控制。说明：控制的目的是确保设计和开发依据策划的方式进行，并在必要的时候进行策划更新
18
使用多方论证方法的方面
19
设计和开发的策划输出应及时更新。说明：这些更新是依据设计和开发的进展、客户的需求和期望的变化、产品要求及标准的更变、资源需求的要求等而进行的
20
设计和开发策划应确定的内容
设计和开发阶段。说明：可以根据产品的特点、过程复杂程度、组织的水平、历史经验、和顾客的要求等因素来划分设计和开发阶段
13
顾客和使用者参与设计和开发过程的需求
14
对后续产品和服务提供的要求
15
顾客和其他相关方期望的设计和开发过程的控制水平
16
证实已经满足设计和开发要求所需的成文信息
17
设计和开发策划要求
应确保设计和开发策划涵盖组织内部所有受影响的利益相关者及其（适当的）供应链。说明：采购、供应商和维护功能也许会作为利益相关方被包括
21
设计和开发的评审活动。说明：明确活动的方式、时机、参与人员等
22设Leabharlann 和开发的验证活动23设计和开发的确认活动。说明：设计和开发的评审、验证和确认具有各自明确的目的，根据产品和组织的具体情况，可以单独或一起进行并记录
24
设计和开发的职责
25
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
依从性
是否遵守了项目的文档编写标准？
一致性
数据元素、流程和对象的命名和使用在整套系统和外部接口之间是否一致？
该设计是否反映了实际操作环境（硬件、软件、支持软件）？
可行性
从进度、预算和技术角度上看该设计是否可行？是否存在错误的、ຫໍສະໝຸດ 少的或不完整的逻辑？数据使用
所有复合数据元素、参数以及对象的概念是否都已文档化？
是否将需求分别述，因此它们是独立的并且是可检查的？
是否所有需求都可以回溯到相应的需求素材，反之亦然？
是否已详细说明需求变更的过程？
需求规格说明书检查表
概要设计检查表
Y: 是 TBD: 不确定 N: 不是 NA:不适用
检查项
Y/TBD/N/NA
清晰性
是否所设计的架构，包括数据流，控制流和接口，被清楚地表达了？
主要性能参数是否已被详细说明（例如：实时、速度要求、磁盘输入/输出接口等）？
可靠性
该设计能够提供错误检测和恢复（例如：输入输出检查）？
是否已考虑非正常情况？
是否所有的错误情况都被完整和准确地说明？
该设计是否满足该系统进行集成时所遵守的约定？
易测性
是否能够对该套系统进行测试、演示、分析或检查来说明它是满足需求的？
Y: 是 TBD: 不确定 N: 不是 NA:不适用
备注
检查项
Y/TBD/N/NA
清晰性
系统的目标是否已定义？
是否对关键术语和缩略语进行定义和描述？
所使用的术语是否和用户/客户使用的一致？
需求的描述是否清晰，不含糊？
是否有对整套系统进行功能概述？
是否已详细说明了软件环境 (共存的软件) 和硬件环境 (特定的配置)？
该设计是否包含检查点来帮助测试（例如：有条件的编译代码和数据声明测试）？
是否所有的逻辑都能被测试？
是否已描述测试程序、测试数据集和测试结果？
可追溯性
是否设计的每一部分都能追溯到其它项目文档的需求，也能追溯到更高级别文档的需求？
是否所有的设计决定都能追溯到权衡考虑？
依从性
该文档是否遵守了该项目的文档编写标准？
一致性
需求说明是否存在直接相互矛盾的条目？
本需求说明书是否与相关需求素材一致？
可行性
所描述的所有功能是否必要并充分地满足了客户/系统目标？
需求说明书的描述的详细程度是否足以进行详细的设计？
已知的限制（局限）是否已经详细说明？
是否已确定每个需求的优先级别？
可管理性
是否所有的假设、约束、策略及依赖都被记录在本文档了？
是否定义了总体设计目标？
完整性
是否所有的以前的TBD（待确定条目）都已经被解决了？
是否设计已经可以支持本文档中遗留的TBD有可能带来的变更？
是否所有的TBD的影响都已经被评估了？
是否仍存在可能不可行的设计部分？
是否已记录设计时的权衡考虑？ 该文件是否包括了权衡选择的标准和不选择其它方案的原因？
是否详细说明了参数的度量单位、取值围、正确度和精度？
共享数据区域及其存取规定的映射是否一致？
可维护性
单元是否具有高聚度和低耦合度（例如：对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小）？
性能
是否该单元的所有约束例（如过程时间和规模）都被详细说明？
可靠性
初始化是否使用到缺省值，缺省值是否正确？
如果有会影响实施的假设情况，是否已经声明？
是否已经对每个业务逻辑进行输入、输出以及过程的详细说明？
完整性
是否列出了系统所必须的依赖、假设以及约束？
是否对每个提交物或阶段实施都进行了需求说明？
需求说明书是否已包括了主要的质量属性，例如有效性、高效性、灵活性、完整性、互操作性、可靠性、健壮性、可用性、可维护性、可移植性、可重用性和可测试性。
一致性
数据元素的命名和使用在整个单元和单元接口之间是否一致？
所有接口的设计是否互相一致并且和更高级别文档一致？
正确性
是否处理所有条件 （大于、等于、小于零、switch/case）？是否存在处理“case not found”的条件？
是否正确地规定了分支（逻辑没有颠倒）？
数据使用
是否所有声明的数据都被实际使用到？
是否所有界面都互相一致，与其它模块一致，以及和更高级别文档中的需求一致？
是否所有的界面都提供了所要求的信息？
是否已说明部各界面之间的关系？
界面的数量和复杂程度是否已减少到最小？
可维护性
该设计是否是模块化的？
这些模块具有高聚度和低耦合度？
是否已经对继承设计、代码或先前选择工具的使用进行了详细说明？
性能
包括了数据流、控制流和接口的单元设计是否已清晰的说明？
完整性
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）?
是否已列出该单元的调用？
依从性
该文档是否遵循了该项目已文档化的标准？
是否采用了所要求的方法和工具来进行单元设计？
该套系统是否能用增量型的方法来集成和测试？
可追溯性
是否各部分的设计都能追溯到需求说明书的需求？
是否所有的设计决策都能追溯到原来确定的权衡因素?
所继承设计的已知风险是否已确定和分析？
详细设计检查表
Y: 是 TBD: 不确定 N: 不是 NA:不适用
检查项
Y/TBD/N/NA
清晰性
所有单元或过程的目的是否都已文档化？
是否所有该单元的数据结构都被详细说明？
是否所有修改共享数据（或文件）的程序都考虑到了其它程序对该共享数据（或文件）的存取权限？
是否所有逻辑单元、时间标志和同步标志都被定义和初始化？
接口
接口参数在数量、类型和顺序上是否匹配？
是否所有的输入和输出都被正确定义和检查？
是否传递参数序列都被清晰的描述？
是否所有参数和控制标志由已描述的单元传递或返回？
是否在存访问的时候执行了边界检查（例如：数组、数据结构、指针等）来确保只是改变了目标存储位置？
是否执行输入、输出、接口和结果的错误检查？
是否对所有错误情况都发出有意义的信息？
对特殊情况返回的代码是否和已规定的全局定义的返回代码相匹配？
是否考虑到意外事件？
易测性
是否能够对每个单元进行测试、演示、分析或检查来说明它们是满足需求的？
是否还有任何需要的但还没有定义的数据结构，反之亦然？
是否已描述最低级别数据元素？是否已详细说明取值围？
功能性
是否对每一下级模块进行了概要算法说明？
所选择的设计和算法能否满足所有的需求？
接口
操作界面的设计是否有为用户考虑（例如：词汇、使用信息和进入的简易）？
是否已描述界面的功能特性？
界面将有利于问题解决吗？
是否遵守了项目的文档编写标准？
一致性
数据元素、流程和对象的命名和使用在整套系统和外部接口之间是否一致？
该设计是否反映了实际操作环境（硬件、软件、支持软件）？
可行性
从进度、预算和技术角度上看该设计是否可行？是否存在错误的、ຫໍສະໝຸດ 少的或不完整的逻辑？数据使用
所有复合数据元素、参数以及对象的概念是否都已文档化？
是否将需求分别述，因此它们是独立的并且是可检查的？
是否所有需求都可以回溯到相应的需求素材，反之亦然？
是否已详细说明需求变更的过程？
需求规格说明书检查表
概要设计检查表
Y: 是 TBD: 不确定 N: 不是 NA:不适用
检查项
Y/TBD/N/NA
清晰性
是否所设计的架构，包括数据流，控制流和接口，被清楚地表达了？
主要性能参数是否已被详细说明（例如：实时、速度要求、磁盘输入/输出接口等）？
可靠性
该设计能够提供错误检测和恢复（例如：输入输出检查）？
是否已考虑非正常情况？
是否所有的错误情况都被完整和准确地说明？
该设计是否满足该系统进行集成时所遵守的约定？
易测性
是否能够对该套系统进行测试、演示、分析或检查来说明它是满足需求的？
Y: 是 TBD: 不确定 N: 不是 NA:不适用
备注
检查项
Y/TBD/N/NA
清晰性
系统的目标是否已定义？
是否对关键术语和缩略语进行定义和描述？
所使用的术语是否和用户/客户使用的一致？
需求的描述是否清晰，不含糊？
是否有对整套系统进行功能概述？
是否已详细说明了软件环境 (共存的软件) 和硬件环境 (特定的配置)？
该设计是否包含检查点来帮助测试（例如：有条件的编译代码和数据声明测试）？
是否所有的逻辑都能被测试？
是否已描述测试程序、测试数据集和测试结果？
可追溯性
是否设计的每一部分都能追溯到其它项目文档的需求，也能追溯到更高级别文档的需求？
是否所有的设计决定都能追溯到权衡考虑？
依从性
该文档是否遵守了该项目的文档编写标准？
一致性
需求说明是否存在直接相互矛盾的条目？
本需求说明书是否与相关需求素材一致？
可行性
所描述的所有功能是否必要并充分地满足了客户/系统目标？
需求说明书的描述的详细程度是否足以进行详细的设计？
已知的限制（局限）是否已经详细说明？
是否已确定每个需求的优先级别？
可管理性
是否所有的假设、约束、策略及依赖都被记录在本文档了？
是否定义了总体设计目标？
完整性
是否所有的以前的TBD（待确定条目）都已经被解决了？
是否设计已经可以支持本文档中遗留的TBD有可能带来的变更？
是否所有的TBD的影响都已经被评估了？
是否仍存在可能不可行的设计部分？
是否已记录设计时的权衡考虑？ 该文件是否包括了权衡选择的标准和不选择其它方案的原因？
是否详细说明了参数的度量单位、取值围、正确度和精度？
共享数据区域及其存取规定的映射是否一致？
可维护性
单元是否具有高聚度和低耦合度（例如：对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小）？
性能
是否该单元的所有约束例（如过程时间和规模）都被详细说明？
可靠性
初始化是否使用到缺省值，缺省值是否正确？
如果有会影响实施的假设情况，是否已经声明？
是否已经对每个业务逻辑进行输入、输出以及过程的详细说明？
完整性
是否列出了系统所必须的依赖、假设以及约束？
是否对每个提交物或阶段实施都进行了需求说明？
需求说明书是否已包括了主要的质量属性，例如有效性、高效性、灵活性、完整性、互操作性、可靠性、健壮性、可用性、可维护性、可移植性、可重用性和可测试性。
一致性
数据元素的命名和使用在整个单元和单元接口之间是否一致？
所有接口的设计是否互相一致并且和更高级别文档一致？
正确性
是否处理所有条件 （大于、等于、小于零、switch/case）？是否存在处理“case not found”的条件？
是否正确地规定了分支（逻辑没有颠倒）？
数据使用
是否所有声明的数据都被实际使用到？
是否所有界面都互相一致，与其它模块一致，以及和更高级别文档中的需求一致？
是否所有的界面都提供了所要求的信息？
是否已说明部各界面之间的关系？
界面的数量和复杂程度是否已减少到最小？
可维护性
该设计是否是模块化的？
这些模块具有高聚度和低耦合度？
是否已经对继承设计、代码或先前选择工具的使用进行了详细说明？
性能
包括了数据流、控制流和接口的单元设计是否已清晰的说明？
完整性
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）?
是否已列出该单元的调用？
依从性
该文档是否遵循了该项目已文档化的标准？
是否采用了所要求的方法和工具来进行单元设计？
该套系统是否能用增量型的方法来集成和测试？
可追溯性
是否各部分的设计都能追溯到需求说明书的需求？
是否所有的设计决策都能追溯到原来确定的权衡因素?
所继承设计的已知风险是否已确定和分析？
详细设计检查表
Y: 是 TBD: 不确定 N: 不是 NA:不适用
检查项
Y/TBD/N/NA
清晰性
所有单元或过程的目的是否都已文档化？
是否所有该单元的数据结构都被详细说明？
是否所有修改共享数据（或文件）的程序都考虑到了其它程序对该共享数据（或文件）的存取权限？
是否所有逻辑单元、时间标志和同步标志都被定义和初始化？
接口
接口参数在数量、类型和顺序上是否匹配？
是否所有的输入和输出都被正确定义和检查？
是否传递参数序列都被清晰的描述？
是否所有参数和控制标志由已描述的单元传递或返回？
是否在存访问的时候执行了边界检查（例如：数组、数据结构、指针等）来确保只是改变了目标存储位置？
是否执行输入、输出、接口和结果的错误检查？
是否对所有错误情况都发出有意义的信息？
对特殊情况返回的代码是否和已规定的全局定义的返回代码相匹配？
是否考虑到意外事件？
易测性
是否能够对每个单元进行测试、演示、分析或检查来说明它们是满足需求的？
是否还有任何需要的但还没有定义的数据结构，反之亦然？
是否已描述最低级别数据元素？是否已详细说明取值围？
功能性
是否对每一下级模块进行了概要算法说明？
所选择的设计和算法能否满足所有的需求？
接口
操作界面的设计是否有为用户考虑（例如：词汇、使用信息和进入的简易）？
是否已描述界面的功能特性？
界面将有利于问题解决吗？