软件设计评审检查表
软件设计方案评审检查单
类依赖的对象是否超过了5个?
9
类继承层次是否超过了6层?
10否存在某个基类不是抽象类?
12
继承自非抽象类的关系是否合适?
13
是否存在某个接口,某些客户仅仅使用其部分方法?
14
是否需要在运行时刻判断对象的类型?
15
类的访问权限是否合适?
软件设计评审检查单
序号
检查项
1
所有的功能需求与非功能需求是否都体现在了设计中?
2
在设计中是否增加了不必要的功能?是否为未来的变更进行了过度设计?
3
类的属性是否超过了公共方法的个数的2倍?
4
类提供的公共方法是否超过了7个?
5
某个类的方法是否即执行了修改又执行了查询?
6
方法的参数是否超过了3个?
7
每个方法估计的规模是否超过了200行代码?
软件设计评审表-模板
用户接口是否模块化,并且修改时不影响其他程序
10
是否提供了一致的错误处理机制
11
各子系统、模块之间的关系是否描述得清楚
12
系统的设计是否考虑了系统的可扩展性
13
设计是否考虑了重用性
14
重用构件是否进行了标识
15
是否说明了重用模块的获得方式和相关的文档
Байду номын сангаас16
系统的设计是否考虑了系统的易移植性
17
设计是否使用标准的技术,避免使用怪异的、不易理解的方式和方法
设计范围、边界是否清晰,文档中是否清晰阐明了系统的各项特性及预期的结果
15
逻辑性、算法和处理过程是否正确
16
文档是否符合客户的需要
17
设计是否考虑到未来的扩充性
18
设计的系统是否易于维护
评审项目
详细设计说明书
评审日期
评审结果标记
合格不合格TBD待完成 NA 不适用
评审情况
检查项:项;有效检查项:项;通过项:项;通过率:%
18
设计的调用宽度、调用深度、耦合度、内聚度和结构化程序是否进行了描述
追溯性
19
设计是否可以追踪到需求
20
需求是否可追溯到设计
编制: 日期: 审核: 日期: 批准: 日期:
序号
主要检查项
检查结果
说明
标准化
1
有规定的文档标识
2
引用的文档现行有效
3
文档编写的内容、格式符合相关标准、规定的要求
4
文档签署完整
5
设计陈述中的命名、属于和缩写是否上下文一致
完整性
5
文档有独立的版本说明部分
软件需求评审检查表模板
需求中定义的每个过程是否都可验证?
5
环境
5.1
是否指定了需要的软件环境/操作系统?
5.2
是否指定了需要的网路拓扑环境?
5.3
是否指定了所有要和系统一起购买的软件产品?
5.4
用户的操作能力如何?
6
用例描述
6.1
用例图上所有角色都定义了吗?是否遗漏了重要的角色,例如其他的软件、硬件系统?角色的划分是否正确?
6.2
用例中是否不包含设计和实现的细节?
6.3
是否确定了对时间要求很高的功能并且定义了它们的时间标准?
7文档Leabharlann 织7.1所有对于其他需求的内部交叉引用都正确吗?
7.2
所有需求都是按照一致和恰当的详细程度描述的吗?
7.3
需求为设计提供了充分的基础了吗?
7.4
需求是否进行了统一的编号?是否确定了每一个需求的优先级?
7.5
是否每个需求都没有内容和语法错误?
7.6
某些功能需求具有固有的内部算法,这样的算法定义了吗?
7.7
是否每个需求都没有内容和语法错误?
8
特殊问题
8.1
是否已明确阐述了对浏览器的支持(针对B/S系统)
1.4
是否对所有预料的错误条件定义了期望的系统行为?
2
正确性
2.1
是否某些需求与其他的需求冲突或者重复?
2.3
需求里有遗漏的必要信息吗?如果有的话,那些信息被标明为“待决定(TBD)”了吗?
2.4
任何定义的错误信息都是唯一和有意义的吗?
2.5
需求是否具有歧义?如果需求命名不容易理解,是否给予了足够的描述?
软件
项目名称
软件设计评审表-模板
引用的文档现行有效
3
文档编写的内容、格式符合相关标准、规定的要求
4
文档签署完整
完整性
5
文档有独立的版本说明部分
6
有文档的文字目录页
7
有总体设计部分
8
有功能设计
9
有接口设计
10
有性能设计
追溯性
11
设计是否可以追踪到需求
12
需求是否可追溯到设计
符合性
13
是否每个设计都是可测试的或以别的方式可以确定的
14
9
用户接口是否模块化,并且修改时不影响其他程序
10
是否提供了一致的错误处理机制
11
各子系统、模块之间的关系是否描述得清楚
12
系统的设计是否考虑了系统的可扩展性
13
设计是否考虑了重用性
14
重用构件是否进行了标识
15
是否说明了重用模块的获得方式和相关的文档
16
系统的设计是否考虑了系统的易移植性
17
设计是否使用标准的技术,避免使用怪异的、不易理解的方式和方法
设计范围、边界是否清晰,文档中是否清晰阐明了系统的各项特性及预期的结果
15
逻辑性、算法和处理过程是否正确
16
文档是否符合客户的需要
17
设计是否考虑到未来的扩充性
18
设计的系统是否易于维护
评审项目
详细设计说明书
评审日期
评审结果标记
合格不合格TBD待完成 NA 不适用
评审情况
18
设计的调用宽度、调用深度、耦合度、内聚度和结构化程序是否进行了描述
追溯性
19
设计是否可以追踪到需求
20
需求评审检查表
2.所规定的处理及其数据是否与必须完成的功能要求一致?
3.是否有超出范围的功能?
4.文档内部是否存在前后不一致的描述?
正确性
1.是否正确理解和描述了客户对软件的需求?所有错误是否已经排除?
明确性
1.是否存在含混、不清楚和含有二义的描述?
2.图表是否清楚?
可管理性
1.是否所有需求是以一种可管理的方式表达的?一个需求项的改变会不会影响其它很多功能?
问题
编号
问题说明和建议
(如果是针对文档中具体的内容,请标识位置)
1
2
……
n
评审检查结论
(邮件评审时填写此项)
□通过□有条件通过□不通过
说明:
需求评审检查表
项目名称
评委姓名
评审检查日期
评审检查用时(小时)
主要检查内容
意见
完整性
1.是否完整地定义了软件需求规格?
2.是否考虑了数据量和处理量?
3.是否定义了关键的接口和界面?
4.范围内的功能是否都有适当的描述?
5.在定义功能时是否考虑了异常处理ቤተ መጻሕፍቲ ባይዱ例外处理?
6.是否考虑过其它可选的软件需求?
一致性
3.某些信息是否被忽略了或有冗余?
可实施性
1.是否每一项软件需求都存在实现的可能?
2.软件设计是否可行?
3.约束条件是否现实?
4.是否考虑了实现需求的技术风险?
可追溯性
1.是否能够在后续过程中对每一项软件需求进行追溯?
2.是否需求中的每一项都能到用户问题域中找到对应?
相关性
1.是否文档的所有内容都跟要解决的问题相关?无关的内容都要去掉。
软件设计评审表模板
XXXXXXXXXXXX 单位名称软件设计评审表项目名称型号规格软件产品设计人评审人员部门职务或职称评审人员部门职务或职称评审项目概要设计说明书评审日期评审结果标记合格x 不合格TBD 待完成NA 不适用评审情况检查项:项;有效检查项:项;通过项:项;通过率:% 序号主要检查项检查结果说明标准化1 有规定的文档标识2 引用的文档现行有效3 文档编写的内容、格式符合相关标准、规定的要求4 文档签署完整完整性5 文档有独立的版本说明部分6 有文档的文字目录页7 有总体设计部分8 有功能设计9 有接口设计10 有性能设计追溯性11 设计是否可以追踪到需求12 需求是否可追溯到设计符合性13 是否每个设计都是可测试的或以别的方式可以确定的设计范围、边界是否清晰,文档中是否清晰阐明了系统14的各项特性及预期的结果15 逻辑性、算法和处理过程是否正确16 文档是否符合客户的需要17 设计是否考虑到未来的扩充性18 设计的系统是否易于维护评审项目详细设计说明书评审日期评审结果标记合格x 不合格TBD 待完成NA 不适用评审情况检查项:项;有效检查项:项;通过项:项;通过率:% 序号主要检查项检查结果说明标准化1 有规定的文档标识2 引用的文档现行有效3 文档编写的内容、格式符合相关标准、规定的要求4 文档签署完整5 设计陈述中的命名、属于和缩写是否上下文一致完整性5 文档有独立的版本说明部分6 每个设计是否都有相应的标识7 每个设计的输入/输出是否进行了描述8 关键的用户接口是否进行了描述9 用户接口是否模块化,并且修改时不影响其他程序10 是否提供了一致的错误处理机制11 各子系统、模块之间的关系是否描述得清楚12 系统的设计是否考虑了系统的可扩展性13 设计是否考虑了重用性14 重用构件是否进行了标识15 是否说明了重用模块的获得方式和相关的文档16 系统的设计是否考虑了系统的易移植性设计是否使用标准的技术,避免使用怪异的、不易理解17的方式和方法设计的调用宽度、调用深度、耦合度、内聚度和结构化18程序是否进行了描述追溯性19 设计是否可以追踪到需求20 需求是否可追溯到设计编制:日期:审核:日期:批准:日期:。
软件质量保证立项评审检查表
软件质量保证立项评审检查表1000字软件质量保证立项评审检查表一、需求分析1. 需求是否清晰、具体,是否与用户需求相符合?2. 是否需要补充或精化需求?是否已经广泛征求用户意见?3. 需求是否可以量化,是否可以度量,以及程度?4. 需求是否完整具备可行性、可实现性、可测试性?5. 需求是否构成了完整的规格说明书?二、设计文档1. 设计文档是否清晰、具体,是否是项目整体的完整性?2. 设计文档中的系统模块、功能模块是否划分明确,模块之间的接口定义是否清晰?3. 设计文档是否考虑了可扩展性、可维护性、可测试性等因素?4. 是否有详细的数据结构和算法描述?5. 是否有详细的接口设计和协议定义?三、编码1. 编码是否遵照设计文档,变量、函数、接口等定义是否清晰规范?2. 编码是否遵循团队约定的代码规范,是否合乎良好的编程习惯?3. 长大的复杂度是否能够在可控的范围内?4. 是否设置了有效的代码注释,方便其他程序员理解和维护?5. 代码风格是否美观,可读性是否良好?四、测试1. 测试计划是否清晰,测试用例是否完善?2. 是否考虑到各种不同的测试策略和测试方法?3. 测试是否包含细致的测试脚本和测试数据,以及详细的测试记录?4. 测试报告是否符合规范和需求,是否能够详细地描述问题和解决方案?5. 测试人员的反馈是否及时,是否遵循优先级原则及时解决问题?五、文档1. 是否有详尽的用户帮助手册和安装说明文档?2. 文档是否符合公司或部门的标准及规范,包括版式及内容等?3. 文档是否易于查找,是否提供详细的目录及索引规划?4. 文档是否准确、详细、易懂、有用,容易让用户理解?5. 是否有响应的文档版本控制及更新机制?六、验收1. 是否有详细的验收计划和验收流程?2. 验收标准是否符合用户要求,以及实际软件工程产品的需求?3. 是否有足够的验收数据,是否全面?4. 是否制定了验收的测试和评估机制?5. 是否有足够的用户支持和评估人员参与测试和评估?七、项目工程价值1. 项目工程是否符合公司或部门的目标与愿景?2. 项目工程是否有足够的经济效益或社会效益?3. 项目工程是否为公司或部门突破技术障碍或获得新技术而做出的贡献?4. 项目工程是否有行业领先水平,是否通过认证?5. 项目工程是否对公司或部门的进一步发展有推动作用?八、项目管理1. 项目经理是否有权威和汇报机制,是否有足够的资源配备?2. 项目管理是否有充足的规划和控制,是否符合公司或部门的项目管理流程和规范?3. 是否全面掌握和收集项目信息,在管理中进行有效的变更控制和风险管理?4. 是否足够注意项目的质量控制和工程的规划合理性?5. 是否通过合理的时间、人力和财务的管理,使得项目得以成功完成?以上是软件质量保证立项评审检查表。
软件评审检查表
在体系结构设计中,是否清晰描述了数据流、控制流与接口? 在体系结构设计中,是否清晰描述了数据流、控制流与接口? 在设计说明书中是否描述了所有的假设、约束、决定与依赖? 在设计说明书中是否描述了所有的假设、 约束、 决定与依赖? 是否定义了目标? 是否定义了目标? 在合适时,是否有设计是多样的、一致的? 在合适时,是否有设计是多样的、一致的? 功能性 对每个子模块是否都做了简要描述并概略描述了采用的算法? 对每个子模块是否都做了简要描述并概略描述了采用的算法? 选择的设计或算法是否满足需求? 选择的设计或算法是否满足需求? 接口 所有接口的描述是否与需求文档一致? 所有接口的描述是否与需求文档一致? 在软件各个功能模块之间的数据流是否得到了明确描述? 在软件各个功能模块之间的数据流是否得到了明确描述? 是否对所有的元件之间的接口都进行了定义? 是否对所有的元件之间的接口都进行了定义? 是否接口的定义正确、 合理? 是否接口的定义正确、 合理? 是否所有的外部接口定义可以追索到需求? 是否所有的外部接口定义可以追索到需求? 细节 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]免[ ] ] ] ] ] ] ]
软件评审检查表-计分
交互性要求
简易位,一致性;反馈性;容错性图形化.
人机交互简单、形象输入、输出方面的-致性对用户的操作及时作出皮馈;对可能出现的错误迸行检测、报告和处理.
15
软件性能
响应性要求
页面转焕的响应性 ;
载入时间的短时间要求
短时启动时间要求;
负裁指标明确化.
页面转换快捷;媒体装入时间简短;有确定的负载性能指标.
部署后是否可以正常使用.
5
运行环境
环境适用性.
运行环镜是否与软件愿景说明书一致
5
界面
界面布局
界面布局的合理性.
布局合理,层次清晰
2
界面美观设计
界面的美观性.
界面美观.
3
界画元素
界面元素的-致性.
窗口、菜单、图标、按钮等元素的-性.
5
功能要求
技术运用
技术运用的合理性;内容实现的正确性.
各种技术表现与具体内容结合 ,各种媒体使用协调;多媒体信息的呈现可控,链接准确、无死链.
100分
评审结论:
5ห้องสมุดไป่ตู้
稳定性要求
帮助机制的完备性;
错误处理机制完备性;
确认退出出机制的完备性.
每个操作都有联机帮助或提示;
联机帮助易读、易懂
处理用户可能出现的任何错误操作;
避免出现数据未保留而退出.
5
安全性要求
访问安全性,使用安全
性
用户身份管理和访问控制
数据安全性
10
软件文档
文档资料
完整性
规范性
软件过程文件目录
20
分数
软件产品评审表
评审时间:
评审人员:评审组长(),评审成员()
软件项目计划评审检查表
3.4
是否考虑了所有可能的风险,有没有为风 险留出一定时间?
3.5
风险的应对措施是否可执行?是否有效? 成本是否过高?
版本号:2 修订号:0
缺陷描述
第1页 共2页
4
客户关注
4.1
项目范围是否覆盖了合同的所有内容?
4.2
项目进度目标是否在合同要求内?里程碑 设置是否满足客户要求?
4.3
客户需要参与的任务有哪些?进度安排是 否合理可行?
4.4
与客户的沟通机制是怎样的,可行吗?有 效吗?
版本号:2 修订号:0
第2页 共2页
1.5
项目里程碑的设置是否合理?
2
PG和QA关注项
2.1
PDP的相关内容是否符合裁减指南的要求?
2.2
生命周期的选择是否合理?
2.3
项目特征识别的依据是否合理,识别的结 果是否符合过程要求?
3
项目组关注项
3.1
所有需自己完成的工作包和任务内容,质量 要求、进度要求是否明确?
3.2
工作包和任务工作量、人员安排、进度安 排计划是否合理?
项目计划评审检查表
项目名称
评审人 评审规模
(页) 序号
1
检查项 公司高层项目管理部关注项
项目编号
评审日期
评审耗时 (小时)
是否通过 N/A,Y,N
缺陷 个数
1.1
项目范围是否覆盖了合同的所有内容?
1.2
项目进度目标是否在合同要求内?
1.3
项目成本、质量目标是否在公司认可范围 内?
1.4
项目估算使用的方法、估算依据、基准值 等,是否合理?
1QH_19_02软件设计评审表
评审时间
评审内容
评审结论
很好
好
一般
不通过
文档的规范性
描述的一致性
文字的易读性
系统的完整性
系统的正确性
系统的安全性
类及对象合理性
数ห้องสมุดไป่ตู้设计合理性
接口完整简洁性
系统运行高效性
评审意见:通过修改后复审(问题附后)未通过
参加评审人员签字:
评审组长(签字):_______年月日
总工审批意见:
总工(签字):_______年月日
xx股份有限公司标题软件设计评审表项目名称评审时间评审内容评审结论很好一般不通过文档的规范性描述的一致性文字的易读性系统的完整性系统的正确性系统的安全性类及对象合理性数据设计合理性接口完整简洁性系统运行高效性评审意见
清华紫光股份有限公司
标题软件设计评审表
版本号:02编号:QH-19-02第0次修改
第1页共1页
软件设计评审检查表
Y: 是 TBD:不确定 N: 不是 NA:不适用
检查项
Y/TBD/N/NA
完整性
该测试计划是否详细说明测试的大体方法和策略?
该测试计划是否详细说明所有测试活动的顺序?
该测试计划是否描述了将使用的软硬件系统环境?
该测试计划是否描述了测试活动中断和恢复的条件/情形?
该测试计划是否为所有测试定义了成功标准?
是否详细说明了参数的度量单位、取值范围、正确度和精度?
共享数据区域及其存取规定的映射是否一致?
可维护性
单元是否具有高内聚度和低耦合度(例如:对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小)?
性能
是否该单元的所有约束例(如过程时间和规模)都被详细说明?
可靠性
初始化是否使用到缺省值,缺省值是否正确?
包括了数据流、控制流和接口的单元设计是否已清晰的说明?
完整性
是否已定义和初始化所有的变量、指针和常量?
是否已描述单元的全部功能?
是否已详细说明用来实现该单元的关键算法(例如:用自然语言或PDL)?
是否已列出该单元的调用?
依从性
该文档是否遵循了该项目已文档化的标准?
是否采用了所要求的方法和工具来进行单元设计?
该测试计划是否充分地描述了被测试的功能?
该测试计划是否明确地描述了不被测试的功能?
该测试计划是否充分地描述了测试基线?
对于阶段交付,该测试计划是否有在每一阶段建立测试基线给下一阶段使用?
该测试计划是否定义了足够和正确的衰退测试?
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档?
一致性
是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序?
软件项目设计评审检查表
技能水平及其他因素?
1.3
系统架构是否考虑了性能、安全、可扩展 、维护性等因素
1.4
系统架构是否有利于充分发挥现有硬件资 源的效能?
系统架构是否有利于在应用环境中的部
1.5
署?是否有利于系统管理员进行管理、维
护?
各个层的划分是否合理,各个层之间是否
1.6
有清晰的功能划分?是否符合主流的分层 规则(界面、业务逻辑、业务对象、数据
3.15 表或实体设计命名是否符合规范?
4
界面设计
是否描述项目所需要实现的各种典型界面
4.1
并给出界面demo?
是否遵循软件界面设计指南的要求?界面
4.2
风格的美学要求?
界面操作是否足够的人性化,能够获得交 好的用户体验? 4.3
版本号:2 修订号:0
第3页 共3页
访问等)?
系统功能模块的划分是否合理,是否符合
1.7
用户的实际业务操作方式?是否与用户的
岗位分工保持一致?
1.8
每个模块的功能、职责是否定义清楚?
1.9
各个模块的接口(通信界面)是否定义清 楚,以利于与其它系统的交互以及集成?
1.10
是否充分考虑到架构或组件的复用。
1.11
是否充分考虑了系统实现技术上的风险和 解决办法?
2
模块设计
版本号:2 修订号:0
缺陷描述第1页 共3页 Nhomakorabea 2.1
功能模块的设计文字说明是否清晰,比 较好的表达问题?
界面类设计布局及界面包含元素是否合
理,界面的显示或功能操作是否涵盖对
2.2
应的模块功能?是否能够满足人机交互 的友好性?界面类是否耦合了业务逻辑
软件设计评审检查表
是否已定义和初始化所有的变量、指针和常量?
是否已描述单元的全部功能?
是否已详细说明用来实现该单元的关键算法(例如:用自然语言或PDL)?
是否已列出该单元的调用?
依从性
该文档是否遵循了该项目已文档化的标准?
是否采用了所要求的方法和工具来进行单元设计?
一致性
数据元素的命名和使用在整个单元和单元接口之间是否一致?
可维护性
单元是否具有高内聚度和低耦合度(例如:对该单元的更改不会在该单元有任 何无法预料的影响并对其它单元的影响很小)?
性能
是否该单元的所有约束例(如过程时间和规模)都被详细说明?
可靠性
初始化是否使用到缺省值,缺省值是否正确?
是否在内存访问的时候执行了边界检查(例如:数组、数据结构、指针等)来 确保只是改变了目标存储位置?
Y:是TBD:不确定N:不是NA:不适用
检查项
Y/TBD/N/NA
清晰性
系统的目标是否已定义?
是否对关键术语和缩略语进行定义和描述?
所使用的术语是否和用户/客户使用的一致?
需求的描述是否清晰,不含糊?
是否有对整套系统进行功能概述?
是否已详细说明了软件环境(共存的软件)和硬件环境(特定的配置)?
如果有会影响实施的假设情况,是否已经声明?
完成软件确认测 试说明、执行软件 确认测试、进行测 试分析、编写确认 测试报告
完成系统测试 说明、执行系 统测试、进行 测试分析、编 写系统测试报 告
是否将需求分别陈述,因此它们是独立的并且是可检查的?
是否所有需求都可以回溯到相应的需求素材,反之亦然?
是否已详细说明需求变更的过程?
Y:是TBD:不确定N:不是NA:不适用
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
接口
接口参数在数量、类型和顺序上是否匹配?
是否所有的输入和输出都被正确定义和检查?
是否传递参数序列都被清晰的描述?
是否所有参数和控制标志由已描述的单元传递或返回?
是否详细说明了参数的度量单位、取值范围、正确度和精度?
共享数据区域及其存取规定的映射是否一致?
是否所有的逻辑都能被测试?
是否已描述测试程序、测试数据集和测试结果?
可追溯性
是否设计的每一部分都能追溯到其它项目文档的需求,也能追溯到更高级别文档的需求?
是否所有的设计决定都能追溯到权衡考虑?
单元需求是否都能上溯到更高级别的文档?更高级别文档的需求是否已经在单元中体现?
是否已描述单元的全部功能?
是否已详细说明用来实现该单元的关键算法(例如:用自然语言或PDL)?
是否已列出该单元的调用?
依从性
该文档是否遵循了该项目已文档化的标准?
是否采用了所要求的方法和工具来进行单元设计?
一致性
数据元素的命名和使用在整个单元和单元接口之间是否一致?
所有接口的设计是否互相一致并且和更高级别文档一致?
正确性
是否处理所有条件(大于、等于、小于零、switch/case)?是否存在处理“case not found”的条件?
是否正确地规定了分支(逻辑没有颠倒)?
数据使用
是否所有声明的数据都被实际使用到?
是否所有该单元的数据结构都被详细说明?
是否所有修改共享数据(或文件)的程序都考虑到了其它程序对该共享数据(或文件)的存取权限?
是否执行输入、输出、接口和结果的错误检查?
是否对所有错误情况都发出有意义的信息?
对特殊情况返回的代码是否和已规定的全局定义的返回代码相匹配?
是否考虑到意外事件?
易测性
是否能够对每个单元进行测试、演示、分析或检查来说明它们是满足需求的?
该设计是否包含检查点来帮助测试(例如:有条件的编译代码和数据声明测试)?
是否已经对每个业务逻辑进行输入、输出以及过程的详细说明?
完整性
是否列出了系统所必须的依赖、假设以及约束?
是否对每个提交物或阶段实施都进行了需求说明?
需求说明书是否已包括了主要的质量属性,例如有效性、高效性、灵活性、完整性、互操作性、可靠性、健壮性、可用性、可维护性、可移植性、可重用性和可测试性。
依从性
是否定义了总体设计目标?
完整性
是否所有的以前的TBD(待确定条目)都已经被解决了?
是否设计已经可以支持本文档中遗留的TBD有可能带来的变更?
是否所有的TBD的影响都已经被评估了?
是否仍存在可能不可行的设计部分?
是否已记录设计时的权衡考虑?该文件是否包括了权衡选择的标准和不选择其它方案的原因?
依从性
是否遵守了项目的文档编写标准?
一致性
数据元素、流程和对象的命名和使用在整套系统和外部接口之间是否一致?
该设计是否反映了实际操作环境(硬件、软件、支持软件)?
可行性
从进度、预算和技术角度上看该设计是否可行?
是否存在错误的、缺少的或不完整的逻辑?
数据使用
所有复合数据元素、参数以及对象的概念是否都已文档化?
是否还有任何需要的但还没有定义的数据结构,反之亦然?
是否将需求分别陈述,因此它们是独立பைடு நூலகம்并且是可检查的?
是否所有需求都可以回溯到相应的需求素材,反之亦然?
是否已详细说明需求变更的过程?
需求规格说明书检查表
概要设计检查表
Y:是TBD:不确定N:不是NA:不适用
检查项
Y/TBD/N/NA
清晰性
是否所设计的架构,包括数据流,控制流和接口,被清楚地表达了?
是否所有的假设、约束、策略及依赖都被记录在本文档了?
是否所有的界面都提供了所要求的信息?
是否已说明内部各界面之间的关系?
界面的数量和复杂程度是否已减少到最小?
可维护性
该设计是否是模块化的?
这些模块具有高内聚度和低耦合度?
是否已经对继承设计、代码或先前选择工具的使用进行了详细说明?
性能
主要性能参数是否已被详细说明(例如:实时、速度要求、磁盘输入/输出接口等)?
是否所有的设计决策都能追溯到原来确定的权衡因素?
所继承设计的已知风险是否已确定和分析?
详细设计检查表
Y:是TBD:不确定N:不是NA:不适用
检查项
Y/TBD/N/NA
清晰性
所有单元或过程的目的是否都已文档化?
包括了数据流、控制流和接口的单元设计是否已清晰的说明?
完整性
是否已定义和初始化所有的变量、指针和常量?
是否已描述最低级别数据元素?是否已详细说明取值范围?
功能性
是否对每一下级模块进行了概要算法说明?
所选择的设计和算法能否满足所有的需求?
接口
操作界面的设计是否有为用户考虑(例如:词汇、使用信息和进入的简易)?
是否已描述界面的功能特性?
界面将有利于问题解决吗?
是否所有界面都互相一致,与其它模块一致,以及和更高级别文档中的需求一致?
可维护性
单元是否具有高内聚度和低耦合度(例如:对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小)?
性能
是否该单元的所有约束例(如过程时间和规模)都被详细说明?
可靠性
初始化是否使用到缺省值,缺省值是否正确?
是否在内存访问的时候执行了边界检查(例如:数组、数据结构、指针等)来确保只是改变了目标存储位置?
可靠性
该设计能够提供错误检测和恢复(例如:输入输出检查)?
是否已考虑非正常情况?
是否所有的错误情况都被完整和准确地说明?
该设计是否满足该系统进行集成时所遵守的约定?
易测性
是否能够对该套系统进行测试、演示、分析或检查来说明它是满足需求的?
该套系统是否能用增量型的方法来集成和测试?
可追溯性
是否各部分的设计都能追溯到需求说明书的需求?
Y:是TBD:不确定N:不是NA:不适用
检查项
Y/TBD/N/NA
清晰性
系统的目标是否已定义?
是否对关键术语和缩略语进行定义和描述?
所使用的术语是否和用户/客户使用的一致?
需求的描述是否清晰,不含糊?
是否有对整套系统进行功能概述?
是否已详细说明了软件环境(共存的软件)和硬件环境(特定的配置)?
如果有会影响实施的假设情况,是否已经声明?
该文档是否遵守了该项目的文档编写标准?
一致性
需求说明是否存在直接相互矛盾的条目?
本需求说明书是否与相关需求素材一致?
可行性
所描述的所有功能是否必要并充分地满足了客户/系统目标?
需求说明书的描述的详细程度是否足以进行详细的设计?
已知的限制(局限)是否已经详细说明?
是否已确定每个需求的优先级别?
可管理性