软件设计评审检查表讲解学习

格式：doc
大小：147.00 KB
文档页数：8

下载文档原格式

软件测试用例评审检查单

1《需求规格说明书》是否评审并建立了基线?
2 是否按照测试计划时间完成用例编写?
3 需求新增和变更是否进行了对应的调整?
4 用例是否按照公司定义的模板进行编写?
5 测试用例是否覆盖了《需求规格说明书》?
6 用例编号是否和需求进行对应?
7 非功能测试需求或不可测试需求是否在用例中列出并说明?
8 用例设计是否包含了正面、反面的用例?
9 每个测试用例是否清楚的填写了测试特性、步骤、预期结果?
10 步骤/输入数据部分是否清晰，是否具备可操作性?
11 测试用例是否包含测试数据、测试数据的生成办法或者输入的相关描述?
12 测试用例是否包含边界值、等价类分析、因果图、错误推测、等测试用例设计方法?是否针对需求不同部分设计使用不同设计方法?
13 重点需求用例设计至少要有三种设计方法?
14 每个测试用例是否都阐述预期结果和评估该结果的方法? 软件测试
15 需要进行打印、表格、导入、导出、接口是否存在打印位置、表格名称、指定数据库表名或文件位置;表格和数据格式是否有说明或附件?
16 用例覆盖率是否达到相应质量指标?
17 用例预期缺陷率是否达到相应质量指标?。

软件设计方案评审检查单

8
类依赖的对象是否超过了5个？
9
类继承层次是否超过了6层？
10否存在某个基类不是抽象类？
12
继承自非抽象类的关系是否合适？
13
是否存在某个接口，某些客户仅仅使用其部分方法？
14
是否需要在运行时刻判断对象的类型？
15
类的访问权限是否合适？
软件设计评审检查单
序号
检查项
1
所有的功能需求与非功能需求是否都体现在了设计中？
2
在设计中是否增加了不必要的功能？是否为未来的变更进行了过度设计？
3
类的属性是否超过了公共方法的个数的2倍?
4
类提供的公共方法是否超过了7个？
5
某个类的方法是否即执行了修改又执行了查询？
6
方法的参数是否超过了3个？
7
每个方法估计的规模是否超过了200行代码？

软件需求规格说明书的评审检查单

软件需求规格说明书的评审检查单软件需求评审，作为一种软件产品验证的活动之一，通过及早地从软件产品中识别并消除缺陷，从而减少后期的返工，加快开发进度，提高产品的质量。

在需求阶段，发现一个需求缺陷的价值是多大呢？业内有个缺陷修复成本比例，需求阶段：设计阶段：测试阶段：上市阶段＝N:10N:100N:1000N；方案一一、注意对需求规格说明的正确性进行评审需求规格说明的正确性通常可以从如下方面得以体现：1 是否有需求与其他需求相互冲突或者重复？2 是否清晰、简洁、无二义地表达了每个需求?“清晰”是让人能够读懂；“简洁”是让人愿意去读；“无二义”决定”读”的效果,是让大家对需求描述的理解能够达成一致。

3 是否每个需求都通过了演示、测试、评审，分析是否得到了验证?4 是否每个需求都在项目的范围内?5 是否每个需求都没有内容和语法上的错误?6 在现有的资源内, 是否能实现所有的需求?7 每一条特定的错误信息，是否都是唯一的和具有含义的?二、注意对需求规格说明的实践性进行评审所谓实践性是指需求本身是否来源于目前企业的相关业务规则和文件制度,而非源于分析师们经验主义的臆测。

实践性是判断需求规格说明是不是理论联系实践、密切和用户联系的一个关键性指标。

三、注意对需求规格说明的完整性进行评审我们经常由下面的问题清单来评审需求说明书是否”完整” 。

1 编写的所有需求，其详细程度是否一致和合适?2 需求是否能为设计提供足够的基础?3 所有对其他需求的内部引用是否正确?4 是否包含了每个需求的实现优先级?5 是否定义了功能说明的内在算法?6 是否包含了所有已知的客户需求或系统需求?7 是否遗漏了必要的信息?如果有遗漏的话,把他们标记为待确定的问题(TBD) ?8 是否对所有预期的错误条件所产生的系统行为都编制了文档?需求说明的完整性主要体现在需求说明的详细程度上，我们怎样判断该需求的描述是否详细呢?我认为需求需要精化，而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应，等等。

软件质量保证立项评审检查表

