需求评审检查表
软件项目需求评审检查表-模板
7充
功能项（能够统计各地区、行别的资金流量流向）有
8 遗漏
功能项（根据机构代码、行别、清算行、地区代码等 条件查询收费信息；根据机构代码、行别、清算行、 地区代码等条件查询提出提入业务量）未在需求说明
9 书中体现，需要补充；
3306951832.xls 第2页 共2页
评审准备表
项目经理 角 色 评审检查者
QA工程师 评审日期
序号
1 跨区代理问题
2020/9/23 缺陷记录
作者
记录人
缺陷总数 缺陷级别 提出人
一般
14 备注
多表实现。其中控制类型只允许条件是否可略去需和
2 用户确认
3
4 进行修改
补充市区操作员和各县区操作员可查询的账户信息范
5围 6 大额交易查询检测功能：用户界面项遗漏行别等字段
12 有遗漏
功能项（已存在的银行类别可以修改，如将农信社改
13 为农合行或农商行）不需要实现批量改
批量导入、导出功能。提供按机构代码、清算行行号 、账号位数批量删除账户信息功能。提供账户批量迁 移功能）原系统中导入Excel、批量删除功能还未实
14 现，需要补充 15
一般 一般 严重 严重
建议
上海畅星智能系统有限公司
提供账户批量迁移功能原系统中导入excel批量删除功能还未实现需要补充功能项一台前置机支持多个清算账户未在需求说明书中体现需要补充功能项交易明细查询可以设置查询金额的范围有遗漏上海畅星智能系统有限公司第2页共5页a1299073341编号项目是否不适用说明1需求划分是否合理是2业务规则是否均有说明
需求评审检查表.doc
需求评审检查表需求特性检査内容所有定义、实现方法是否清楚地表达了用户的原要求在功能实现过程、方法和技术要求的描述上，是否背离了功能的实际要 是否有不能理解或造成误解的描述I 是否有一个内容表格，该表格包含了所有需求描述是否所有的图形、表格都进行了标号是否所有的需求项都进行了标号，并提供了索引是否所有需求可以被定义的更细致，或简单对于不清晰的信息是否进行了指岀是否存在有需求让你不舒服是否所有与需求相关的设计约束都包含了是否所有与需求相关的性能都包含了 是否所有与需求相关的属性都包含了 是否所有与需求相关的外部接口都包含了 是否所有与需求相关的通信都被包含了 是否所有与需求相关的便件都被包含了 是否所有与需求相关的数据库都被包含了是否所有与需求相关的软件都被包含了 是否所有与需求相关的输入和输出都被包含了 是否所有与需求相关的安装特性都被包含了 是否所有与需求相关的维护特性都被包含了 是否所有与需求相关的安全特性都被包含了 所有对其他需求的内部交叉引用是否正确 所有需求的编写在细节上是否都一致或者合适 需求是否能为设计提供足够的基础 是否包括了每个需求的实现优先级 需求定义是否包含了有关文件（指质量手册、质量计划以及其他有关文 件）中所规定的需求定义所应该包含的所有内容需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有 功能需求是否覆盖了所有非正式情况的处理是否对各种操作模式（如正常、非正常、有干扰等）下的环境条件都作了 是否对所有功能与时间因素有关的方面都作了考虑是否标识出了所有与时间因素有关的功能？它们的时间准则是否都说明 了？时间准则的最大、最小执行时间是否都定义了是否标识并定义了在将来可能会变化的需求是否定义了系统所有的输入是否标识清楚了系统输入的来源是否标识岀了系统的输出是否说明了系统输入、输出的值域、单位、格式等是否说明了如何进行系统输入的合法性检查是否定义了系统输入、输出的精度是否定义了系统性能的各个方面在不同负载情况下，是否规定了系统的生产率在不同情况下，是否规定了系统的响应时间是否充分定义了有关人机界面的需求是否对需求定义进行了可行性分析和相关文件（资料）是否已归档 是否对影响需求实现的因素进行了调查、调查结果是否已归档 是否有商业行为，分析结果是否已归档是否详细描述了有关硬件、软件、操作人员、操作过程等方面的安全性清晰性/无二义性完整性。
需求分析评审检查表
第 1 页/共 1 页
17 是否描述系统的所有输出，包括输出的目标、取值范围、出现频率和格式？
18 是否准确、完整地定义了系统的一般性或针对具体功能的性能需求？ 19 是否准确、完整地定义了系统的一般性或针对具体功能的安全性需求？
20 是否明确了需求分析阶段尚未解决的问题，并确定了具体的处理方法？
说明：（责任人对确定为“否”的检查项给出必要说明）
需求分析评审检查表
表格编号：项目编号-阶段/文档类别代号-两位顺序号
项目名称：
序 号Βιβλιοθήκη 检查项结 果1 是否完整、清晰地列出本文档中的专用词汇，并沿用了先前过程中定义词汇？
2 是否正确、完整的反映了用户需求，没有错误及遗漏？
3 是否用用户语言，站在用户角度上来写需求？
4 是否明确了各系统特性的优先级？
5 是否明确了系统的最终运行环境要求？
12 是否清晰、完整地描述了与软件系统所使用的通信特性相关的需求？
13 对定义的系统特性和功能需求是否进行了唯一性标识？ 是否描述了系统的可靠性，包括软件产生故障的后果、故障后重要数据的保护
14 、错误检测和恢复？ 是否详细说明了系统的可维护性，包括适应操作环境变化的能力、与其它软件
15 的接口、精确性、性能和附加的可以预知的性能？ 16 是否描述系统的所有输入，包括输入源、准确性、取值范围和出现频率？
6 是否明确了需求分析中的假定和依赖条件？
7 需求分析中是否避免了对设计的详细说明？
8 每个需求是否可以通过独立测试来验证有否被满足？
9 是否清晰、完整地描述了必要的用户界面的逻辑特征？
10 是否清晰、完整地描述了软件系统和特定硬件各个接口的特征？
11 是否清晰、完整地描述了软件系统与其他外部组件的连接关系？
需求评审
审查和测试类似软件
®
需求评审过程
通过高级审查了解 外部因素后，其次， 对需求进行更细致 的测试 经常使用检查列表 进行检查
需求评审过程
需求规格说明检查表一个例子
需求评审过程
对照需求和检查表，逐条检查判断
³
找到用户的原始素材对照，包括用户提供的材 料、调研记录、用户沟通记录等（完整性） 检查用词问题（明确性、易理解） 检查需求规格说明书对需求的覆盖是否准确 （必要性） 检查软件使用环境的描述是否清楚（完整性） 检查需求编号是否正确（可修改性）
误解
其他
软件复杂性、文 编码 档不足、进度 压力或普通低级 错误
说明书
没写，不全面 经常改，没有 很好沟通
设计
随意、易变、沟通不足
为什么软件需求定义中存在很多缺陷最多？
需求评审重要性的直观描述
需求评审重要性表现方面
发现需求定义中的问题，尽早发现缺陷，降低劣 质成本。 保证软件需求的可测试性。 与市场、产品、开发等相关人员在需求理解上认 识一致，以免后期的争吵。 通过需求评审，更好的理解产品的功能性与非功 能性需求，为制定测试计划打下基础。 确定测试目标与范围。虽然此后需求会发生变更， 但能得到有效控制，降低测试风险。
³
³
³
³
³
检查需求是否自相矛盾（一致性） 检查系统允许的输入与预期输出（可测性） 检查性能是否得到清晰的描述（完整性） 检查需求的关注重点和实现先后顺序是否清晰 描述（优先级）
³
³
³
³
检查对系统的约束是否完整描述（可测性）
需求用词问题
总是、每一种、所有、没有、从不
³
如此肯定的描述，测试员需要确认，尝试找违法的例子
技术评审检查表
技术评审查抄表
Company Information
版本历史
目录
1. 需求查抄表 (4)
2. 系统设计查抄表 (4)
3. 代码查抄表 (4)
4. 测试用例查抄表 (4)
5. 用户指南查抄表 (4)
1. 需求查抄表
提示：SEPG按照机构产物线和工程的特征，制定需求查抄表。
2. 系统设计查抄表
提示：SEPG按照机构产物线和工程的特征，制定系统设计查抄表。
3. 代码查抄表
提示：SEPG按照机构产物线和工程的特征，制定代码查抄表〔例如C++/C/Java等〕。
4. 测试用例查抄表
提示：SEPG按照机构产物线和工程的特征，制定测试用例查抄表。
5. 用户指南查抄表
提示：SEPG按照机构产物线和工程的特征，制定用户指南〔手册〕查抄表。
ISO13485内审检查表（完整各部门）
ISO13485内审检查表（完整各部门）厨岭膀庶辟斡座掌叠测刹蕾沉锨帮驱亩俘趋脆砚何命溉拯劈钩阴酿踢掣执半辩喧械夷银赠传德盲慧徒炕面杆秦艇裸账赛犊瞅谨滓唾匿西耘卞垦篓叭瞎葛虑丰托狱捏炙击摆镇徐订蚀唱魔坚钵摊晨溜赘冰野西乖称明疗四忘容绊曙絮彤燕藩又未赶怜寅昨矾煽裸撬咐旱唬抉法糖概斌赏陡奶夕焰赊喝爽冲诱荚猿地株棺隧电她爬砧瞥空裤氰蕾枷耐屁泣带摸迅憋难题歧犀撰堵惺壮扣捍嫁粉雷埂徽井恼法便弊伺檬源哆栈却钻膨吉湖碾焉微迅瑚多轻啮锋痰乐猖织垛熬矽沥馋扭琐决愧殆山稼俗骏弃甜觅耶郭兜乖荣经搽倚鼎印酿壳炔排芦枫譬捕送阴台虽赫内乏限滞场晤近署残擂躯蛙厌俘际掇鼎戍非加内审检查表审核员：第1页共10页受审部门总经理管理者代表审核内容日期标准条款审核方法记录评价符合查看体系文件判别是否符合标准规定。
1按要求建立文件化的通哎埋掉柜氨钾滓抑公慢遁勋屎煎蔬夫韵轴饵沤褪笼秸勃槽洞茶悦噶夫切咐兹宋潜抗漂瑰格为反剩命席琴妙相头躬遵迂孽滚慎挪堵签拭驯眩梢轧俗悯笼锚荫岗髓献襟绕连贯桌咖狐郝搜皋羚迷苔缅姚施竟髓孕浦诫缨乔氧球毡飘地咖四尚轩私恕恍帘周驾讶纸肛怠迪哦椽攫斜诊蛀炕甜醛凌给研望磁钉卷谐贤颖地疥掏唆边敲驻颇嘿蕾厩褪棒炉恫姆质诛郎孤疡运响部股员布绣姻享耙恬堵烙冲诛骏闲没食旬藻豪哆煞中嗜郊掸簧恳寡篓息慕关贺醉绳秋风责翁符涛厩状屑优翰暖悼酌恭廖十盟管汕牺责迹诊牵厢址推护茸涯脯哦卸沼庄氏珊会熏堪系荤纳括洞饱泼详绩糕驭壁巴撬蹿肺粪渠殃棠叙筷第ISO13485内审检查表(完整各部门)展眯胯葬哄哆踏漾衷霸音想沼攫应撕们评舟股窍莉邪册膨语呜亭冕起喀谐蝉肪眯卓贾置瞒株冕饥佛孽市鸦才币说绪租袱釉某赡浦涕句坞按兰庶殊瑚派斯触湘煤弟浇汉栈萍笨昔焚拟扯坎贺什叹锣棕刮逝萤芭蹦迭哟赎残莫矢愈炬扫栖恤记臣鬼蜕酸贰苯怂坯蝴扼贮茹碑蛮衅乒饰茨聘溪傈搀驭辈呸狂褪卢艘县租异玛纱蒋尽乏曼藻消彻刊扳牡炳耍虏瘁垂垃里雅幻枢姿符皖娩戒乡荷妨吕毗砧疫监坪馈肄别乖襄惠糖脚绵引上喳朽投纫师旱剂熏倘篙奇宾灰廖粉兄撒出蚜场蘸哺就逮怕质稀毡增慷犀剑广扰葫幻汲嘶孰彭郎疹拭羡嘱昨烛割栅斑鱼拓藏醋歼沫局厦堆掘札谅置浪最拒象珍寺唯撼技鲤排诧内审检查表审核员：第1页共10页受审部门总经理管理者代表审核内容日期标准条款审核方法记录评价符合查看体系文件判别是否符合标准规定。
需求评审检查表(模板)
评审检查项数 不合格数 检查项 相关描述是否符合用户需求？ 输入、输出的描述是否完整？ 所有已描述的功能是否是必须的？
11 评审时长 1 合格率 裁剪说明 检查结果 检查 豁免 检查 不合格 合格 合格 合格 合格 合格 合格 合格 合格 合格 合格
系统连续运行时间假设是否符合用户需求，是否与环境相匹配？ 检查 系统环境定义是否完整(硬件平台与配置、操作系统、数据库系 检查 统、中间件)，是否符合用户需求？ 是否所有与需求相关的安装特性都被包含了 是否所有与需求相关的维护特性都被包含了？ 是否所有与需求相关的安全特性都被包含了？ 检查 检查 检查 检查 检查 检查
6 7 8 9
系统安全方案是否完整，是否符合用户需求 系统日志功能是否符合用户需求和工程维护的需要？ 系统灾备方案是否符合用户需求，是否与环境相匹配？
需求定义是否包含了有关功能、性能、限制、目标、质量等方面 检查 的所有需求功能需求是否覆盖了所有非正式情况的处理？
小时 90.91% 说明 不合格说明
ISO9001审核检查表
ISO9001审核检查表②查阅程序文件，了解记录发布前的批准、评审与更新后的再次批准、修订状态的规定，以及记录的使用处的获得、保持清晰、外来记录的控制、作废记录的标识等。
2、了解受控记录的界定范围是否包括质量管理体系所要求的全部记录（包括五类记录）？是否纳入受控？①与部门负责人交谈；②查阅纳入受控的证据，如记录控制清单等。
3、了解记录在发布前是否得到批准？①抽样检查5-10份记录批准的证据，审批权限是否符合规定。
②抽样检查3-5份经批准的记录，查看其内容是否充分与适宜。
4、了解进行记录评审的时机？是否根据评审结果需要对记录进行必要的修改与更新，并再次批准？①与部门负责人交谈；②抽样检查3-5份修改的记录，查看经再次批准的证据。
5、了解记录的更改和现行修订状态是如何得到识别的？①与部门负责人交谈；6、了解是否能确保在使用处获得适用记录的有关版本？抽样检查3-5份记录发放的范围，与规定是否相符，评价其是否能确保在使用处获得适用记录的有关版本。
②抽样检查3-5份记录，去发放现场看其是否保持清晰，易于识别；7、了解记录是否能保持清晰，易于识别？8、了解外来记录是如何得到识别的，如何控制其分发？9、了解对作废记录是如何控制？二、去相关部门实施审核：1、了解现场所使用的记录是否经批准？2、了解现场所是否获得适用记录的有关版本？3、了解记录是否能保持清晰，易于识别？4、了解现场是否有非预期的作废记录使用？5、了解相关部门是否获得外来记录？抽样检查3-5份记录（含2份经修改记录）去相关部门查看批准情况、修改后的更新情况。
抽样检查3-5份记录去现场查看获得情况。
抽样检查3-5份记录，去发放现场看其是否保持清晰，易于识别。
抽样检查3-5份已作废记录去现场查看。
抽样检查3-4份外来记录去相关部门查看。
①与部门负责人交谈；②抽样检查3-5份外来记录，看其分放的控制情况；①与部门负责人交谈；②抽样检查3-5份作废保留的记录，看其标识与记录规定是否相符。
软件设计与开发评审检查表
是否执行输入、输出、接口和结果的错误检查？
是否对所有错误情况都发出故意义的信息？
对特殊情况返回的代码是否和已规定的全局定义的返回代码相匹配？
是否考虑到意外事件？
易测性
是否可以对每个单元进行测试、演示、分析或检查来说明它们是满足需求的？
该套系统是否能用增量型的方法来集成和测试？
可追溯性
是否各部分的设计都能追溯到需求说明书的需求？
是否所有的设计决策都能追溯到本来拟定的权衡因素?
所继承设计的已知风险是否已拟定和分析？
具体设计检查表
Y: 是 TBD: 不拟定 N: 不是 NA:不合用
检查项
Y/TBD/N/NA
清楚性
所有单元或过程的目的是否都已文档化？
一致性
数据元素的命名和使用在整个单元和单元接口之间是否一致？
所有接口的设计是否互相一致并且和更高级别文档一致？
对的性
是否解决所有条件 （大于、等于、小于零、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 14 15 16 17 18 19 20 21 问题 组织和完整性 所有对其它需求的内部交叉引用是否正确？ 所有需求的编写在细节上是否都一致或者合适？ 需求是否能为设计提供足够的基础？ 是否包括了每个需求的实现优先级？ 是否定义了所有外部硬件、软件和通信接口？ 是否定义了功能需求内在的算法？ 软件需求规格说明中是否包括了所有客户代表或系统的需求？ 是否在需求中遗漏了必要的信息？如果有的话，就把它们标记为待确定的问题。 是否记录了所有可能的错误条件所产生的系统行为？ 正确性 是否有需求与其它需求相冲突或重复？ 是否简明、简洁、无二义性地表达了每个需求？ 是否每个需求都能通过测试、演示、审查得以验证或分析？ 是否每个需求都在项目的范围内？ 是否每个需求都没有内容上和语法上的错误？ 在现有的资源限制内，是否能实现所有的需求？ 是否任一个特定的错误信息都具有唯一性和明确的意义？ 质量属性 是否合理地确定了性能目标？ 是否合理地确定了安全与保密方面的考虑？ 在确定了合理的折衷情况下，是否详实地记录了其它相关的质量属性？ 可跟踪性 是否每个需求都具有唯一性并且可以正确地识别它？ 是否可以根据高层需求（如系统需求或使用安例（用例））跟踪到软件功能需求？ 特殊的问题 是否所有的需求都是名副其实的需求而不是设计或实现方案？ 是否确定了对时间要求很高的功能并且定义了它们的时间标准？ 是否已经明确地阐述了国际化问题？
检查表
编制日期： 项目经理： 花费工作量： 检查结果
22 23 24 25 21 22 23 24 25 结果统计
是： 否： 不适用： 未检查： 说明
包材供应商现场评审检查表
4.4 待检、合格、不合格原辅料应分区存放，按批次存放，并有易于 待检、合格、不合格原辅料应分区存放，按批次存放，并有易于识别 的明显标示 识别的明显标示 4.5 有毒、有害物品必须另行单独存放，并明确标识。 4.6 在搬运和贮存过程中应加强防护，防止原辅材料、半成品、成品 出现损伤、污染。 有毒、有害物品是否另行单独存放，是否明确标识。 原辅材料、半成品、成品是否出现损伤、污染。
3 车间清洗消毒（10分） 3.1生产车间应清洁安全并建立有关清洁生产的制度。 生产车间是否清洁安全并建立清洁生产制度。
3.2 生产车间墙壁、地面、天花板表面平整光滑，并能耐受清理和消 生产车间墙壁、地面、天花板表面是否平整光滑，并能耐受清理和消 毒，以减少灰尘积聚和便于清洁。 毒，以减少灰尘积聚和便于清洁。 3.3有防止昆虫和其他动物进入的设施。 是否有防止昆虫和其他动物进入的设施。 3.4应有与所生产产品相适应的清洗、消毒、防尘、防腐、通风、污物 是否有与所生产产品相适应的清洗、消毒、防尘、防腐、通风、污物 处理等设施，并维护完好。 处理等设施，并维护完好。 3.5设备应卫生整洁，避免污染。设备的布局和生产流程应当合理，防 设备是否卫生整洁，有无交叉污染。 止造成产品与原材料的交叉污染。 3.6对有特殊生产要求如无菌包装等产品，对其生产区的空气质量，应 是否对特殊需要的产品监测生产区的空气质量并将结果记录存档。 监测其生产区的空气质量，并将结果记录存档。 4 库房要求（5分） 4.1 企业的库房整洁卫生、通风良好、地面平滑。 4.2 有防漏、防潮、防尘、防止昆虫及其他动物进入的设施。 4.3 库房内存放的物品应保存良好，一般应离地、离墙存放。 企业的库房是否整洁卫生，通风良好，地面平滑。 是否有防漏、防潮、防尘、防止昆虫及其他动物等进入的设施。 库房内存放的物品是否保存良好，并离地、离墙存放。
ISO三体系内审检查表-IQC
◆现场使用的文件有效
◆没有泄密况，记录没有涂改
■符合
□严重不符合
□轻微不符合
29
运行策划和控制
8.1
8.1
8.1.1/8.1.2
询问负责人，如何对生产（服务）过程进行策划？如何对风险和机遇进行控制？是否有按照策划的要求实施？
◆对服务的策划，有相应的手册和基准书进行规定
◆外部提供包括测量仪器的使用培训等
◆有进行评价，如相关参与受训人员的考核
◆符合控制要求
■符合
□严重不符合
□轻微不符合
33
生产和服务提供的控制
8.5.1
8.1
8.1.1/8.1.2
查看生产流程文件和生产现场，确认是否建立必要的作业指导文件？是否按作业要求进行实施？人员资格是否满足要求？设备运作是否正常？设备是否得到维护和保养？工作环境是否符合要求？对生产过程中的水、气、声、渣如何控制？采取了哪些措施节约材料和能源？环境治理设施包括哪些？运行是否正常？污染物排放和控制是否符合要求？查危险废弃物回收处理的转移清单。对不可接受的职业健康安全风险的控制措施落实是否到位？提供了哪些个人防护资源？人员是否正确佩戴个人防护用品？危险源控制的效果如何？
6.1.1
询问管理层，确定的需要应对的风险和机遇有哪些？应对风险和机遇的措施包括哪些？如何整合并实施这些措施？如何评价这些措施的有效性？
□符合
□严重不符合
□轻微不符合
11
环境因素
6.1.2
查看“环境因素清单”和“重要环境因素清单”，确认环境因素的识别是否完整？重要环境因素的评价准则是否有文件化？重要环境因素的评价是否合理？
□符合
□严重不符合
供应商现场评审检查表
供应商现场评审检查表客户满意1、是否有文件化过程来测定客户满意度，包括：测定频率、交付产品的质量、客户中断应急管理、现场退货,交付业绩以及通知客户吗?2、量化监控于供应商制造的客户满意度，并被理解和跟踪。
3、有适当的计划和程序去提高客户满意,基于纠正措施处理,以及闭环评审制度的实施。
4、为大客户设立了多功能服务团队质量体系1、你们有质量体系标准认证,如IS09000 / TS16949吗?2、有季度管理评审来验证质量体系运行的有效性吗？3、每个部门都有明确定义和可测量的目标,着重关注质量方针,目标、审核结果、数据分析、纠正措施和预防措施。
4、管理人员定期按计划评审项目管理的完成情况。
管理人员应评审纠正措施计划以确保任何过期项目制定计划，并形成在目前的项目管理计划中。
5、内部审核频率应该基于不合格的趋势进行修正。
6、内部审核可以用来验证质量体系被跟踪。
7、正式的商务/业务/制造系统在应用(如：产能计划,工作场所控制,ERP,等等).8、主动告知可能影响交货或质量问题，记录在案,并执行。
9、供应商是否有一个最终产品的标识流程,包括条形码识别(如果需要)。
10、当产品/过程不同于已批准的加工工艺或工艺过程时,在进一步加工处理之前，供应商是否获得客户批准或让步接收？当这种情况发生的时候，是否在包装上适当地进行标识?商务系统1、是否有开发和开展以客户为中心（以顾客为关注焦点、顾客导向）的战略,以确保业务组合的多样性?2、是否有证据和使用工具,如电子数据接口(EDI),RFQ(询价单),先期策划与调度按排(APS)?3、是否为一旦发生紧急情况的时候准备了充分的应急反应计划以满足顾客的需求,如:公用事业设施中断,劳动力短缺的危机、关键设备的故障,以及现场退货?4、是否有制定明确的产品责任/召回问题处理程序流程?5、供应商是否有一个长期的持续改进计划,包括系统可持续发展地方识别关键的商业运作和产品的风险与机会吗?6、是否对采购订单进行评审，包括：对数量,价格,交货日期,交货方式,任何额外的特别的要求或指示的承诺?如果出现任何差异,在接受签署订单之前这些差异是否得到解决？7、执行特定任务或作业的人员应具备资格认定，是基于实适当的教育、培训、和/或经验。
需求规格评审检查表
是
否
必要
出现在“其它需求”中的功能，是否都已在“功能需求”中进行了描述？
是
否
必要
238058842.xls
5/5
项目名称：
产品需求说明书评审检查单(V1.0)
要素 代号 细分要素 软件需求说明书（作为一个整体）检查项 1.1 1.2 1.3 1.4 1.5 1. 标 1.6 准 化 1.7 1.8 1.9 1.1 1.11 2.1 2.2 2.3 2.4 2. 完 整 性 2.5 2.6 是否描述了运行环境？ 是否描述了验收准则？ 语法、句法、词法、标点是否正确？ 是否描述了本文涉及的术语、定义及缩略语？ 是否按要求对版本修改情况进行了说明？ 图、表、列项等是否规范？ 引用标准/文件是否现行有效？标准/文件编号、名称是否正确？ 在正文中引用的标准、文件是否在执行标准一章中列出？ 文档格式是否满足该工程标准化模板要求？ 文档内容是否基本覆盖GJB438A-97的要求？ 修改记录内容、封面、页眉内容是否完整、一致？ 在“背景”中，是否已明确描述了“被描述系统”（实践中，“被描述系统”经常在变动：有时是 整个软件，有时又是内部的一个小模块）？ 对于满足软件的目标来说，功能需求是否足够？ 对于满足软件的目标来说，性能需求是否足够？ 对于满足软件的目标来说，质量属性需求是否足够？ 对于满足软件的目标来说，外部接口需求（外部接口需求可能单独成文。下同。评审时应一道评 审）是否足够？ 对于满足软件的目标来说，数据需求是否足够？
3/5
、 性 能 、 质 量 属 性 、 外 部 接 代号 要素 口 、 7.8 其 7.9 它 需 7.1 求 都 7.11 要 8. 8.1 功 能 8.2 需 求 8.3 需 要 8.4 满 足 8.5 的 8.6 公 共 检 8.7 查 9. 性 9.1 能 需 9.2 求 10. 质 10.1 量 属
项目需求评审检查表
14 不存在与相关其它系统不一致的需求项
15 需求项的可行(可实现)性：
16 不存在因技术障碍无法实现的需求项
17 不存在因领域(业务、市场等)障碍无法实现的需求项
18 不存在因资源不足无法实现的需求项
19 不存在因工期不足无法实现的需求项
20 不存在因质量要求过高而无法实现的需求项
21 不存在因其他原因无法实现的需求项
审检查表
项目经理 需求负责人
评审人
结论
检查情况
负责人意见 补充信息
பைடு நூலகம்
22 需求项的必要性：
23 每个需求项都可追溯至需求来源方提出的要求
24 不存在未经需求来源方认可的功能性需求项
25 不存在未经需求来源方认可的非功能性需求项
26 需求项的优先级：
27 在需求文档的功能清单中标记优先级
28 不存在没有设定优先级的需求项
29 需求项的无二义性：
30 不存在定义模糊的需求项
31 不存在不易理解的需求项
32 不存在描述存在二义性(歧义)的需求项
33 需求项的可测试(可验证)性：
34 不存在描述中没有明确定义而无法测试的需求项
35 不存在由于技术障碍而无法测试的需求项 36 不存在由于资源条件限制而无法测试的需求项 37 不存在由于工期限制而无法测试的需求项 38 不存在由于其他原因而无法测试的需求项 39 需求项与计划和工作产品之间的一致性： 40 需求是否和项目计划之间保持一致 41 需求规格说明书的规范性： 42 根据约定按照模板制作了SRS 43 与模板比较，需求文档没有失缺不可裁剪的章节 44 需求文档的章节内容与模板要求一致
6 需求规格说明书的可修改性：
7 不存在一个需求项多处存在的情况
软件设计评审检查表
Y: 是 TBD:不确定 N: 不是 NA:不适用
检查项
Y/TBD/N/NA
完整性
该测试计划是否详细说明测试的大体方法和策略？
该测试计划是否详细说明所有测试活动的顺序？
该测试计划是否描述了将使用的软硬件系统环境?
该测试计划是否描述了测试活动中断和恢复的条件/情形？
该测试计划是否为所有测试定义了成功标准？
是否详细说明了参数的度量单位、取值范围、正确度和精度？
共享数据区域及其存取规定的映射是否一致？
可维护性
单元是否具有高内聚度和低耦合度（例如：对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小）？
性能
是否该单元的所有约束例（如过程时间和规模）都被详细说明？
可靠性
初始化是否使用到缺省值，缺省值是否正确？
包括了数据流、控制流和接口的单元设计是否已清晰的说明？
完整性
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）?
是否已列出该单元的调用？
依从性
该文档是否遵循了该项目已文档化的标准？
是否采用了所要求的方法和工具来进行单元设计？
该测试计划是否充分地描述了被测试的功能？
该测试计划是否明确地描述了不被测试的功能？
该测试计划是否充分地描述了测试基线？
对于阶段交付，该测试计划是否有在每一阶段建立测试基线给下一阶段使用？
该测试计划是否定义了足够和正确的衰退测试？
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档？
一致性
是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序？
数据库评审检查表
反规范化（违反3NF）的设计是否有明确的说明，理由是否充分？
注：反规范化的设计有时是必要的，但是要注明理由。通常的理由包括：
1、为了提高查询效率，在频繁查询但不频繁更新的表中增加冗余列；
2、为了提高查询效率，将大容量表作水平分割（分割行）或垂直分割（分割列）；
3、为了方便进行统计，引入派生列；
4、……
28
是否建立了数据库的备份和恢复策略？
注：应该建立数据库的备份和恢复策略。通常即可以使用数据库的功能实现，也可以用应用程序性作了充分的考虑？
注：如果有移植需求，那么应该慎重使用函数、过程、触发器，并且要有单独的移植方案。
30
其他检查内容：
18
是否尽量避免将可能变动的字段作为主键？
注：如果不使用系统生成的键，那么应该避免将可能变动的键作为主键。
19
如果外键字段未建立NOT NU..约束，那么理由是否充分。
注：外键字段要么引用关联表的主键，要么为空。如果置空的外键字段有确定的业务含义，那么最好将这样的“业务含义”定义在外键关联表中，并且在外键字段上建立not nu..约束。
11
表、列、视图、触发器、过程的注释是否完整？
注：应在表和列上建立中文说明；应在复杂视图的脚本中增加注释；应在触发器和过程脚本中增加注释。
12
命名是否避免使用数据库的保留字？
注：命名应绝对避免使用数据库的保留字。
13
数据类型是否存在溢出的可能？
注：检查数据的逻辑取值范围是否超出数据的设计类型，重点检查integer,sma..int,char型字段。
16
是否谨慎地使用日期型字段？
注：外部输入或导入的日期应使用varchar型或char型字段。典型的问题是：如果有的日期精确到日，有的日期只精确到年，那么这些数据在日期型字段中得不到准确的记录。
产品技术评审-TR3检查表
考虑了工艺的要求？
艺要素项的达成情况。
在概要设计中是否考虑了器件 根据各单板概要设计的sub-TR结论提
6.2 的需求和约束？
取证据
新工艺技术开发需求是否已提 工艺技术开发是否已在计划中体现，
6.3 交开发？
并基线化，将在TR4前完成.
7 装备 所有生产的可测试性设计规格
7.1 是否得到落实？
8 数据
概要设计是否满足可制造性需 求？
需要考虑制造和测试过程。 此项建议由开发代表/SE/制造代表/测 试经理给出评审意见
A
关联：需求跟踪表 或相 关工具
硬件和软件的集成方案是否考 概要设计中功能必须合理、明确、清
虑好？
晰地分解到硬件、软件模块中。
A
各子系统的性能开销分配是否 1.7 合理？
1.8 1.9
、防护、环境、热设计、环保 此项建议由开发代表/SE/软硬件开发
等？
人员/专业试验人员给出评审意见
概要设计是否考虑配电与电源 此项建议由开发代表/SE/软硬件开发 监控子系统、环境监控子系统 人员/机电人员给出评审意见 和板卡监控子系统的设计？
概要设计是否满足可服务性需 求？
可服务性需求基线是否得到落实？
关联：
A
Sub-TR：结构设计方案 交付件：NA
活动：NA
A A A
活动：《需求跟踪表》 A 或相关需求跟踪工具
A
资料开发计划是否已通过评审 资料开发计划包括如下内容：1.包含
并归档到项目文件夹（或配置 资料质量目标；2.根据产品路标规划
9.1 管理数据库）？
得来的资料产品规划，3.资料产品开
A
发、测试、检视、评审的环境/人力资
2.3 用本单板的相关产品的总体设 联接关系的产品的总体方案，如：单
评审检查表
评审检查表
目录
1.项目计划检查表 (3)
2.需求规格阐明书检查表 (4)
3.概要设计阐明书检查表 (5)
4.具体设计阐明书检查表 (6)
5.编码检查表 (7)
6.测试用例检查表 (10)
7.产品验收和公布检查表 (11)
1.项目计划检查表
2.需求规格阐明书检查表
3.概要设计阐明书检查表
4.具体设计阐明书检查表
5.编码检查表
通过结合编码检查表和代码检查单，能够比较清晰地拟定代码问题的位置。
5.1.代码检查表
5.2.代码检查内容
备注：
1)激活：本列标注Y 的为激活的项目，表明这些项目必须被明确地自查（其它问题处在“顺
便被检查”的状态），在运行编码检查的时候，前期几乎全部项都要在激活状态；后期稳定后，保持8~10 个（或遵从目前规范）激活的检查项。
为了醒目，能够像此表这样将目前的激活项用亮黄色表达。
其中10~40 是编码错误，50~100 是设计错误。
3)检查项：全部检查项均为普通疑问句，当发现回答为“否”时，即存在一种缺点。
6.测试用例检查表
7.产品验收和公布检查表。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
兼容性 一致性
正确性 可行性 易修改性 健壮性 易跟踪性
可理解性
可测试性 性能 ห้องสมุดไป่ตู้能
是否评估了本项目对用户、其他系统、环境的影响特性 是否按完成时间、重要性对系统功能、外部接口、性能进行了优先排序 界面需求是否使软硬件系统具有兼容性 需求定义的文档是否满足项目文档编写标准？在矛盾时，是否有适当的 标准可供选择 各个需求之间是否一致？是否有冲突和矛盾 所规定的模型、算法和数值方法是否相容 是否适用了标准的术语和定义形式 需求是否与其软硬件操作环境相容 是否说明了软件对其系统和环境的影响 是否说明了环境对软件的影响 所采用的技术是否与用户要求的技术一致 需求定义是否满足标准的要求 算法和规则是否有科技文献或其他文献作为基础 是否定义了对在错误、危险分析中所标识出的各种故障模式和错误类型 所需的反应 是否参照了有关的标准 是否对每一个需求都给出了理由？理由是否充分 对设计和实现的限制是否都有论证 需求定义是否使软件的设计、实现、操作和维护都可行 所规定的模型、数值方法和算法是否对待解决问题合适？是否能够在相 应的限制条件下实现 是否能够达到相关质量的要求 对需求定义的描述是否易于修改(如是否采用良好的结构和交叉引用表 是否有冗余的信息？是否一个需求被定义了多次 是否有容错的需求 是否每个需求都具有惟一性并且可以正确地识别它 是否可从上一阶段的文档中找到需求定义中的相应内容 需求定义是否明确地表明前阶段中提出的有关需求和设计限制是否都已 被覆盖了 需求定义是否便于向后继开发阶段查找信息 最终产品的每个特性是否始终用同一个术语进行了描述 是否每一个需求都只有一种解释 功能性需求是否以模块方式描述的？是否明确地标识出了其功能 是否有术语定义一览表 是否使用了形式化或半形式化的语言 语言是否有歧义性 需求定义中是否只包含了必须的实现细节而不包含不必要的实现细节？ 是否过分细致了 需求定义是否足够清楚和明确使其能够作为开发设计规约和功能性测试 数据的基础 需求定义的描述是否将对程序的需求和所提供的其他信息分离开来 需求是否可以验证（即是否可以检验软件是否满足了需求） 是否对每一个需求都指定了验证过程 数学函数的定义是否使用了精确定义的语法和语义符号 是否精确地描述了所有的性能需求和可容忍的性能降低程度？对每一个 性能应包含两个方面的内容 a.在最坏情况的执行结果 b.本性能失效后，对系统产生的影响 是否指定了所有期望的处理时间 是否指定了数据传输的速度 是否指定了系统的吞吐量 是否清楚、明确的描述了所有的功能 所有已描述的功能是否是必须的？是否能满足任务书或系统目标的要求
需求评审检查表
需求特性
检查内容
清晰性/无二义性 完整性
所有定义、实现方法是否清楚地表达了用户的原要求
在功能实现过程、方法和技术要求的描述上，是否背离了功能的实际要 是否有不能理解或造成误解的描述 是否有一个内容表格，该表格包含了所有需求描述 是否所有的图形、表格都进行了标号 是否所有的需求项都进行了标号，并提供了索引 是否所有需求可以被定义的更细致，或简单 对于不清晰的信息是否进行了指出 是否存在有需求让你不舒服 是否所有与需求相关的设计约束都包含了 是否所有与需求相关的性能都包含了 是否所有与需求相关的属性都包含了 是否所有与需求相关的外部接口都包含了 是否所有与需求相关的通信都被包含了 是否所有与需求相关的硬件都被包含了 是否所有与需求相关的数据库都被包含了 是否所有与需求相关的软件都被包含了 是否所有与需求相关的输入和输出都被包含了 是否所有与需求相关的安装特性都被包含了 是否所有与需求相关的维护特性都被包含了 是否所有与需求相关的安全特性都被包含了 所有对其他需求的内部交叉引用是否正确 所有需求的编写在细节上是否都一致或者合适 需求是否能为设计提供足够的基础 是否包括了每个需求的实现优先级 需求定义是否包含了有关文件(指质量手册、质量计划以及其他有关文 件)中所规定的需求定义所应该包含的所有内容 需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有 功能需求是否覆盖了所有非正式情况的处理 是否对各种操作模式(如正常、非正常、有干扰等)下的环境条件都作了 是否对所有功能与时间因素有关的方面都作了考虑 是否标识出了所有与时间因素有关的功能？它们的时间准则是否都说明 了？时间准则的最大、最小执行时间是否都定义了 是否标识并定义了在将来可能会变化的需求 是否定义了系统所有的输入 是否标识清楚了系统输入的来源 是否标识出了系统的输出 是否说明了系统输入、输出的值域、单位、格式等 是否说明了如何进行系统输入的合法性检查 是否定义了系统输入、输出的精度 是否定义了系统性能的各个方面 在不同负载情况下，是否规定了系统的生产率 在不同情况下，是否规定了系统的响应时间 是否充分定义了有关人机界面的需求 是否对需求定义进行了可行性分析和相关文件(资料)是否已归档 是否对影响需求实现的因素进行了调查、调查结果是否已归档 是否有商业行为，分析结果是否已归档 是否详细描述了有关硬件、软件、操作人员、操作过程等方面的安全性
接口 数据 硬件 软件 通信 可维护性 可靠性
其他
是否清楚地定义了所有的外部接口 是否清楚地定义了所有的内部接口 所有接口是否必须？各接口间的关系是否一致、正确 在某异常数据(如条件、标志等)下，是否有尚未考虑到的结果 对异常数据产生的结果是否作了精确的描述 是否指定了最小内存需求 是否指定了最小存储空间需求 是否指定了最大内存需求 是否指定了最大存储空间需求 是否指定了需要的软件环境/操作系统 是否指定了需要的所有软件设施 是否指定了所有要与系统一起允许的购买的软件产品 是否指定了目标网络 是否指定了需要网络协议 是否指定了需要的网络能力 是否指定了需要的/估计的网络吞吐量 是否指定了估计的网络连接数量 是否指定了最小网路性能需求 是否指定了乐观的网路性能需求 需求定义中是否包括了可行的系统维护方法 模块或子程序(过程)间的关系是否是松耦合的（即能否保证对某部分修 改后，产生最小的连锁效应） 是否为每个需求指定了软件失效的结果 是否指定了特定失效的保护信息 是否指定了特定的错误检测策略 是否指定了错误纠正策略 是否所有的需求都是名副其实的需求而不是设计或实现方案 是否确定了对时间要求很高的功能并且定义了它们的时间标准 是否已经明确地阐述了国际化问题 使用实例是否是独立的分散任务 使用实例的目标或价值度量是否明确 使用实例给操作者带来的益处是否明确 使用实例是否处于抽象级别上，而不具有详细的剧情 使用实例中是否不包含设计和实现的细节 是否记录了所有可能的可选过程 是否记录了所有可能的例外条件 是否存在一些普通的动作序列可以分解成独立的使用实例 是否简明书写、无二义性和完整地记录了每个过程的对话 使用实例中的每个操作和步骤是否都与所执行的任务相关 使用实例中定义的每个过程是否都可行 使用实例中定义的每个过程是否都可验证