源文件获取评论“评审报告获取”
需求变更技术评审报告
|
项目名称 | 物联网大数据平台 | |||||||||||||||||||
项目级别 | √公司级 □ 部门级 □ 子部门级 | 项目经理 | ||||||||||||||||||
要求评审的工作产品的名称 | 《物联网大数据需求规格说明书》 | |||||||||||||||||||
产品作者 (评审申请人) | 建议评审时间 | 20XX年XX月XX日 | ||||||||||||||||||
要求评审的工作产品所属 开发阶段 | □规划阶段 √ 需求分析阶段 □ 系统设计阶段 □ 实现与测试阶段 □ 系统验收阶段 □ 安装运行阶段 □ 其它 | |||||||||||||||||||
评审准则 | ◆ 可追溯性：软件需求规格说明书中的每一个需求要一一列出并标识，与别的需求区别开来。每项需求只应在软件需求规格说明书中出现一次。 ◆ 正确性：软件需求都是与用户所期望的相符合。与涉及的相关行业技术规范相符合。 ◆ 完整性：软件需求规格说明书中没有遗漏任何必要的需求。 ◆ 一致性：各软件需求之间或软件需求与高层（系统，业务）需求之间不相矛盾。 ◆ 可行性：软件需求规格说明书中的每一个需求都是可实现的。 ◆ 无二义性：软件需求规格说明书中的每一个需求都只有惟一的含义。 ◆ 可验证性：软件需求规格说明书中的每一个需求对用户而言都是可验证、测试的。 ◆ 必要性：软件需求规格说明书中的每一个需求对用户而言都是必须的，没有画蛇添足。 ◆ 可理解性：软件需求规格说明书中的每一个需求都能清楚表达，保证项目干系人都能看懂。 ◆ 划分优先级：软件需求规格说明书中，应根据需求的轻重缓急对需求划分优先级。 ◆ 具有概要设计所需的相关的输入信息。 | |||||||||||||||||||
评审需提交 的资料 | 《物联网大数据平台产品需求规格说明书》 《物联网大数据平台用户需求调查报告》 《物联网大数据平台系统用户需求说明书（系统）》 《物联网大数据平台系统软件需求跟踪矩阵表单》 | |||||||||||||||||||
产品批准人 （审核人） 意 见 | √ 同意评审 由 XXX 担任评审负责人，按技术评审流程开展评审工作。 评审方式：√ 正式技术评审（会议评审） □ 非正式技术评审（□ Email会签 □ 走查 □其他： ） 评审级别：□ 部门级 √ 子部门级 □ 项目组内 □ 暂不评审 原因是：□ 方案不成熟 □ 资料不完整 □ 其他 | |||||||||||||||||||
签 字 | XXX | 日 期 | 20XX年XX月XX日 | |||||||||||||||||
技 术 评 审 意 见 及 结 果 | ||||||||||||||||||||
评审时间 | 自 20XX年XX月XX日XX时 至 20XX年XX月XX日 XX 时 | |||||||||||||||||||
评审 问答 记录 | 本次评审是针对用户的新增需求进行评审。 1、 此次需求的增加，对系统的整体进度影响有多大？ 答：由于需求的变更点已经是在准备进行编码设计的时候了，所以需求增加后，也涉及到了系统设计的增加，整体的进度有偏差，但会进行有效的控制。 2、 此次需求的增加，存在什么技术上的问题吗？ 答：此次增加的需求，在技术角度上是完全可以实现的，不存在什么技术难题，主要是要有时间来做这些增加。 | |||||||||||||||||||
记录人签名 | 日 期 | 20XX年XX月XX日 | ||||||||||||||||||
评 审 人员签名 | ||||||||||||||||||||
其他参与 人员签名 | ||||||||||||||||||||
|
评审意见 汇 总 | 一、缺陷识别
二、总体评价及建议 属于变更类项目。新增需求分析比较透彻、完善； 基本通过。 20XX-XX-XX | |||||||||||||||||||
评审结论 | √评审通过：工作产品合格，“无需修改”或“需要轻微修改但不必再审核”； □评审基本通过：工作产品基本合格，需要作少量修改，之后通过审核即可； □评审不通过：工作产品不合格，需要作比较大的修改，之后必须重新对其评审。 | |||||||||||||||||||
建议整改完成时间 | 20XX年XX月XX日 | |||||||||||||||||||
评审负责人签字 | XXX | 日 期 | 20XX年XX月XX日 | |||||||||||||||||
缺陷修正及验证（如果使用缺陷跟踪软件，则无需填写下表） | ||||||||||||||||||||
序号 | 缺陷内容 | 修正措施 | 实施结果 | 实施人、日期 | ||||||||||||||||
缺陷修正 验证情况 | 验证结论： 验证通过 | |||||||||||||||||||
验证人签字 | XXX | 日 期 | 20XX年XX月XX日 | |||||||||||||||||
需求跟踪矩阵表技术评审报告
|
项目名称 | 物联网大数据系统 | ||||||||||||||||||||||||||||||
项目级别 | √公司级 □部门级 □ 子部门级 | 项目经理 | |||||||||||||||||||||||||||||
要求评审的工作产品的名称 | 《物联网大数据平台产品需求规格说明书》 《物联网大数据平台用户需求调查报告》 《物联网大数据平台用户需求说明书》 《物联网大数据平台设计文档》 《物联网大数据平台软件需求跟踪矩阵表单》 | ||||||||||||||||||||||||||||||
产品作者 (评审申请人) | 建议评审时间 | 20XX 年3月12日 | |||||||||||||||||||||||||||||
要求评审的工作产品所属 开发阶段 | □ 规划阶段 √需求分析阶段 □ 系统设计阶段 □ 实现与测试阶段 □ 系统验收阶段 □ 安装运行阶段 □ 其它 | ||||||||||||||||||||||||||||||
评审准则 | ◆ 可追溯性：用户需求ID、产品需求ID、设计文档、测试用例等能找到一一对应关系。 ◆ 正确性：用户需求ID、产品需求ID、设计文档、测试用例等对应正确。 ◆ 完整性：软件需求规格说明书中没有遗漏任何必要的需求。 ◆ 一致性：各软件需求之间或软件需求与高层（系统，业务）需求之间不相矛盾。 ◆ 可行性：软件需求规格说明书中的每一个需求都是可实现的。 ◆ 无二义性：软件需求规格说明书中的每一个需求都只有惟一的含义。 ◆ 可验证性：软件需求规格说明书中的每一个需求对用户而言都是可验证、测试的。 ◆ 变更控制：需求相关的产品的变更也放映到RTM中。 | ||||||||||||||||||||||||||||||
评审需提交 的资料 | 《物联网大数据平台产品需求规格说明书》 《物联网大数据平台用户需求调查报告》 《物联网大数据平台用户需求说明书》 《物联网大数据平台设计文档》 《物联网大数据平台软件需求跟踪矩阵表单》 | ||||||||||||||||||||||||||||||
产品批准人 （审核人） 意 见 | √同意评审 由 担任评审负责人，按技术评审流程开展评审工作。 评审方式：√正式技术评审（会议评审） □ 非正式技术评审（□ Email会签 □ 走查 □其他： ） 评审级别：□ 部门级 □ 子部门级 □ 项目组内 □ 暂不评审 原因是：□ 方案不成熟 □ 资料不完整 □ 其他 | ||||||||||||||||||||||||||||||
签 字 | 日 期 | 20XX 年3月12日 | |||||||||||||||||||||||||||||
技 术 评 审 意 见 及 结 果 | |||||||||||||||||||||||||||||||
评审时间 | 自 20XX 年3月12日10时 至 20XX 年3月12日 11 时 | ||||||||||||||||||||||||||||||
评审 记录 |
按照RTM的记录对项目需求、设计文档等进行了检查。记录完整。但还是存在一些问题： （1）、在系统设计文档中，有部分需求与设计文档对应章节不上； （2）、需求规格说明书的版本好变化后没有更改过来。 | ||||||||||||||||||||||||||||||
记录人签名 | 日 期 | 20XX 年3月12日 | |||||||||||||||||||||||||||||
评 审 人员签名 | |||||||||||||||||||||||||||||||
其他参与 人员签名 | |||||||||||||||||||||||||||||||
|
评审意见 汇 总 | 一、缺陷识别
二、总体评价及建议 需求分析比较透彻、完善，而且能够将客户需求与产品需求、高层设计、单元测试、集成测试和系统测试等统一起来管理，工作进行的比较认真。 基本通过。 20XX-3-12 | ||||||||||||||||||||||||||||||
评审结论 | □评审通过：工作产品合格，“无需修改”或“需要轻微修改但不必再审核”； √评审基本通过：工作产品基本合格，需要作少量修改，之后通过审核即可； □评审不通过：工作产品不合格，需要作比较大的修改，之后必须重新对其评审。 | ||||||||||||||||||||||||||||||
建议整改完成时间 | 20XX 年3月12日 | ||||||||||||||||||||||||||||||
评审负责人签字 | 日 期 | 20XX 年3月12日 | |||||||||||||||||||||||||||||
缺陷修正及验证（如果使用缺陷跟踪软件，则无需填写下表） | |||||||||||||||||||||||||||||||
序号 | 缺陷内容 | 修正措施 | 实施结果 | 实施人、日期 | |||||||||||||||||||||||||||
1 | 在《软件需求跟踪矩阵表单》的第3条记录中SRS列表与设计文档对应不正确。 | 修改RTM。 | 完成 |
20XX 年3月12日 | |||||||||||||||||||||||||||
2 | 需求规格说明书对应的版本号未更新。 | 修改RTM。 | 完成 |
20XX 年3月12日 | |||||||||||||||||||||||||||
缺陷修正 验证情况 | 验证结论： 验证通过 | ||||||||||||||||||||||||||||||
验证人签字 | 日 期 | 20XX 年3月12日 | |||||||||||||||||||||||||||||
需求规格技术评审报告
|
项目名称 | 物联网大数据平台 | ||||||||||||||||||
项目级别 | √公司级 □部门级 □ 子部门级 | 项目经理 | |||||||||||||||||
要求评审的工作产品的名称 | 《物联网大数据平台产品需求规格说明书》 | ||||||||||||||||||
产品作者 (评审申请人) | 建议评审时间 | 20XX 年3月9日 | |||||||||||||||||
要求评审的工作产品所属 开发阶段 | □规划阶段 √ 需求分析阶段 □ 系统设计阶段 □ 实现与测试阶段 □ 系统验收阶段 □ 安装运行阶段 □ 其它 | ||||||||||||||||||
评审准则 | ◆ 可追溯性：软件需求规格说明书中的每一个需求要一一列出并标识，与别的需求区别开来。每项需求只应在软件需求规格说明书中出现一次。 ◆ 正确性：软件需求都是与用户所期望的相符合。与涉及的相关行业技术规范相符合。 ◆ 完整性：软件需求规格说明书中没有遗漏任何必要的需求。 ◆ 一致性：各软件需求之间或软件需求与高层（系统，业务）需求之间不相矛盾。 ◆ 可行性：软件需求规格说明书中的每一个需求都是可实现的。 ◆ 无二义性：软件需求规格说明书中的每一个需求都只有惟一的含义。 ◆ 可验证性：软件需求规格说明书中的每一个需求对用户而言都是可验证、测试的。 ◆ 必要性：软件需求规格说明书中的每一个需求对用户而言都是必须的，没有画蛇添足。 ◆ 可理解性：软件需求规格说明书中的每一个需求都能清楚表达，保证项目干系人都能看懂。 ◆ 划分优先级：软件需求规格说明书中，应根据需求的轻重缓急对需求划分优先级。 ◆ 具有概要设计所需的相关的输入信息。 | ||||||||||||||||||
评审需提交 的资料 | 《物联网大数据平台产品需求规格说明书》 《物联网大数据平台用户需求调查报告》 《物联网大数据平台系统用户需求说明书（系统）》 《物联网大数据平台系统软件需求跟踪矩阵表单》 | ||||||||||||||||||
产品批准人 （审核人） 意 见 | √ 同意评审 由 担任评审负责人，按技术评审流程开展评审工作。 评审方式：√ 正式技术评审（会议评审） □ 非正式技术评审（□ Email会签 □ 走查 □其他： ） 评审级别：√ 部门级 □ 子部门级 □ 项目组内 □ 暂不评审 原因是：□ 方案不成熟 □ 资料不完整 □ 其他 | ||||||||||||||||||
签 字 | 日 期 | 20XX 年3月9日 | |||||||||||||||||
技 术 评 审 意 见 及 结 果 | |||||||||||||||||||
评审时间 | 自20XX 年3月9日11时 至 20XX 年3月9日 12 时 | ||||||||||||||||||
评审 问答 记录 |
1、在《产品需求规格说明书》中“1.3 文本读者”。描述相关读者对象，但不用描述他们用此文档做什么。 2、1.6名词解释。 3、“界面需求”，在对具体的功能模块描述的时候，要有相应的界面与之对应。 4、要有对需求优先级别的定义。 5、“内部文管理”模块，在总体结构中没有体现。 6、给出相关模块的界面图。 | ||||||||||||||||||
记录人签名 | 日 期 | 20XX 年3月9日 | |||||||||||||||||
评 审 人员签名 | |||||||||||||||||||
其他参与 人员签名 | |||||||||||||||||||
|
评审意见 汇 总 | 一、缺陷识别 无缺陷 二、总体评价及建议 总体需求分析比较透彻、完善；但需求优先级，相关需求界面没有进行描述，要进行详细补充。 基本通过。 20XX-3-9 | ||||||||||||||||||
评审结论 | □评审通过：工作产品合格，“无需修改”或“需要轻微修改但不必再审核”； √评审基本通过：工作产品基本合格，需要作少量修改，之后通过审核即可； □评审不通过：工作产品不合格，需要作比较大的修改，之后必须重新对其评审。 | ||||||||||||||||||
建议整改完成时间 | 20XX 年3月9日 | ||||||||||||||||||
评审负责人签字 | 日 期 | 20XX 年3月9日 | |||||||||||||||||
缺陷修正及验证（如果使用缺陷跟踪软件，则无需填写下表） | |||||||||||||||||||
序号 | 缺陷内容 | 修正措施 | 实施结果 | 实施人、日期 | |||||||||||||||
1 | |||||||||||||||||||
2 | |||||||||||||||||||
3 | |||||||||||||||||||
缺陷修正 验证情况 | 验证结论： 验证通过 | ||||||||||||||||||
验证人签字 | 日 期 | 20XX 年3月9日 |
|||||||||||||||||
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。