(完整版)需求评审表
采购文件项目需求及评审建议表【模板】

(一)采购标的需实现的功能或者目标,以及为落实政府采购政策需满足的、地方标准或者其他标准、规范;
(三)采购标的需满足的质量、安全、技术规格、物理特性等要求;
(四)采购标的的数量、采购项目交付或者实施的时间和地点;
(五)采购标的需满足的服务标准、期限、效率等要求;
(六)采购标的的验收标准;
(七)采购标的的其他技术、服务等要求;
(八)非单一产品采购项目,采购标的中的核心产品。
四、评审方法与评审标准(评定成交的标准)建议
备注
采购文件项目需求及评审建议表
委托单位(公章)
项目名称
采购计划编号
委托人授权代理人
联系电话
一、供应商的资格要求(注:1、不得将投标人的注册资本、资产总额、营业收入、从业人员、利润、纳税额等规模条件作为资格要求;2、不得将除进口货物以外的生产厂家授权、承诺、证明、背书等作为资格要求)
二、项目最高限价(如有请填写)
需求评审检查表(模板)

评审检查项数 不合格数 检查项 相关描述是否符合用户需求? 输入、输出的描述是否完整? 所有已描述的功能是否是必须的?
11 评审时长 1 合格率 裁剪说明 检查结果 检查 豁免 检查 不合格 合格 合格 合格 合格 合格 合格 合格 合格 合格 合格
系统连续运行时间假设是否符合用户需求,是否与环境相匹配? 检查 系统环境定义是否完整(硬件平台与配置、操作系统、数据库系 检查 统、中间件),是否符合用户需求? 是否所有与需求相关的安装特性都被包含了 是否所有与需求相关的维护特性都被包含了? 是否所有与需求相关的安全特性都被包含了? 检查 检查 检查 检查 检查 检查
6 7 8 9
系统安全方案是否完整,是否符合用户需求 系统日志功能是否符合用户需求和工程维护的需要? 系统灾备方案是否符合用户需求,是否与环境相匹配?
需求定义是否包含了有关功能、性能、限制、目标、质量等方面 检查 的所有需求功能需求是否覆盖了所有非正式情况的处理?
小时 90.91% 说明 不合格说明
需求规格评审检查表

是 是
否 否
是
否
是 是 是 是 是 是 是 是 是
否 否 否 否 否 否 否 否
112488372.xls
1/3
项目名称: 3. 一 致 要素 代号 性 3.9 3.10 3.11 3.12 3.13 4.1 4. 可 修 改 性 5. 可 追 踪 性 4.2 4.3 4.4 5.1 5.2 6.1 6.2 6. 6.3 其 它 6.4 6.5 6.6
是 是 是 是 是 是 是 是 是 是 是 是 是 是 是 是 是
评审对象: 评审人/时间: 评审记录
否 否 否 否 否 否 否 否 否 否 否 否 否 否 否 否 否
等级 必要 必要 必要 必要 必要 必要 必要 必要 必要 必要 必要 必要 必要 必要 必要 必要 必要
问题描述/不合格需求数
单条需求说明评审检查项 7. 功 能 需 求 、 性 能 需 求 、 质 量 属 性 需 求 、 外 7.1 7.2 7.3 7.4 每个叶节点需求是否都有优先级? 每个叶节点需求是否都有项目内唯一的标识? 每个叶节点需求是否可验证(应注意验证的代价。 如果验证的代价太大,也认为是不可验证的)? 需求描述是否正确? 需求描述是否完整(至少应“可验证”,且描述了 模板要求的所有“字段”。另外,对所有可能出现 的输入/激励都应予以定义;应对合法和非合法的输 入值的响应做出规定;未遗漏插图、表、图示标记 和参照,并且定义了使用到的术语和度量单位、取 值范围等) 从成本、进度、技术角度来看,需求是否可行? 从市场角度来看,需求是否必要?
XXX产品需求说明书评审检查单(V1.0)
细分要素 各性能需求在内容上是否与功能需求、质量属性需 求、外部接口需求、其它需求一致? 各质量属性需求在内容上是否与功能需求、性能需 求、外部接口需求、其它需求一致? 各外部接口需求在内容上是否与功能需求、性能需 求、质量属性需求、其它需求一致? 各其它需求在内容上是否与功能需求、性能需求、 质量属性需求、外部接口需求一致? 所有需求的编写在详细程度上是否都一致或合适? 变更一个需求是否不会对其它若干需求有重大影 响? 功能需求、性能需求、质量属性需求、外部接口需 求、其它需求各自及相互间是否不存在冗余? 内部交叉引用是否正确、明确(读者应能在1分钟之 内定位被引用的内容)? 外部引用是否正确、明确(具有权限的读者应能在 10分钟之内定位被引用的内容)? 需求中提出的要求,是否可追溯到“软件开发任务 书”或“系统/子系统设计文档”? 与需求相关的表格的使用是否符合要求(即不可以 使用n (2 =< n < 全部) 个单元格描述一个需求)? 已经描述的、本文涉及的术语、定义及缩略语正确 、完整? 是否已可基于需求进行设计? 是否已可基于需求进行系统测试方案及系统测试用 例的编写? 是否已可基于需求编写用户类文档(初稿)? 是否考虑了软件的数据保密性要求? 是否考虑了初始状态和特殊状态(例如:冷启动、 异常终止)?
评审表怎么填写范本

