软件项目设计评审检查表
VDA6.3检查表-2016版(评分矩阵+要素说明+评审提问表)-编辑版
必须定义和规范质量数据和过程参数（设定值），这些数据对于证明产品一致性来说是必要的。
记录实
际数据（实际值），用于展示对目标要求的符合性。
这些数据必须确保可用以评价。
对异常情况进行记录（班次日志/设备日志）。
收集的数据要与产品和过程相关，数据来源是实际的、易获取的、可查的、可存档的。
要考虑追溯性要求。
对收集的数据进行分析，并启动相应的改进措施。
潜在的改进必须根据质量、成本、服务的先前问题来持续开展。
导致过程或产品发生偏离的事件，及其相关措施，被体现在相应的风险分析（例如FMEA ）当中。
●控制图●特殊特性
●过程参数（温度，时间，压力...）
●生产数据采集
●故障信号（例如停线，断电，程序故障报警）
●参数变化
●失效类型/失效频率
●失效成本（不符合）
●报废/返工
●隔离通知/拣选行动
●节拍时间，周期时间
●SPC●柏拉图分析●因果图
●风险分析（FMEA 、FTA…）。
内审检查表—项目部GBT19001—2016、GBT24001—2016、ISO45001：2018质量环境、职业健康安全一体化管理体系
设计和开发更改控制适宜。
不适用
Q:8.5.1生产和服务提供的控制
8.6产品和服务的放行
8.7不合格输出的控制
1.有无生产和服务方面的管理制度？主要包含哪些？
2.生产计划单的填制是否明确?产品信息是否明确，是否具备一致性？
6.策划的相关内容有无成文信息？是否满足需要？
公司建立了设计和开发管理制度，并形成了文件。
抽查最新产品的设计开发
对市场进行了调研，考虑目前市场上基本情况，公司可考虑开发效率高、作业面大、节约成本的新产品，抢占更高端的市场
公司决策层会同各部门负责人等进行了新产品的策划，确定了设计开发的相关阶段：
设计完成时间，完成人
策划的实施形成了相关证据，包括试飞测试报告、设计评审报告等。
对产品的设计开发策划控制适宜。
不适用
Q：8.3.3设计和开发的输入
1.有无设计开发输入的成文信息？
2.成文信息中是否包括了功能和性能要求；来源于以前类似设计和开发活动的信息；法律法规要求；组织承诺实施的标准和行业规范；由产品和服务性质所决定的、失效的潜在后果等内容？
依据条款条款
检查内容
检查记录
是否符合
Q
E
S
Q/E/S:5.3组织的岗位、职责和权限
1. 是否明确了相应的职能和岗位？
2.本部门和岗位的职责、权限是否清楚？
3 各岗位员工是否明确自己的职责、权限？
1.明确了相应的职能和岗位？
2.本部门和岗位的职责、权限清楚？
3 各岗位员工明确自己的职责、权限？
符合
Q:6.1.2组织策划/E：6.1.2环境因素/S:6.1.2危险源辨识和职业健康安全风险评价
软件项目检查表
软件项目检查表
项目概述
该软件项目检查表旨在帮助团队对软件项目进行全面的检查和
评估，以确保项目的顺利进行和高质量的交付。
本检查表包括多个
方面，包括项目计划、需求分析、设计、开发、测试和部署等环节。
项目计划
- 项目是否有明确的目标和可行的计划？
- 是否有详细的项目计划及时间表？
- 是否有项目经理负责监督和管理项目进度？
需求分析
- 是否完整、准确地收集和记录了项目的需求？
- 是否对需求进行了合理的分类和优先级排序？
- 是否与相关利益相关者沟通确认了需求？
设计
- 是否进行了系统的架构设计和模块设计？
- 是否充分考虑了扩展性和可维护性等因素？
- 是否进行了界面设计和交互设计？
开发
- 是否按照设计文档进行开发工作？
- 是否按照编码规范完成代码编写？
- 是否进行了代码评审和单元测试？
测试
- 是否制定了详细的测试计划和测试用例？
- 是否进行了功能测试、性能测试和安全测试等多个方面的测试？
- 是否及时修复了测试中发现的缺陷和问题？
部署
- 是否制定了可靠的部署计划？
- 是否进行了部署前的完整测试和验证？
- 是否提供了必要的文档和培训？
运维支持
- 是否确保了系统的可靠性和稳定性？
- 是否建立了监控和报警机制？
- 是否保障了系统的安全性和数据的完整性？
以上是软件项目检查表的主要内容，通过对每个方面的检查和评估，能够有效提升软件项目的质量和成功交付的概率。
请针对具体项目的不同需求和情况，适当调整和完善该检查表。
VDA6.3过程审核检查表(带示例_自动计算符合率)
0 4 6 8 10 X 0 4 6 8 10 X
Is a process development plan available and
are the targets maintained? rel 是否已具有过程开发计划,是否遒守目标值?
已根据产品族系列做了相应的P-FMEA。 PCB板系列接插件产品目前还没有做P-FMEA。
0 4 6 X 8 10
X
第3页共6页 Page 3 / 6
审核员签名（Auditor sign）:______________
ABC有限公司 过程审核检查表
NO： 版次： 修订号： 表格编号：
审核报告编号（Audit Report Nbr.）2005-001
0 4 6 X 8 10
X
M4.2 Is a quality plan prepared?
是否制定了质量计划? rel
X
M4.3 Are the required releases/qualification records
available at the respective times? rel 是否已具备各阶段所要求的认可/合格证明?
0 4 6 X 8 0 4 6 8 10 X
X
M2.2 Is the design FMEQA updated in the project
process and are established measures realized? rel 设计D-FMEA是否在项目过程中补充更新?已确 定的措施是否已落实?
X
M4.6 Are the required resources available?
rel
VDA6.3检查表-2016版(评分矩阵+要素说明+评审提问表)
必须定义和规范质量数据和过程参数（设定值），这些数据对于证明产品一致性来说是必要的。
记录实际数据（实际值），用于展示对目标要求的符合性。
这些数据必须确保可用以评价。
对异常情况进行记录（班次日志/设备日志）。
收集的数据要与产品和过程相关，数据来源是实际的、易获取的、可查的、可存档的。
要考虑追溯性要求。
对收集的数据进行分析，并启动相应的改进措施。
潜在的改进必须根据质量、成本、服务的先前问题来持续开展。
导致过程或产品发生偏离的事件，及其相关措施，被体现在相应的风险分析（例如FMEA ）当中。
●控制图●特殊特性
●过程参数（温度，时间，压力...）
●生产数据采集●故障信号（例如停线，断电，程序故障报警）●参数变化●失效类型/失效频率●失效成本（不符合）●报废/返工●隔离通知/拣选行动●节拍时间，周期时间●SPC●柏拉图分析●因果图
●风险分析（FMEA 、FTA…）。
2023版产品开发流程内审检查表
2023版产品开发流程内审检查表一、项目准备阶段
- 是否确定了产品开发项目的目标和范围？
- 是否制定了项目计划和时间表？
- 是否评估了项目所需的资源和成本？
- 是否制定了质量管理计划？
二、需求分析阶段
- 是否收集了产品需求和用户需求？
- 是否定义了产品的功能和特性？
- 是否分析了竞争产品和市场需求？
- 是否编写了需求规格说明书？
三、设计阶段
- 是否根据需求规格说明书进行产品设计？
- 是否对产品进行结构和界面设计？
- 是否评审了产品的设计方案？
- 是否完成了详细设计文档？
四、开发阶段
- 是否按照详细设计文档进行产品开发？
- 是否进行了代码编写和模块测试？
- 是否进行了整体集成和系统测试？
- 是否解决了开发过程中的问题和缺陷？
五、验收阶段
- 是否完成了产品的完整性测试和功能测试？- 是否与用户进行了验收测试？
- 是否修正了用户反馈的问题和改进意见？- 是否准备了产品发布和交付的计划？
六、产品发布阶段
- 是否按照发布和交付计划进行产品发布？
- 是否考虑了产品的营销和推广策略？
- 是否进行了产品的性能测试和安全评估？
- 是否解决了产品发布过程中的问题和风险？
七、产品维护阶段
- 是否建立了产品的维护和技术支持团队？
- 是否收集了用户的意见和反馈？
- 是否解决了产品维护过程中的问题和改进要求？
- 是否进行了产品的定期更新和升级？
以上是2023版产品开发流程内审检查表的内容。
请在每个问题后面填写是或否，并记录相关的说明和细节。
设计内审检查表
设计开发输出输出文件被批准的证据。
都符合要求。
标准/文件
条款号
检查内容和方法
检查记录
备注
7.3.4设计和开发评审
1.是否按照设计和开发策划设置的评审点进行系统的评审?各评审点的内容和参加人员是否符合策划的安排?
2.对各评审点和评审是否达到:
标准/文件
条款号
检查内容和方法
检查记录
备注
7.3.7设计和开发更改的控制
1.当需要更改设计时,是否及时予以识别并进行更改?实施更改前是否得到了批准?
2.对某些设计和开发的重要更改是否经过评审、验证和确认?评审是否包括评价(如零部件)更改对产品组成部分和已交付产品的影响?
3.更改记录是否包括更改的评审结果及必要措施?
条款号
检查内容和方法
检查记录
备注
7.3.3设计和开发输出
1.设计和开发输出文件有哪些?是否以能够对输入进行验证的方式提出?
2.设计和开发输出文件在发放前是否得到批准?
3.设计和开发输出文件是否满足如下要求:
满足输入要求?
给出采购/生产和服务提供的适当信息?
包含或引用产品接受准则?
规定产品安全和正常使用所必需的产品特点(如操作/贮存、/维修和处置的要求).
技术部
标准/文件
条款号
检查内容和方法
检查记录
备注
7.3.2设计和开发输入
1.设计和开发是否形成了文件?文件的内容应包括:
产品的适宜性要求(如性能和功能,感官特性)?
法律法规和标准要求.
适用时以前类似设计提供的信息?
所必需的其他要求(如使用条件及限制、材料、零件要求、需开发的材料、工艺要求等)?
软件评审检查表
在体系结构设计中，是否清晰描述了数据流、控制流与接口？ 在体系结构设计中，是否清晰描述了数据流、控制流与接口？ 在设计说明书中是否描述了所有的假设、约束、决定与依赖？ 在设计说明书中是否描述了所有的假设、 约束、 决定与依赖？ 是否定义了目标？ 是否定义了目标？ 在合适时，是否有设计是多样的、一致的？ 在合适时，是否有设计是多样的、一致的？ 功能性 对每个子模块是否都做了简要描述并概略描述了采用的算法？ 对每个子模块是否都做了简要描述并概略描述了采用的算法？ 选择的设计或算法是否满足需求？ 选择的设计或算法是否满足需求？ 接口 所有接口的描述是否与需求文档一致？ 所有接口的描述是否与需求文档一致？ 在软件各个功能模块之间的数据流是否得到了明确描述？ 在软件各个功能模块之间的数据流是否得到了明确描述？ 是否对所有的元件之间的接口都进行了定义？ 是否对所有的元件之间的接口都进行了定义？ 是否接口的定义正确、 合理？ 是否接口的定义正确、 合理？ 是否所有的外部接口定义可以追索到需求？ 是否所有的外部接口定义可以追索到需求？ 细节 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]免[ ] ] ] ] ] ] ]
VDA6.1 (VDA6.3)检查表
P2.3 是否具备项目计划，并与顾客进行了协商确定？
项目计划应满足顾客的护体要求。所有内部里程碑以及顾客里程碑都应被 - 包括里程碑在内的项目计划
完整的纳入项目计划，并且定期针对实际发生的变更加以调整。
- 针对具体过程技术和/或产品组的顾客要求
一旦项目计划发生变更，则将通过一位指定的分发人，确保内部的联络沟 - 顾客的项目计划
- 针对具体的过程技术，提供资源证明（专业人员） - 资源策划方面的证明（顾及到（其他）进一步的顾客项目） - 策划应将顾及到顾客项目（短路径）
划开展复核。必要时，还应调整实际需求。
上述情况既涉及到由顾客触发的变更，页涉及到自身内部的变更以及由供
方触发的变更。
资源策划同样也会考虑到供方。而在资源策划中，应特别留意关键路径。
工具，容器，仓库
P3.3 是否为产品和过程开发编制了相关的计划？
- CAM，CAQ
- 顾客要求
- 顾客的时间安排(里程碑，前提)
- 系列生产时间安排，原型件技术放行程序时间安排
在项目计划下，还应为产品和过程开发编制撞门的计划。
- 开发阶段样件的时间安排，生产测试，模具的时间安排，准
这些假话中包含有特定开发和策划活动的具体时间点/持续时间，里程 碑，生产测试等相关信息。
- VDA手册：新零件开发成熟度保障
外包的过程和服务也是项目策划的组成部分。
- 批量生产方面的过程技术经验
- 模具时间表
- 生产/检验设备，软件，包装的提供
- 变更的保障方案（投产问题等）
P3.4 针对产品和过程开发，是否考虑了所需的资源？
必须对确定资源的程序加以规范。
在这里，所谓的确定资源具体指的是具备资格的人员，预算，基础设施， 试验设施，试验室用品，机器，设备等都是已经到位（机器和设备的负荷 情况）。 每次启动开发前，都需要首先确定对人员资格的要求以及需要提供的工 具，并且加以记录。
软件评审检查表-计分
交互性要求
简易位，一致性;反馈性;容错性图形化.
人机交互简单、形象输入、输出方面的-致性对用户的操作及时作出皮馈;对可能出现的错误迸行检测、报告和处理.
15
软件性能
响应性要求
页面转焕的响应性 ;
载入时间的短时间要求
短时启动时间要求;
负裁指标明确化.
页面转换快捷;媒体装入时间简短;有确定的负载性能指标.
部署后是否可以正常使用.
5
运行环境
环境适用性.
运行环镜是否与软件愿景说明书一致
5
界面
界面布局
界面布局的合理性.
布局合理，层次清晰
2
界面美观设计
界面的美观性.
界面美观.
3
界画元素
界面元素的-致性.
窗口、菜单、图标、按钮等元素的-性.
5
功能要求
技术运用
技术运用的合理性;内容实现的正确性.
各种技术表现与具体内容结合 ，各种媒体使用协调;多媒体信息的呈现可控，链接准确、无死链.
100分
评审结论：
5ห้องสมุดไป่ตู้
稳定性要求
帮助机制的完备性;
错误处理机制完备性;
确认退出出机制的完备性.
每个操作都有联机帮助或提示;
联机帮助易读、易懂
处理用户可能出现的任何错误操作;
避免出现数据未保留而退出.
5
安全性要求
访问安全性，使用安全
性
用户身份管理和访问控制
数据安全性
10
软件文档
文档资料
完整性
规范性
软件过程文件目录
20
分数
软件产品评审表
评审时间：
评审人员：评审组长（），评审成员（）
需求规格评审检查表
是
否
必要
出现在“其它需求”中的功能，是否都已在“功能需求”中进行了描述？
是
否
必要
238058842.xls
5/5
项目名称：
产品需求说明书评审检查单(V1.0)
要素 代号 细分要素 软件需求说明书（作为一个整体）检查项 1.1 1.2 1.3 1.4 1.5 1. 标 1.6 准 化 1.7 1.8 1.9 1.1 1.11 2.1 2.2 2.3 2.4 2. 完 整 性 2.5 2.6 是否描述了运行环境？ 是否描述了验收准则？ 语法、句法、词法、标点是否正确？ 是否描述了本文涉及的术语、定义及缩略语？ 是否按要求对版本修改情况进行了说明？ 图、表、列项等是否规范？ 引用标准/文件是否现行有效？标准/文件编号、名称是否正确？ 在正文中引用的标准、文件是否在执行标准一章中列出？ 文档格式是否满足该工程标准化模板要求？ 文档内容是否基本覆盖GJB438A-97的要求？ 修改记录内容、封面、页眉内容是否完整、一致？ 在“背景”中，是否已明确描述了“被描述系统”（实践中，“被描述系统”经常在变动：有时是 整个软件，有时又是内部的一个小模块）？ 对于满足软件的目标来说，功能需求是否足够？ 对于满足软件的目标来说，性能需求是否足够？ 对于满足软件的目标来说，质量属性需求是否足够？ 对于满足软件的目标来说，外部接口需求（外部接口需求可能单独成文。下同。评审时应一道评 审）是否足够？ 对于满足软件的目标来说，数据需求是否足够？
3/5
、 性 能 、 质 量 属 性 、 外 部 接 代号 要素 口 、 7.8 其 7.9 它 需 7.1 求 都 7.11 要 8. 8.1 功 能 8.2 需 求 8.3 需 要 8.4 满 足 8.5 的 8.6 公 共 检 8.7 查 9. 性 9.1 能 需 9.2 求 10. 质 10.1 量 属
软件过程检查表
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）设计开发方案是否符合客户的要求？ ■是 □否 □不适用
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）?
是否已列出该单元的调用？
依从性
该文档是否遵循了该项目已文档化的标准？
是否采用了所要求的方法和工具来进行单元设计？
该测试计划是否充分地描述了被测试的功能？
该测试计划是否明确地描述了不被测试的功能？
该测试计划是否充分地描述了测试基线？
对于阶段交付，该测试计划是否有在每一阶段建立测试基线给下一阶段使用？
该测试计划是否定义了足够和正确的衰退测试？
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档？
一致性
是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序？
软件设计评审检查表
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）?
是否已列出该单元的调用？
依从性
该文档是否遵循了该项目已文档化的标准？
是否采用了所要求的方法和工具来进行单元设计？
一致性
数据元素的命名和使用在整个单元和单元接口之间是否一致？
可维护性
单元是否具有高内聚度和低耦合度（例如：对该单元的更改不会在该单元有任 何无法预料的影响并对其它单元的影响很小）？
性能
是否该单元的所有约束例（如过程时间和规模）都被详细说明？
可靠性
初始化是否使用到缺省值，缺省值是否正确？
是否在内存访问的时候执行了边界检查（例如：数组、数据结构、指针等）来 确保只是改变了目标存储位置？
Y:是TBD:不确定N:不是NA:不适用
检查项
Y/TBD/N/NA
清晰性
系统的目标是否已定义？
是否对关键术语和缩略语进行定义和描述？
所使用的术语是否和用户/客户使用的一致？
需求的描述是否清晰，不含糊？
是否有对整套系统进行功能概述？
是否已详细说明了软件环境（共存的软件）和硬件环境（特定的配置）？
如果有会影响实施的假设情况，是否已经声明？
完成软件确认测 试说明、执行软件 确认测试、进行测 试分析、编写确认 测试报告
完成系统测试 说明、执行系 统测试、进行 测试分析、编 写系统测试报 告
是否将需求分别陈述，因此它们是独立的并且是可检查的？
是否所有需求都可以回溯到相应的需求素材，反之亦然？
是否已详细说明需求变更的过程？
Y:是TBD:不确定N:不是NA:不适用
设计输入评审记录
顾客名称
项目名称
制动器总成
序号
评初始特殊特性是否识别出来？
√
2.
产品外观，标识，包装，性能等要求是否识别出来，是否包括了顾客的所有要求？
√
3.
是否对产品质量在产品责任书中进行了规定?
√
4.
是否明确了设计任务及完成期限？
√
5.
成本是否进行了规定，是否可行?
√
6.
产品责任书是否清楚易懂，可操作？
√
7.
现有供应商是否能满足客户的要求？
√
8.
现有员工数量是否能保证生产需要？
√
9.
是否进行了可行性分析？
√
10.
是否能提供类似设计的信息？
√
评审结论：
设计输入充分，可以进行开发工作
评审人/日期
批准/日期
设计和开发策划内审检查表模板
编号
检查内容
1
设计和开发的目的
确保后续的产品和服务的提供
2
设计和开发过程要求
应建立、实施和保持适当的设计和开发过程
3
产品和制造过程的设计和开发，应着重于错误预防，而不是探测
4
应对设计和开发过程形成文件
5
应对产品的设计和开发进行控制。说明：控制的目的是确保设计和开发依据策划的方式进行，并在必要的时候进行策划更新
18
使用多方论证方法的方面
19
设计和开发的策划输出应及时更新。说明：这些更新是依据设计和开发的进展、客户的需求和期望的变化、产品要求及标准的更变、资源需求的要求等而进行的
20
设计和开发策划应确定的内容
设计和开发阶段。说明：可以根据产品的特点、过程复杂程度、组织的水平、历史经验、和顾客的要求等因素来划分设计和开发阶段
13
顾客和使用者参与设计和开发过程的需求
14
对后续产品和服务提供的要求
15
顾客和其他相关方期望的设计和开发过程的控制水平
16
证实已经满足设计和开发要求所需的成文信息
17
设计和开发策划要求
应确保设计和开发策划涵盖组织内部所有受影响的利益相关者及其（适当的）供应链。说明：采购、供应商和维护功能也许会作为利益相关方被包括
21
设计和开发的评审活动。说明：明确活动的方式、时机、参与人员等
22设Leabharlann 和开发的验证活动23设计和开发的确认活动。说明：设计和开发的评审、验证和确认具有各自明确的目的，根据产品和组织的具体情况，可以单独或一起进行并记录
24
设计和开发的职责
25
评审检查表
评审检查表
目录
1.项目计划检查表 (3)
2.需求规格阐明书检查表 (4)
3.概要设计阐明书检查表 (5)
4.具体设计阐明书检查表 (6)
5.编码检查表 (7)
6.测试用例检查表 (10)
7.产品验收和公布检查表 (11)
1.项目计划检查表
2.需求规格阐明书检查表
3.概要设计阐明书检查表
4.具体设计阐明书检查表
5.编码检查表
通过结合编码检查表和代码检查单，能够比较清晰地拟定代码问题的位置。
5.1.代码检查表
5.2.代码检查内容
备注：
1)激活：本列标注Y 的为激活的项目，表明这些项目必须被明确地自查（其它问题处在“顺
便被检查”的状态），在运行编码检查的时候，前期几乎全部项都要在激活状态；后期稳定后，保持8~10 个（或遵从目前规范）激活的检查项。
为了醒目，能够像此表这样将目前的激活项用亮黄色表达。
其中10~40 是编码错误，50~100 是设计错误。
3)检查项：全部检查项均为普通疑问句，当发现回答为“否”时，即存在一种缺点。
6.测试用例检查表
7.产品验收和公布检查表。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
3.15 表或实体设计命名是否符合规范？
4
界面设计
是否描述项目所需要实现的各种典型界面
4.1
并给出界面demo？
是否遵循软件界面设计指南的要求？界面
4.2
风格的美学要求？
界面操作是否足够的人性化，能够获得交 好的用户体验？ 4.3
版本号：2 修订号：0
第3页 共3页
技能水平及其他因素？
1.3
系统架构是否考虑了性能、安全、可扩展 、维护性等因素
1.4
系统架构是否有利于充分发挥现有硬件资 源的效能？
系统架构是否有利于在应用环境中的部
1.5
署？是否有利于系统管理员进行管理、维
护？
各个层的划分是否合理，各个层之间是否
1ห้องสมุดไป่ตู้6
有清晰的功能划分？是否符合主流的分层 规则（界面、业务逻辑、业务对象、数据
访问等）？
系统功能模块的划分是否合理，是否符合
1.7
用户的实际业务操作方式？是否与用户的
岗位分工保持一致？
1.8
每个模块的功能、职责是否定义清楚？
1.9
各个模块的接口（通信界面）是否定义清 楚，以利于与其它系统的交互以及集成？
1.10
是否充分考虑到架构或组件的复用。
1.11
是否充分考虑了系统实现技术上的风险和 解决办法？
3.9
枚举值是否进行了说明？
版本号：2 修订号：0
第2页 共3页
3.10
数据库对象的命名是否符合数据库设计规 范？
3.11
数据库对象的每一个约束是否设置合理？ 是否完善？
3.12
海量数据的存储是否进行了特别的处理？
3.13 3.14
是否使用了触发器？有必要吗？
系统是否涉及对以前版本或其他系统数据 的更新？如果有，是否能保证数据的完整 性和一致性？
2.6
类设计是否充分考虑了代码的可复用性， 足够的抽象？
3
数据库设计
E-R图或ERD图(实体关系图)之间的结构是
3.1
否清晰。是否遵循面向对象思想，实体客
观存在并易于理解？
3.2
每个实体是否都是必须储存的？实体之间 的关系逻辑上是否是正确的？
3.3
数据库设计是否考虑了系统性能上特别的 需要？是否适当设计了数据冗余？
及接口，它们之间的访问结构是否清
2.3
晰？是否尽可能采用设计模式增强类结
构的可读性以及可维护性？类之间的耦
合性和可扩展性是否合理？
顺序图是否比较直观的体现了类之间的
2.4
接口调用关系，并涵盖模块主要的操作 功能？是否对比较复杂的接口实现进行
较为详细的算法描述？
2.5
类的职责是否与层的职责冲突？层和类的 设计是否有利于进行单元测试？
2
模块设计
版本号：2 修订号：0
缺陷描述
第1页 共3页
2.1
功能模块的设计文字说明是否清晰，比 较好的表达问题？
界面类设计布局及界面包含元素是否合
理，界面的显示或功能操作是否涵盖对
2.2
应的模块功能？是否能够满足人机交互 的友好性？界面类是否耦合了业务逻辑
和数据存取逻辑及其他非界面处理逻
辑？
需要定义出模块的主要业务逻辑控制类
表的主键生成策略是否合理，是否能满足
3.4
要求？是否使用了用户的键作主键？如果
用了，会不会有问题？
3.5
每个实体对象在数据库中存放都是唯一的 一处？
3.6
实体之间的关系是否用外键进行了适当的 表示？
3.7
每个模式对象（表、视图、存储过程等） 及其字段是否都有说明？
3.8
是否对允许空值及空值的意义进行了说 明？
设计评审检查表
项目名称
项目编号
评审人 评审规模 （页）
序号
1
检查项 架构设计
评审日期
评审耗时 （小时）
是否通过 N/A,Y,N
缺陷 个数
从需求到设计是否维护了良好的可追踪
1.1
性？每个需求用例都能追溯到是哪些类怎
么实现需求的。
系统架构是否适合应用于这个系统的应
1.2
用？是否考虑了用户的分布情况、计算机