详细设计说明书评审检查表
软件设计评审检查表
是否所有修改共享数据 （或文件）的程序都考虑到了其它程序对该共享数据 （或 文件）的存取权限？
是否所有逻辑单元、时间标志和同步标志都被定义和初始化？
接口
接口参数在数量、类型和顺序上是否匹配？
是否所有的输入和输出都被正确定义和检查？
是否传递参数序列都被清晰的描述？
该套系统是否能用增量型的方法来集成和测试？
可追溯性
是否各部分的设计都能追溯到需求说明书的需求？
是否所有的设计决策都能追溯到原来确定的权衡因素?
所继承设计的已知风险是否已确定和分析？
详细设计检查表
Y:是TBD:不确定N:不是NA:不适用
检查项
Y/TBD/N/NA
清晰性
所有单元或过程的目的是否都已文档化？
一致性
数据元素的命名和使用在整个单元和单元接口之间是否一致？
所有接口的设计是否互相一致并且和更高级别文档一致？
正确性
是否处理所有条件 （大于、等于、小于零、switch/case）？是否存在处理“case not found”的条件？
是否正确地规定了分支（逻辑没有颠倒）？
数据使用
是否所有声明的数据都被实际使用到？
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档？
一致性
是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序？
该测试计划是否和更高级别的测试计划文档一致？
正确性
该测试计划的进入和退出条件是否实现？
是否所有必须的驱动程序和桩（stubs）都已被定义且可利用来测试指定的功 能？
详细级别/程度
是否定义了总体设计目标？
完整性
是否所有的以前的TBD（待确定条目）都已经被解决了？
详细设计说明书检查表
是否所有的设计决定都能追溯到权衡考虑
▢是▢否
单元需求是否都能上溯到更高级别的文档更高级别文档的需求是否已经在单元中体现
▢是▢否
承建单位（盖章）：
负责人：
日期：
建设单位（盖章）：
项目经理：
日期：
监理机构（盖章）：
监理工程师：
日期：
是所有的逻辑都能被测试
▢是▢否
是否已描述测试程序、测试数据集和测试结果
▢是▢否
是否能够对每个单元进行测试、演示、分析或检查来说明它们是满足需求的。
▢是▢否
该设计是否包含检查点来帮助测试（例如：有条件的编译代码和数据声明测试）
▢是▢否
可追溯性
是否设计的每一部分都能追溯到其它项目文档的需求，也能追溯到更高级别文档的需求
可维护性
这些模块具有高内聚度和低耦合度
▢是▢否
性能
是否该单元的所有约束例如过程时间和规模都被详细说明
▢是▢否
可靠性
初始化是否使用到缺省值，缺省值是否正确
▢是▢否
是否在内存访问的时候执行了边界检查（例如：数组、数据结构、指针等）来确保只是改变了目标存储位置
▢是▢否
是否执行输入、输出、接口和结果的错误检查
▢是▢否
是否对所有错误情况都发出有意义的信息
▢是▢否
对特殊情况返回的代码是否和已规定的全局定义的返回代码相匹配
▢是▢否
是否考虑到意外事件
▢是▢否
易测性
是否能够对每个单元进行测试、演示、分析或检查来说明它们是满足需求的。
▢是▢否
该设计是否包含检查点来帮助测试（例如：有条件的编译代码和数据声明测试）
▢是▢否
▢是▢否
接口
设计说明书评审检查单(设计说明书检查单)
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.0版)
系统测试是否符合产品要求，验证结果是否符合要求
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
是否已选择特殊特性？
设计评审检查表
评审日期：No.
风险评估：
改正方法
改正计划
项目组评审意见：
生产部评审意见：
品质部评审意见：
工程部评审意见：
市场部评审意见：
计划部评审意见：
中央研究院：
改善的结果
评审结论：
通过不通过
总工/副总评审意见：签名：Leabharlann 总经理评审意见：签名：
第2页共2页
一、设计资料的制订：
特殊特性清单
DFMEA表
产品规格书
材料表
样品控制计划表
PFMEA
物料技术要求
小试控制计划
工艺文件
技术图纸
工艺流程图
中试控制计划
试产前控制计划
量产控制计划
二、新增设备/工装/模具
新增设备/工装
新增量具检验设备
新增模具
三、验证报告
四、小/中试产品合格率
五、生产过程记录
不完善事项：
第1页共2页
设计评审检查表
评审日期：编制人：No.
产品名称
设计人员
产品规格
评审人员
数量
（中/小试）数量：(试产)数量：（批量）数量：
评审依据：
客户要求：
其它：
评审项目名称：
项目目标：
评审阶段
评审内容
评审资料编号
备注
样品试作前评审
样品制作后评审
小试前评审
小试后评审
中试前评审
中试后评审
试产前评审
批量生产前评审
批量生产后评审
产品详细设计评审检查表-模板
××产品详细设计评审检查表
【内容】
●评审人员根据此表认真审核《产品详细设计规格说明书》。
●如果是合同项目，可能还需要用户审核，视具体情况而定。
【裁剪原则】
此部分内容不允许裁剪。
评委名称
评委日期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 在确定了合理的折衷情况下，是否详实地记录了其它相关的质量属性？
概要设计评审检查表模板
不适 优秀 合 用 格
不合格
备注
16 17 18 19 20 21 22 23 24
25
26
Hale Waihona Puke 27 28 29 30 建议:
系统出错处理的设计是否合理？是否说明每种可 能的出错或故障情况出现时，系统输出信息的形 式、含意及处理方法？ 存储及传输方面的设计是否合理？ 是否定义了技术与工作的标准？ 该项工作的计划与实际成本是否合理？ 该项工作的计划与实际进度是否合理？
概要设计评审检查表 序号
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
检查项 是否确定了合理的构架原则，考虑到稳定性、持 久性、容错性和可扩展性等? 与需求说明是否一致?是否所有的需求都能追溯到 设计方案中 设计中有无可以复用资产库(成熟构件/开源代码) 的地方? 系统、子系统的接口是否清晰简单?接口设计是否 合理? 系统的功能模块划分是否合理? 模块间的耦合程度是否合理？ 模块的内聚程度是否合理？ 是否有安全设计? 后续设计人员是否认为可以据此做详细设计? 设计是否易于测试? 是否有技术风险，对这些风险给予应有的对应处 理办法？ 算法与数据结构的设计是否合理？ 总体设计/主体架构的是否是明确、完整合理的？ 系统的I/O是否符合应用要求、标准？其一致性、 复杂性是否合理，如在：硬件接口、软件接口、 体系接口等方面？ 系统的性能设计是否合理？是否分析到：时间与 空间上的瓶颈之处；随着运行时间、处理数据量 、通信带宽、并行访问的人数、次数等参数变 化，系统的效率情况 系统的易用性是否合理？ 对系统的硬件环境与支持环境是否有明确的规 定？ 对系统的基本设计思想和处理流程是否使用图形 表现出来？ 是否用一览表的形式说明本系统的各层模块、子 程序、公用程序等的划分？ 是否说明每个系统元素的标识符和功能，分层次 地给出各元素之间的控制与被控制关系？ 是否存在待解决问题并给予明确的识别？ 软件界面的美观性、一致性的要求是否符合用户 的主题，体现完整的结构思想 界面：整体布局、字体、色彩、动态效果、页面/ 图形的生成速度、检索速度、导航/链接是否正 是否说明本系统同外界的所有接口的安排包括软 件与硬件之间的接口、本系统与各支持软件之间 的接口关系？ 是否给出本系统内所使用的每个数据结构的名称 、标识符以及它们之中每个数据项、记录、文卷 和系的标识、定义、长度及它们之间的层次的或 表格的相互关系？
设计方案审查表
设计方案审查表
设计方案审查表
设计方案审查表是在进行设计方案审核时使用的一种工具，用于对设计方案的内容、表达、合理性等进行评估和审查。
下面是一个设计方案审查表的示例：
项目名称：XXX设计项目
设计方案名称：XXX设计方案
设计方案编码：XXX-001
审核人员：（填写审核人员姓名）
一、设计方案内容审查：
1.设计方案是否符合项目要求？
2.设计方案是否满足客户的需求和期望？
3.设计方案的创意和独特性如何？
4.设计方案所提供的解决方案是否可行？
5.设计方案中是否存在与安全、环保等相关法律法规冲突的内容？
6.设计方案的整体质量如何？
二、设计方案表达审查：
1.设计方案的结构和组织是否合理？
2.设计方案的文字表述是否清晰易懂？
3.设计方案的图表和图片是否清晰、准确且具有较高的美观度？
4.设计方案中的数据和信息是否准确？
三、设计方案合理性审查：
1.设计方案在技术上是否可行？
2.设计方案的成本是否合理？
3.设计方案的工期是否合理？
4.设计方案的风险评估是否充分？
5.设计方案的可维护性和可持续性如何？
四、其他问题：
（在此列出除上述问题之外的其他需要审查的内容）
五、审查结论：
（在此填写对设计方案的审查结论，例如：通过、不通过、待改进等）
备注：
（在此填写对设计方案审查时的其他需要说明的内容）
以上是一个设计方案审查表的示例，实际使用时可以根据具体项目的需求进行适当调整和补充。
通过使用设计方案审查表，可以更加系统和全面地评估设计方案的优劣，并提出针对性的意见和建议，有助于设计方案的改进和完善。
图纸规格书设计审查查检表
□
□
是否已准备就绪
□
□
是否完整正确
□
□
是否符合规格要求
□
□
是否执行
□
□
是否符合要求
□
□
是否符合要求规格
□
□
二、评审单位意见：
部门
意见签核栏
□工程
□塑模
□注塑
□冲压
部门 □机设 □品保 □组装 □协力商
意见签核栏
三、最终裁定： 是否执行：□是 □否
核准人：
FK-RDD-28C
是
否
是否符合客户需求或协会规定
□
□
是否符合客户需求
□
□
是否符合客户需求
□
□
是否符合客户需求或协会规定
□
□
ห้องสมุดไป่ตู้
是否符合客户需求或协会规定
□
□
是否符合客户需求或协会规定
□
□
是否照预定
□
□
是否照预定
□
□
是否照预定
□
□
是否侵害其他公司的专利
□
□
是否申请自己公司的专利权
□
□
是否符合特定GP测试、安规之要求 □
□
是否有缺漏或错误等
图面、规格书设计审查查检表
新产品名称：
项目代号：
负责人： 日期：
一、检查项目： 1.适用之标准文件 2. 材料与电镀规格 3. 使用之电压、电流、操作温度 4. 电气特性 5. 机械特性 6. 环境特性 7.成本 8.外观 9.大小、重量 10.专利
11.特殊要求 12.文件、图面 13.模具、治具、检具 14.测试方法 15.结构概要 16.FMEA 17.产品安全及法令规章 18.GP要求标准
软件的设计的评审检查表
完整性
是否所有的以前的TBD（待确定条目）都已经被解决了？
是否设计已经可以支持本文档中遗留的TBD有可能带来的变更？
是否所有的TBD的影响都已经被评估了？
是否仍存在可能不可行的设计部分？
是否已记录设计时的权衡考虑？该文件是否包括了权衡选择的标准和不选择其它方案的原因？
依从性
是否遵守了项目的文档编写标准？
正确性
是否处理所有条件（大于、等于、小于零、switch/case）？是否存在处理“case not found”的条件？
是否正确地规定了分支（逻辑没有颠倒）？
数据使用
是否所有声明的数据都被实际使用到？
是否所有该单元的数据结构都被详细说明？
是否所有修改共享数据（或文件）的程序都考虑到了其它程序对该共享数据（或文件）的存取权限？
是否将需求分别陈述，因此它们是独立的并且是可检查的？
是否所有需求都可以回溯到相应的需求素材，反之亦然？
是否已详细说明需求变更的过程？
需求规格说明书检查表
概要设计检查表
Y:是TBD:不确定N:不是NA:不适用
检查项
Y/TBD/N/NA
清晰性
是否所设计的架构，包括数据流，控制流和接口，被清楚地表达了？
是否所有的假设、约束、策略及依赖都被记录在本文档了？
可维护性
单元是否具有高内聚度和低耦合度（例如：对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小）？
性能
是否该单元的所有约束例（如过程时间和规模）都被详细说明？
可靠性
初始化是否使用到缺省值，缺省值是否正确？
是否在内存访问的时候执行了边界检查（例如：数组、数据结构、指针等）来确保只是改变了目标存储位置？
详细设计评审表模板
详细设计评审表模板
工程负责人: 评审时间：
:评审流程
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
评审对象： 评审人/时间： 评审记录
否 否 否 否 否 否 否 否 否 否 否 否 否 否 否 否 否
等级 必要 必要 必要 必要 必要 必要 必要 必要 必要 必要 必要 必要 必要 必要 必要 必要 必要
问题描述/不合格需求数
单条需求说明评审检查项 7. 功 能 需 求 、 性 能 需 求 、 质 量 属 性 需 求 、 外 7.1 7.2 7.3 7.4 每个叶节点需求是否都有优先级？ 每个叶节点需求是否都有项目内唯一的标识？ 每个叶节点需求是否可验证（应注意验证的代价。 如果验证的代价太大，也认为是不可验证的）？ 需求描述是否正确？ 需求描述是否完整（至少应“可验证”，且描述了 模板要求的所有“字段”。另外，对所有可能出现 的输入/激励都应予以定义；应对合法和非合法的输 入值的响应做出规定；未遗漏插图、表、图示标记 和参照，并且定义了使用到的术语和度量单位、取 值范围等） 从成本、进度、技术角度来看，需求是否可行？ 从市场角度来看，需求是否必要？
是 是 是 是 否 否 否 否
可选 必要 必要 必要
7.5
是
否
必要
7.6 7.7
是 是 是
否 否
必要 必要
186487852.xls
2/3
需 求 、 性 能 需 求 、 质 量 属 性 要素 代号 需 求 7.8 、 7.9 外 部 7.1 接 口 7.11 需 8.1 8. 功 能 需 求 需 要 满 足 的 公 共 检 查 项 8.2 8.3 8.4 8.5
是 是
否 否
是
否
是 是 是 是 是 是 是 是 是
否 否 否 否 否 否 否 否
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
# 检查项 是/否/不适用 否 不适用 清晰性、完整性 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 设计的复杂度已经最小了吗？
38 是否具有清晰性、可读性、可修改性，满足维护需求？ 39 是否设定了正确的初始化缺省值？ 40 是否对输入、输出、接口和结果进行了错误检查？ 41 是否对错误情况给出了有意义的信息提示？ 42 是否考虑了意外情况？ 43 是否符合相关ห้องสมุดไป่ตู้法律法规