评审表怎么填写范本评审表范本:项目名称:XXX项目评审人姓名:XXX评审日期:XXXX年XX月XX日评审内容:1. 项目目标和需求分析方案的详细度和可行性2. 项目计划和进度安排的合理性3. 项目组成员的能力和责任划分4. 技术方案和系统设计的合理性和可行性5. 项目实施过程中风险管理方案6. 预算和资源的合理使用7. 项目报告的清晰度和完整度评审标准:5分:完全符合要求,无须进一步讨论4分:大部分符合要求,可接受3分:部分符合要求,需要进一步改进2分:不符合要求,但可以进行修正1分:完全不符合要求,不可接受评审结果:1. 项目目标和需求分析方案的详细度和可行性:4分评审意见:需求分析较为详细,但具体实施方案可进一步完善。
2. 项目计划和进度安排的合理性:3分评审意见:项目计划较为合理,但进度安排较为紧张,需进一步评估可行性。
3. 项目组成员的能力和责任划分:5分评审意见:项目组成员能力较强,责任划分明确。
4. 技术方案和系统设计的合理性和可行性:2分评审意见:技术方案和系统设计缺乏详细说明,需要进一步完善。
5. 项目实施过程中风险管理方案:4分评审意见:风险管理方案较为完善,但需要进一步完善应急预案。
6. 预算和资源的合理使用:3分评审意见:预算和资源的使用较为合理,但还可以进一步优化。
7. 项目报告的清晰度和完整度:4分评审意见:项目报告详细完整,逻辑清晰,但可增加图表等可视化内容。
综合评价:XXX项目在目标和需求分析、项目组成员能力和责任划分等方面表现较好,但在技术方案和系统设计、进度安排等方面还有待改进。
建议在改进方案中更加详细说明技术实施细节、优化进度安排,并补充相关预算和资源的详细使用计划。
同时,可以考虑增加项目报告的可视化内容,提升报告的展示效果。
设计评审表(需求分析)

需求设计评审表
设计名称需求分析说明书
项目名称
日期合同编号
参加人员
设计要求
根据项目合同以及客户部与客户接触调研所提供的材料,编写需求分析说明书。
编写的需求说明书能充分表达客户的需求,能作为软件编码、设计、测试及技术管理人员提供下一步工作的依据。
评审重点
评审重点:
1、是否符合软件需求分析说明书的编写规范。
2、是否能为编写《概要设计说明书》提供依据。
3、是否能为软件编码、设计人员提供依据。
4、是否能为软件测试人员提供依据。
评审意见
该文档的编写符合设计要求,可以通过评审。
人员签到:。
需求规格说明评审表

是否每一个需求都只有一种解释
功能性需求是否以模块方式描述的,是否明确地标识了其功能
评审意见:通过修改后复审(问题附后)未通过
参加评审人员签年 月 日
研发部经理审批意见:
研发部经理(签字):_______ 年 月 日
需求规格评审表
项目名称
评审时间
评审内容
评审结论是否通过(请以√表示)
硬件
软件
网管
软件,硬件,网管规格是否覆盖总休规格需求
软件,硬件,网管规格是否做到细化说明
硬件设计是否满足软件需求
在功能实现过程、方法和技术要求的描述上,是否背离了功能的实际要求
是否有不能理解或造成误解的描述
是否所有与需求相关的设计约束都包含了
是否所有与需求相关的硬件都被包含了
是否所有与需求相关的软件都被包含了
是否所有与需求相关的输入输出都被包含了
是否所有与需求相关的安全特性都被包含了
是否对各种操作模式(如正常、非正常、有干扰等)下的环境条件都做了规定
需求定义是否满足标准的要求
是否定义了对在错误、危险分析中所标识的各种故障模式和错误类型所需的反应
需求评审表

