软件评审检查表-问题记录
软件项目需求评审检查表-模板
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业务规则是否均有说明
软件开发部内审检查表
软件开发部内审检查表内部审核检查表JL-HWKS-24 受审核部门软件开发部审核日期2017年9月15日审核员茆秋琪ISO9001管理体系要求条款检查内容和方法检查记录6.2质量目标与应对措施组织是否设定了质量目标？目标的内容是否符合方针的要求？目标的内容是否包括产品要求及满足产品要求的所需的内容？目标的内容是否体现了持续改进的精神？组织均已设定了质量目标。
目标的内容均已符合方针的要求。
目标的内容均已包括产品要求及满足产品要求的所需的内容。
目标的内容均已体现了持续改进的精神。
9.3管理评审询问管理评审会议是如何筹备的；查评审计划和评审记录：a评审计划和.会议通知，b.评审输入的发言文件，c.签到表，d.会议记录，e. 评审决定（输出），f. 会议决定落实的文件。
已查管理评审的相关记录，基本筹备符合ISO标准要求。
9.1.3 分析和评价如何证实质量管理体系的适宜性和有效性，并评价在何处可以持续改进质量管理体系的有效性，公司建立和保持《分析与改进管理程序》，以确定、收集和分析适当的数据和信息？证实质量管理体系的适宜性和有效性，并评价在何处可以持续改进质量管理体系的有效性，公司建立和保持《分析与改进管理程序》，以确定、收集和分析适当的数据和信息。
8.5.2产品标识对产品是否进行了标识，产品的检验状态标识是否符合规定的要求？在记录中对标示和可追溯性进行了规定。
7.1.3基础设施是否为公司的设备设施提供管理？配备了满足公司软件开发，开发的产品能够满足客户的需求，符合相关产品标准7.1.4过程运行环境是否为公司办的环境提供检查？为公司软件开发的工作环境提供检查，见相关制度7.1.5监视和测量的资源是否编制了《监视和测量控制程序》？对于计量器具的管理是否建立台账并且年度检测？编制了《监视和测量控制程序》对于计量器具的管理建立台账并且年度检测8.7不合格控制的输出公司采用那些对不合格控制的方法a)本公司采用内部审核、过程审核、工作质量的检查活动，对质量管理体系的各个过程及其派出进行有效性评价；通过对原材料检测、成品检测过程过程实现服务提供过程进行分析8.5开发和服务的控制本公司是否对开发和服务提供过程进行策划，并使其在受控条件下进行。
软件项目过程文档评审检查表
评审耗时 （小时）
是否通过 N/A,Y,N
缺陷 个数
缺陷描述
版本号：2 修订号：0
第1页 共1评审人
评审日期
评审规模 （页）
序号
1 1.1 1.2 1.3
1.4
1.5
1.6
2 2.1 2.2 2.3 2.4
检查项
过程规范 是否符合过程文件模板要求 规范中的角色是否已经定义清楚 活动中对应的角色是否正确 活动的描述是否使用了多余的形容词和 副词 规范中的模板是否用蓝色标注出来 规范中提到的模板是否和定义的模板一 致
软件质量问题跟踪记录表模板
确定解决问题措施
确定解决问题措施
第一次检杳日期
质量人员检杳的日期
第一次跟踪缺陷的实际检杳日期
第二次解决人
对存在的问题进行修正人
检杳后对问题确定修改人
第二次预计解决日期
确定解决问题的日期
确定解决问题的日期
第二次解决措施
确定解决问题措施
确定解决问题措施
第一次检杳日期
质量人员检杳的日期
第三次跟踪缺陷的实际检查日期
2、一般：活动已经进行/工作产品已经存在，但其中部分内容不符合要求；
3、严重：活动完全没有进行或工作产品完全没有；检杳点前应该执行的过 程没有执行，比如已经到测试阶段，但测试用例评审没有进行;后补或伪造；能引发客户投诉或产生重大质量问题；
问题描述
简要描述问题
检杳后填与，对不合格项简要说明问题
第一次解决人
提升后结果
上报提升后的结果描述
对上报缺陷的审核，对结果描述。上报的原则参照过程与产品质量保证规范
质量人员
执行检查的人员
检杳后填与，质量人员姓名
检验项编号
检验项在质量检查表中的编号
根据过程任务名称从质量检杳表中复制并且不能修改
检验项
用来衡量检查对象的标准
检杳类型
有审核，监察
从检杳表中复制并且不能修改，检杳后必须选择审核，或者监察
负责人
该项检验项的主要负责人或作者
检杳前填写，项目或活动成员的姓名
缺陷严重性
该缺陷的严重性
分为三个等级。
1、轻微：对质量、进度、成本等项目因素产生轻微影响；
第
次 解 决
措 施
第
次 检 查 日 期
第二次缺陷关闭状态
测试计划评审检查表
5 是否明确测试环境（软件、硬件环境）？
6 是否对选定的测试工具的相关信息进行了详细描述并且经过确认？
7 测试各阶段的人员和进度安排是否合理？ 是否确定了测试阶段存在的主要风险，制定了详细的控制措施，并已经取得部
8 门或公司领导层的支持？
9 是否明确了配置库的层次结构？
10 《配置库结构层次ຫໍສະໝຸດ 》中确定的层次结构是否完整、实用？
11 是否明确了测试过程中基准配置项变更与完善控制的界定准则？
说明：（责任人对确定为“否”的检查项给出必要说明）
第 1 页/共 1 页
测试计划评审检查表
表格编号：项目编号-阶段/文档类别代号-两位顺序号
项目名称：
序 号
检查项
结 果
1 是否明确测试目的、预期达到的目标以及本次测试的范围？
2 是否完整、清晰地列出本计划中的专用词汇，并沿用了先前过程中定义词汇？
3 是否根据确定的测试类型与测试范围明确测试所需的手段、方法？
4
是否根据软件产品或项目的实际特点，对"A"、"B"、"C"、"D"四类问题的分级 原则进行了明确、详细地描述？
软件过程检查表
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=5.67第二次计划跟踪和监督过程，实际检查了15项，标准分为15×10＝150；实际检查得分140。
软件评审检查表
在体系结构设计中，是否清晰描述了数据流、控制流与接口？ 在体系结构设计中，是否清晰描述了数据流、控制流与接口？ 在设计说明书中是否描述了所有的假设、约束、决定与依赖？ 在设计说明书中是否描述了所有的假设、 约束、 决定与依赖？ 是否定义了目标？ 是否定义了目标？ 在合适时，是否有设计是多样的、一致的？ 在合适时，是否有设计是多样的、一致的？ 功能性 对每个子模块是否都做了简要描述并概略描述了采用的算法？ 对每个子模块是否都做了简要描述并概略描述了采用的算法？ 选择的设计或算法是否满足需求？ 选择的设计或算法是否满足需求？ 接口 所有接口的描述是否与需求文档一致？ 所有接口的描述是否与需求文档一致？ 在软件各个功能模块之间的数据流是否得到了明确描述？ 在软件各个功能模块之间的数据流是否得到了明确描述？ 是否对所有的元件之间的接口都进行了定义？ 是否对所有的元件之间的接口都进行了定义？ 是否接口的定义正确、 合理？ 是否接口的定义正确、 合理？ 是否所有的外部接口定义可以追索到需求？ 是否所有的外部接口定义可以追索到需求？ 细节 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
分数
软件产品评审表
评审时间：
评审人员：评审组长（），评审成员（）
软件开发项目检查记录
软件开发项目检查记录日期：[填写日期]项目名称：[填写项目名称]1. 项目背景在软件开发过程中，进行定期的项目检查是确保项目质量和进度的关键一环。
本次软件开发项目检查记录旨在对项目进展情况进行全面梳理和评估。
2. 项目概况本项目为[填写项目名称]，旨在开发[填写项目目标]。
项目启动于[填写启动日期]，预计完成日期为[填写完成日期]。
3. 检查内容及结果3.1 进度评估项目进度是保障项目按时完成的重要指标之一。
根据本次检查，项目进度评估如下：- 需求收集阶段：已完成，达到预期目标。
- 概要设计阶段：完成进度为70%，与计划相符。
- 详细设计阶段：已完成，达到预期目标。
- 编码与单元测试阶段：完成进度为50%，稍有偏低。
- 综合测试阶段：尚未开始。
针对进度偏低的编码与单元测试阶段，需加强团队协作，提高效率，以确保后续阶段按计划进行。
3.2 质量评估项目的质量是保障软件可信度和可用性的重要保证。
根据本次检查，项目质量评估如下：- 需求规格说明书：规范明确，无明显缺陷。
- 概要设计文档：设计思路清晰，符合要求。
- 详细设计文档：设计文档完整，细节准确。
- 编码规范：编码规范符合标准，代码结构清晰。
- 单元测试：单元测试用例覆盖全面，测试结果符合预期。
在保证项目进度的前提下，建议项目团队继续加强对软件质量的控制和评估，特别是在编码与单元测试阶段加大工作量和质量监控力度。
3.3 风险评估项目进行中不可避免地存在着各种风险和不确定性因素。
根据本次检查，项目风险评估如下：- 人员流失风险：目前项目团队成员稳定，风险较低。
- 需求变更风险：需求稳定性良好，变更请求控制在可接受范围。
- 技术难题风险：目前无明显技术难题，项目进展顺利。
项目团队需要继续关注项目的风险因素，及时采取相应的风险应对措施，以确保项目的顺利进行和最终交付。
4. 下一步计划综合以上的检查结果，制定下一步的项目计划如下：- 完成编码与单元测试阶段，提高进度并保证代码质量。
软件开发工程师带班检查记录
软件开发工程师带班检查记录日期：xxxx年xx月xx日检查人员：xxx被检查人员：xxx检查项目：软件开发进度、代码质量、团队合作情况检查内容：1. 软件开发进度在本次检查中，我们对正在进行的软件开发项目进行了进度检查，主要包括任务分配、进度把控、工作记录等方面的内容。
根据现场观察和与开发人员的沟通，整个团队对于任务的拆分与分配合理，每位成员都有明确的工作职责，并按照规定的时间节点有序推进工作。
开发过程中存在的问题和障碍能够及时沟通解决，保证项目进度顺利推进。
2. 代码质量在本次检查中，我们对软件开发过程中产生的代码进行了质量检查，主要关注代码规范、注释、可维护性等方面。
经过代码审查，我们发现团队成员对于编码规范的要求较高，代码风格统一，变量命名和注释编写清晰，便于他人理解和维护。
代码中也没有出现明显的逻辑错误和潜在的安全隐患。
3. 团队合作情况在本次检查中，我们对团队成员之间的合作情况进行了观察和了解，主要包括沟通协作、知识分享、技术支持等方面。
通过与团队成员的交流，我们了解到团队内部的协作氛围良好，成员之间相互支持，及时沟通问题，分享经验和技术，共同解决开发过程中遇到的难题。
团队成员之间相互信任，形成了高效的合作机制。
总结与建议：通过本次带班检查，我们对软件开发进度、代码质量和团队合作情况进行了全面的了解。
总体来说，团队在软件开发过程中展现出了卓越的能力和合作精神，任务分配合理，工作进度把控得当，并且代码质量高，符合规范要求。
团队成员之间的合作密切，沟通畅通，共同解决问题，保证了项目的顺利进行。
针对本次检查，我们提出以下几点建议：1. 进一步加强代码质量管理，注重代码的可读性和可维护性，进一步规范变量命名和注释的编写。
2. 继续保持团队内部的良好沟通与协作，加强技术分享和知识积累，提高整个团队的技术水平。
3. 针对项目进度，实时跟踪和监控，及时发现和解决问题，确保项目按计划推进。
在今后的软件开发工作中，我们将持续关注软件开发进度、代码质量和团队合作情况，定期进行检查与改进，确保项目的高质量完成。
VDA6.3-2016版-过程审核提问检查表
P2 项目管理项目提问概述是否为项目组织确定P2.1了项目管理？是否为项目开发策划并落实了所需的资P2.2源，并且展示了变更情况？是否有项目计划，并P2.3 与顾客进行了协商确定？是否在项目中进行了P2.4 先期产品质量策划并监视其符合性？是否实施了采购活动P2.5 并监视了符合性？项目组织是否确保了P2.6 项目中的变更管理？是否确定了事态升级P2.7 过程并有效实施？P3 产品和过程开发的策划项目提问概述指定的产品和过程要P3.1求是否可用？能否依据产品和过程P3.2 要求评估了制造可行性？是否详细地策划了产P3.3品和过程开发活动？VDA6.3 2016 版过程审核提问表/检查表有关评估的最低要求-存在一个项目管理过程。
-指定了项目组织并定义了联系人。
-定义了项目组长和团队成员的职责和权限。
-项目的团队成员有组织完成他们的任务。
-项目组织满足顾客要求。
-资源策划考虑到顾客的要求，基于合同覆盖到的项目。
-确立并实现为项目成员的资源策划。
考虑了工作量。
-当变更出现 ( 日期 / 开发性能的范围⋯ ) 实施资源策划的评审及必要的调整。
该应用在由顾客或更换供方触发的变更上。
-资源策划特别考虑了关键路径。
-策划和批准了人员和设备的必要项目预算（如：测试和实验设备）。
-项目策划满足特定的顾客要求-所有内部和顾客定义的里程碑完整的合并在项目策划里。
-执行项目策划里定义的里程碑评审以检查所有执行的活动与完成成熟度的要求。
-若法定授权产品的程序特殊要求，该程序持续期包含在项目策划中。
-当项目策划变更时确保内部沟通，与顾客协调项目策划变更对顾客的影响。
-从项目策划产生的关键路径考虑关键的交付项目。
-项目策划必须包含先期产品质量策划活动。
这可能在参考来自于项目策划单列文件。
策划必须考虑原型样件和前期制作。
-项目策划必须包含产品和过程开发的详细活动。
详细的的计划参阅项目策划单列文件。
计划必须考虑原型样件和前期制作。
需求规格评审检查表
是
否
必要
出现在“其它需求”中的功能，是否都已在“功能需求”中进行了描述？
是
否
必要
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 量 属
软件设计评审检查表
Y: 是 TBD:不确定 N: 不是 NA:不适用
检查项
Y/TBD/N/NA
完整性
该测试计划是否详细说明测试的大体方法和策略？
该测试计划是否详细说明所有测试活动的顺序？
该测试计划是否描述了将使用的软硬件系统环境?
该测试计划是否描述了测试活动中断和恢复的条件/情形？
该测试计划是否为所有测试定义了成功标准？
是否详细说明了参数的度量单位、取值范围、正确度和精度？
共享数据区域及其存取规定的映射是否一致？
可维护性
单元是否具有高内聚度和低耦合度（例如：对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小）？
性能
是否该单元的所有约束例（如过程时间和规模）都被详细说明？
可靠性
初始化是否使用到缺省值，缺省值是否正确？
包括了数据流、控制流和接口的单元设计是否已清晰的说明？
完整性
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）?
是否已列出该单元的调用？
依从性
该文档是否遵循了该项目已文档化的标准？
是否采用了所要求的方法和工具来进行单元设计？
该测试计划是否充分地描述了被测试的功能？
该测试计划是否明确地描述了不被测试的功能？
该测试计划是否充分地描述了测试基线？
对于阶段交付，该测试计划是否有在每一阶段建立测试基线给下一阶段使用？
该测试计划是否定义了足够和正确的衰退测试？
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档？
一致性
是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序？
ISO9001-内审检查表(附检查记录)
根据公司产品和服务特点，确定公司的质量目标：
a、每年提交主管部分审批的成果很多于4项，并每年递增2项；
b、各研发成果交付率90%
c、相关方满意率95%以上
6.2.2筹划如何实现质量目标时，应对质量目标进行分解，需要规定：考核措施，综合管理部负责过程的监视和丈量，管理评审前组织各部分对质量目标实现情况进行检查，并在管理评审中进行汇报。
a)现有内部资源的能力和约束；
b)需要从外部供方获取的资源。
√
2.组织对资源的确定、提供、使用是否进行管理、验证，清除了不适当资源、不适当使用，提高资源利用率？
√
人员
1.组织各个岗位的任务、性质及要求是否确定？是否根据履行岗位职责所要求的能力安插人员？
组织应确定并提供所需要的人员，以有效实施质量管理体系并运行和控制其过程，具体见《岗务职责说明书》。
4.4.1本公司确保依照本尺度的要求，建立、实施、坚持和持续改进质量管理体系，包含所需过程及其相互作用。
通过实施以下活动，确定质量管理体系所需的领导、筹划、支持、运行、绩效评价和改进等过程及其在整个组织内的应用：
a)确定这些过程所需的输入和期望的输出；
b)确定这些过程的顺序和相互作用；
c)确定和应用所需的准则和方法（包含监视、丈量和相关的绩效指标），以确保这些过程的运行和有效控制；
组织应考虑以下相关方：
--顾客；
--最终用户或受益人；
--法人，股东；
--银行；
--外部供应商；
--雇员及其他为组织工作者；
--法律法规及监管机关；
--地方社区团体；
--非政府组织；。
理解相关方的需求和期望可以帮忙本公司更好的建立清晰的方针和目标，做到目的明确。满足相关方的要求并争取做到更高的期望值。
软件设计评审检查表
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）?
是否已列出该单元的调用？
依从性
该文档是否遵循了该项目已文档化的标准？
是否采用了所要求的方法和工具来进行单元设计？
一致性
数据元素的命名和使用在整个单元和单元接口之间是否一致？
可维护性
单元是否具有高内聚度和低耦合度（例如：对该单元的更改不会在该单元有任 何无法预料的影响并对其它单元的影响很小）？
性能
是否该单元的所有约束例（如过程时间和规模）都被详细说明？
可靠性
初始化是否使用到缺省值，缺省值是否正确？
是否在内存访问的时候执行了边界检查（例如：数组、数据结构、指针等）来 确保只是改变了目标存储位置？
Y:是TBD:不确定N:不是NA:不适用
检查项
Y/TBD/N/NA
清晰性
系统的目标是否已定义？
是否对关键术语和缩略语进行定义和描述？
所使用的术语是否和用户/客户使用的一致？
需求的描述是否清晰，不含糊？
是否有对整套系统进行功能概述？
是否已详细说明了软件环境（共存的软件）和硬件环境（特定的配置）？
如果有会影响实施的假设情况，是否已经声明？
完成软件确认测 试说明、执行软件 确认测试、进行测 试分析、编写确认 测试报告
完成系统测试 说明、执行系 统测试、进行 测试分析、编 写系统测试报 告
是否将需求分别陈述，因此它们是独立的并且是可检查的？
是否所有需求都可以回溯到相应的需求素材，反之亦然？
是否已详细说明需求变更的过程？
Y:是TBD:不确定N:不是NA:不适用
用户界面检查表(1)
系统用户界面设计的原则
1、所有的操作可在一个主界面下完成，根据操作员等条件进行动态调整界面
2、界面清晰简洁友好、易于操作，突出重点，及时所需的信息。
3、 所有程序的界面风格保持一致、操作习惯保持一致，尽量向Windows的标准操作习惯靠要考虑原有的操作习惯。
4、前台完成一切所需的输入控制，如焦点、输入类型、长度、最大最小值等。
5、 提供鼠标和键盘的灵活操作方式，有必要的快捷键、快捷按钮等完成常用功能
6、提供开关参数设置一些需灵活配置的界面。
习惯靠拢，也。
软件需求规格说明书评审检查表
22 是否所有的需求都是名副其实的需求而不是设计或实现方案？
23 是否确定了对时间要求很高的功能并且定义了它们的时间标准？
24 是否已经明确地阐述了国际化问题？
25
21
22
23
24
25
结果统计
是：
0个
否：
0个
不适用：
0个
未检查：
0个
说明
检查结果
使 用 说 明 ： 本 检 查 表 在 项 目 中 各 种 评 审 、 审 计 工 作 实 施 前 编 制 ， 用 于 列 出 问 题 、 记 录
软件需求规格说明书模板需求开发过程序问题号组织和完好性全部对其他需求的内部交织引用能否正确
软件需求规格说明书评审
检查表
编制人员： 项目名称： 检查依据：《 软件需求规格说明书模板》、《需求开发过程》
编制日期： 项目经理： 花费工作量：
序 号
问题
组织和完整性
1 所有对其它需求的内部交叉引用是否正确？
2 所有需求的编写在细节上是否都一致或者合适？
正确性
10 是否有需求与其它需求相冲突或重复？
11 是否简明、简洁、无二义性地表达了每个需求？
12 是否每个需求都能通过测试、演示、审查得以验证或分析？
13 是否每个需求都在项目的范围内？
14 是否每个需求都没有内容上和语法上的错误？
15 在现有的资源限制内，是否能实现所有的需求？
16 是否任一个特定的错误信息都具有唯一性和明确的意义？
质量属性
17 是否合理地确定了性能目标？
18 是否合理地确定了安全与保密方面的考虑？
19 在确定了合理的折衷情况下，是否详实地记录了其它相关的质量属性？
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
技术运用
技术运用的合理性;内容实现的正确性.
各种技术表现与具体内容结合 ，各种媒体使用协调;多媒体信息的呈现可控，链接准确、无死链.
交互性要求
简易位，一致性;反馈性;容错性图形化.
人机交互简单、形象输入、输出方面的-致性对用户的操作及时作出皮馈;对可能出现的错误迸行检测、报告和处理.
软件性能
软件定位
使用者的明确性.
明确的使用者定位.明确的目标
软件部署
部署
软件的发布与安装部署
部署后是否可以正常使用.
运行环境
环境适用性.
运行环镜是否与软件愿景说明书一致
界面
界面布局
界面布局的合理性.
布局合理，层次清晰
界面美观设计
界面的美观性.
界面美观.
界画元素
界面元素的-致性.
窗口、菜单、图标、按钮等元素的-性.
软件产品评审
评审时间：2019-5-17
评审人员：评审组长（），评审成员（）
产品介绍主讲：程飞
项目名称
智能交通集成管理平台
开发小组
研发中心（智能交通）
开发人员
组长：成员：
评审项目
评审细顶评审指标(评要点)指标说明(评审要点说明}
问题列表
产品内容
产品内容
内容完整性
即相对完整的完成软件愿景,说明书上的功能.
安全性要求
访问安全性，使用安全性
用户身份管理和访问控制
数据安全性
软件文档
文档资料
完整性
规范性
软件过程文件目录
评审结论：通过
有条件的通过
不通过（需再次评审）
响应性要求
页面转焕的响应性 ;
载入时间的短时间要求
短时启动时间要求;
负裁指标明确化.
页面转换快捷;媒体装入时间简短;有确定的负载性能指标.
稳定性要求
帮助机制的完备性;
错误处理机制完备性;
确认退出出机制的完备性.
每个操作都有联机帮助或提示;
联机帮助易读、易懂
处理用户可能出现的任何错误操作;
避免出现数据未保留而退出.