1、需求变更技术评审报告
2、需求跟踪矩阵表技术评审报告
3、需求规格说明书评审报告
技术评审报告
项目名称 | xxx管理系统 | |||
项目级别 | □ 公司级 √ 部门级 □ 子部门级 | 项目经理 | xxx | |
要求评审的工作产品的名称 | 《xxx需求规格说明书》 | |||
产品作者 (评审申请人) | xxx | 建议评审时间 | xxx年10月15日 | |
要求评审的工作产品所属 开发阶段 | □规划阶段 需求分析阶段 □ 系统设计阶段 □ 实现与测试阶段 □ 系统验收阶段 □ 安装运行阶段 □ 其它 | |||
评审准则 | u 可追溯性:软件需求规格说明书中的每一个需求要一一列出并标识,与别的需求区别开来。每项需求只应在软件需求规格说明书中出现一次。 ◆ 正确性:软件需求都是与用户所期望的相符合。与涉及的相关行业技术规范相符合。 ◆ 完整性:软件需求规格说明书中没有遗漏任何必要的需求。 ◆ 一致性:各软件需求之间或软件需求与高层(系统,业务)需求之间不相矛盾。 ◆ 可行性:软件需求规格说明书中的每一个需求都是可实现的。 ◆ 无二义性:软件需求规格说明书中的每一个需求都只有惟一的含义。 ◆ 可验证性:软件需求规格说明书中的每一个需求对用户而言都是可验证、测试的。 ◆ 必要性:软件需求规格说明书中的每一个需求对用户而言都是必须的,没有画蛇添足。 ◆ 可理解性:软件需求规格说明书中的每一个需求都能清楚表达,保证项目干系人都能看懂。 ◆ 划分优先级:软件需求规格说明书中,应根据需求的轻重缓急对需求划分优先级。 u 具有概要设计所需的相关的输入信息。 | |||
评审需提交 的资料 | 《xxx产品需求规格说明书》 《xxx用户需求调查报告》 《xxx系统用户需求说明书(系统)》 《xxx系统软件需求跟踪矩阵表单》 | |||
产品批准人 (审核人) 意 见 | √ 同意评审 由担任评审负责人,按技术评审流程开展评审工作。 评审方式:√ 正式技术评审(会议评审) □ 非正式技术评审(□ Email会签 □ 走查 □其他: ) 评审级别:□ 部门级 √ 子部门级 □ 项目组内 □ 暂不评审 原因是:□ 方案不成熟 □ 资料不完整 □ 其他 | |||
签 字 | xxx | 日 期 | xxx年10月15日 | |
技 术 评 审 意 见 及 结 果 | ||||
评审时间 | 自 xxx年10月15日14时 至 xxx年10月15日 16 时 | |||
评审 问答 记录 | 本次评审是针对用户的新增需求进行评审。 1、 此次需求的增加,对系统的整体进度影响有多大? 答:由于需求的变更点已经是在准备进行编码设计的时候了,所以需求增加后,也涉及到了系统设计的增加,整体的进度有偏差,但会进行有效的控制。 2、 此次需求的增加,存在什么技术上的问题吗? 答:此次增加的需求,在技术角度上是完全可以实现的,不存在什么技术难题,主要是要有时间来做这些增加。 | |||
记录人签名 | xxx | 日 期 | xxx年10月15日 | |
评 审 人员签名 | ||||
其他参与 人员签名 | ||||
评审意见 汇 总 | 一、缺陷识别
二、总体评价及建议 属于变更类项目。新增需求分析比较透彻、完善; 基本通过。 xxx xxx-XX-XX | |||
评审结论 | √评审通过:工作产品合格,“无需修改”或“需要轻微修改但不必再审核”; □评审基本通过:工作产品基本合格,需要作少量修改,之后通过审核即可; □评审不通过:工作产品不合格,需要作比较大的修改,之后必须重新对其评审。 | |||
建议整改完成时间 | xxx年10月15日 | |||
评审负责人签字 | xxx | 日 期 | xxx年10月15日 | |
缺陷修正及验证(如果使用缺陷跟踪软件,则无需填写下表) | ||||
序号 | 缺陷内容 | 修正措施 | 实施结果 | 实施人、日期 |
缺陷修正 验证情况 | 验证结论: 验证通过 | |||
验证人签字 | 日 期 | xxx年10月15日 |
需求跟踪矩阵表技术评审报告
项目名称 | xxx管理系统 | ||||||||||||
项目级别 | □ 公司级 √ 部门级 □ 子部门级 | 项目经理 | xxx | ||||||||||
要求评审的工作产品的名称 | 《xxx产品需求规格说明书》 《xxx 用户需求调查报告》 《xxx用户需求说明书(系统)》 《xxx软件需求跟踪矩阵表单》 | ||||||||||||
产品作者 (评审申请人) | xxx | 建议评审时间 | xxx 年10月9日 | ||||||||||
要求评审的工作产品所属 开发阶段 | □ 规划阶段 √需求分析阶段 □ 系统设计阶段 □ 实现与测试阶段 □ 系统验收阶段 □ 安装运行阶段 □ 其它 | ||||||||||||
评审准则 | u 可追溯性:软件需求规格说明书中的每一个需求要一一列出并标识,与别的需求区别开来。每项需求只应在软件需求规格说明书中出现一次。 ◆ 正确性:软件需求都是与用户所期望的相符合。与涉及的相关行业技术规范相符合。 ◆ 完整性:软件需求规格说明书中没有遗漏任何必要的需求。 ◆ 一致性:各软件需求之间或软件需求与高层(系统,业务)需求之间不相矛盾。 ◆ 可行性:软件需求规格说明书中的每一个需求都是可实现的。 ◆ 无二义性:软件需求规格说明书中的每一个需求都只有惟一的含义。 ◆ 可验证性:软件需求规格说明书中的每一个需求对用户而言都是可验证、测试的。 ◆ 必要性:软件需求规格说明书中的每一个需求对用户而言都是必须的,没有画蛇添足。 ◆ 可理解性:软件需求规格说明书中的每一个需求都能清楚表达,保证项目干系人都能看懂。 ◆ 划分优先级:软件需求规格说明书中,应根据需求的轻重缓急对需求划分优先级。 ◆ 具有概要设计所需的相关的输入信息。 | ||||||||||||
评审需提交 的资料 | 《xxx需求规格说明书》 《xxx 用户需求调查报告》 《xxx用户需求说明书(系统)》 《xxx软件需求跟踪矩阵表单》 | ||||||||||||
产品批准人 (审核人) 意 见 | √同意评审 由担任评审负责人,按技术评审流程开展评审工作。 评审方式:√正式技术评审(会议评审) □ 非正式技术评审(□ Email会签 □ 走查 □其他: ) 评审级别:□ 部门级 □ 子部门级 □ 项目组内 □ 暂不评审 原因是:□ 方案不成熟 □ 资料不完整 □ 其他 | ||||||||||||
签 字 | xxx | 日 期 | xxx 年10月9日 | ||||||||||
技 术 评 审 意 见 及 结 果 | |||||||||||||
评审时间 | 自 xxx 年10月9日10时 至 xxx 年10月9日 11 时 | ||||||||||||
评审 问答 记录 | 需求是否得到客户代表和所有最终客户的确认? 答:由用户需求调查表最先进行客户需求的调查,从而总结出用户需求说明书;根据用户需求说明书,需求分析人员得到产品需求规格说明书。已经得到所有用户的确认,并且已经签字。 1、在《产品需求规格说明书》中软件系统中的角色要求增加说明。 2、在《产品需求规格说明书》中需求有重复。 3、在《产品需求规格说明书》中应增加PC机的显示分辨率,如:800*600。 4、在《产品需求规格说明书》中4.3故障处理要求中第1、2项是目的不是要求,应该除去。 5、在《用户需求说明书》中2产品介绍中任务提出者由公司后勤改为研发中心。 6、在《用户需求调查报告》中调查对象中考虑增加对调查对象的名称。 7、在《用户需求调查报告》中建议写明参考某文件。 8、在《软件需求跟踪矩阵表单》的SRS列表中没有填写’需求分级’ 9、在《产品需求规格说明书》中实现语言建议改为实现语言及开发环境(建议QA修改模板)。 | ||||||||||||
记录人签名 | 王利 | 日 期 | xxx 年10月9日 | ||||||||||
评 审 人员签名 | |||||||||||||
其他参与 人员签名 | xxx | ||||||||||||
评审意见 汇 总 | 一、缺陷识别
二、总体评价及建议 需求分析比较透彻、完善,而且能够将客户需求与产品需求、高层设计、单元测试、集成测试和系统测试等统一起来管理,工作进行的比较认真。 基本通过。 xxx xxx-10-9 | ||||||||||||
评审结论 | □评审通过:工作产品合格,“无需修改”或“需要轻微修改但不必再审核”; √评审基本通过:工作产品基本合格,需要作少量修改,之后通过审核即可; □评审不通过:工作产品不合格,需要作比较大的修改,之后必须重新对其评审。 | ||||||||||||
建议整改完成时间 | xxx 年10月9日 | ||||||||||||
评审负责人签字 | xxx | 日 期 | xxx 年10月9日 | ||||||||||
缺陷修正及验证(如果使用缺陷跟踪软件,则无需填写下表) | |||||||||||||
序号 | 缺陷内容 | 修正措施 | 实施结果 | 实施人、日期 | |||||||||
1 | 在《软件需求跟踪矩阵表单》的SRS列表中没有填写’需求分级’ | 在需求跟踪矩阵中对SRS列表进行需求分级。 | 完成 | xxxxxx-10-9 | |||||||||
2 | 其它具体参见文档缺陷见《缺陷管理表》 | 其它具体参见文档缺陷见《缺陷管理表》 | 完成 | xxxxxx-10-9 | |||||||||
缺陷修正 验证情况 | 验证结论: 验证通过 | ||||||||||||
验证人签字 | 日 期 | xxx 年10月9日 |
技术评审报告
项目名称 | xxx项目 | |||
项目级别 | □ 公司级 √ 部门级 □ 子部门级 | 项目经理 | xxx | |
要求评审的工作产品的名称 | 《xxx产品需求规格说明书》 | |||
产品作者 (评审申请人) | xxx | 建议评审时间 | xxx 年10月 8日 | |
要求评审的工作产品所属 开发阶段 | □规划阶段 √ 需求分析阶段 □ 系统设计阶段 □ 实现与测试阶段 □ 系统验收阶段 □ 安装运行阶段 □ 其它 | |||
评审准则 | u 可追溯性:软件需求规格说明书中的每一个需求要一一列出并标识,与别的需求区别开来。每项需求只应在软件需求规格说明书中出现一次。 ◆ 正确性:软件需求都是与用户所期望的相符合。与涉及的相关行业技术规范相符合。 ◆ 完整性:软件需求规格说明书中没有遗漏任何必要的需求。 ◆ 一致性:各软件需求之间或软件需求与高层(系统,业务)需求之间不相矛盾。 ◆ 可行性:软件需求规格说明书中的每一个需求都是可实现的。 ◆ 无二义性:软件需求规格说明书中的每一个需求都只有惟一的含义。 ◆ 可验证性:软件需求规格说明书中的每一个需求对用户而言都是可验证、测试的。 ◆ 必要性:软件需求规格说明书中的每一个需求对用户而言都是必须的,没有画蛇添足。 ◆ 可理解性:软件需求规格说明书中的每一个需求都能清楚表达,保证项目干系人都能看懂。 ◆ 划分优先级:软件需求规格说明书中,应根据需求的轻重缓急对需求划分优先级。 u 具有概要设计所需的相关的输入信息。 | |||
评审需提交 的资料 | 《xxx产品需求规格说明书》 《xxx用户需求调查报告》 《xxx系统用户需求说明书(系统)》 《xxx系统软件需求跟踪矩阵表单》 | |||
产品批准人 (审核人) 意 见 | √ 同意评审 由担任评审负责人,按技术评审流程开展评审工作。 评审方式:√ 正式技术评审(会议评审) □ 非正式技术评审(□ Email会签 □ 走查 □其他: ) 评审级别:√ 部门级 □ 子部门级 □ 项目组内 □ 暂不评审 原因是:□ 方案不成熟 □ 资料不完整 □ 其他 | |||
签 字 | xxx | 日 期 | xxx 年9月 29日 | |
技 术 评 审 意 见 及 结 果 | ||||
评审时间 | 自 xxx 年10月 8日10时 至 xxx 年10月 8日 11 时 | |||
评审 问答 记录 | 1、在《产品需求规格说明书》中“1.3 文本读者”。描述相关读者对象,但不用描述他们用此文档做什么。 2、1.6名词解释。 3、“界面需求”,在对具体的功能模块描述的时候,要有相应的界面与之对应。 4、要有对需求优先级别的定义。 5、“内部文管理”模块,在总体结构中没有体现。 6、给出相关模块的界面图。 | |||
记录人签名 | xxx | 日 期 | xxx 年10月 8日 | |
评 审 人员签名 | ||||
其他参与 人员签名 | xxx | |||
评审意见 汇 总 | 一、缺陷识别 无缺陷 二、总体评价及建议 总体需求分析比较透彻、完善;但需求优先级,相关需求界面没有进行描述,要进行详细补充。 基本通过。 | |||
评审结论 | □评审通过:工作产品合格,“无需修改”或“需要轻微修改但不必再审核”; √评审基本通过:工作产品基本合格,需要作少量修改,之后通过审核即可; □评审不通过:工作产品不合格,需要作比较大的修改,之后必须重新对其评审。 | |||
建议整改完成时间 | xxx 年10月 9日 | |||
评审负责人签字 | xxx | 日 期 | xxx 年10月 8日 | |
缺陷修正及验证(如果使用缺陷跟踪软件,则无需填写下表) | ||||
序号 | 缺陷内容 | 修正措施 | 实施结果 | 实施人、日期 |
1 | ||||
2 | ||||
3 | ||||
缺陷修正 验证情况 | 验证结论: 验证通过 | |||
验证人签字 | 日 期 | xxx 年10月 9日 |