需求规格说明书评审报告文档格式.doc
- 文档编号:13049049
- 上传时间:2022-10-03
- 格式:DOC
- 页数:3
- 大小:53.50KB
需求规格说明书评审报告文档格式.doc
《需求规格说明书评审报告文档格式.doc》由会员分享,可在线阅读,更多相关《需求规格说明书评审报告文档格式.doc(3页珍藏版)》请在冰豆网上搜索。
XXX
建议评审时间
2007年10月8日
要求评审的工作产品所属
开发阶段
□规划阶段需求分析阶段□系统设计阶段
□实现与测试阶段□系统验收阶段□安装运行阶段□其它
评审准则
u可追溯性:
软件需求规格说明书中的每一个需求要一一列出并标识,与别的需求区别开来。
每项需求只应在软件需求规格说明书中出现一次。
◆正确性:
软件需求都是与用户所期望的相符合。
与涉及的相关行业技术规范相符合。
◆完整性:
软件需求规格说明书中没有遗漏任何必要的需求。
◆一致性:
各软件需求之间或软件需求与高层(系统,业务)需求之间不相矛盾。
◆可行性:
软件需求规格说明书中的每一个需求都是可实现的。
◆无二义性:
软件需求规格说明书中的每一个需求都只有惟一的含义。
◆可验证性:
软件需求规格说明书中的每一个需求对用户而言都是可验证、测试的。
◆必要性:
软件需求规格说明书中的每一个需求对用户而言都是必须的,没有画蛇添足。
◆可理解性:
软件需求规格说明书中的每一个需求都能清楚表达,保证项目干系人都能看懂。
◆划分优先级:
软件需求规格说明书中,应根据需求的轻重缓急对需求划分优先级。
u具有概要设计所需的相关的输入信息。
评审需提交
的资料
《FTCS用户需求调查报告》
《FTCS系统用户需求说明书(系统)》
《FTCS系统软件需求跟踪矩阵表单》
产品批准人
(审核人)
意见
同意评审
由XXX担任评审负责人,按技术评审流程开展评审工作。
评审方式:
正式技术评审(会议评审)
□非正式技术评审(□Email会签□走查□其他:
)
评审级别:
部门级□子部门级□项目组内
□暂不评审
原因是:
□方案不成熟□资料不完整□其他
签字
日期
2007年9月29日
技术评审意见及结果
评审时间
自2007年10月8日10时至2007年10月8日11时
评审
问答
记录
1、在《产品需求规格说明书》中“1.3文本读者”。
描述相关读者对象,但不用描述他们用此文档做什么。
2、1.6名词解释。
3、“界面需求”,在对具体的功能模块描述的时候,要有相应的界面与之对应。
4、要有对需求优先级别的定义。
5、“内部文管理”模块,在总体结构中没有体现。
6、给出相关模块的界面图。
记录人签名
ZZ
日期
2007年10月8日
评审
人员签名
XX,YY,ZZ,…
其他参与
评审意见
汇总
一、缺陷识别
无缺陷
二、总体评价及建议
总体需求分析比较透彻、完善;
但需求优先级,相关需求界面没有进行描述,要进行详细补充。
基本通过。
评审结论
□评审通过:
工作产品合格,“无需修改”或“需要轻微修改但不必再审核”;
评审基本通过:
工作产品基本合格,需要作少量修改,之后通过审核即可;
□评审不通过:
工作产品不合格,需要作比较大的修改,之后必须重新对其评审。
建议整改完成时间
2007年10月9日
评审负责人签字
xxx
日 期
缺陷修正及验证(如果使用缺陷跟踪软件,则无需填写下表)
序号
缺陷内容
修正措施
实施结果
实施人、日期
1
2
3
缺陷修正
验证情况
验证结论:
验证通过
验证人签字
ZZZ
2007年10月9日
-内部资料,注意保密-第3页共3页
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 需求 规格 说明书 评审 报告