详细设计说明书评审检查表
详细设计说明书评审检查表
# 检查项 是/否/不适用 否 不适用 清晰性、完整性 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 设计的复杂度已经最小了吗？
概要设计说明书检查表
是否设计已经可以支持本文档中遗留的TBD有可能带来的变更
▢是▢否
是否所有的TBD的影响都已经被评估了
▢是▢否
是否仍存在可能不可行的设计部分
▢是▢否
是否已记录设计时的权衡考虑该文件是否包括了权衡选择的标准和不选择其它方案的原因
▢是▢否
依从性
依从性该文档是否遵守了该项目的文档编写标准
▢是▢否
一致性
▢是▢否
是否所有的界面都提供了所要求的信息
▢是▢否
是否已说明内部各界面之间的关系
▢是▢否
界面的数量和复杂程度是否已减少到最小
▢是▢否
操作界面的设计是否有为用户考虑（例如：词汇、使用信息和进入的简易）
▢是▢否
可维护性
该设计是否是模块化的
▢是▢否
这些模块具有高内聚度和低耦合度
▢是▢否
是否已经对继承设计、代码或先前选择工具的使用进行了详细说明
▢是▢否
性能
主要性能参数是否已复（例如：输入输出检查）
▢是▢否
是否已考虑非正常情况
▢是▢否
是否所有的错误情况都被完整和准确地说明
▢是▢否
该设计是否满足该系统进行集成时所遵守的约定
▢是▢否
易测性
是否能够对该套系统进行测试、演示、分析或检查来说明它是满足需求的
▢是▢否
是否已描述最低级别数据元素是否已详细说明取值范围
▢是▢否
功能性
是否对每一下级模块进行了概要算法说明
▢是▢否
所选择的设计和算法能否满足所有的需求
▢是▢否
接口
操作界面的设计是否有为用户考虑（例如：词汇、使用信息和进入的简易）
▢是▢否
是否已描述界面的功能特性
产品详细设计评审检查表-模板
每一个模块的关键算法、关键数据结构是否清楚？
各模块之间的接口是否清晰？
设计是否是可实现的？
设计是否有遗漏和缺陷？
可读性检查
设计说明是否通俗易懂？
设计中，关键部分是否使用图表加以说明？
是否提供软件设计图（类图，序列图，状态图…）
是否提供数据结构设计图(数据库设计，XML结构设计，文件格式设计)
设计实现的瓶颈
依赖型检查
是否使用或依赖于第三方的产品？
第三方产品是否可以由不同的提供商替换？
设计中涉及到关键技术是否成熟？
其他问题
××产品详细设计评审检查表
【内容】
评审人员根据此表认真审核《产品详细设计规格说明书》。
如果是合同项目，可能还需要用户审核，视具体情况而定。
【裁剪原则】
此部分内容不允许裁剪。
评委名称
评委日期
YYYY-MM-DD
评审结论
合格不合格TBD待完成NA不适用
详细设计检查表
结论
基本检查
详细设计是否覆盖了所有的总体设计条目？
是否提供样例代码，说明如何使用？
可用性检查
设计中的命名是否与现有系统冲突
是否存在不合理的设计结构（例如包耦合：不应交叉耦合，层，包不应依赖于子系统，仅应依赖于其它包或接口）
设计是否与某些现有规范存在冲突？（编码规范，设计规范，J2EE规范….）
设计实现的复杂程度
详细设计检查单
NO：
项目名称
检查人
文档名称
版本号
检查内容
检查结果
1、规范性
文档是否齐全
按模板编制
2、一致性、完整性
软件功能是否与《软件需求规格说明书》保持一致，并完整体现。
在数据流和控制流的设计实现上是否与《概要设计说明书》保持一致
3、正确性、可靠性
软件功能是否正确、完整地予以描述
流程逻辑是否正确、合理
5、接口的开放性和兼容性
如果本系统分阶段开发，是否有适用的阶段接口，使得更便于从一个阶段转向另一个阶段？
6、可追踪性
是否有设计部件和数据与需求之间对应的交叉索引
7、健壮性
易修改性
可扩充性
可移植性
8、复用性
本设计可复用吗？
是否复用了其它项目的部件？
9、可行性
是否便于编码实现、维护和使用？
评审组成员会后意见：（以下内容在评审会议后填写）
算法是否合适、有效
设计能达到性能最佳吗
设计中是否考虑采用了处理故障和避免失效的实用方法？
用户界块结构是否良好、清晰，易于理解
流程逻辑是否清晰、明了
用户界面设计是否简洁、明了，并具有功能指导性
是否每一种设计都只有一种理解
是否有歧义性或二义性
4、可测试性
设计是否是可测试，便于编写测试用例？
本人对本次评审结果的建议为：□通过□有条件通过□不通过
具体意见如下（如评审结果建议为“有条件通过”或“不通过”，请务必填写遗留的问题与建议）：
评审组成员签名：
设计说明书评审检查单(设计说明书检查单)
Design Specification Review Checklist设计说明书评审检查单（DVPCHK01 / IPD-CMM V2.0 / for internal use only）Project ID 项目编号Owner 责任人Reviewer 检查者Date 检查日期yyyy-mm-dd Item 审查内容Comment 说明1Description 说明This checklist is consisted of two partitions, one is for HLD review, another is for LLDreview. When HLD and LLD are combined to one document, both checklists should be used.本检查单由两部分组成，一部分适用于概要设计评审，一部分适用于详细设计评审。
如果概要设计和详细设计合成一篇文档，应同时关注这两个检查单。
2For High Level Design specification 概要设计适用No. 序号Checklist检查项Status执行情况Comment说明1 Does the document conform to HLD templates as required by thePHB?文档是否符合项目过程手册中要求的概要设计模板？Yes 是[ ] No 否[ ] NA 免[ ]2 Is the purpose and function of each partioned sub-module definedclearly and unambiguously?每个已划分的子模块，其目的和功能是否已清晰定义且无歧义？Yes 是[ ] No 否[ ] NA 免[ ]3 Are the global data structures defined completely and rightly?全局数据结构是否已经完整定义并且正确？Yes 是[ ] No 否[ ] NA 免[ ]4 Are the interaction described completely in the dependency ?依赖性是否描述了主要的交互过程？Yes 是[ ] No 否[ ] NA 免[ ]5 Are the external interfaces (include function interfaces and datainterfaces) complete, correct and unambiguously?所有的外部接口（包括函数接口和数据接口）是否完整，正确且无歧义？Yes 是[ ] No 否[ ] NA 免[ ]6 Does the granularity accord with what is descripted in the Yes 是[ ]No. 序号Checklist检查项Status执行情况Comment说明spcecification's purpose section?概要设计说明书描述的内容是否达到的目的中所描述的功能分解粒度？No 否[ ]NA 免[ ]7 Does HLD meet perforamnce goal as per PPL and SRS ?HLD是否满足PPL和SRS中的性能目标？Yes 是[ ] No 否[ ] NA 免[ ]8 Has the software requirements track matrix been updatedcorrectly?是否已正确更新了软件需求跟踪矩阵？Yes 是[ ] No 否[ ] NA 免[ ]3 For Low Level Design specification 详细设计适用No. 序号Checklist检查项Status执行情况Comment说明1 Does the document conform to LLD templates as required by thePHB?文档是否符合项目过程手册中要求的详细设计模板？Yes 是[ ] No 否[ ] NA 免[ ]2 Are the interfaces between the submodules (including datainterfaces and function interfaces) stated clearly?对已划分的子模块，和其它子模块的接口和该子模块内部的接口（包括数据接口和函数调用接口）是否已明确描述？Yes 是[ ] No 否[ ] NA 免[ ]3 Are all the procedure/functions in each sub-module specified?是否列出了每个子模块包含的所有过程/函数？Yes 是[ ] No 否[ ] NA 免[ ]4 Are all data structures and global variables defined correctly?是否已经正确定义所有的数据结构和全局变量？Yes 是[ ] No 否[ ] NA 免[ ]5 Are all the pivotal procedures/functions is described by usingpseudocode/flow chart correctly?是否对每个子模块的各个关键过程/函数，都给出了正确的伪码/流程图描述？Yes 是[ ] No 否[ ] NA 免[ ]6 Does LLD meet performance goal as per PPL and SRS ?LLD是否满足PPL和SRS中的性能目标？Yes 是[ ] No 否[ ] NA 免[ ]7 Has the software requirements track matrix been updatedcorrectly?是否已正确更新了软件需求跟踪矩阵？Yes 是[ ] No 否[ ] NA 免[ ]。
设计内审检查表
设计开发输出输出文件被批准的证据。
都符合要求。
标准/文件
条款号
检查内容和方法
检查记录
备注
7.3.4设计和开发评审
1.是否按照设计和开发策划设置的评审点进行系统的评审?各评审点的内容和参加人员是否符合策划的安排?
2.对各评审点和评审是否达到:
标准/文件
条款号
检查内容和方法
检查记录
备注
7.3.7设计和开发更改的控制
1.当需要更改设计时,是否及时予以识别并进行更改?实施更改前是否得到了批准?
2.对某些设计和开发的重要更改是否经过评审、验证和确认?评审是否包括评价(如零部件)更改对产品组成部分和已交付产品的影响?
3.更改记录是否包括更改的评审结果及必要措施?
条款号
检查内容和方法
检查记录
备注
7.3.3设计和开发输出
1.设计和开发输出文件有哪些?是否以能够对输入进行验证的方式提出?
2.设计和开发输出文件在发放前是否得到批准?
3.设计和开发输出文件是否满足如下要求:
满足输入要求?
给出采购/生产和服务提供的适当信息?
包含或引用产品接受准则?
规定产品安全和正常使用所必需的产品特点(如操作/贮存、/维修和处置的要求).
技术部
标准/文件
条款号
检查内容和方法
检查记录
备注
7.3.2设计和开发输入
1.设计和开发是否形成了文件?文件的内容应包括:
产品的适宜性要求(如性能和功能,感官特性)?
法律法规和标准要求.
适用时以前类似设计提供的信息?
所必需的其他要求(如使用条件及限制、材料、零件要求、需开发的材料、工艺要求等)?
详细设计评审表模板
详细设计评审表模板
工程负责人: 评审时间：
:评审流程
1、由公司领导、各部门相关人员、主审人、评审专家、工程负责人、软件测试人员组成一个评审小组,通过阅读和讨论详细设计的内容,
对详细设计进行评审.
2、工程负责人提前把概要设计说明书、详细设计说明书等文档分发给评审小组成员,作为评审依据,小组成员在充分阅读这些材料之后,
进入下一步.
3、召开详细设计评审会.在会上,首先由该工程的系统分析员介绍总体设计思想,包括需求概述和软件结构,然后由各个模块的具体设计者
分别对模块设计进行说明,在此过程中,小组成员可以提出问题,展开讨论,审查是否有错误存在.
4、在讨论结束后,由工程负责人整理出一份?详细设计评审报告?.
5、假设发现错误较多,或发现重大错误,那么在改正之后,再次组织详细设计评审.
详细设计评审.doc
第1页共2页
工程名称: 主审人：
详细设计评审.doc
主审人的总结意见和签字:
第2页共2页。
《需求规格说明书》评审检查单
检查出的缺陷
《用户需求规格说明书》评审检查单
序号 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
检查项
技术框架描述是否清楚明白? 有没有给出整体界面示意图? 界面清单及其流转关系是否明确? 有没有遗漏的界面清单及其流转关系? 状态图或状态流转图是否完备? 是否完整地描述了（数据处理/流程）功能性需求? 是否完整地描述了（查询统计）功能性需求? 是否完整地描述了（用户/角色/授权）功能性需求 是否完整地描述了（审计）功能性需求 需求是否正确地反映了《业务需求说明书》的内容？ 需求是否存在二义性？ 每项需求间是否存在冲突？ 需求是否完备？ 每项需求都是可实现的吗？ 每项需求都是可验证的吗？ 从技术层面分析用户所提需求是否可以实现？ 是否完整地记录了质量属性？ 质量属性的描述是定量地说明所需要达到的程度了吗？ 每项需求都确定了优先级吗？ 功能描述重要程度与用户需求重要程序一致吗？
设计评审检查表
评审日期：No.
风险评估：
改正方法
改正计划
项目组评审意见：
生产部评审意见：
品质部评审意见：
工程部评审意见：
市场部评审意见：
计划部评审意见：
中央研究院：
改善的结果
评审结论：
通过不通过
总工/副总评审意见：签名：Leabharlann 总经理评审意见：签名：
第2页共2页
一、设计资料的制订：
特殊特性清单
DFMEA表
产品规格书
材料表
样品控制计划表
PFMEA
物料技术要求
小试控制计划
工艺文件
技术图纸
工艺流程图
中试控制计划
试产前控制计划
量产控制计划
二、新增设备/工装/模具
新增设备/工装
新增量具检验设备
新增模具
三、验证报告
四、小/中试产品合格率
五、生产过程记录
不完善事项：
第1页共2页
设计评审检查表
评审日期：编制人：No.
产品名称
设计人员
产品规格
评审人员
数量
（中/小试）数量：(试产)数量：（批量）数量：
评审依据：
客户要求：
其它：
评审项目名称：
项目目标：
评审阶段
评审内容
评审资料编号
备注
样品试作前评审
样品制作后评审
小试前评审
小试后评审
中试前评审
中试后评审
试产前评审
批量生产前评审
批量生产后评审
概要设计说明书评审检查表
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 是否对性能参数进行了说明?（如，实施约束、内存大小、速度要求等）
设计方案审查表
设计方案审查表
设计方案审查表
设计方案审查表是在进行设计方案审核时使用的一种工具，用于对设计方案的内容、表达、合理性等进行评估和审查。
下面是一个设计方案审查表的示例：
项目名称：XXX设计项目
设计方案名称：XXX设计方案
设计方案编码：XXX-001
审核人员：（填写审核人员姓名）
一、设计方案内容审查：
1.设计方案是否符合项目要求？
2.设计方案是否满足客户的需求和期望？
3.设计方案的创意和独特性如何？
4.设计方案所提供的解决方案是否可行？
5.设计方案中是否存在与安全、环保等相关法律法规冲突的内容？
6.设计方案的整体质量如何？
二、设计方案表达审查：
1.设计方案的结构和组织是否合理？
2.设计方案的文字表述是否清晰易懂？
3.设计方案的图表和图片是否清晰、准确且具有较高的美观度？
4.设计方案中的数据和信息是否准确？
三、设计方案合理性审查：
1.设计方案在技术上是否可行？
2.设计方案的成本是否合理？
3.设计方案的工期是否合理？
4.设计方案的风险评估是否充分？
5.设计方案的可维护性和可持续性如何？
四、其他问题：
（在此列出除上述问题之外的其他需要审查的内容）
五、审查结论：
（在此填写对设计方案的审查结论，例如：通过、不通过、待改进等）
备注：
（在此填写对设计方案审查时的其他需要说明的内容）
以上是一个设计方案审查表的示例，实际使用时可以根据具体项目的需求进行适当调整和补充。
通过使用设计方案审查表，可以更加系统和全面地评估设计方案的优劣，并提出针对性的意见和建议，有助于设计方案的改进和完善。
工程设计方案审查评审表
工程设计方案审查评审表项目名称：XXX工程设计方案审查人：XXXX一、项目概况项目名称：项目地点：项目概述：二、设计方案内容1. 设计总图及说明- 设计总图是否清晰准确，符合规划要求？- 设计说明是否详细清晰，包含有关设计的必要信息？- 设计是否满足业主要求，符合相关标准要求？2. 结构设计- 结构设计是否合理，符合安全、稳定、经济的原则？- 结构设计是否考虑了抗震、抗风等特殊条件的要求？- 结构设计是否满足相关标准要求，是否有明显缺陷？3. 建筑设计- 建筑设计是否体现了美观、实用、人性化的设计理念？- 建筑设计是否符合规划要求和相关标准要求？- 建筑设计是否满足业主要求，是否有不合理之处？4. 设备设计- 室内外给排水系统、通风、空调、供暖等设备设计是否合理？- 设备设计是否符合相关标准要求，是否有漏洞？- 设备设计是否满足功能要求，是否有提升空间？5. 施工图设计- 施工图设计是否详细、准确，包含了施工过程中的关键信息？- 施工图设计是否符合规划要求、相关标准和法规要求？- 施工图设计是否考虑了施工方面的实际操作性和施工安全性？6. 其他设计内容- 是否存在特殊设计内容，是否满足相关标准和规范要求？- 是否存在针对性较强的设计，是否合理可行？- 其他需要审查的设计内容及评价：三、审查意见1. 设计方案的可行性评价：（评审人需简要概述对设计方案的整体评价，提出设计方案的优缺点、不足之处。
）2. 需改进及完善的设计内容：（评审人需列出需要改进、完善的设计内容，并提出具体修改意见。
）3. 适当予以肯定的设计内容：（评审人需适当给出肯定意见，对符合要求、创新有独到之处的设计内容表示认可。
）四、评审结论（评审人根据设计方案审查情况，给出综合评审结论。
）五、评审人签名：日期：以上是本次工程设计方案审查评审表的内容，鉴于该工程设计方案的重要性，希望各位评审人员能够认真审查，提出合理的意见和建议，以确保设计方案的准确性、可行性和先进性。
产品详细设计评审检查表-模板
××产品详细设计评审检查表
【内容】
●评审人员根据此表认真审核《产品详细设计规格说明书》。
●如果是合同项目，可能还需要用户审核，视具体情况而定。
【裁剪原则】
此部分内容不允许裁剪。
评委名称
评委日期YYYY-MM-DD
评审结论 合格 不合格 TBD 待完成 NA 不适用详细设计检查表结论
基本检查详细设计是否覆盖了所有的总体设计条目？
详细设计和总体设计之间是否存在冲突？每一个模块的关键算法、关键数据结构是否清楚？
各模块之间的接口是否清晰？
设计是否是可实现的？
设计是否有遗漏和缺陷？
可读性检查设计说明是否通俗易懂？
设计中，关键部分是否使用图表加以说明？是否提供软件设计图（类图，序列图，状态图…）
是否提供数据结构设计图(数据库设计，XML结构设计，文件格式设计)
是否提供样例代码，说明如何使用？
可用性检查设计中的命名是否与
现有系统冲突
是否存在不合理的设计结构（例如包耦合：不应交叉耦合，下层中的包不应依赖于上层中的包，依赖关系不得跳层，包不应依赖于子系统，仅应依赖于其它包或接口）
设计是否与某些现有规范存在冲突？（编码规范，设计规范，J2EE 规范….）
设计实现的复杂程度设计实现的瓶颈
依赖型检查是否使用或依赖于第三方的产品？
第三方产品是否可以由不同的提供商替换？
设计中涉及到关键技术是否成熟？
其他问题。
详细设计评审表
软件详细设计评审表
项目名称：项目负责人：
主审人：评审时间：
一评审流程
1、由公司领导、各部门相关人员、主审人、评审专家、项目负责人、软件测试人员组成一个评审小组通过阅读和讨论详细设计的内容对详细设计进行评审。
2、项目负责人提前把概要设计说明书、详细设计说明书等文档分发给评审小组成员作为评审依据小组成员在充分阅读这些材料之后进入下一步。
3、召开详细设计评审会。
在会上首先由该项目的系统分析员介绍总体设计思想包括需求概述和软件结构然后由各个模块的具体设计者分别对模块设计进行说明在此过程中小组成员可以提出问题展开讨论审查是否有错误存在。
4、在讨论结束后由项目负责人整理出一份《详细设计评审报告》。
5、若发现错误较多或发现重大错误则在改正之后再次组织详细设计评审。
二评审人员
公司高层
营销部
技术部
工程部
研发部
主审人
评审专家
项目负责人
软件测试人员
三评审内容（评审的具体结果可以参见评审会议记录）
模块评审指标评审内容评审
要求
结果
1.软件架构设计1.1合理性
系统应用架构的逻辑清晰、关系明确、层次合
理。
必须1.2先进性
系统开发技术架构先进、充分考虑系统功能可
重用、可扩展的要求。
建议1.3可维护性
设计易于理解，易于修改，易于测试和调试，
稳定性较好，方便用户未来的系统运维。
建议1.4安全性设计充分考虑系统运行的安全性，子系统间及建议
评审结果签署意见：。
软件需求规格说明书评审检查表
22 是否所有的需求都是名副其实的需求而不是设计或实现方案？
23 是否确定了对时间要求很高的功能并且定义了它们的时间标准？
24 是否已经明确地阐述了国际化问题？
25
21
22
23
24
25
结果统计
是：
0个
否：
0个
不适用：
0个
未检查：
0个
说明
检查结果
使 用 说 明 ： 本 检 查 表 在 项 目 中 各 种 评 审 、 审 计 工 作 实 施 前 编 制 ， 用 于 列 出 问 题 、 记 录
软件需求规格说明书模板需求开发过程序问题号组织和完好性全部对其他需求的内部交织引用能否正确
软件需求规格说明书评审
检查表
编制人员： 项目名称： 检查依据：《 软件需求规格说明书模板》、《需求开发过程》
编制日期： 项目经理： 花费工作量：
序 号
问题
组织和完整性
1 所有对其它需求的内部交叉引用是否正确？
2 所有需求的编写在细节上是否都一致或者合适？
正确性
10 是否有需求与其它需求相冲突或重复？
11 是否简明、简洁、无二义性地表达了每个需求？
12 是否每个需求都能通过测试、演示、审查得以验证或分析？
13 是否每个需求都在项目的范围内？
14 是否每个需求都没有内容上和语法上的错误？
15 在现有的资源限制内，是否能实现所有的需求？
16 是否任一个特定的错误信息都具有唯一性和明确的意义？
质量属性
17 是否合理地确定了性能目标？
18 是否合理地确定了安全与保密方面的考虑？
19 在确定了合理的折衷情况下，是否详实地记录了其它相关的质量属性？
软件的设计的评审检查表
完整性
是否所有的以前的TBD（待确定条目）都已经被解决了？
是否设计已经可以支持本文档中遗留的TBD有可能带来的变更？
是否所有的TBD的影响都已经被评估了？
是否仍存在可能不可行的设计部分？
是否已记录设计时的权衡考虑？该文件是否包括了权衡选择的标准和不选择其它方案的原因？
依从性
是否遵守了项目的文档编写标准？
正确性
是否处理所有条件（大于、等于、小于零、switch/case）？是否存在处理“case not found”的条件？
是否正确地规定了分支（逻辑没有颠倒）？
数据使用
是否所有声明的数据都被实际使用到？
是否所有该单元的数据结构都被详细说明？
是否所有修改共享数据（或文件）的程序都考虑到了其它程序对该共享数据（或文件）的存取权限？
是否将需求分别陈述，因此它们是独立的并且是可检查的？
是否所有需求都可以回溯到相应的需求素材，反之亦然？
是否已详细说明需求变更的过程？
需求规格说明书检查表
概要设计检查表
Y:是TBD:不确定N:不是NA:不适用
检查项
Y/TBD/N/NA
清晰性
是否所设计的架构，包括数据流，控制流和接口，被清楚地表达了？
是否所有的假设、约束、策略及依赖都被记录在本文档了？
可维护性
单元是否具有高内聚度和低耦合度（例如：对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小）？
性能
是否该单元的所有约束例（如过程时间和规模）都被详细说明？
可靠性
初始化是否使用到缺省值，缺省值是否正确？
是否在内存访问的时候执行了边界检查（例如：数组、数据结构、指针等）来确保只是改变了目标存储位置？
详细设计评审检查表模板
是否所有的构架原则在子程序中得到了实现? 是否定义了技术与工作的标准，如编码规范等？ 所有的接口（外部和内部）是否在子程序级完整得到描述? 该项工作的计划与实际成本是否合理？ 该项工作的计划与实际进度是否合理？
序号
1 2 3 4 5 6 7 8 9 10 11 12 13 建议: 表述是否清晰? 参数定义是否合理? 算法是否表述清晰? 公用类设计是否合理?
详细设计评审检查表 检查项
内容是否完整,是否覆盖所有功能点，模块?
不适用 优秀参数传递是否实际合理，表述清晰? 是否满足性能需求? 后续工作人员是否可以据此进行工作?
03详细设计说明书报审表.
某市某区网络信息中心“XXX”某分厅采购项目
致：XXX咨询监理有限公司
我方根据合同相关规定完成了江西省“XXX”某区分厅详细设计说明书的编制，并经过我单位上级技术负责人批准，请予以审查。
附:
某省“XXX”某区分厅-详细设计说明书
承建单位（章）
项目经理：
日 期 ：
监理工程师审查意见：
监理单位（章）
监理工程师：
Hale Waihona Puke 日 期 ：建设单位意见：建设单位（章）
建设单位代表：
日期：
详细设计说明书报审表
注：本表由施工单位填报，建设单位、监理单位、承建单位各存一份。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
38 是否具有清晰性、可读性、可修改性，满足维护需求？ 39 是否设定了正确的初始化缺省值？ 40 是否对输入、输出、接口和结果进行了错误检查？ 41 是否对错误情况给出了有意义的信息提示？ 42 是否考虑了意外情况？ 43 是否符合相关的法律法规
10 系统结构是否合理、清晰？ 11 各子系统、模块之间的关系是否描述得清楚? 12 系统的设计是否考虑了系统的可扩展性? 13 设计是否考虑了重用性? 14 重用构件是否进行了标识? 15 是否说明了重用模块的获得方式和相关的文档? 16 系统的设计是否考虑了系统的易移植性? 17 设计是否使用标准的技术，避免使用怪异的、不易理解的方式和方法? 18 是否列出了所有的调用？ 19 对变量、指针和常量进行了定义和初始化吗？ 20 设计能实现特定的需求和目标吗？ 21 是否对程序的注释进行了设计？ 22 是否对程序正确性 24 文档是否符合项目标准？ 25 是否用要求的方法或工具进行设计的？ 26 数据元素的名称在整个单元中保持一致吗？ 27 所有的设计接口相互间是一致的吗？ 28 是否存在逻辑上的问题？ 29 是否对各种情况都进行了处理？（如大于、等于、小于0，switch/case情况） 30 是否为开发和维护代码提供了充分的基础？ 31 所有的设计单元都可追溯回需求吗？ 接口 32 参数的数量、类型和顺序是否匹配？ 33 是否正确的定义了输入输出数据？ 34 是否清晰的描述了传递参数的顺序？ 35 是否识别了传递参数的机制？ 可维护性、可靠性 设计单元是否具有高内聚度低耦合度？（即该单元的变化不会对本单元造成不可预 36 料的影响，对其他单元的影响达到最小） 37 设计的复杂度已经最小了吗？
详细设计检查表
# 检查项 是/否/不适用 清晰性、完整性 1 是否清晰的描述了单元设计信息，包括数据流程、控制流程、接口？ 2 3 4 5 6 7 8 9 文档结构是否清晰、组织是否合理？ 文档结构是否便于维护和修改？ 设计是否易于理解？ 每个单元模块是否都有相应的标识? 是否对单元模块的目的和功能进行了描述？ 每个单元模块的输入/输出是否进行了描述? 是否说明了用于实现该单元模块的算法？ 是否提供了一致的错误处理机制?