概要设计评审检查表

格式：xlsx
大小：12.47 KB
文档页数：2

下载文档原格式

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

详细设计检查表
# 检查项是/否/不适用否不适用清晰性、完整性 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 设计的复杂度已经最小了吗？

软件设计评审检查表

是否所有该单元的数据结构都被详细说明？
是否所有修改共享数据（或文件）的程序都考虑到了其它程序对该共享数据（或文件）的存取权限？
是否所有逻辑单元、时间标志和同步标志都被定义和初始化？
接口
接口参数在数量、类型和顺序上是否匹配？
是否所有的输入和输出都被正确定义和检查？
是否传递参数序列都被清晰的描述？
该套系统是否能用增量型的方法来集成和测试？
可追溯性
是否各部分的设计都能追溯到需求说明书的需求？
是否所有的设计决策都能追溯到原来确定的权衡因素?
所继承设计的已知风险是否已确定和分析？
详细设计检查表
Y:是TBD:不确定N:不是NA:不适用
检查项
Y/TBD/N/NA
清晰性
所有单元或过程的目的是否都已文档化？
一致性
数据元素的命名和使用在整个单元和单元接口之间是否一致？
所有接口的设计是否互相一致并且和更高级别文档一致？
正确性
是否处理所有条件（大于、等于、小于零、switch/case）？是否存在处理“case not found”的条件？
是否正确地规定了分支（逻辑没有颠倒）？
数据使用
是否所有声明的数据都被实际使用到？
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档？
一致性
是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序？
该测试计划是否和更高级别的测试计划文档一致？
正确性
该测试计划的进入和退出条件是否实现？
是否所有必须的驱动程序和桩（stubs）都已被定义且可利用来测试指定的功能？
详细级别/程度
是否定义了总体设计目标？
完整性
是否所有的以前的TBD（待确定条目）都已经被解决了？

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

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

方案设计评审检查表

项目名称：制定人：顾客零件号：评审日期：责任人日期11.1外来文件清单特殊特性清单1.2产品技术条件2特殊特性清单2.12.2装配图表初始零部件及材料清单仿真报告共用件清单经验教训IMDS34仿真试验报告一般要求产品结构分解评审？材料规范顾客提供的产品设计信息资料和要求？包括产品图纸、标准、样件或其它信息主要组、部及零件图中的装配尺寸、重要特性及标准化、系列化、通用化考虑情况？是否在设计中采用了以往的设计经验？针对同类型产品在公司内部和外部发生的问题进行分析，避免产生相同的质量问题方案设计信息评审检查表备注客户要求方面序号方案设计评审内容检查内容具体内容及措施产品的主要尺寸理解客户的产品技术要求是否清晰产品的装车位置及工作温度范围产品性能要求产品的防护等级要求及地方环保要求产品设计的依据及指导原则？工作温度、要求、性能、防护等级、环保等产品是否需要？新材料？特殊工装？各组、部及零件的组成是否结构合理？材料合理？加工可行性？产品是否符合适用的相关国际/国家/政府安全、法令、法规、标准和/或行业标准？工程图纸为设计功能性量具，是否已确认了足够的控制点和基准平面？公差是否和被接受的制造标准相一致？产品总图、零部件图中的尺寸、性能、材料等是否满足顾客要求？设计中的计算机仿真分析评估？存在的和可用的检测技术是否能够测量所有的技术要求？顾客制定的工程更改管理过程是否被用于管理工程更改？是否已确认了材料的特殊特性？新技术或过程？编号：ZL-B-21版本：A/0页次：1/2项目名称：制定人：顾客零件号：评审日期：方案设计信息评审检查表编号：ZL-B-21版本：A/0页次：1/2在客户要求的装车环境中，图纸上规定的材料、热处理和表面处理是否和耐。

需求评审检查表

