软件需求评审报告

项目名称 XX科技有限公司XXXX项目 项目经√公司级 □ 部门级 □ 子部门级 项目级别 □理 要求评审的工作产品的《XXXXXXX综合管理系统需求规格说明书》 名称 产品作者 建议评审时(评审申请XXX 间 人) 要求评审的□规划阶段 □ 需求分析阶段 √□ 系统设计阶段 工作产品所□ 实现与测试阶段 □ 系统验收阶段 □ 安装运行阶段 □ 属 其它 开发阶段 可追溯性：软件需求规格说明书中的每一个需求要一一列出并标识，与别的需求区别开来。每项需求只应在软件需求规格说明书中出现一次。 ◆ 正确性：软件需求都是与用户所期望的相符合。与涉及的相关行业技术规范相符合。 ◆ 完整性：软件需求规格说明书中没有遗漏任何必要的需求。 ◆ 一致性：各软件需求之间或软件需求与高层（系统，业务）需求之间不相矛盾。 ◆ 可行性：软件需求规格说明书中的每一个需求都是可实现的。 ◆ 无二义性：软件需求规格说明书中的每一个需求都只有惟一的含义。 ◆ 可验证性：软件需求规格说明书中的每一个需求对用户而言 2016 年5月 31日 XXX 评审准则 都是可验证、测试的。 ◆ 必要性：软件需求规格说明书中的每一个需求对用户而言都是必须的，没有画蛇添足。 ◆ 可理解性：软件需求规格说明书中的每一个需求都能清楚表达，保证项目干系人都能看懂。 ◆ 划分优先级：软件需求规格说明书中，应根据需求的轻重缓急对需求划分优先级。 具有概要设计所需的相关的输入信息。 评审需提交 《IBMS智能楼宇综合管理系统需求规格说明书（版本）》 的资料 √□ 同意评审 由 XXX 担任评审负责人，按技术评审流程开展评审工作。 √ 正式技术评审（会议评审） 评审方式：□ □ 非正式技术评审（□ Email会签 □ 走查 □其产品批准人 他： ） （审核人） √ 部门级 □ 子部门级 □ 项目组内 评审级别：□意 见 □ 暂不评审 原因是：□ 方案不成熟 □ 资料不完整 □ 其他 2016 年5月 31签 字 日 期 日 技 术 评 审 意 见 及 结 果 评审时间 自 2016 年5月31日14时 至 2016 年5月 31日 18 时 1、 考虑用户同名情况，如何处理 2、 用户信息扩展要求 3、 增加跨平台要求 4、 增加系统支持点位容量功能描述 评审 5、 系统响应时间描述更详细一点 问答 6、 增加在虚拟机上测试 记录 7、 部署环境要求（最低要求、配置要求） 8、 模块化功能要求 记录人签XXX 名 评 审 人员签名 其他参与 人员签名 评审意见 汇 总 一、缺陷识别 无缺陷 二、总体评价及建议 总体需求分析比较透彻、完善；但需求优先级，相关需求界面没有进行描述，要进行详细补充。 基本通过。 □评审通过：工作产品合格，“无需修改”或“需要轻微修改但评审结论 不必再审核”； 日 期 2016 年5月 31日 √评审基本通过：工作产品基本合格，需要作少量修改，之后通□过审核即可； □评审不通过：工作产品不合格，需要作比较大的修改，之后必须重新对其评审。 建议整改完成 2016 年6月 2日 时间 评审负责人签 字 缺陷修正及验证（如果使用缺陷跟踪软件，则无需填写下表） 序缺陷内容 号 对系统能够支持的点1 数没有作出说明。 对系统能够支持的摄见需求分析文件中的需2 像机数量没有作出说求 明。 XXX、2016r对系统能否实现跨平3 台没有进行说明 求 日 XXX、2016r对系统能否在虚似机4 上运行没有进行说明 求 日 见需求分析文件中的需已实施 年06月01见需求分析文件中的需已实施 年06月01已实施 06月01日 XXX、2016年求 见需求分析文件中的需已实施 06月01日 修正措施 实施结果 期 XXX、2016年实施人、日日 期 2016 年5月 31日 对支行平台的计算机见需求分析文件中的需5 硬件的基本要求没有求4和需求5 作出评估。 缺陷修验证结论： 正 验证情验证人签 况

字 日 期 2016 年6月 2日 验证通过 已实施 06月01日 XXX、2016年