详细设计说明书评审检查表
详细设计说明书评审检查表
# 检查项 是/否/不适用 否 不适用 清晰性、完整性 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
检查项
技术框架描述是否清楚明白? 有没有给出整体界面示意图? 界面清单及其流转关系是否明确? 有没有遗漏的界面清单及其流转关系? 状态图或状态流转图是否完备? 是否完整地描述了（数据处理/流程）功能性需求? 是否完整地描述了（查询统计）功能性需求? 是否完整地描述了（用户/角色/授权）功能性需求 是否完整地描述了（审计）功能性需求 需求是否正确地反映了《业务需求说明书》的内容？ 需求是否存在二义性？ 每项需求间是否存在冲突？ 需求是否完备？ 每项需求都是可实现的吗？ 每项需求都是可验证的吗？ 从技术层面分析用户所提需求是否可以实现？ 是否完整地记录了质量属性？ 质量属性的描述是定量地说明所需要达到的程度了吗？ 每项需求都确定了优先级吗？ 功能描述重要程度与用户需求重要程序一致吗？
- 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 文档结构是否清晰、组织是否合理？ 文档结构是否便于维护和修改？ 设计是否易于理解？ 每个单元模块是否都有相应的标识? 是否对单元模块的目的和功能进行了描述？ 每个单元模块的输入/输出是否进行了描述? 是否说明了用于实现该单元模块的算法？ 是否提供了一致的错误处理机制?