1．所描述的软件需求与客户需求和系统需求是否一致？
2．所规定的处理及其数据是否与必须完成的功能要求一致？
3．是否有超出范围的功能？
4．文档内部是否存在前后不一致的描述？
正确性
1．是否正确理解和描述了客户对软件的需求？所有错误是否已经排除？
明确性
1．是否存在含混、不清楚和含有二义的描述？
2．图表是否清楚？
可管理性
1．是否所有需求是以一种可管理的方式表达的？一个需求项的改变会不会影响其它很多功能？
问题
编号
问题说明和建议
（如果是针对文档中具体的内容，请标识位置）
1
2
……
n
评审检查结论
（邮件评审时填写此项）
□通过□有条件通过□不通过
说明：
需求评审检查表
项目名称
评委姓名
评审检查日期
评审检查用时（小时）
主要检查内容
意见
完整性
1．是否完整地定义了软件需求规格？
2.是否考虑了数据量和处理量？
3．是否定义了关键的接口和界面？
4．范围内的功能是否都有适当的描述？
5．在定义功能时是否考虑了异常处理ቤተ መጻሕፍቲ ባይዱ例外处理？
6．是否考虑过其它可选的软件需求？
一致性
3．某些信息是否被忽略了或有冗余？
可实施性
1．是否每一项软件需求都存在实现的可能？
2．软件设计是否可行？
3．约束条件是否现实？
4．是否考虑了实现需求的技术风险？
可追溯性
1．是否能够在后续过程中对每一项软件需求进行追溯？
2．是否需求中的每一项都能到用户问题域中找到对应？
相关性
1．是否文档的所有内容都跟要解决的问题相关？无关的内容都要去掉。

软件的设计的评审检查表

是否所有界面都互相一致，与其它模块一致，以与和更高级别文档中的需求一致？
是否所有的界面都提供了所要求的信息？
是否已说明内部各界面之间的关系？
界面的数量和复杂程度是否已减少到最小？
可维护性
该设计是否是模块化的？
模块具有高内聚度和低耦合度？
是否已经对继承设计、代码或先前选择工具的使用进展了详细说明？
性能
软件测试
无
完成集成测试说明、执行集成测试、进展测试分析、编写软件集成测试报告
完成软件确认测试说明、执行软件确认测试、进展测试分析、编写确认测试报告
完成系统测试说明、执行系统测试、进展测试分析、编写系统测试报告
是否将需求分别陈述，因此它们是独立的并且是可检查的？
是否所有需求都可以回溯到相应的需求素材，反之亦然？
是否已详细说明需求变更的过程？
需求规格说明书检查表
概要设计检查表
Y: 是 TBD:不确定 N: 不是 NA:不适性
是否所设计的架构，包括数据流，控制流和接口，被清楚地表达了？
是否详细说明了参数的度量单位、取值X围、正确度和精度？
共享数据区域与其存取规定的映射是否一致？
可维护性
单元是否具有高内聚度和低耦合度〔例如：对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小〕？
性能
是否该单元的所有约束例〔如过程时间和规模〕都被详细说明？
可靠性
初始化是否使用到缺省值，缺省值是否正确？
包括了数据流、控制流和接口的单元设计是否已清晰的说明？
完整性
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明用来实现该单元的关键算法〔例如：用自然语言或PDL〕?

设计项目检查表

设计项目检查表
项目信息
- 项目名称：
- 项目负责人：
- 设计师：
- 项目开始日期：
- 项目结束日期：
施工图设计
- 是否按照设计要求绘制施工图纸？
- 是否包含必要的细节和尺寸说明？
- 是否准确反映了设计意图？
材料选择
- 是否根据设计要求选择了合适的材料？
- 是否与业主和甲方协商确认了材料选择？
色彩搭配
- 是否根据设计要求进行了色彩搭配？
- 是否符合设计风格和整体效果？
- 是否与业主和甲方协商确认了色彩选择？
设备与家具
- 是否根据设计要求选择了合适的设备和家具？- 是否考虑了设备和家具的功能性和美观性？
施工进度
- 是否按照预定的施工计划进行施工？
- 是否存在延迟或进度滞后的情况？
- 是否与施工方协商解决了任何施工进度问题？
质量控制
- 是否进行了质量控制检查？
- 是否解决了质量问题和缺陷？
- 是否满足了设计要求和标准？
项目评估
- 是否定期评估项目进展和质量？
- 是否与项目团队和业主讨论了改进和调整措施？
需要解决的问题
- 是否存在需要解决的问题？请列举。