软件质量保证立项评审检查表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. 是否通过合理的时间、人力和财务的管理，使得项目得以成功完成？以上是软件质量保证立项评审检查表。

软件质量保证开发计划评审检查表

（√）
评审的组织
以上资料是否提前2天发给参加评审的人员
（√）
是否指定评审会议主持人
（√）
评审的参与人
产品经理（PM）
（√）
系统分析员（SA）
（√）
测试经理（TM）
（√）
开发经理（DM）
（√）
配置管理员
（√）
SQA
（√）
项目外部相关组代表
（√）
评审的过程
项目描述
（√）
人员职责
（√）
项目估计
（√）
开发计划
（√）
是否有软件项目的工作量和成本估计
（√）
是否有关键计算机资源估计
（√）
开发计划
是否有项目资源描述，包括人员配备、职责与权限、人员及其技术职位、设备与支持工具等
（√）
是否明确定义项目开发主要阶段和每个阶段的输入、输出的软件工作产品及验证准则
（√）
是否有进度表
（√）
是否明确标识里程碑和评审点
（√）
是否说明项目开发中的使用的主要的开发工具和技术方法
时间：2014-05-06
请在（）内标注相关检查结果
√：检查通过
х：检查不通过需修改
其他标记：请注明原因
需要项目组外的人员和部门协助配合的，是否已经达成共识
（√）
进度表是否得到高层经理、项目经理和开发人员、测试人员的认同
（√）
开发目标和范围是否和需求一致
（√）
风险分析
（√）
评审结论
评审结论是否明确
（√）
评审遗留问题是否落实
（√）
评审报告
评审报告是否成文
（√）
评审报告是否发给参加评审的人员

软件评审检查表-计分

15
交互性要求
简易位，一致性;反馈性;容错性图形化.
人机交互简单、形象输入、输出方面的-致性对用户的操作及时作出皮馈;对可能出现的错误迸行检测、报告和处理.
15
软件性能
响应性要求
页面转焕的响应性 ;
载入时间的短时间要求
短时启动时间要求;
负裁指标明确化.
页面转换快捷;媒体装入时间简短;有确定的负载性能指标.
部署后是否可以正常使用.
5
运行环境
环境适用性.
运行环镜是否与软件愿景说明书一致
5
界面
界面布局
界面布局的合理性.
布局合理，层次清晰
2
界面美观设计
界面的美观性.
界面美观.
3
界画元素
界面元素的-致性.
窗口、菜单、图标、按钮等元素的-性.
5
功能要求
技术运用
技术运用的合理性;内容实现的正确性.
各种技术表现与具体内容结合，各种媒体使用协调;多媒体信息的呈现可控，链接准确、无死链.
100分
评审结论：
5ห้องสมุดไป่ตู้
稳定性要求
帮助机制的完备性;
错误处理机制完备性;
确认退出出机制的完备性.
每个操作都有联机帮助或提示;
联机帮助易读、易懂
处理用户可能出现的任何错误操作;
避免出现数据未保留而退出.
5
安全性要求
访问安全性，使用安全
性
用户身份管理和访问控制
数据安全性
10
软件文档
文档资料
完整性
规范性
软件过程文件目录
20
分数
软件产品评审表
评审时间：
评审人员：评审组长（），评审成员（）

软件需求开发-需求评审检查单模版

2)系统连续运行时间假设是否符合用户需求，是否与环境相匹配？
3)系统安全方案是否完整，是否符合用户需求？
4)系统灾备方案是否符合用户需求，是否与环境相匹配？
5)系统日志功能是否符合用户需求和工程维护的需要？
评审组成员会后意见：（以下内容在评审会议后填写）
评审组对本次评审结果的建议为：□通过□有条件通过□不通过
3)输入、输出的描述是否完整？
4)正常业务处理流程是否合理？
5)异常状况是否列举充分，相应的容错处理是否合理？
6பைடு நூலகம்约束条件的设定是否合理？
7)兼容性和扩展性是否得到了必要的考虑？
8)易验证性：定义的需求是否是能够得到验证的？
3.非功能需求检查
3.
1)是否对负载和环境的不同组合进行了必要的枚举，组合条件的假设是否合理，相应的系统执行效率描述是否准确、合理？
需求评审检查单
项目名称
被评审人
文档名称
版本号
评审时间
检查内容
检查结果
1.总体检查
1)是否符合公司制定的模板？
2)术语定义是否完整、清晰、符合行业规范和惯例？
3)参考资料是否完整，是否符合时效性的要求？
4)系统用户分类是否符合用户需求(用户需求包括行业标准、合同约定、目标用户群的普遍共识、目标用户的个性化需求等，下同)？
具体意见如下（如评审结果建议为“有条件通过”或“不通过”，请务必填写遗留的问题与建议）：
评审组长签名：
10)需求设计的完整性（需求定义是否包含了有关功能、性能、安全性、限制、目标、质量等方面的所有需求）？
11)是否识别并定义了在将来可能会变化的需求？
12)需求定义是否使软件的设计、实现、操作和维护都可行？

