评审文档文档格式.doc

资源描述

评审文档文档格式.doc

《评审文档文档格式.doc》由会员分享，可在线阅读，更多相关《评审文档文档格式.doc（7页珍藏版）》请在冰豆网上搜索。

评审文档文档格式.doc

姓名

角色

主持人（评审组长）

项目组成员

作　者

书记员

项目总监

客户

1.2软件工作产品评审指导方针

软件工作产品评审指导方针

评审重点

进入准则

参与者

项目计划

•满足项目管理和控制需求

•计划是否完整和明确

•计划是否可实施

•符合计划书标准模板

项目经理

SEPG成员

与其它项目经理

软件需求说明书

•软件需求满足客户需求

•软件需求是可实施的

•软件需求是否完整、一致和明确

•文档符合规范要求

设计人员

系统测试人员

安装实施人员

用户文档作者

概要设计说明书

•设计覆盖了需求

•设计是可实施的

•设计是否有遗漏和缺陷

•需求经过评审并已定稿

需求作者

详细设计人员

开发人员

源代码

•编码前进行了设计

•源代码是否完整和正确

•源代码中的缺陷

•源代码已经完成汇编

•源代码符合编程规范

测试人员

系统测试用例

•用例覆盖了需求中的所有条件

•用例是否正确

•用例是否可执行

•已建立需求基线

•系统测试计划符合规范

1.3评审检查表

例1：

软件需求评审检查表

序号

问题

完整性

•是否完整地定义了软件需求规格？

•是否定义了所要解决问题范围内的处理结构和信息流？

•是否考虑了数据量和处理量？

•是否定义了关键的接口和界面？

•范围内的功能是否都有适当的描述？

•是否考虑了异常处理和例外处理？

•是否考虑过其它可选的软件需求？

•是否定义了用户手册概要？

一致性

•所描述的软件需求与客户需求和系统需求是否一致？

•所规定的处理及其数据是否与必须完成的功能要求一致？

•是否有超出范围的功能？

•是否存在前后不一致的描述？

正确性

•是否正确理解和描述了客户对软件的需求？

明确性

•是否存在含混、不清楚和含有二义的描述？

•图表是否清楚？

•某些信息是否被忽略了或有冗余？

可实施性

•是否每一项软件需求都存在实现的可能？

•约束条件是否现实？

•是否考虑了实现需求的技术风险？

•计划的估算是否受到影响？

可验证性

•是否对每一项软件需求都能够进行验证？

•是否详细描述了验证标准？

•验证标准是否合适？

可追溯性

•是否能够在后续过程中对每一项软件需求进行追溯？

例2：

概要设计评审检查表

•是否覆盖了所有软件需求？

•概要设计是否完整？

•是否定义了各子系统或模块之间的接口？

•是否存在设计遗漏和缺陷？

•与软件需求和系统需求是否一致？

•所设计的处理及其数据是否与必须完成的功能要求一致？

•是否满足约束条件的限制？

•是否正确理解和描述了软件需求的要求？

•是否存在设计上的错误？

•是否每一项设计要求都是可实现的？

•是否考虑了设计实现的技术风险？

•是否对每一项设计要求都能够进行验证？

•是否能够从每一项设计要求追溯到其对应的软件需求？

可靠性

•是否满足客户的要求，以及所达到的程度如何？

安全性

•是否考虑了误操作的防范和处理？

•是否考虑了非法操作的防范和处理？

•是否满足客户的要求？

可维护性

•是否便于发现错误，并易于纠正所发现错误？

可移植性

•是否易于移植和改造？

运行效率

•是否满足客户要求？

方便性

•是否便于用户使用操作？

灵活性

•是否能够灵活处理不同的业务/操作需求？

1.4评审会议记录

[XXXX]_RVMT_[ReviewType]-V1.0

评审会议总工时（小时）

会议日期

确认缺陷的截止日期

会议时间

会议时数（小时）

主持人

书记员

作　　者

评审人员

缺陷/问题记录

序

号

文档号

页号

位置

类型

描述

参照项

解决办法

主

次

改

问

有待解决的问题记录

问题描述

负责人

目标日期

解决日期

说明：

主－主要缺陷，次－次要缺陷；

改－改进建议，问－疑问；

参照项－对应的检查表项。

1.5评审报告

[XXXX]_RVRP_[ReviewType]-V1.0

评审性质

评审□　　　　复审□

评审日期

项目名

项目标识号

被评审对象名称

所处阶段

开发策划需求分析系统设计实现测试安装验收设计更改

[][][][][][][]（请打√）

评审内容（空间不够可附页）：

评审结论（空间不够可附页）：

评审各方签字认可

SQA

日期

年月日

备注

展开阅读全文