结论
综上所述，本设计项目检查表用于评估设计项目的各个方面，包括施工图设计、材料选择、色彩搭配、设备与家具选择、施工进度、质量控制等。

通过在项目进行过程中进行检查和评估，可以及时解决问题，确保项目按照设计要求顺利进行。

设计内审检查表

(6)查：设计开发输出信息。（图纸、产品特性、产品使用说明书等）
设计开发输出输出文件被批准的证据。
都符合要求。
标准/文件
条款号
检查内容和方法
检查记录
备注
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]免[ ] ] ] ] ] ] ]

评审检查表

评审检查表
1 / 11
目录
1.项目计划检查表 (3)
2.需求规格说明书检查表 (4)
3.概要设计说明书检查表 (5)
4.详细设计说明书检查表 (6)
5.编码检查表 (7)
6.测试用例检查表 (10)
7.产品验收和发布检查表 (11)
2 / 11
1.项目计划检查表
2.需求规格说明书检查表
3.概要设计说明书检查表
4.详细设计说明书检查表
5.编码检查表
通过结合编码检查表和代码检查单，可以比较清楚地确定代码问题的位置。

5.1. 代码检查表
5.2. 代码检查内容
备注：
1）激活：本列标注Y 的为激活的项目，表明这些项目必须被明确地自查（其他问题处于“顺便被检查”的状态），在运行编码检查的时候，前期几乎所有项都要在激活状态；后期稳定后，保持8~10 个（或遵从当前规范）激活的检查项。

为了醒目，可以像此表这样将当前的激活项用亮黄色表示。

10~40 50~100
3) 检查项：所有检查项均为一般疑问句，当发现回答为“否”时，即存在一个缺陷。

6.测试用例检查表
10 / 11
7.产品验收和发布检查表
11 / 11。

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

是否清晰、组织是否合理？文档结构是否便于维护和修改？设计是否易于理解？各模块之间的关系是否描述的清楚？是否清晰地描述了数据流程、控制流程和接口？二、完整性、正确性是否定义了目标？是否记录了与本设计文档相关的假设、约束、决议、依赖？设计在进度、预算和技术上是否可行？所选的设计或算法是否满足模块的需求？是否有一些必要的数据结构没有定义？或定义了一些不必要的数据结构？是否对数据元素进行了充分的描述？说明了有效的数据范围？是否对共享和存储数据的管理和使用进行了明确的描述？是否说明了数据结构与系统模块之间的关系？此设计是否能为详细设计提供充分的基础？是否每个设计都是可测试的或以别的方式可以确定的？设计是否考虑到未来的扩充性？设计的系统是否易于维护？是否对性能参数进行了说明?（如，实施约束、内存大小、速度要求等）三、一致性在整个设计中，是否对数据元素、程序、功能的命名保持一致？设计是否反应了真实的运行环境，包括软件和硬件？对模块的说明是否与软件需求文档中的功能要求相一致？是否所有的设计元素都可追踪回需求？四、接口是否对接口的功能特征进行了描述？接口是否便于问题的解决？备注
是否所有的接口间相互一致，并和其他模块及需求相一致？是否所有接口都提供了要求的类型、数量和质量信息？是否对接口的数量和复杂度进行了权衡，使接口的数量少并且复杂程度可以接受？用户接口是否进行了描述? 用户接口是否模块化，并且修改时不影响其他程序? 四、可维护性、可靠性设计是模块化的吗？模块具有高内聚度低耦合度吗？设计中是否提供了对错误的检测和恢复的设计？是否考虑了异常情况？错误条件描述的是否完整、准确？设计是否满足系统完整性要求？是否符合相关的法律法规？