需求评审表
相关方需求与期望评审表
1、采购信息描述清楚；
3
供方与合作伙伴
2、价格合理，订单稳定； 3、沟通渠道畅通；
4、良好的付款信誉；
供应商年审核考评表 来料批数合格率 货款月结
每年一次 每月一次 每月一次
4 员工
1、薪资、福利的增加； 2、提供培训机会； 3、有一定的娱乐活动； 4、良好的工作环境； 5、职业安全和健康； 6、得到承认和奖励； 7、合理的工作时间；
序号 相关方类型
需求与期望
XX有限公司
相关方需求与期望评审表
监测指标或项目
1 顾客
1、产品的订单交付及时； 2、产品质量符合顾客要求； 3、产品服务及时； 4、投诉得到及时满意的处理； 5、沟通渠道畅通；
顾客满意度 客户投诉率 交期变更率
监测频率 每年一年 每月一次 每月一次
2 所有者
持续的盈利能力；团队的管理能力； 公司管理层人员绩效考核 每年一年
1、公司标准的薪酬制度； 2、公司管理制度公平、透 明、高效； 3、公司良好的培训制度及 执行机制； 4、改善工作环境
每年一次
5
社会
6 审核机构
7 政府机构
就业机会、环境保护、道德行为、遵守 法律法规
经营指标、环境健康安全指 标考核
每年一年
1、公司体系运作的有效性、充分性和 符合性，满足相关标准要求； 2、按时接收监督、换证审核；每年一次
规范化经营
安全生产、环保生产、就业最大化、经
营效益好
工伤事故考核
效益
每年一次 每月一次 每年一次
监测部门 营销中心 营销中心 营销中心/生 产部 人力资源部 采购部 品质部 财务部
人力资源部
人力资源部
品质部
生产部 人力资源部 总经理
项目需求评审表
项目需求评审表
合同号
年月日 /
项目名称
项目编号
/
项目评审 方式工程概况 及任 Nhomakorabea范围
客户对项 目不明确 或不合理
要求
技术评审
会议 □ 传阅
评审依据
任务书 □客户单位口头记录
为客户提供网络、硬件等信息化建设中所需的内容提供技术支持与维护服务。
填写人：
日期：
（技术要求、质量要求、进度要求、支持服务、价格等）
客户基本能了解我司提供的项目情况，暂时未发生不合理情况。
填写人：
日期：
（人力资源、物力资源）：
人员资源、物力资源充足，可以胜任本次项目建设。
填写人：
日期：
评审结论 能胜任本次项目建设。
项目负责人：
日期：
评审会签
客户结论
所提供服务能满足我司要求。 客户负责人：
日期：
可靠性需求分析评审表
可靠性需求分析评审表
1. 评审目的
本评审表的目的是对可靠性需求进行分析和评审，以确保在设计和开发过程中满足可靠性标准。
2. 评审内容
3. 评审过程
1. 将可靠性需求分析文档分发给评审人员。
2. 评审人员独立阅读需求文档，确保对内容有全面的了解。
3. 就每个评审项目提出问题、意见或建议。
4. 对每个评审项目进行讨论，确保达成一致意见。
5. 记录评审过程中的所有问题、意见和建议。
6. 归纳评审人员的意见和建议，形成评审报告。
4. 评审标准
针对每个评审项目，使用以下评审标准进行评估：
- 满足：符合所有评审标准，无需进一步修改。
满足：符合所有评审标准，无需进一步修改。
- 部分满足：在一些方面不符合评审标准，但可以接受。
部分满足：在一些方面不符合评审标准，但可以接受。
- 不满足：在多个方面不符合评审标准，需要修改。
不满足：在多个方面不符合评审标准，需要修改。
5. 结论
可靠性需求分析评审是确保设计和开发过程中的可靠性标准得到满足的重要环节。
通过本评审表的使用，能够全面评估可靠性需
求的合理性、准确性和可行性。
评审人员的意见和建议将为后续的设计和开发工作提供重要参考。
请在下方记录评审意见和建议。
技术评审表
技术评审表序号评审内容分值评审规则得分1.服务总体实施方案10分（1）针对本项目需求，提供详细的作业方案，包括但不限于清扫保洁（含垃圾收集）、垃圾压缩中转站管理、垃圾转运、公厕管理方案、项目重点难点问题及相应的解决措施等。
方案内容完整、合理、可行性强的，得5分；方案内容较为完整、较为合理、可行性一般的，得4分；方案内容一般完整、不太合理、可行性差的，得3分；不提供不得分。
（2）编制具有保证环卫作业质量可行性措施、质量保障措施，措施内容完整、合理、可行性强的，得5分；措施内容较为完整、较为合理、可行性一般的，得4分；措施内容一般完整、不太合理、可行性差的，得3分。
不提供不得分。
0-10分2.项目接收与移交方案10分（1）项目对人员的接收与移交方案。
方案内容完整、合理、可行性强的，得3分；方案内容较为完整、较为合理、可行性一般的，得2分；方案内容一般完整、不太合理、可行性差的，得1分。
不提供不得分。
（2）新设备进场、旧设备移除清理方案。
方案内容完整、合理、可行性强的，得3分；方案内容较为完整、较为合理、可行性一般的，得2分；方案内容一般完整、不太合理、可行性差的，得1分。
不提供不得分。
（3）合同期满项目交接方案。
方案内容完整、合理、可行性强的，得4分；方案内容较为完整、较为合理、可行性一般的，得3分；方案内容一般完整、不太合理、可行性差的，得2分。
0-10分不提供不得分。
3.项目管理架构和人员配置30分按项目管理架构设置、人员管理方案、拟投入人员的综合素质进行评分：①针对本项目有详细可行的管理架构，制定人员管理方案，有人员培训和晋升计划，可保障和吸引人才从事本市环卫工作的，方案内容完整、合理、可行性强的，得5分；方案内容较为完整、较为合理、可行性一般的，得4分；方案内容一般完整、不太合理、可行性差的，得3分。
不提供不得分。
②拟投入本项目的项目负责人（1人）获得：1）本科或以上学历；2）地级市或以上政府相关职能部门颁发的中级或以上职称证书；3）地级市或以上住建部门或应急管理部门或安监局颁发的安全生产考核合格证书；4）地级市或以上政府相关行政主管部门颁发的中级或以上有害生物防制员资格证书；5）政府或其相关行政机关/事业单位颁发的“城市美容师”证书；6）具有五年或以上项目管理经验，第1）、2）项，每项得1分，3）、4）、5）、6）项，每项得1.5分，该小项最高分8分。
(完整版)需求评审表
(完整版)需求评审表
(完整版) 需求评审表
项目信息
- 项目名称：
- 提交日期：
- 项目负责人：
- 评审日期：
- 评审人员：
需求概述
（在此处对需求进行简要概述，包括项目的背景、目标以及主要功能模块）
评审目的
（在此处说明进行需求评审的目的，例如确保需求的准确性、完整性和可行性，避免后期开发过程中的问题）
需求评审内容
功能需求
（在此处列出各个功能的详细描述，包括输入/输出、操作流程、业务规则等）
非功能需求
（在此处列出诸如性能、可用性、安全性等方面的非功能需求）
界面设计
（在此处对系统的界面设计进行评审，包括页面布局、颜色搭配、交互效果等）
数据库设计
（在此处对系统的数据库设计进行评审，包括表结构、字段定义、关系设计等）
评审结果
（在此处根据评审的内容进行评审结果的总结，包括各个方面
的问题及解决方案、意见和建议等）
审核意见
（在此处根据评审结果提出具体的审核意见，并可以要求作出
相应修改或补充）
参考材料
（在此处可以列出与需求相关的文档或资料，方便评审人员参考）
附件
（在此处可以列出与需求相关的附件，如界面原型图、用户故
事等）
以上是本次需求评审表的完整版，敬请查阅，并及时进行评审。
如有任何问题或需要进一步讨论，请及时与项目负责人联系。
谢谢
合作！
以上是一份完整版的需求评审表，你可以根据实际情况修改和
完善其中的内容，确保文档符合实际需求评审过程中的要求。
产品设计评审表模板
产品设计评审表模板1. 产品信息
- 产品名称：
- 产品描述：
- 产品分类：
- 受众群体：
- 竞争对手：
- 数据来源：
2. 目标
- 主要目标：
- 附加目标：
3. 设计准则
- 用户体验：
- 可用性：
- 可靠性：
- 安全性：
- 可维护性：4. 功能需求
- 必需功能：
- 附加功能：
- 不做的功能：5. 技术要求
- 技术框架：
- 系统要求：
- 数据库需求：- 测试要求：
6. 时限与资源- 开发周期：
- 团队人员：
- 预算：
- 依赖资源：7. 风险评估
- 技术风险：
- 时间风险：
- 人员风险：
- 市场风险：
- 其他风险：8. 监控与评估
- 监控指标：
- 评估方法：
- 反馈渠道：9. 决策与审批
- 项目经理：
- 设计团队：
- 技术团队：
- 高层管理：
10. 附加材料
- 原型设计：
- 需求文档：
- 技术文档：
- 其他参考资料：
以上为产品设计评审表模板，需要根据具体产品的需求进行相应填写和调整。
此评审表旨在提供一个全面的产品设计评估框架，以确保产品满足市场需求和用户期望，并在开发过程中管理风险和资源。
客户需求评审表模板
顾客需求评审记录表
顾客编号
顾客需求的确认
供货能力 1.批量订单数量、货期 2.样品交期
评审意见：
技术能力要求 3.产品的性能指标要求 执行标准 4.产品包装要求 5.运输方式 6.其他
评审意见：
质保能力要求： 7.关键尺寸 8.客户批量验收标准 9.客户样品认定标准 10.客户需提供的资料 11.对我司的质保要求 12.其他
产品名称 顾客需求的评审
计划物控部： 工业工程部： 品质部： 压铸厂： 喷塑厂：
评审意见：
制造能力要求： 13.产品的性能指标要求 评审意见：
执行标准
14.铝锭材质要求
15..压铸设备型号
16.精工打磨设备型号
17.是否有外购物料
18.其他
制造能力要求： 19.产品的性能指来自要求评审意见：执行标准
20.塑粉牌号要求
21.挂具要求
22.是否有外购物料
23.其他
需跟客户再沟通确认事项：
产品需求说明书PRD评审表
我司产品的主要卖点是否能与竞争产品竞争？
需求是否确定优先级？
对市场需求的重要性分类,需要市场、技术、销售等相关人员达成一致
客户需求是否得到充分验证？
（产品经理找客服人员确认PRD文档，12.9得出结论）
可运营需求
产品需求说明书PRD评审表
项目名称:
评审项
评审要素
检查结果
评审操作指导
备注
是
否
免
产品需求
产品市场需求是否清晰并依据产品市场需求说明书模板进行了整理？
必须依照模板编写，保证内容的全面性。
所有的客户需求（外部需求）是否得到采纳？
关注外部客户需求，包括主要客户的$APPEALS需求。
说明：识别哪些客户需求必须包含在产品需求中？
客户的所有需求是否得到定义？如果没有全部得到采纳，需说明情况和理由。
已采纳需求是否满足主要客户提出的主要需求？
如果客户需求只得到部分采纳，已采纳需求是否包括了主要客户的主要需求。也要注意到主要客户的特殊需求，并评估该需求的市场前景，当前的微小需求是否可以演变成一个机会点
竞争产品的主要特性（功能、性能）我司产品能否提供？
2评审人员：产品经理，ID设计师，UI设计师，交互设计师，SDE，硬件主管，软件主管，测试主管，结构主管，认证工程师，专利工程师，运营工程师，DQA，及其他相关人员
签名
检查人：_____________部门：__________________日期：__运营未给出需求
软件著作权
是否具备软件著作权申报条件
安规认证
认证需求是否满足
关键物料
关键物料的供应商/物料选择计划是否已经考虑？
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
需有“组织架构”的树型结构图
采纳
1
软件界面
大部分界面里，设计显得比较粗糙，颜色搭配不够协调，而且最为明显的是，实用性不足，每一块布局的面积都不太合乎比例，导致信息显示空间太少,参考作用性不太!
完善中
2
软件界面
界面设计关注点"的描述不太明白,菜单功能模块、操作功能键与以表单数据内容结合是什么意思，我建设做到数据内容和界面样式分离，这样可以对界面样式作多方面的尝试或者改动上，不至于影响数据内容的显示。
采纳
3
需求规格说明书
权限管理部分未见与用户的关系
已有
4
需求规格说明书
操作权限系统的用户和系统普通用户有什么区别？
已有
5
需求规格说明书
15页分类查询的含义
已有
6
需求规格说明书
权限类型的含义？
已有
7
需求规格说明书
用户，角色，权限三者的关系描述不清晰,个体的操作行为对其他相关内容的影响没有描述
已有
8
需求规格说明书
权限列表页面
5.2.2.4.2
权限查询
（1）分类查询
提供权限分类查询功能
业务系统分类选择、权限类型分类选择
经过分类的权限列表页面
5.2.2.5
角色管理
5.2.2.5.1
角色管理
为业务系统的管理员提供自有业务系统的角色配置功能
角色名称、对应业务系统
角色列表页面。显示的栏目包括角色名称
5.2.2.5.2
角色查询
（1）分类查询
提供角色分类查询功能
业务系统分类选择、角色类型分类选择
经过分类的角色列表页面
5.2.2.6
用户角色配置管理
5.2.2.6.1
用户角色配置管理
(1)
用户角色配置管理
为业务系统的管理员提供给机构用户进行自有业务系统的角色配置功能
用户名称，业务系统名称、权限类型，角色名称
已进行角色配置的用户列表页面
权限的配置流程不清晰
完善中
9
需求规格说明书
业务系统配置角色，用户配置角色，二者的关系？
已有
10
需求规格说明书
组织架构管理中有用户认证？
已有
11
需求规格说明书
实体关系图看不明白
已有
12
需求规格说明书
界面自定义部分缺少操作描述
完善中
沈毅强
5.1
角色
缺“部门管理员”---管理本分公司/本部门的用户
采纳
5.2.1
(2)
用户角色配置查询
（1）分类查询
提供用户角色分类查询功能
用户分类选择、业务系统分类选择
经过分类的用户列表页面
5.2.2.6.2
业务系统用户接口角色管理
(1)
业务系统用户接口角色配置管理
对使用业务系统接口的业务系统用户进行使用接口角色配置
业务系统用户名称，业务系统名称，角色名称、权限类型
已进行角色配置的业务系统用户列表页面
机构名称、部门代码等等..
多级部门信息页面
ｑｉｎｇｌｉａｎｇ
5.2.1.3
用户管理
5.2.1.3.1
用户维护要求
提供用户管理主页面功能
机构名称、部门名称等等..
用户列表页面
Qingbing
5.2.1.3.2
用户查询要求
（1）分类查询
提供用户分类查询功能
机构分类选择、部门分类选择
经过分类的用户列表页面
权限中要考虑门户和权限影射
暂不考虑
2
组织结构
是否满足集团化组织结构设置及系统布置（包括数据库分库或分布式设备控制等可能的情况）
采纳部分
分布式设备控制在本阶段暂无涉猎
3
界面
基础同意界面中显示部分（现有DOMINO协同平台的风格基本相统一）。但公司的品名牌标记/用户的页眉标记等信息是否现在明确
采纳
梁明
1
(2)
业务系统用户接口角色配置查询
（1）分类查询
提供对已配置的业务系统用户接口角色分类查询功能
所属业务系统分类选择、使用接口业务系统分类选择
经过分类的业务系统用户使用接口情况列表页面
5.3.2
权限管理系统
5.3.2.1
业务系统用户访问权限认证-用户权限认证
该部分向进行了权限设定的业务系统提供用户权限认证功能
5.4.2
界面模板管理
针对普通用户的界面模板定制，包括界面中的色彩，字体及其大小，文字背景等界面基本元素的定制
普通用户可以定制属于自己的模板类型，并设置默认风格。
项目组各成员意见汇总
意见提出者
编号
问题模块
问题描述
解析人
解析内容
修改意见
备注
确认
刘顺华
1
用户管理
用户名进行排序（由用户自定排列顺序，在组织架构、邮件等模块中有人名供选择）
C、权限的重新定位（不同系统接口时，要进入重新定位，如OA系统与档案系统衔接十权限必发生改变）
后期加入
10
界面自定义
A、界面排版自定义
B、界面分辨率自动识别
C、登陆页面自定义（填写密码的位置要修改）
采纳部分
关于界面排版自定义本系统暂无此功能.
11
系统日志管理
要求记录用户查询、导出的记录
采纳
罗经理
1
权限管理
采纳
7
管理员权限
具体操作系统管理员的权限不可以逾越在部门管理之上，可以设置部门超级管理员、文档管理员、档案管理员等
采纳
8
检索功能
A、全系统都应该有检索功能
B、检索功能包括模糊检索、精确检索和组合查询等。
采纳部分
关于检索功能,本系统分为普通检索和高级检索
9
接口权限管理
A、两套不同的权限如何统一
B、如何实现单点登陆
提供权限管理系统操作用户分类查询功能
业务系统分类选择。
经过分类的权限管理系统操作用户列表页面
5.2.2.3
权限类型管理
提供权限管理系统权限类型配置功能
权限类型名称、权限类型ID
权限类型列表页面
5.2.2.4
权限管理
5.2.2.4.1
权限管理
为业务系统的管理员提供自有业务系统的权限配置功能
访问权限名称、权限类型
.
权限管理系统中必须有外部系统的登记信息等.
5.3.2.2
业务系统用户访问权限获取-用户权限获取
该部分向进行了权限设定的业务系统提供业务系统用户访问权限的获取功能
权限管理系统中必须有外部系统的登记信息等.
登陆帐号调用信息验证用户
界面自定义系统
5.4
界面自定义系统
5.4.1
系统VI管理
对整个系统VI（Visual Identity视觉形象识别系统）的定制管理，包括系统的logo标识，系统所允许选择的背景，系统名称等（以后逐步完善）
采纳
李飞
1
界面
网站内部框架选择，选择第二种，对页眉、页脚怎样美化很重要，个别内容建议做成动态。
现已选用第三种
2
权限管理
权限不要角色对功能点，分配权限操作起来会非常麻烦。建议采用3层权限：一层为用户登录；二层为功能模块；三层为按钮（即增加、修改、删除等）
以后加入
3
系统功能
外接系统由支撑平台统一管理接口的处理细节，建议提前深入考虑
3
需求规格说明书
目前的设计是从自定义角度出发进行的设计，请大家对该需求能否反映用户自定义的需要，及该种需求是否能满足系统设计目标上多提改进意见。
在框架上，请大家把系统的网站大框架先确定下来。本人偏向于框架二。
采纳
冯志强
1
需求规格说明书
对于多级别管理，增加删除修改描述都不清晰
采纳
2
需求规格说明书
下拉菜单选择机构/部门是否合理？如果机构很多的情况
业务系统名称，业务系统代号
业务系统列表页面
5.2.2.2
权限管理系统用户管理
5.2.2.2.1
权限管理系统用户维护
对操作权限管理系统的用户进行维护
用户名称、用户代号、
业务系统名称等等...
权限管理系统操作用户列表页面
超级管理员设定待研究（写死）
5.2.2.2.2
权限管理系统操作用户查询
（1）分类查询
功能框架
考虑到如何跟自定义菜单系统和界面自定义挂钩。如果两个系统都能够做出这样的结构。则是最好的。
采纳
所以该框架最好安排人手找时间做一下技术验证。一切以自定义系统能否实现为基本。
2
界面
具体界面的设计需要与菜单功能模块、自定义模块、业务系统操作等一起考虑。
需要对应功能模块的技术人员进行评估，并拿出相应的解决方案，才能确定。从自菜单功能模块的实现与该界面的设计上考虑，目前还不能实现该种框架设计。
需求评审表
编号
名称
功能需求
系统需求
批注
确认
功能概述
输入
输出
前提条件
基本流程
组织架构管理系统
5.2.1
组织架构管理系统
该系统的使用者只有SUPERVISOR。
5.2.1.1
机构管理
提供机构管理主页面功能
机构代码、机构名称等等..
多级（集团性）机构信息页面
ｑｉｎｇｌ门管理主页面功能
完善中
3
组织架构、权限管理
组织架构、权限管理可分为三类：
一、组织机构：
部门
用户
二、权限：
角色
岗位(由于角色对应的“菜单、操作”过于细致，需抽象一个层次，方便管理，对应用户实际情况，例如：某某处处长)