软件需求规格说明书评审检查表

软件需求规格说明书评审
编制人员：项目名称：检查依据：《软件需求规格说明书模板》、《需求开发过程》序号 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 21 22 23 24 25 结果统计
是：否：不适用：未检查：说明

软件项目计划评审检查表

漏或错误，与需求及其变更是否保持一致？
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
项目估算使用的方法、估算依据、基准值等，是否合理？

软件设计评审检查表

测试计划检查表
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
应的模块功能？是否能够满足人机交互的友好性？界面类是否耦合了业务逻辑

软件需求分析评审检查单

软件需求分析评审检查单
软件评审记录
工程代号项目名称
评审日期
年月日
评审性质
序
评审项目
合格不合格不适用
号
1. 文档文档齐全
2. 规范文档编制规范
需求分析方法 3.
工具使用正确
4.
软件功能需求
5.
需求性能要求
6.
ቤተ መጻሕፍቲ ባይዱ
内容接口要求
7.
完整、数据要求
8. 软件正确环境要求
9. 需求软件实时性需求
计划
22.
验证计划安排明确、合理可行
23.
确认计划安排明确、合理可行
24. 软件质量保证计划明确、完整
25. 软件测试的范围和内容明确
26. 配置测试结果评价准则明确、可行
项测测试的组织、人员、进度安排
27. 试计合理、明确
划
评审 □ 复审 □ 备注
10. 规格需求正确性要求
11. 说明合理、完备性要求
12.
可行一致性要求
13.
无二义性要求
14.
可验证性要求
15.
可追踪性要求
16.
可靠性要求明确
17.
数据安全和保密要求明确
18.
阶段划分明确
19.
计划安排明确、合理、可行
软件
20.
软件配置管理要求明确
开发
21.
安全计划安排明确、合理可行

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

