□评审不通过：工作产品不合格，
需要作比较大的修改，之后必须重新对其评
审。
建议整改完成时间2007年10月9日
评审负责人签字
xxx
日期2007年10月8日
缺陷修正及验证（如果使用缺陷跟踪软件，则无需填写下表）
序号
缺陷内容
修正措施
实施结果实施人、日期
1
2
3
缺陷修正 验证情况
验证结论：
验证通过
验证人签字
ZZZ
评审准则
可追溯性：软件需求规格说明书中的每一个需求要一一列出并标识，与别 的需求区别开来。每项需求只应在软件需求规格说明书中出现一次。
♦正确性：软件需求都是与用户所期望的相符合。与涉及的相关行业技术规 范相符合。
♦完整性：软件需求规格说明书中没有遗漏任何必要的需求。
♦一致性：各软件需求之间或软件需求与高层（系统，业务）需求之间不相 矛盾。
日期
2007年10月9日
技术评审报告
项目名称
x
项目级别
□公司级宓部门级口子部门级项目经理XX
要求评审的工 作产品的名称
《FTCS产品需求规格说明书》
产品作者
（评审申请人）
XXX建议评审时间2007年10月8日
要求评审的工 作产品所属 开发阶段
□规划阶段宓需求分析阶段口系统设计阶段
□实现与测试阶段口系统验收阶段口安装运行阶段口 其它
♦可行性：软件需求规格说明书中的每一个需求都是可实现的。
♦无二义性：软件需求规格说明书中的每一个需求都只有惟一的含义。
♦可验证性：软件需求规格说明书中的每一个需求对用户而言都是可验证、 测试的。
♦必要性：软件需求规格说明书中的每一个需求对用户而言都是必须的，没 有画蛇添足。
♦可理解性：软件需求规格说明书中的每一个需求都能清楚表达，保证项目 干系人都能看懂。
□非正式技术评审（口Email会签□走杳 □其他：）
评审级别：□/部门级口子部门级口项目组内
□暂不评审
原因是：口 方案不成熟口 资料不完整口 其他
签字
XX
日
期
2007年9月29日
技术评
审意见及
结果
评审时间
自2007
年10月8日10时
至2007
年10月8日11时
1、在《产品需求规格说明书》中“
文本读者”。描述相关读者对象，但不用描述
他们用此文档做什么。
评审
2、名词解释。
问答
3、“界面需求”，在对具体的功能模块描述的时候，要有相应的界面与之对应。
记录
4、要有对需求优先级别的定义。
5、“内部文管理”模块，在总体结构中没有体现。
6、给出相关模块的界面图。
记录人签名ZZ
日期2007年10月8日
评审
XX,YY,ZZ,…
人员签名
其他参与
ZZ
♦划分优先级：软件需求规格说明书中，应根据需求的轻重缓急对需求划分 优先级。
具有概要设计所需的相关的输入信息。
评审需提交 的资料
《FTCS产品需求规格说明书》
《FTCS用户需求调查报告》
《FTCS系统用户需求说明书（系统）》
《FTCS系统软件需求跟踪矩阵表单》
产品批准人
（审核人） 意见
宓同意评审
由XXX担任评负责人，按技术评审流程开展评审工作。 评审方式：□/正式技术评审（会议评审）
人员签名
一、缺陷识别
评审意见
无缺陷
汇总
二、总体评价及建议
总体需求分析比较透彻、
完善 完善
;但需求优先级，相关需求界面没有进行描述，
要进行详细补充。
基本通过。
□评审通过：工作产品合格，“无需修改”或“需要轻微修改但不必再审核”；
冈评审基本通过： 工作产品基本合格，需要作少量修改，之后通过审核即可；
评审结论