软件需求评审报告、评审要点、评审准则.docVIP

XX科技有限公司

PAGE

-内部资料，注意保密-第PAGE1页共NUMPAGES3页

软件需求评审报告

项目名称

XX科技有限公司XXXX项目

项目级别

eq\o\ac(□,√)公司级□部门级□子部门级

项目经理

XXX

要求评审的工作产品的名称

《XXXXXXX综合管理系统需求规格说明书》

产品作者

(评审申请人)

XXX

建议评审时间

年月日

要求评审的工作产品所属

开发阶段

□规划阶段□需求分析阶段eq\o\ac(□,√)系统设计阶段

□实现与测试阶段□系统验收阶段□安装运行阶段□其它

评审准则

可追溯性：软件需求规格说明书中的每一个需求要一一列出并标识，与别的需求区别开来。每项需求只应在软件需求规格说明书中出现一次。

正确性：软件需求都是与用户所期望的相符合。与涉及的相关行业技术规范相符合。

完整性：软件需求规格说明书中没有遗漏任何必要的需求。

一致性：各软件需求之间或软件需求与高层（系统，业务）需求之间不相矛盾。

可行性：软件需求规格说明书中的每一个需求都是可实现的。

无二义性：软件需求规格说明书中的每一个需求都只有惟一的含义。

可验证性：软件需求规格说明书中的每一个需求对用户而言都是可验证、测试的。

必要性：软件需求规格说明书中的每一个需求对用户而言都是必须的，没有画蛇添足。

可理解性：软件需求规格说明书中的每一个需求都能清楚表达，保证项目干系人都能看懂。

划分优先级：软件需求规格说明书中，应根据需求的轻重缓急对需求划分优先级。

具有概要设计所需的相关的输入信息。

评审需提交

的资料

《IBMS智能楼宇综合管理系统需求规格说明书（V1.1版本）》

产品批准人

（审核人）

意见

eq\o\ac(□,√)同意评审

由XXX担任评审负责人，按技术评审流程开展评审工作。

评审方式：eq\o\ac(□,√)正式技术评审（会议评审）

□非正式技术评审（□Email会签□走查□其他：）

评审级别：eq\o\ac(□,√)部门级□子部门级□项目组内

暂不评审

原因是：□方案不成熟□资料不完整□其他

签字

日期

2016年5月31日

技术评审意见及结果

评审时间

自年月日时至年月日时

评审

问答

记录

考虑用户同名情况，如何处理

用户信息扩展要求

增加跨平台要求

增加系统支持点位容量功能描述

系统响应时间描述更详细一点

增加在虚拟机上测试

部署环境要求（最低要求、配置要求）

模块化功能要求

9、等等

记录人签名

XXX

日期

2016年5月31日

评审

人员签名

其他参与

人员签名

评审意见

汇总

一、缺陷识别

无缺陷

二、总体评价及建议

总体需求分析比较透彻、完善；但需求优先级，相关需求界面没有进行描述，要进行详细补充。

基本通过。

评审结论

□评审通过：工作产品合格，“无需修改”或“需要轻微修改但不必再审核”；

eq\o\ac(□,√)评审基本通过：工作产品基本合格，需要作少量修改，之后通过审核即可；

□评审不通过：工作产品不合格，需要作比较大的修改，之后必须重新对其评审。

建议整改完成时间

2016年6月2日

评审负责人签字

日期

2016年5月31日

缺陷修正及验证（如果使用缺陷跟踪软件，则无需填写下表）

序号

缺陷内容

修正措施

实施结果

实施人、日期

1

对系统能够支持的点数没有作出说明。

见需求分析文件中的需求6.5

已实施

XXX、年月日

2

对系统能够支持的摄像机数量没有作出说明。

见需求分析文件中的需求6.5

已实施

XXX、年月日

3

对系统能否实现跨平台没有进行说明

见需求分析文件中的需求6.6

已实施

XXX、年月日

4

对系统能否在虚似机上运行没有进行说明

见需求分析文件中的需求6.6

已实施

XXX、年月日

5

对支行平台的计算机硬件的基本要求没有作出评估。

见需求分析文件中的需求4和需求5

已实施

XXX、年月日

缺陷修正

验证情况

验证结论：

验证通过

验证人签字

日期

年月日