需求评审检查表
软件项目需求评审检查表-模板
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 结果统计
是： 否： 不适用： 未检查： 说明
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
兼容性 一致性
正确性 可行性 易修改性 健壮性 易跟踪性
可理解性
可测试性 性能 ห้องสมุดไป่ตู้能
是否评估了本项目对用户、其他系统、环境的影响特性 是否按完成时间、重要性对系统功能、外部接口、性能进行了优先排序 界面需求是否使软硬件系统具有兼容性 需求定义的文档是否满足项目文档编写标准？在矛盾时，是否有适当的 标准可供选择 各个需求之间是否一致？是否有冲突和矛盾 所规定的模型、算法和数值方法是否相容 是否适用了标准的术语和定义形式 需求是否与其软硬件操作环境相容 是否说明了软件对其系统和环境的影响 是否说明了环境对软件的影响 所采用的技术是否与用户要求的技术一致 需求定义是否满足标准的要求 算法和规则是否有科技文献或其他文献作为基础 是否定义了对在错误、危险分析中所标识出的各种故障模式和错误类型 所需的反应 是否参照了有关的标准 是否对每一个需求都给出了理由？理由是否充分 对设计和实现的限制是否都有论证 需求定义是否使软件的设计、实现、操作和维护都可行 所规定的模型、数值方法和算法是否对待解决问题合适？是否能够在相 应的限制条件下实现 是否能够达到相关质量的要求 对需求定义的描述是否易于修改(如是否采用良好的结构和交叉引用表 是否有冗余的信息？是否一个需求被定义了多次 是否有容错的需求 是否每个需求都具有惟一性并且可以正确地识别它 是否可从上一阶段的文档中找到需求定义中的相应内容 需求定义是否明确地表明前阶段中提出的有关需求和设计限制是否都已 被覆盖了 需求定义是否便于向后继开发阶段查找信息 最终产品的每个特性是否始终用同一个术语进行了描述 是否每一个需求都只有一种解释 功能性需求是否以模块方式描述的？是否明确地标识出了其功能 是否有术语定义一览表 是否使用了形式化或半形式化的语言 语言是否有歧义性 需求定义中是否只包含了必须的实现细节而不包含不必要的实现细节？ 是否过分细致了 需求定义是否足够清楚和明确使其能够作为开发设计规约和功能性测试 数据的基础 需求定义的描述是否将对程序的需求和所提供的其他信息分离开来 需求是否可以验证（即是否可以检验软件是否满足了需求） 是否对每一个需求都指定了验证过程 数学函数的定义是否使用了精确定义的语法和语义符号 是否精确地描述了所有的性能需求和可容忍的性能降低程度？对每一个 性能应包含两个方面的内容 a.在最坏情况的执行结果 b.本性能失效后，对系统产生的影响 是否指定了所有期望的处理时间 是否指定了数据传输的速度 是否指定了系统的吞吐量 是否清楚、明确的描述了所有的功能 所有已描述的功能是否是必须的？是否能满足任务书或系统目标的要求
需求评审检查表
需求特性
检查内容
清晰性/无二义性 完整性
所有定义、实现方法是否清楚地表达了用户的原要求
在功能实现过程、方法和技术要求的描述上，是否背离了功能的实际要 是否有不能理解或造成误解的描述 是否有一个内容表格，该表格包含了所有需求描述 是否所有的图形、表格都进行了标号 是否所有的需求项都进行了标号，并提供了索引 是否所有需求可以被定义的更细致，或简单 对于不清晰的信息是否进行了指出 是否存在有需求让你不舒服 是否所有与需求相关的设计约束都包含了 是否所有与需求相关的性能都包含了 是否所有与需求相关的属性都包含了 是否所有与需求相关的外部接口都包含了 是否所有与需求相关的通信都被包含了 是否所有与需求相关的硬件都被包含了 是否所有与需求相关的数据库都被包含了 是否所有与需求相关的软件都被包含了 是否所有与需求相关的输入和输出都被包含了 是否所有与需求相关的安装特性都被包含了 是否所有与需求相关的维护特性都被包含了 是否所有与需求相关的安全特性都被包含了 所有对其他需求的内部交叉引用是否正确 所有需求的编写在细节上是否都一致或者合适 需求是否能为设计提供足够的基础 是否包括了每个需求的实现优先级 需求定义是否包含了有关文件(指质量手册、质量计划以及其他有关文 件)中所规定的需求定义所应该包含的所有内容 需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有 功能需求是否覆盖了所有非正式情况的处理 是否对各种操作模式(如正常、非正常、有干扰等)下的环境条件都作了 是否对所有功能与时间因素有关的方面都作了考虑 是否标识出了所有与时间因素有关的功能？它们的时间准则是否都说明 了？时间准则的最大、最小执行时间是否都定义了 是否标识并定义了在将来可能会变化的需求 是否定义了系统所有的输入 是否标识清楚了系统输入的来源 是否标识出了系统的输出 是否说明了系统输入、输出的值域、单位、格式等 是否说明了如何进行系统输入的合法性检查 是否定义了系统输入、输出的精度 是否定义了系统性能的各个方面 在不同负载情况下，是否规定了系统的生产率 在不同情况下，是否规定了系统的响应时间 是否充分定义了有关人机界面的需求 是否对需求定义进行了可行性分析和相关文件(资料)是否已归档 是否对影响需求实现的因素进行了调查、调查结果是否已归档 是否有商业行为，分析结果是否已归档 是否详细描述了有关硬件、软件、操作人员、操作过程等方面的安全性
接口 数据 硬件 软件 通信 可维护性 可靠性
其他
是否清楚地定义了所有的外部接口 是否清楚地定义了所有的内部接口 所有接口是否必须？各接口间的关系是否一致、正确 在某异常数据(如条件、标志等)下，是否有尚未考虑到的结果 对异常数据产生的结果是否作了精确的描述 是否指定了最小内存需求 是否指定了最小存储空间需求 是否指定了最大内存需求 是否指定了最大存储空间需求 是否指定了需要的软件环境/操作系统 是否指定了需要的所有软件设施 是否指定了所有要与系统一起允许的购买的软件产品 是否指定了目标网络 是否指定了需要网络协议 是否指定了需要的网络能力 是否指定了需要的/估计的网络吞吐量 是否指定了估计的网络连接数量 是否指定了最小网路性能需求 是否指定了乐观的网路性能需求 需求定义中是否包括了可行的系统维护方法 模块或子程序(过程)间的关系是否是松耦合的（即能否保证对某部分修 改后，产生最小的连锁效应） 是否为每个需求指定了软件失效的结果 是否指定了特定失效的保护信息 是否指定了特定的错误检测策略 是否指定了错误纠正策略 是否所有的需求都是名副其实的需求而不是设计或实现方案 是否确定了对时间要求很高的功能并且定义了它们的时间标准 是否已经明确地阐述了国际化问题 使用实例是否是独立的分散任务 使用实例的目标或价值度量是否明确 使用实例给操作者带来的益处是否明确 使用实例是否处于抽象级别上，而不具有详细的剧情 使用实例中是否不包含设计和实现的细节 是否记录了所有可能的可选过程 是否记录了所有可能的例外条件 是否存在一些普通的动作序列可以分解成独立的使用实例 是否简明书写、无二义性和完整地记录了每个过程的对话 使用实例中的每个操作和步骤是否都与所执行的任务相关 使用实例中定义的每个过程是否都可行 使用实例中定义的每个过程是否都可验证