(1)分类查询
提供角色分类查询功能
业务系统分类选择、角色类型分类选择
经过分类的角色列表页面
5.2.2.6
用户角色配置管理
5.2.2.6.1
用户角色配置管理
(1)
用户角色配置管理
为业务系统的管理员提供给机构用户进行自有业务系统的角色配置功能
用户名称,业务系统名称、权限类型,角色名称
已进行角色配置的用户列表页面
.
权限管理系统中必须有外部系统的登记信息等.
5.3.2.2
业务系统用户访问权限获取-用户权限获取
该部分向进行了权限设定的业务系统提供业务系统用户访问权限的获取功能
权限管理系统中必须有外部系统的登记信息等.
登陆帐号调用信息验证用户
界面自定义系统
5.4
界面自定义系统
5.4.1
系统VI管理
对整个系统VI(Visual Identity视觉形象识别系统)的定制管理,包括系统的logo标识,系统所允许选择的背景,系统名称等(以后逐步完善)
需求评审表
编号
名称
功能需求
系统需求
批注
确认
功能概述
输入
输出
前提条件
基本流程
组织架构管理系统
5.2.1
组织架构管理系统
该系统的使用者只有SUPERVISOR。
5.2.1.1
机构管理
提供机构管理主页面功能
机构代码、机构名称等等..
多级(集团性)机构信息页面
qingliang
5.2.1.2
部门管理
提供部门管理主页面功能
业务系统名称,业务系统代号
业务系统列表页面
5.2.2.2
权限管理系统用户管理
产品部需求评审表模板

中心/部门 实际时间
1 2 3 4 实 际 操 作 阶 段 5 6 7 8 9 10 产品意见: 研发意见: 总经理核准:
1.需求分类:A、Bug修复;B、功能优化;C、新增需求(只填字母) 2.优先级:此栏等级次序为:P1>P2>P3 3.签字确认:此栏重要改动需求经上级确认(可为空)
评 审 决 议
产品部-需求评审模板
项目名称: 阶段 序号 所属模块 名称 需求 优先级 时间 提交人 项目阶段: 申请 项目负责人: 产品计划 需求分析 预计时间 原型设计 实际时间 预计时间 UI设计 实际时间 预计时间 架构设计 实际时间 预计时间 立项时间: 确认时间: 开发计划 开发实施 实际时间 预计时间 测试验收 实际时间 预计时间 备注
负责人签字/日期: 负责人签字/日期: 核准签字/日期:
பைடு நூலகம்备 注 说 明
编制:
审查:
核准:
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
(完整版)需求评审表
(完整版) 需求评审表
项目信息
- 项目名称:
- 提交日期:
- 项目负责人:
- 评审日期:
- 评审人员:
需求概述
(在此处对需求进行简要概述,包括项目的背景、目标以及主要功能模块)
评审目的
(在此处说明进行需求评审的目的,例如确保需求的准确性、完整性和可行性,避免后期开发过程中的问题)
需求评审内容
功能需求
(在此处列出各个功能的详细描述,包括输入/输出、操作流程、业务规则等)
非功能需求
(在此处列出诸如性能、可用性、安全性等方面的非功能需求)
界面设计
(在此处对系统的界面设计进行评审,包括页面布局、颜色搭配、交互效果等)
数据库设计
(在此处对系统的数据库设计进行评审,包括表结构、字段定义、关系设计等)
评审结果
(在此处根据评审的内容进行评审结果的总结,包括各个方面
的问题及解决方案、意见和建议等)
审核意见
(在此处根据评审结果提出具体的审核意见,并可以要求作出
相应修改或补充)
参考材料
(在此处可以列出与需求相关的文档或资料,方便评审人员参考)
附件
(在此处可以列出与需求相关的附件,如界面原型图、用户故
事等)
以上是本次需求评审表的完整版,敬请查阅,并及时进行评审。
如有任何问题或需要进一步讨论,请及时与项目负责人联系。
谢谢
合作!
以上是一份完整版的需求评审表,你可以根据实际情况修改和
完善其中的内容,确保文档符合实际需求评审过程中的要求。