是否所有的设计决策都能追溯到原来确定的权衡因素?
所继承设计的已知风险是否已确定和分析？
详细设计检查表
Y:是TBD:不确定N:不是NA:不适用
检查项
Y/TBD/N/NA
清晰性
所有单元或过程的目的是否都已文档化？
包括了数据流、控制流和接口的单元设计是否已清晰的说明？
完整性
是否已定义和初始化所有的变量、指针和常量？
是否所有的逻辑都能被测试？
是否已描述测试程序、测试数据集和测试结果？
可追溯性
是否设计的每一部分都能追溯到其它项目文档的需求，也能追溯到更高级别文档的需求？
是否所有的设计决定都能追溯到权衡考虑？
一致性
数据元素、流程和对象的命名和使用在整套系统和外部接口之间是否一致？
该设计是否反映了实际操作环境（硬件、软件、支持软件）？
可行性
从进度、预算和技术角度上看该设计是否可行？
是否存在错误的、缺少的或不完整的逻辑？
数据使用
所有复合数据元素、参数以及对象的概念是否都已文档化？
是否还有任何需要的但还没有定义的数据结构，反之亦然？
正确性
是否处理所有条件（大于、等于、小于零、switch/case）？是否存在处理“case not found”的条件？
是否正确地规定了分支（逻辑没有颠倒）？
数据使用
是否所有声明的数据都被实际使用到？
是否所有该单元的数据结构都被详细说明？
是否所有修改共享数据（或文件）的程序都考虑到了其它程序对该共享数据（或文件）的存取权限？
是否执行输入、输出、接口和结果的错误检查？
是否对所有错误情况都发出有意义的信息？
对特殊情况返回的代码是否和已规定的全局定义的返回代码相匹配？
是否考虑到意外事件？
易测性
是否能够对每个单元进行测试、演示、分析或检查来说明它们是满足需求的？
该设计是否包含检查点来帮助测试（例如：有条件的编译代码和数据声明测试）？
可维护性
单元是否具有高内聚度和低耦合度（例如：对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小）？
性能
是否该单元的所有约束例（如过程时间和规模）都被详细说明？
可靠性
初ห้องสมุดไป่ตู้化是否使用到缺省值，缺省值是否正确？
是否在内存访问的时候执行了边界检查（例如：数组、数据结构、指针等）来确保只是改变了目标存储位置？
软件设计评审检查表
Y:是TBD:不确定N:不是NA:不适用
检查项
Y/TBD/N/NA
清晰性
系统的目标是否已定义？
是否对关键术语和缩略语进行定义和描述？
所使用的术语是否和用户/客户使用的一致？
需求的描述是否清晰，不含糊？
是否有对整套系统进行功能概述？
是否已详细说明了软件环境(共存的软件)和硬件环境(特定的配置)？
可靠性
该设计能够提供错误检测和恢复（例如：输入输出检查）？
是否已考虑非正常情况？
是否所有的错误情况都被完整和准确地说明？
该设计是否满足该系统进行集成时所遵守的约定？
易测性
是否能够对该套系统进行测试、演示、分析或检查来说明它是满足需求的？
该套系统是否能用增量型的方法来集成和测试？
可追溯性
是否各部分的设计都能追溯到需求说明书的需求？
是否定义了总体设计目标？
完整性
是否所有的以前的TBD（待确定条目）都已经被解决了？
是否设计已经可以支持本文档中遗留的TBD有可能带来的变更？
是否所有的TBD的影响都已经被评估了？
是否仍存在可能不可行的设计部分？
是否已记录设计时的权衡考虑？该文件是否包括了权衡选择的标准和不选择其它方案的原因？
依从性
是否遵守了项目的文档编写标准？
是否已描述单元的全部功能？
是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）?
是否已列出该单元的调用？
依从性
该文档是否遵循了该项目已文档化的标准？
是否采用了所要求的方法和工具来进行单元设计？
一致性
数据元素的命名和使用在整个单元和单元接口之间是否一致？
所有接口的设计是否互相一致并且和更高级别文档一致？
是否已描述最低级别数据元素？是否已详细说明取值范围？
功能性
是否对每一下级模块进行了概要算法说明？
所选择的设计和算法能否满足所有的需求？
接口
操作界面的设计是否有为用户考虑（例如：词汇、使用信息和进入的简易）？
是否已描述界面的功能特性？
界面将有利于问题解决吗？
是否所有界面都互相一致，与其它模块一致，以及和更高级别文档中的需求一致？
是否所有的界面都提供了所要求的信息？
是否已说明内部各界面之间的关系？
界面的数量和复杂程度是否已减少到最小？
可维护性
该设计是否是模块化的？
这些模块具有高内聚度和低耦合度？
是否已经对继承设计、代码或先前选择工具的使用进行了详细说明？
性能
主要性能参数是否已被详细说明（例如：实时、速度要求、磁盘输入/输出接口等）？
如果有会影响实施的假设情况，是否已经声明？
是否已经对每个业务逻辑进行输入、输出以及过程的详细说明？
完整性
是否列出了系统所必须的依赖、假设以及约束？
是否对每个提交物或阶段实施都进行了需求说明？
需求说明书是否已包括了主要的质量属性，例如有效性、高效性、灵活性、完整性、互操作性、可靠性、健壮性、可用性、可维护性、可移植性、可重用性和可测试性。
是否将需求分别陈述，因此它们是独立的并且是可检查的？
是否所有需求都可以回溯到相应的需求素材，反之亦然？
是否已详细说明需求变更的过程？
需求规格说明书检查表
概要设计检查表
Y:是TBD:不确定N:不是NA:不适用
检查项
Y/TBD/N/NA
清晰性
是否所设计的架构，包括数据流，控制流和接口，被清楚地表达了？
是否所有的假设、约束、策略及依赖都被记录在本文档了？
是否所有逻辑单元、时间标志和同步标志都被定义和初始化？
接口
接口参数在数量、类型和顺序上是否匹配？
是否所有的输入和输出都被正确定义和检查？
是否传递参数序列都被清晰的描述？
是否所有参数和控制标志由已描述的单元传递或返回？
是否详细说明了参数的度量单位、取值范围、正确度和精度？
共享数据区域及其存取规定的映射是否一致？
依从性
该文档是否遵守了该项目的文档编写标准？
一致性
需求说明是否存在直接相互矛盾的条目？
本需求说明书是否与相关需求素材一致？
可行性
所描述的所有功能是否必要并充分地满足了客户/系统目标？
需求说明书的描述的详细程度是否足以进行详细的设计？
已知的限制（局限）是否已经详细说明？
是否已确定每个需求的优先级别？
可管理性