软件产品评审表
互联网软件项目评审表
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
作
软件设计评审表-模板
用户接口是否模块化，并且修改时不影响其他程序
10
是否提供了一致的错误处理机制
11
各子系统、模块之间的关系是否描述得清楚
12
系统的设计是否考虑了系统的可扩展性
13
设计是否考虑了重用性
14
重用构件是否进行了标识
15
是否说明了重用模块的获得方式和相关的文档
Байду номын сангаас16
系统的设计是否考虑了系统的易移植性
17
设计是否使用标准的技术，避免使用怪异的、不易理解的方式和方法
设计范围、边界是否清晰，文档中是否清晰阐明了系统的各项特性及预期的结果
15
逻辑性、算法和处理过程是否正确
16
文档是否符合客户的需要
17
设计是否考虑到未来的扩充性
18
设计的系统是否易于维护
评审项目
详细设计说明书
评审日期
评审结果标记
合格不合格TBD待完成 NA 不适用
评审情况
检查项：项；有效检查项：项；通过项：项；通过率：%
18
设计的调用宽度、调用深度、耦合度、内聚度和结构化程序是否进行了描述
追溯性
19
设计是否可以追踪到需求
20
需求是否可追溯到设计
编制： 日期： 审核： 日期： 批准： 日期：
序号
主要检查项
检查结果
说明
标准化
1
有规定的文档标识
2
引用的文档现行有效
3
文档编写的内容、格式符合相关标准、规定的要求
4
文档签署完整
5
设计陈述中的命名、属于和缩写是否上下文一致
完整性
5
文档有独立的版本说明部分
(整理)SE-Checklist-TR1ChecklistTR1评审表-030000.
RAS:可靠性\可获得性\可服务性.
A
关联：
Sub-TR：产品包需求
交付件：NA
活动：NA
Link：
Sub-TR：Offering Requirements
Deliverables：Usability And Benchmark Requirements
此项建议由开发代表/测试人员给出评审意见
It's recommended thatRDPDT/EEis responsible for this checklist item
A
关联：
Sub-TR：产品包需求－可测试性需求
交付件：NA
活动：NA
Link：
Sub-TR：Offering Requirements -Testability Requirements
软件是否具备行为跟踪、控制支撑功能，是否具备系统日志、测试能力安装与配置功能，是否提供标准外部测试接口，是否符合《软件可测试性工程技术规范》之STES01标准？
Does the software support the functions such as behave tracing, action control, system log, testability configuration and etc? Can it supply external test interface? Does it meet the requirement of STES01 in Software testability engineering technical specification?
软件设计评审表-模板
引用的文档现行有效
3
文档编写的内容、格式符合相关标准、规定的要求
4
文档签署完整
完整性
5
文档有独立的版本说明部分
6
有文档的文字目录页
7
有总体设计部分
8
有功能设计
9
有接口设计
10
有性能设计
追溯性
11
设计是否可以追踪到需求
12
需求是否可追溯到设计
符合性
13
是否每个设计都是可测试的或以别的方式可以确定的
14
9
用户接口是否模块化，并且修改时不影响其他程序
10
是否提供了一致的错误处理机制
11
各子系统、模块之间的关系是否描述得清楚
12
系统的设计是否考虑了系统的可扩展性
13
设计是否考虑了重用性
14
重用构件是否进行了标识
15
是否说明了重用模块的获得方式和相关的文档
16
系统的设计是否考虑了系统的易移植性
17
设计是否使用标准的技术，避免使用怪异的、不易理解的方式和方法
设计范围、边界是否清晰，文档中是否清晰阐明了系统的各项特性及预期的结果
15
逻辑性、算法和处理过程是否正确
16
文档是否符合客户的需要
17
设计是否考虑到未来的扩充性
18
设计的系统是否易于维护
评审项目
详细设计说明书
评审日期
评审结果标记
合格不合格TBD待完成 NA 不适用
评审情况
18
设计的调用宽度、调用深度、耦合度、内聚度和结构化程序是否进行了描述
追溯性
19
设计是否可以追踪到需求
20
软件过程检查表
1.过程检查要素表配置管理过程√√√√设计阶段结束测试阶段结束软件过程审计报告SQA人员，项目经理，配置管理员软件质量保证过程√√√√验收阶段结束软件过程审计报告高级经理，SQA经理，项目经理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=(∑1z B)/z 。
9)项目的过程得分C=∑1N B 。
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。
4.2 软件项目产品质量评审表
查询结果少了统计信息
在报表增加相关统计信息
产品的性能指标
数据库查询时系统的响应时间不大于20秒
显示性指标
产品上线以后，产品出现Bug的频度为每周不能多于4个
试用一周时发现了10个Bug
☆☆☆☆☆
增加测试力度，必须保证上线前的Bug出现频度。
4.2软件项目产品质量评审表
项目名称
项目经理
产品功能性指标
指标
实际情况
重要性（五分制）
评审结果
人员、区域管理
满足实际业务要求
通过
权限管理
只对部门进行了管理，没有对区域权限进行管理
增加对区域权限进行管理
产品是带图标的图形用户界面
只是下拉菜单的界面，不生动
停止其它模块的开发，赶快修改现有模块界面
产品的输出界面和报表
软件质量保障-软件架构评审表Design Review Checklist
Design Review ChecklistArchitecture DesignGeneral:Does the architecture convey a clear vision ofthe system that can be used for furtherdevelopment?Is the architecture structured to support likelychanges?Does the architecture describe the system at ahigh level of detail? (No interface orimplementation details.)Does the architecture cleanly decompose thesystem?Is the architecture independent of theinfrastructure used to develop the system?Has maintainability been considered?No duplicate functionality in the architecture?Complete:Are software requirements reflected in thesoftware architecture?Is effective modularity achieved? Are modulesfunctionally independent?Does each module/class have anunderstandable name?Is each association well named?Is each association’s and aggregation’scardinality correct?Correct:Does each association reflect a relationshipthat exists over the lives of the relatedmodules/classes?Does the architecture have loose coupling andgood cohesion?1Detailed DesignGeneral:Does the design support moving to the next phase ofdevelopment?Does design contain proper level of detail?Does the design have conceptual integrity? (Qualitywhere the individual pieces all contribute to making alarger whole. Design consistency.)Will the design be easy to port to anotherenvironment?Have reusable components been identified?Is effective modularity achieved? Are modulesfunctionally independent?Complete:Is the class design consistent with architecturaldesign? (i.e., each class traceable to architecturalcomponent and no classes span architecturalcomponents)Does each class have an understandable name?Does each class define attributes, methods,relationships, and cardinality?Is each association well named?Is each association’s and aggregation’s cardinalitycorrect?2Correct:Does each class have a clearly defined purpose? Caneach class be described in a single sentence?Is a consistent naming scheme used for all classes?Are all attributes private?Are all method signatures specified including returntypes and parameters?Do all subclasses implement the "is-a-kind-of"relationship properly?Is there no duplicate functionality between classes inthe design?In inheritance structures, are all attributes and methodspushed as high in the inheritance structure as isproper?Are all polymorphic methods within related subclassesidentically named?Does each association reflect a relationship that existsover the lives of the related objects?Has error handling been specified?Is design detail amenable to implementation language?No hidden implementation details shown?Does design display high cohesion and low coupling?Consistent:Are each 0..* and 1..* relationships implemented withcontainers/collectors?Are each association’s cardinalities consistent(instantaneous vs. over-time)?Are the views provided by different modelingnotations consistent?Is a consistent naming convention used and followed?3。
软件评审检查表-计分
交互性要求
简易位，一致性;反馈性;容错性图形化.
人机交互简单、形象输入、输出方面的-致性对用户的操作及时作出皮馈;对可能出现的错误迸行检测、报告和处理.
15
软件性能
响应性要求
页面转焕的响应性 ;
载入时间的短时间要求
短时启动时间要求;
负裁指标明确化.
页面转换快捷;媒体装入时间简短;有确定的负载性能指标.
部署后是否可以正常使用.
5
运行环境
环境适用性.
运行环镜是否与软件愿景说明书一致
5
界面
界面布局
界面布局的合理性.
布局合理，层次清晰
2
界面美观设计
界面的美观性.
界面美观.
3
界画元素
界面元素的-致性.
窗口、菜单、图标、按钮等元素的-性.
5
功能要求
技术运用
技术运用的合理性;内容实现的正确性.
各种技术表现与具体内容结合 ，各种媒体使用协调;多媒体信息的呈现可控，链接准确、无死链.
100分
评审结论：
5ห้องสมุดไป่ตู้
稳定性要求
帮助机制的完备性;
错误处理机制完备性;
确认退出出机制的完备性.
每个操作都有联机帮助或提示;
联机帮助易读、易懂
处理用户可能出现的任何错误操作;
避免出现数据未保留而退出.
5
安全性要求
访问安全性，使用安全
性
用户身份管理和访问控制
数据安全性
10
软件文档
文档资料
完整性
规范性
软件过程文件目录
20
分数
软件产品评审表
评审时间：
评审人员：评审组长（），评审成员（）
TR2评审表-模板
3
量、商务、交期方面满足要求并签订相关 硬件工程师
协议。
结构设计工程师
所有的器件，原则上有两家以上的合格供 应商。地图，语音，输入法等外购件是否 终端产品经理
4
结构T0/T1件是否完成测 结构T0/T1件已完成试装及相关测试，发
试
现的问题已解决
结构设计工程师 测试组长
□OK □NOK □POK □OK □NOK □POK □OK □NOK □POK □OK □NOK □POK □OK □NOK □POK □OK □NOK □POK
12 LPDT
13
质量监察部签发TR报 告
14 研发CTO核准
已有可行的开发计划。 后台PRD需求是否全部实 1.后台服务需求是否全部实现；2.软件需 平台软件工程师
7 现，软件需求评审是否 求评审是否通过；
通过
轻应用产品经理
采购工程师
□OK □NOK □POK □OK □NOK □POK □OK □NOK □POK □OK □NOK □POK □OK □NOK □POK
自检发现问题：
签名
评审结论：□通过 □带风险通过 评审结论陈述：
□不通过
序 会签角色 号
1 车载软件部长
会签意见
终端产品经理签字：
日期：
会签人签字及日期
2 硬件结构部长
3 核心系统部长
4 测试部长
5 中试部长
6 采购经理
7 技术采购经理
8 品质部经理
9 智能网联部长
10 销售部长
11 产品管理中心主任
测试计划是否评审通过 测试所需的需求列表、产品说明书、设计 测试组长
5
文档已提供，按照这些文档制定的测试计 终端产品经理 划（含DV/EMC、路试、客户测试等）已经 系统工程（SE）
设计方案评审表
口方案不合理，但需要做少量的修改，需再次评审
口方案不合理，不同意立项
项目负责人：
产品经理：
方案批准：
列席人员 签名
修改意见调整设计方
项目名称
项目编号
设计方案评审表
评审主持
评审日期
评审地点
RD 参与评审
人员
业务
采购
PIE
PQE
财务
项管
列席人员
产品设计方案简述：（评审输入设计方案、客户需求表、产品设计标准书）
评审主要内容
评审项目
评审结果
设计外观风格，属性定位是否符合客户要 口通过
求
口不通过
设计创意点包含，形态，材料，结构，工 口通过
成本控制，模具成本、材料成本预估是否 口通过
满足设计规划要求
口不通过
其他需要评审部分 参加会议人员签名：
口名
备注：评审人员半数以上通过，即认定设计方案初级评审通过。如未达到，待RD根据修改意见调整设计方 案，确定二次评审时间。（如有任何不符合客户要求即评审失败） 评审结论：
艺是否符合客户要求
口不通过
设计整体外观尺寸，是否符合客户要求
口通过 口不通过
设计结构，配合方案是否满足客户要求
口通过 口不通过
电路设计、电器控制方案是否满足客户需 口通过
求
口不通过
软件部分设计（如果有）方案是否能够满 口通过
足客户规格要求
口不通过
新元器件或外购件货源及价格是否便于国 口通过
内采购
口不通过
产品需求说明书PRD评审表
我司产品的主要卖点是否能与竞争产品竞争？
需求是否确定优先级？
对市场需求的重要性分类,需要市场、技术、销售等相关人员达成一致
客户需求是否得到充分验证？
（产品经理找客服人员确认PRD文档，12.9得出结论）
可运营需求
产品需求说明书PRD评审表
项目名称:
评审项
评审要素
检查结果
评审操作指导
备注
是
否
免
产品需求
产品市场需求是否清晰并依据产品市场需求说明书模板进行了整理？
必须依照模板编写，保证内容的全面性。
所有的客户需求（外部需求）是否得到采纳？
关注外部客户需求，包括主要客户的$APPEALS需求。
说明：识别哪些客户需求必须包含在产品需求中？
客户的所有需求是否得到定义？如果没有全部得到采纳，需说明情况和理由。
已采纳需求是否满足主要客户提出的主要需求？
如果客户需求只得到部分采纳，已采纳需求是否包括了主要客户的主要需求。也要注意到主要客户的特殊需求，并评估该需求的市场前景，当前的微小需求是否可以演变成一个机会点
竞争产品的主要特性（功能、性能）我司产品能否提供？
2评审人员：产品经理，ID设计师，UI设计师，交互设计师，SDE，硬件主管，软件主管，测试主管，结构主管，认证工程师，专利工程师，运营工程师，DQA，及其他相关人员
签名
检查人：_____________部门：__________________日期：__运营未给出需求
软件著作权
是否具备软件著作权申报条件
安规认证
认证需求是否满足
关键物料
关键物料的供应商/物料选择计划是否已经考虑？
产品开发流程-技术评审二评审要素表
1
产品名称/版本：
项目
评审要素
检查结果
评审操作指导
类别
备注
需
求
分
配
与
系
统
架
构
产品包需求是否充分转换成设计需求？
A
关联：《产品包需求》、《产品设计需求》
所有产品包需求（包括客户需求、可服务性/可维护性/可靠性等）是否清晰地定义并映射到产品概念中？
A
关联：《产品包需求》、《产品概念》
产品概念的功能分解是否清晰地描述（譬如已经画成框图）？
在评审表模板中，“备注”栏给出的是关联关系，指引检查者查找证据，在具体检查时，检查者的检查意见填写在“备注”栏。
对每一条要素如果有问题，需要进行记录，并制定相应的行动计划，问题和行动计划必须经过评审并进行相应地风险分析，制定风险地规避措施。所有的问题、行动计划和风险分析均须列入评审报告中。
本表从总体上来考虑设计规格的对需求的满足度和质量，是从系统构建以及各专题之间协同方面来考虑的。
A
需要下达储备订单的候选物料是否已确认并报PDT审核？
A
关键物料的询价单是否发给潜在的供应商？
A
是否为定制品
是否有相似的器件在其他机型上使用
价格及有否竞争力（可估价）
成本结构是否合理未来是否有成本上的竞争能力
是否是主力供应商及其在市场的地位如何
样品提供周期
交货期及交货地点付款条件
有否批量供应其他厂商情况如何
文档版本
Product version
密级
Confidentiality level
文档名称Product name:
Total pages：共 6页
软件过程检查表
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。
产品评审流程汇总表
方式、对库存物料的影 审时，发出会议 +NPI+CPQA+MSQE+PM+PMC
响，对已生产的产品之影 邀请
+Sourcing等人员
响等
评审会或评 估报告
一致同意
天线评估流程
评审报告
会议记录
会议
一致同意
会议
一致同意
会议
唯一决策
会议
唯一决策
会议
一致同意 暂无
有固定内 容,无点检 会议纪要 表
有固定内 容,无点检 会议纪要 表
原型项目阶 段关闭评审 11 （ES,PR,PP, MP）(含阶段 项目部 技术评审)
lisa
13
客户特殊需 求评审
14
订单项目评 审
15
订单项目关 闭评审
用户体验输
16
出评审（软 件，铃声，
效果，UI）
18
产品技术规 格评审
ES关闭评审：项目级
PR准入评审：项目级
PP准入评审：公司级；评委：市场，研发,物流，质量
34
新物料、新 工艺、新技 术测试标准 评审
客户与 产品质 量部
Eric
讨论原型或预研项目有关 新物料，新工艺，新技术 的测试标准和测试方法
项目立项后新物 料，新工艺，新 技术确认后一周 内
项目质量+测试+SQE+研 发工程师
35 金机会签
生产与 工厂质 量部
1、按BOM、客户需求表、 工厂评审在包装
相关ID设计师。
（此项评审是否
28
项目供应商 选择评审
确定项目供应商
局限于定制件\ 采管工程师+采购工程师 结构件）ID及3D +设计师+项目经理+SQA 图纸评估比价后 工程师
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
界面布局的合理性。
布局合理，层次清晰。
5
界面美观设计
界面的美观性。
界面美观。
5
界面元素
界面元素的一致性。
窗口、菜单、图标、按钮等元素的一致性。
5
功能要求
技术运用
技术运用的合理性；
内容实现的正确性。
各种技术表现与具体内容有机结合，各种媒体使用协调；
多媒体信息的呈现可控；链接准确、无死链。
15
交互性要求
4.事件化、情绪化、故事化、游戏化
25
软件性能
响应性要求
页面转换的响应性；
互动过程中的响应性；
页面转换快捷；
对用户的操作及时作出交互反馈；
5
稳定性要求
帮助机制的完备性；
错误处理机制完备性；
确认退出机制的完备性。
每个操作都有帮助或提示并易于理解；
保证处理用户可能出现的任何错误操作；
避免出现数据未保留而退出。
5
软件文档
文档资料
文档资料的完整性；
文档资料的规范性。
有功能说明书、开发计划说明书、需求规格说明书、架构设计说明书、详细设计说明书、测试报告等开发文档；
有开发过程管理文档；
有用户手册；
文档编写符合标准和要求。
20
总计
100
评审项目
会议时间
评审组
成员
评审
负责人
主审人
主审人
评审人
评审人
评审人
评审人
评审会议记录
软件
项目名称
策划人
评审项目
评审细项
评审指标
（评
分值
分值
产品内容
产品内容
内容的完整性
内容的趣味性
相对完整的完成软件愿景说明书上的功能；
保证软件使用过程中的趣味性
10
软件定位
使用者的明确性。
学习或娱乐目的的明确性
有明确的使用者定位。
有明确的学习目的，或者娱乐目的
5
界面
第一反应原则；
阿童木原则；
非局域化原则；
引导原则；
互动性原则；
1.做什么事情有关联的针对性反应及语言（不用人联想）。与当前操作是一对一的对应关系，不拐弯抹角，让用户无法理解。
2.在编辑语言时想象是与阿童木机器人在进行对话。
3.杜绝基于自己的理解摘取部分在自己思维中的信息，形成片面性局域性理解。必须是完整的提示性、指导性语言。让用户容易操作。
记录人
签名
日期
评委表决记录
无条件通过
有条件通过
不予通过
结论方式记录
一致决定□过半数表决决定□评审负责人裁决决定□
评审
整改意见