软件项目评审记录表-模板
软件需求规格说明书的评审检查单
软件需求规格阐明书旳评审检查单软件需求评审，作为一种软件产品验证旳活动之一，通过及早地从软件产品中辨认并消除缺陷，从而减少后期旳返工，加快开发进度，提高产品旳质量。
在需求阶段，发现一种需求缺陷旳价值是多大呢？业内有个缺陷修复成本比例，需求阶段：设计阶段：测试阶段：上市阶段＝N:10N:100N:1000N；方案一一、注意对需求规格阐明旳对旳性进行评审需求规格阐明旳对旳性一般可以从如下方面得以体现：1 与否有需求与其他需求互相冲突或者反复？2 与否清晰、简洁、无二义地体现了每个需求?“清晰”是让人可以读懂；“简洁”是让人乐意去读；“无二义”决定”读”旳效果,是让大家对需求描述旳理解可以达到一致。
3 与否每个需求都通过了演示、测试、评审，分析与否得到了验证?4 与否每个需求都在项目旳范畴内?5 与否每个需求都没有内容和语法上旳错误?6 在既有旳资源内, 与否能实现所有旳需求?7 每一条特定旳错误信息，与否都是唯一旳和具有含义旳?二、注意对需求规格阐明旳实践性进行评审所谓实践性是指需求自身与否来源于目前公司旳有关业务规则和文献制度,而非源于分析师们经验主义旳臆测。
实践性是判断需求规格阐明是不是理论联系实践、密切和顾客联系旳一种核心性指标。
三、注意对需求规格阐明旳完整性进行评审我们常常由下面旳问题清单来评审需求阐明书与否”完整” 。
1 编写旳所有需求，其具体限度与否一致和合适?2 需求与否能为设计提供足够旳基础?3 所有对其他需求旳内部引用与否对旳?4 与否涉及了每个需求旳实现优先级?5 与否认义了功能阐明旳内在算法?6 与否涉及了所有已知旳客户需求或系统需求?7 与否漏掉了必要旳信息?如果有漏掉旳话,把他们标记为待拟定旳问题(TBD) ?8 与否对所有预期旳错误条件所产生旳系统行为都编制了文档?需求阐明旳完整性重要体目前需求阐明旳具体限度上，我们如何判断该需求旳描述与否具体呢?我觉得需求需要精化，而不是仅仅提出精化功能、对象要考虑涉众参与者、做些什么、需要什么数据信息、受什么业务规则和条件限制、系统会有什么响应，等等。
互联网软件项目评审表
5
6
7
界面元素
界面元素的一致 窗口、菜单、图标、按钮
性
等元素的一致性
10
技术运用的合理 各种技术表现与具体内容
技术运用
性； 内容实现的正确
有机结合，各种媒体使用 协调；多媒体信息呈现可208 功能要求
性
控；连接准确、无死链。
1.软件的易用性，不让用
第一反应原则； 户无法理解
交互性要求 引导原则；
2.必须有完整的提示、指
主审人 评审人
评审人 评审人
15
A
B
16
17
18
19
20
21 评审会议记录
22
23
C
D
E
F
G
24 25 26
记录人签名 27
评委表决记录 无条件通过 28
结论方式记录 一致决定 29 30 31 32 评审整改意见 33 34 35
日期
有条件通 过
过半数表决决定 评审负责人
不予通 过
裁决决定
A 1
B
C
D
E
F
G
项目评审表
项目名称 2
评审项目 3
评审细项
策划人
评审指标 （评审要点）
指标说明 （评审要点说明）
最高分 值
分值
相对完整的完成软件需求
产品内容 产品内容 内容的完整性 功能；有明确的使用者定
10
位 4
5
界面布局
界面布局的合理 性
布局合理，层次清晰
5
界面
界面美观 界面美观设计 界面美观
25
互动性原则
导性语言，让用户容易操
9
作
软件质量问题跟踪记录表模板
确定解决问题措施
确定解决问题措施
第一次检杳日期
质量人员检杳的日期
第一次跟踪缺陷的实际检杳日期
第二次解决人
对存在的问题进行修正人
检杳后对问题确定修改人
第二次预计解决日期
确定解决问题的日期
确定解决问题的日期
第二次解决措施
确定解决问题措施
确定解决问题措施
第一次检杳日期
质量人员检杳的日期
第三次跟踪缺陷的实际检查日期
2、一般：活动已经进行/工作产品已经存在，但其中部分内容不符合要求；
3、严重：活动完全没有进行或工作产品完全没有；检杳点前应该执行的过 程没有执行，比如已经到测试阶段，但测试用例评审没有进行;后补或伪造；能引发客户投诉或产生重大质量问题；
问题描述
简要描述问题
检杳后填与，对不合格项简要说明问题
第一次解决人
提升后结果
上报提升后的结果描述
对上报缺陷的审核，对结果描述。上报的原则参照过程与产品质量保证规范
质量人员
执行检查的人员
检杳后填与，质量人员姓名
检验项编号
检验项在质量检查表中的编号
根据过程任务名称从质量检杳表中复制并且不能修改
检验项
用来衡量检查对象的标准
检杳类型
有审核，监察
从检杳表中复制并且不能修改，检杳后必须选择审核，或者监察
负责人
该项检验项的主要负责人或作者
检杳前填写，项目或活动成员的姓名
缺陷严重性
该缺陷的严重性
分为三个等级。
1、轻微：对质量、进度、成本等项目因素产生轻微影响；
第
次 解 决
措 施
第
次 检 查 日 期
第二次缺陷关闭状态
质量管理体系软件及系统集成全条款审核记录【最新范本模板】
组织通过网络下发文件、行政例会、宣传栏等形式进行内部沟通，外部沟通主要是通过网络、电话、合同文本等进行沟通，从对组织的审核来看，组织内外部沟通较顺畅。
7.5。1形成文件的信息（总则)
组织有受控文件清单
清单中包括质量管理手册、软件设计开发和系统集成规范等-—个文件
7。5.2创建和更新
查文件的制定人、审核、编号、版本等。
制定了集成、开发流程图,形成了软件开发作业指导书等文件，规定了相关的责任和权限，配备了必要的人力、基础设施，财力方面的资源，识别了相关方、顾客的需求、各个过程之间的相互关系，确定了风险和机遇，并制定了应对措施。
组织利用质量目标完成情况、审核结果、数据分析、纠正和控制风险以及管理评审等来评价过程能力。
7.1。1资源(总则）
组织生产办公面积达10发.
现有员工xx人，基本能满足产品系统集成服务、软件研发的需求。
7。1。2人员
组织现有人员xx人。设立岗位包括研发、测试岗位等，人力资源配置能满足软件开发要求.
7。1。3基础设施
组织有固定资产台账，台账中包括电脑、电话等基础设施。部门领导介绍：公司制定有电脑使用制度，对于研发用的电脑等设备,为避免病毒的侵袭，公司规定由使用人员定期对电脑进行杀毒。
组织制定有各部门工作人员任职要求
要求中对各岗位人员的能力进行了规定
查岗位人员的能力情况
有人员能力评价记录
人员：xxx 岗位：研发部经理
确认结论：符合岗位任职要求
人员：xxx 岗位：技术员
确认结论:符合岗位任职要求
人员：xxx 岗位：销售部经理
确认结论:符合岗位任职要求
部门领导介绍：为提高员工的能力,公司每年制定培训计划，对相关人员进行培训
xxx_软件项目全过程进度跟踪表(模板).xls
名称
1
1.1 1.1.1 1.1.2 1.1.3
1.1.4 1.1.5
1.1.5.1 1.1.5.2
1.1.5.3
1.1.5.4
1.1.5.5 1.1.6
1.1.7 1.1.8
1.1.9 1.1.10 1.1.10.1 1.1.10.2 1.1.10.3
1.1.10.4 1.1.11
1.2 1.2.1 1.2.1.1
11项目其他活动工作量统计项目周例会项目周例会1项目周例会2项目周例会3项目周例会4项目周例会5项目周例会6项目周例会7项目周例会8项目周例会9项目周例会10项目周例会11项目周例会12项目周例会13项目周例会14项目周例会15项目周例会15项目周例会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项目周例会43项目周例会44项目周例会45项目周例会46项目周例会47项目周例会48项目周例会49周期性审计周期性审计1周期性审计2周期性审计3周期性审计4周期性审计5周期性审计6周期性审计7周期性审计8周期性审计9周期性审计10周期性审计11周期性审计12周期性审计13周期性审计14周期性审计15周期性审计16周期性审计17周期性审计18周期性审计19周期性审计20周期性审计21周期性审计22每周1对上周度量数据收集50周项目管理编写项目人员记录表变更控制表编写项目风险管理监控表决策分析会议设计阶段需求跟踪实现阶段需求跟踪测试阶段需求跟踪发布阶段需求跟踪每周项目跟踪50周日常配置管理编写基线变更表编写配置管理备份记录每周日常配置库维护50周培训oracle配置优化jquery培训非计划工作量项目管理需求变更处理配置管理基线变更处理评审审计返工工作量工作量评审项目章程项目管理手册需求汇总表需求规格说明书项目估算表项目进度表项目集成计划概要数据库设计第一里程碑第二里程碑5
研发项目结项评审表
研发项目结项评审表文件编码：CSDP定制软件项目开发平台项目管理计划变更履历目录1文档介绍 (3)1.1 文档目的 (3)1.2 文档范围 (3)1.3 读者对象 (3)1.4 参考文献 (3)1.5 术语与缩写解释 (3)2项目介绍 (4)2.1 项目说明 (4)2.2 项目目标和内容 (4)2.3 项目环境资源要求说明 (5)2.3.1 项目开发环境要求 (5)2.3.2 项目测试环境要求 (5)2.4 注意事项 (5)3项目过程定义 (7)3.1 项目类型 (7)3.2 项目过程定义 (7)4项目主要里程碑 (9)5人力资源计划 (10)5.1 项目组织结构 (10)5.2 项目人员情况 (11)6培训计划 (12)6.1 项目需要的技能一览表 (12)7项目跟踪管理计划 (13)8成本预算 (13)9提交的工作产品清单 (14)10方法与工具 (15)11附属计划 (16)12附录干系人介入规约 (17)1文档介绍1.1文档目的介绍“定制软件项目开发平台”（以下简称“开发平台”项目）的基本情况，制定项目的主要里程碑和总体项目计划，并定义和裁减本项目的管理过程和环节。
通过本项目管理计划，指导民政平台项目研发和过程监管，让项目组成员了解项目总体安排，保证项目各项工作有序进行。
1.2文档范围开发平台项目管理计划的主要内容包括：项目介绍、项目过程定义、项目主要里程碑、人力资源计划、项目跟踪管理计划、提交的工作产品清单、开发方法与工具等。
1.3读者对象项目组成员（包括项目经理、开发人员、测试人员、配置管理人员等）、项目监管部、项目干系人、公司领导等。
1.4参考文献1.5术语与缩写解释2.1项目说明开发平台是通用的电子政务登记、审批类软件项目开发平台，提高应用软件的开发效率，逐步将业务实现由研发向实施转移，使定制类项目研发更注重产品平台的功能，实施更注重业务的配置实现，从而实现定制类项目产品化，业务配置化，分工精细化。
需求分析及评审模板
需求分析及评审模板（总页）-本页仅作为文档封面，使用时请直接删除即可--内页可以根据需求调整合适字体及大小-需求分析沈阳网络通信股份有限公司（版权所有，翻版必究）文件修改控制目录1.目的2.适用范围3.职责开发部门开发体系决策层SMG4.术语和缩略语5.工作程序5.1《需求分析报告》的编制5.2《需求分析报告》的评审5.3《需求分析报告》的更改6.引用文件NP601100《配置管理》NW503101《需求分析报告编写规范》7.质量记录7.1 NR503100A “需求分析报告评审记录1.目的保证本公司开发的软件产品和软件项LI的需求分析活动在受控状态下进行。
在进行软件开发前，明确其应达到的U标，对系统LI标做出完整、准确、清晰、具体的要求。
2.适用范围适用于所有软件项LI和/或软件产品。
3.职责软件研发部门：负责编制《需求分析报告》，并参加评审。
3.2 开发体系决策层SMG：负责参加评审重大项目的《需求分析报告》，并批准相应的评审结果。
4.术语和缩略语SMG ( Senior Manager Group ):开发体系决策层软件项目：指根据合同需求开发的软件。
也可以称为合同软件。
软件产品：公司根据市场的调研、预测等结果而自行开发的软件。
PM (Project Manager):项经理。
5.工作程序《需求分析报告》的编制需求分析文档可山开发人员编制。
软件项LI经理SPM或其指定人员根据调研结果，编制该项U的需求分析文档即《需求分析报告》和/或《软件功能规格说明书》，必要时可邀请客户派人员参加编制工作。
《需求分析报告》的内容以满足客户要求或系统所要实现的功能和性能要求为准，同时还要满足本公司NW503101《需求分析报告编写规范》或《开发计划》中明确的标准与规程的要求，如有明确的法律、法规、行业标准等规定时，《需求分析报告》必须遵守相应规定。
若客户已提供《需求分析报告》或具有同等作用的文档，则本公司无须进行《需求分析报告》的编制。
需求规格评审检查表
是
否
必要
出现在“其它需求”中的功能，是否都已在“功能需求”中进行了描述？
是
否
必要
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 量 属
软件过程检查表
1.过程检查要素表2.过程打分2.1.过程打分原则：1)过程打分占整个项目得分的30％，以30分为满分，最低分不低于9分。
2)不同的项目可以从标准软件过程中剪裁得到项目定义过程，因此各项目包含的软件过程是不同的，为了使软件过程数目不同的项目，仍以合理的方式进行过程打分，需对剪裁后的软件过程数目进行换算，从而不因剪裁而失分。
3)SQA人员对经剪裁的软件过程的检查内容和实施情况进行剪裁。
4)项目级的软件过程剪裁必须得到高级经理，质量管理部经理和项目SQA人员的检查和认可；检查内容和实施情况剪裁必须得到项目经理和受审计人员的认可。
5)软件过程检查打分的依据是“过程检查表”。
2.2.打分步骤：1)依据标准过程定义项目过程，得出项目过程数N。
2)每个项目过程的得分M＝30 / N。
3)采用“过程检查表”，对各个过程进行检查和打分。
4)定义“过程检查表”中的实际检查内容项个数为X，每项标准得分10分，因此每个“过程检查表”的最高得分A = 10X。
5)实际检查时，对“实施情况”一栏中每个条款进行打勾“”,因此实际每项得分Bj=（打勾条款数/ 该项实际检查总条款数）×10。
6)每个过程的实际得分Bi=∑1x Bj。
7)每个过程的换算得分B=Bi /A ×M。
8)若某个过程发生多次z，则该过程得分B=(∑1zB)/z 。
9)项目的过程得分C=∑1NB 。
10)为确保项目组的基本得分不低于9分，因此各过程打分不得低于9/N分，低于此分，以9/N分计算。
2.3.例子：某项目计划进行5个阶段的审计：计划过程，需求过程，设计过程，测试过程，计划跟踪和监督过程，其中计划跟踪和监督过程执行两次，其他各一次则每阶段得分M=30/5=6;第一次计划跟踪和监督过程检查项共15项，实际由于变更未发生检查了13项, 标准分为A=13×10＝130，实际检查得分Bi=123则该阶段得分B1=123/130 * 6=第二次计划跟踪和监督过程，实际检查了15项，标准分为15×10＝150；实际检查得分140。
测试评审模板
表：编号：
项目名称
xxx
项目编号
WDGeneral Office
验证会日期
20xx-06-26
地 点
公司大会议室
组 长
xx
职 务
验证内容
/验证方法
根据软件的《测试报告》、《测试用例》、《错误跟踪表》、《变更控制表》，对测试用例和结果进行分析，验证系统的设计和开发是否达到了预期的目的。
申请人（签字）：xx20xx年06月27日
参加人员
签 到
xx、xx、xx
验证会记录
与会人员针对系统的每个测试用例和结果均进行了一一审核，并对之前出现的功能和性能问题以及建议性问题进行了核实。
会议记录（签字）：xx20xx年06月27日
存在问题
不存在明显问题。
验证组长（签字）：xx20达到了需求的目的。
决议: 通过 □解决以上问题后通过□解决以上问题后于 年 月 日再次验证
验证组长（签字）：xx20xx年06月27日
措施跟踪
不存在问题，故没有措施跟踪。
SQA跟踪（签字）：xx20xx年06月27日
验证组长审阅（签字）：左俊鑫20xx年06月27日
软件验收报告模板
密级：内部保密文件仅限内部使用验收报告模板（V1.0）文档编号：文档名称：编写：编写日期：审核：审核日期：批准：批准日期：用户名称密级：<项目名称>验收报告（版本号）文档编号：项目名称：编写：编写日期：审核：审核日期：批准：批准日期：文档修订记录目录第一章项目概述 (5)1.1 项目背景 (5)1.2 参考资料 (5)第二章验收定义 (5)2.1 验收方式 (5)2.2 验收依据 (6)2.3 验收环境 (6)2.4 验收标准 (6)2.4.1 系统功能标准 (6)2.4.2 性能标准 (7)2.5 验收范围 (7)2.6 验收人员 (7)2.7 验收时间 (7)第三章遗留问题 (8)第四章交付物清单 (8)4.1 文档提交清单 (8)4.2 源码提交清单 (8)第五章验收结论 (8)第六章双方签字 (8)附件: (9)【原则上，验收报告应由客户方起草，双方有关人员签字，此时验收报告的格式主要由客户方选定；当然，也可接受用户方委托，由项目经理起草验收报告，经用户方签字盖章认可。
】第一章项目概述【说明】简述项目的背景及开发过程。
1.1 项目背景1.2 参考资料编写本验收报告时主要参考了如下的资料和文献：1.《XXXXXX系统合同书（主合同）》2.《XXXXXX系统软件开发合同书》3.《XXXXXX系统合同书附件五: 工作说明书》4.《XXXXXX系统需求分析说明书》5.《XXXXXX系统总体设计说明书》6.《XXXXXX系统详细设计说明书》7.《ISO9000质量体系文件》8.《XXXXXX系统柜员操作手册》第二章验收定义2.1 验收方式【说明】写明是仅与客户双方还是邀请了第三方参加，主持人及主要参加者。
2.2 验收依据《XXX系统合同书（主合同）》《XXX系统软件开发合同书》《附件五 XXX系统工作说明书》2.3 验收环境XXXXXXX综合业务系统实际运行的生产环境为验收环境。
⏹硬件平台服务器：AS/400－840系列；RS/6000－H85客户机：IBM_PC、实达、国光、长城系列终端及终端外围设备。
软件项目监理通用表
项目方案/计划报审表
说明：1、本表用于承建单位报批项目设计、实施等技术、组织方案。
本表一式三份，监理单位、承建单位、业主单位各一份。
如果项目有独立的设计单位，此表一式四份，增加设计单位意见。
2、本表应附有报审的方案/计划。
监理工程师评审意见可以以附件形式提供。
总体进度计划报审表
说明：1、本表用于承建单位报审项目进度计划，一式三份，建设单位、监理单位、承建单位各一份。
2、本表应附有报审的进度计划一份。
监理工程师的评审意见可以以附件形式提供。
工程开工/ 复工报审表
需求分析报审表
概要设计报审表
详细设计报审表
测试计划报审表
测试报告报审表
工程软件文档验收检查记录表
报验申请/ 审批表
工程验收申请/ 审批单
工程款支付申请审批表
软件文档移交清点记录表
软件产品移交清点记录表
工程竣工验收证书
监理工程师通知单
抄送：
监理工程师通知回复单
抄送：
工程变更单
项目开发计划评审表
质量保证计划评审表
需求规格说明书评审表
概要设计说明书评审表
详细设计说明书评审表
测试计划评审表。
软件技术评审
以防无休止的争论
IPD-CMM软件技术评审流程
职责：组织者2
组织者
确保Review进度得到控制
确保团队关注于 发现工作产品的问题 而非作者的问题
确保所有缺陷得到分类整理
确保Review会议上 发现问题而非解决问题
IPD-CMM软件技术评审流程
职责：组织者3
组织 者
评审表 单
？ 确保所有缺陷得以修正
使用checklist
YES
数据收集和分析
YES
产品评价决策
YES
作者 作者 由作者自己判断 Maybe Maybe NO NO NO NO
无 无 一段代码、一段文字 无 无 NO NO NO NO
软件技术评审方法
选择合适的review形式
➢基于风险考虑：交付物存在缺陷的可能性以 及如果存在缺陷的影响
Review的对象是 工作产品
而不是作者
关注于缺陷的发 现而非解决
缺陷属性有三种 “严重” “一般” “提示”
IPD-CMM软件技术评审流程
第三小时会议
组织者决定是否召开第三小时会议 会上：
大家对Review表单中未解决的问题给出决议 大家对Review表单中已确认的问题讨论解决方案 记录员进行记录 组织者更新Review表单
Review资料内容太多时， 应分成几次Review
工作产品名称 角色名字
Review会议召开的时间 Review关注点
IPD-CMM软件技术评审流程
介绍会议
Review人员向组织者提出申请 组织者裁决是否召开介绍会议 若召开则：
组织者
启动
项目准备 项目计划
...
...
键入文本 ...
软件项目监理通用表精选全文完整版
可编辑修改精选全文完整版
项目方案/计划报审表
说明：1、本表用于承建单位报批项目设计、实施等技术、组织方案。
本表一式三份，监理单位、承建单位、业主单位各一份。
如果项目有独立的设计单位，此表一式四份，增加设计单位意见。
2、本表应附有报审的方案/计划。
监理工程师评审意见可以以附件形式提供。
总体进度计划报审表
说明：1、本表用于承建单位报审项目进度计划，一式三份，建设单位、监理单位、承建单位各一份。
2、本表应附有报审的进度计划一份。
监理工程师的评审意见可以以附件形式提供。
工程开工 / 复工报审表
需求分析报审表
概要设计报审表
详细设计报审表
测试计划报审表
测试报告报审表
工程软件文档验收检查记录表
报验申请 / 审批表
工程验收申请 / 审批单
工程款支付申请审批表
软件文档移交清点记录表
软件产品移交清点记录表
工程竣工验收证书
监理工程师通知单
抄送：
监理工程师通知回复单
抄送：
工程变更单
项目开发计划评审表
质量保证计划评审表
需求规格说明书评审表
概要设计说明书评审表
详细设计说明书评审表
测试计划评审表
测试报告评审表
用户手册评审表
操作手册评审表。
ISCCCQOT0440 软件安全开发服务资质认证审核记录表
符
合
不 符 合
需 观 察
42.
测试阶段- 集成测试
E2.5.2 a）仅二级/一级要求：明确集成测 试策略，制定集成测试计划。
抽查项目，查验集成测试的测试策略、 测试计划。
43.
E2.5.2 b）仅二级/一级要求：依据概要设 计方案和测试计划进行集成测试设计， 并执行集成测试，形成测试记录。
抽查项目，查验集成测试设计、测试 记录。
查验需求阶段控制程序文件；抽查项 目，查验需求阶段项目文档，内容应 覆盖审核条款的要求。
需求阶段项目文档包括可行性报告、 招标文件、需求分析报告等。
17.
E1.2 b）结合软件项目需求、安全需求， 与客户充分沟通，达成共识并形成记录。
抽查项目，查验与客户沟通的记录。
18.
19.
E2.2 a）仅二级/一级要求：准确识别和 综合分析软件项目在可用性、完整性、 真实性、机密性、不可否认性、可控性 和可靠性等方面的安全需求。
52.
E2.6.1仅二级/一级要求：试运行结束 后，制定系统试运行报告，并提交客户。
抽查项目，查验系统试运行报告，内 容应覆盖审核条款的要求。
53.
E3.6.1 a）仅一级要求：提供三个月以上 的试运行记录和报告。
抽查项目，查验系统试运行记录和报 告。
54.
E3.6.1 b）仅一级要求：综合软件系统试 运行状态，建立软件系统运行策略和安 全指南。
44.
E3.5.2仅一级要求：对集成测试结果进 行分析，形成分析报告。
抽查项目，查验集成测试分析报告。
45.
46.
47.
测试阶段・ 系统测试
E2.5.3a）仅二级/一级要求：制定包括系 统安全性测试在内的测试计划，并执行 系统测试，形成测试记录。