附录风险分类体系表修订版
表内外各类金融资产风险分类制度
表内外各类金融资产风险分类制度可以分为五类，分别为正常类、关注类、次级类、可疑类、损失类，后三类合称不良资产。
以下是具体的风险分类制度：
1.正常类：债务人能够履行合同，没有客观证据表明本金、利息
或收益不能按时足额偿付。
2.关注类：虽然存在一些可能对履行合同产生不利影响的因素，
但债务人目前有能力偿付本金、利息或收益。
3.次级类：债务人无法足额偿付本金、利息或收益，或金融资产
已经发生信用减值。
4.可疑类：债务人已经无法足额偿付本金、利息或收益，金融资
产已发生显著信用减值。
风险分类应真实、准确地反映金融资产风险水平。
此外，还应遵循以下原则：
1.及时性原则：按照债务人履约能力以及金融资产风险变化情况，
及时、动态地调整分类结果。
2.审慎性原则：金融资产风险分类不确定的，应从低确定分类等
级。
3.独立性原则。
用人单位职业病危害风险分级管控体系细则
用人单位职业病危害风险分级管控体系细则东省地方标准DB37/T2973xx目次前言 II引言 .III1 范围12 规范性引用文件13 术语和定义14 基本原则25 工作程序和内容26 文件管理67 建设成果和效果68 持续改进7附录 A （规范性附录）正确使用说明 .8附录 B（资料性附录）工程分析和职业卫生调查内容12附录 C（资料性附录）常见化学毒物的危害指数（THI） .14附录 D（资料性附录）职业病危害风险控制措施举例25附录 E（资料性附录）风险告知卡示例28DB37/T2973xx给出的规则起草。
本标准由山东省安全生产监督管理局提出。
本标准由山东省安全生产标准化技术委员会归口。
本标准主要起草单位：山东省安全生产监督管理局.山东省职业卫生与职业病防治研究院。
本标准主要起草人：王瑞.张海东.张士怀.邵华.王红国.陈明.赵俊峰。
DB37/T2973xx0用人单位职业病危害风险分级管控体系细则1 范围本标准规定了用人单位职业病危害风险分级管控的基本原则.工作程序和内容.文件管理.建设成果和效果以及持续改进等内容。
本标准适用于山东省境内用人单位的职业病危害风险分级管控体系建设和实施指南编制工作。
2 规范性引用文件下列文件对于本文件的应用是必不可少的。
凡是注日期的引用文件，仅所注日期的版本适用于本文件。
凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
GB18871 电离辐射防护与辐射源安全基本标准GBZ2 工作场所有害因素职业接触限值GBZ128 职业性外照射个人监测规范GBZ159 工作场所空气中有害物质监测的采样规范GBZ/T160 工作场所空气有毒物质测定GBZ/T189 工作场所物理因素测量GBZ/T192 工作场所空气中粉尘测定GBZ/T224 职业卫生名词术语GBZ/T229.1 工作场所职业病危害作业分级第1部分：生产性粉尘GBZ/T229.2 工作场所职业病危害作业分级第2部分：化学物GBZ/T229.3 工作场所职业病危害作业分级第3部分：高温GBZ/T229.4 工作场所职业病危害作业分级第4部分：噪声GBZ230 职业性接触毒物危害分级DB37/T2882 安全生产风险分级管控体系通则3 术语和定义GBZ/T224.GBZ/T229.DB37/T2882界定的以及下列术语和定义适用于本文件。
建设项目环境风险评价技术导则 (HJ 169-2018)
前言
为贯彻《中华人民共和国环境保护法》和《中华人民共和国环境影响评价法》，规范环境风险 评价工作，加强环境风险防控，制定本标准。
本标准规定了建设项目环境风险评价的一般性原则、内容、程序和方法。 本标准是对《建设项目环境风险评价技术导则》（HJ/T 169—2004）的修订。主要修订内容有： ——调整了适用范围，与环境影响评价导则重构体系衔接； ——调整、补充规范了相关术语和定义； ——增加了风险潜势初判，改进了评价工作等级划分方法； ——规范了风险识别和源项分析的内容和方法； ——优化调整了大气、地表水风险预测与评价内容； ——增加了地下水风险预测与评价的技术要求； ——调整、细化了风险防范措施内容； ——增加了评价结论与建议章节； ——补充、完善了附录，增加了附图、附表的编制要求。 本标准附录A、附录C、附录D、附录G、附录J为规范性附录；附录B、附录E、附录F、附录H、 附录I、附录K为资料性附录。 自本标准实施之日起，《建设项目环境风险评价技术导则》（HJ/T 169—2004）废止。 本标准由生态环境部组织制订。 本标准主要起草单位：环境保护部环境工程评估中心、中国寰球工程有限公司。 本标准生态环境部2018年10月14日批准。 本标准自2019年3月1日起实施。 本标准由生态环境部解释。
2 规范性引用文件 本标准引用了下列文件或其中的条款。凡是未注明日期的引用文件，其最新版本适用于本
标准。 GB 3095 环境空气质量标准 GB 3097 海水水质标准 GB 3838 地表水环境质量标准 GB 5749 生活饮用水卫生标准 GB 30000.18—2013 化学品分类和标签规范 第 18 部分：急性毒性 GB 30000.28—2013 化学品分类和标签规范 第 28 部分：对水生环境的危害 GB/T 14848 地下水质量标准 GB/T 19485 海洋工程环境影响评价技术导则 HJ 2.1 建设项目环境影响评价技术导则 总纲 HJ 2.2 环境影响评价技术导则 大气环境 HJ 2.3 环境影响评价技术导则 地表水环境 HJ 610 环境影响评价技术导则 地下水环境 HJ 941 企业突发环境事件风险分级方法 《建设项目环境影响评价分类管理名录》 《国家突发环境事件应急预案》（国办函〔2014〕119 号）
FMEA(第三版)
前言第三版FMEA第三版(QS-9000)是戴姆勒克莱斯勒、福特和通用汽车公司的供方所使用的参考手册，为协助他们在开发设计和过程FMEA提供了指导方向。
本手册意图澄清有关FMEA开发上的技术问题。
本手册符合供方质量要求推动小组(Supplier Quality Requirement Task Force) 的授权，将戴姆勒克莱斯勒、福特和通用汽车公司在其各自的供方质量体系中应用的参考手册、程序、报告格式和技术术语进行标准化处理。
由于FMEA第三版手册是用来提供给供方的泛用指导，本手册并不规定要求，它意图在设计阶段或过程分析阶段准备FMEA的时候，提供涵盖了一般的概括指导。
本手册等同于SAE J1739为设计和过程FMEA的技术。
然而，他并不包含机械装置的FMEA 应用。
对机械装置FMEA方面有兴趣，可参考SAE J1739的相关范例。
供方质量要求工作小组感谢下列每个人，和他们的公司，他们贡献时间和努力开发了FMEA 新版手册和较早的版本。
第三版Kevin A. Lange-DaimlerChryslerSteven C. Leggett-General Motors CorporationBeth Baker-AIAG较早版本Howard Riley-DaimlerChrysler Mark T. Wrobbel-- DaimlerChryslerGeorge R. Baumgarther-Ford Motor Company Rebecca French-General MotorsLawrence R. McCullen-General Motors Mary Ann Raymond--BoschRobert A. May-Goodyear William Ireland-Kelsey-HayesTripp Martin-Peterson Spring此外，供方质量要求小组感谢下列在SAE J1739工作小组的个人，他们在这次改版中对技术的变更和改进，有卓越的贡献。
风险分级管控体系文件全套)
文件编号：AQSCBZH01受控状态：受控XXX风险分级管控体系文件2021年月日企业全然信息填表人：联系：填表日期：XXX平安生产风险分级管控体系作业指导书2021年8月1分级管控目的结合本企业特点，建立精准、动态、高效、严格的风险分级管控体系，全面排查、辨识、评估平安风险，落实风险管控责任，采取有效措施操纵重大平安风险，对企业风险实施标准化管控。
通过体系建设形成平安生产长效机制，提升企业平安生产水平，有效防范各类事故，确保平安生产形势持续稳定好转。
2 分级管控的依据GB/T13861生产过程危险和有害因素分类与代码GB6441企业职工伤亡事故分类标准GB/T28001职业健康平安治理体系要求GB/T28002职业健康平安治理体系实施指南GB/T23694风险治理术语GB/T24353风险治理原那么与实施指南GB/T27921风险治理风险评估技术GB/T13861生产过程危险和有害因素分类与代码GB18218危险化学品重大危险源辨识GB6441企业伤亡事故分类GBT33000-2021企业平安生产标准化全然标准DB37/T2882-2021平安生产风险分级管控体系通那么DB37/T2883—2021生产平安事故隐患排查治理体系通那么关于实施遏制重特大事故工作指南构建双重预防机制的意见?安委办〔2021〕11号工贸行业较大危险因素辨识与防范指导手册?〔2021版安监总管四〔2021〕31号〕工贸行业遏制重特大事故工作意见?〔安监总管四〔2021〕68号〕中华人民共和国特种设备平安法〔国家主席令〔2021〕4号〕国家平安监管总局?关于印发开展工贸企业较大危险因素辨识管控提升防范事故能力行动方案?的通知〔安监总管四〔2021〕31号〕山东省平安生产 ?山东省人民政府关于修改〔山东省生产经营单位平安生产主体责任〕的决定?山东省人民政府令第303号企业平安生产资料企业内部平安生产责任制企业内部平安操作规程企业组织机构划分图3分级管控的内容及范围通过对本公司工作场所的现场调查分析，同时对企业现有的风险防控措施进行适应性分表1分级管控的内容及范围4名词解释DB37/T2882-2021界定的及以下术语和定义适用于本文件。
2971 化工企业安全生产风险分级管控体系细则
ICS13.100G 09 DB37 山东省地方标准DB37/T 2971—2017化工企业安全生产风险分级管控体系细则Detailed rule for the management and control system ofchemical industry work safetyrisk classification2017-06-23发布2017-07-23实施目次前言 (III)引言 (IV)1 范围 (1)2 规范性引用文件 (1)3 术语与定义 (1)4 基本要求 (1)4.1 成立组织机构 (1)4.2 实施全员培训 (1)4.3 编写体系文件 (1)5 风险识别评价 (1)5.1 风险点确定 (2)5.1.1 风险点划分原则 (2)5.1.2 风险点排查 (2)5.2 危险源辨识分析 (2)5.2.1 危险源辨识 (2)5.2.2 危险源辨识范围 (2)5.2.3 危险源辨识实施 (2)5.3 风险控制措施 (3)5.4 风险评价 (3)5.4.1 风险评价方法 (3)5.4.2 风险评价准则 (3)5.5 风险分级管控 (3)5.5.1 管控原则 (3)5.5.2 确定风险等级 (4)5.5.3 重大风险判定 (4)5.5.4 风险分级管控实施 (4)5.5.5 编制风险分级管控清单 (4)6 成果与应用 (5)6.1 档案记录 (5)6.2 风险信息应用 (5)7 分级管控的效果 (5)8 持续改进 (5)附录A（资料性附录）分析记录表 (6)附录B（资料性附录）工作危害分析法（JHA） (10)附录C（资料性附录）安全检查表法（SCL） (11)附录D（资料性附录）风险矩阵法（LS） (13)附录E（资料性附录）作业条件危险性分析评价法（LEC） (15)前言本标准按照GB/T 1.1—2009给出的规则起草。
本标准由山东省安全生产监督管理局提出。
本标准由山东安全生产标准化技术委员会归口。
风险评估
2风险评估风险评估是识别及分析影响公司目标实现的因素，是风险管理的基础。
在风险评估中，既要识别和分析对实现战略目标及经营目标具有阻碍作用的风险，也要发现对实现目标具有积极影响的机遇。
风险评估的基本程序包括风险信息收集、风险辨识、风险分析、风险评价四个步骤。
2.1 风险信息收集物流公司应广泛、持续不断地收集与本公司风险和风险管理相关的内部、外部初始信息，包括历史数据和未来预测，应把收集初始信息的职责分工（详见《全面风险管控体系手册---信息与通分册》）落实到各有关职能部门和子公司，风险信息收集示例详见本手册附录部分附件一。
2.2 风险辨识物流公司可以采用多种方法进行风险识别，包括资料查阅法、问卷调查法、面谈采访法、历史事件分析法、情景分析法等。
1）资料查阅法获取公司相关制度、会议资料、管理报告、外部行业研究、业务台账、法律纠纷案件等文档，查阅、汇总风险管理现状信息。
通常资料查阅法是风险信息收集中必不可少的方法之一。
本手册使用的工具——《资料清单》，请参见本手册附录部分附件二。
2）问卷调查法依据公司相关风险管理目标，确定相应的风险因素，按照类别形成表格，向相关人员进行调研，获得相关风险的重要信息。
《风险调查问卷》参见本手册附录部分附件三。
3）面谈采访法预先制定访谈提纲，《访谈提纲》的模板参见本手册附录部分附件四。
对利益相关者进行访谈并记录相关要点，形成《访谈纪要》，了解潜在风险，确认风险事件。
《访谈纪要》参见本手册附录部分附件五。
4）历史事件分析法分析曾经发生的对公司经营管理目标造成一定影响的历史事件（例如法律纠纷诉讼案件），进一步剖析导致事件发生的相关风险。
《风险案例调查表》参见本手册附录部分附件六。
此外，公司管理层通过业务检查、参加行业联合会、利用顾问和其他专业人员等收集风险信息。
公司逐步加强与国内外同行业大型公司、知名咨询机构的沟通，获取更多、更全面的信息，从而全面准确地识别公司风险。
2.3风险分析公司汇总以上各种风险信息收集方法获取的风险信息，将杂乱的风险信息按风险类型进行归集，按照“风险＋对企业的影响”的描述原则确定风险事件，描述该风险的某种状态、现象或行为等对企业目标影响的表现形式，从而直接或间接反映风险的主要特征。
危害因素辨识与风险评价管理规定
发行版本：E危害因素辨识与风险评价管理规定修改码:0文件编码：XJXS/Q.HSE.GL.ZAC-091范围与应用领域1.1目的为持续识别并评价公司活动、产品、服务中的危害因素，实施必要的风险控制和削减措施，预防各类事故的发生，特制定本规定。
1.2适用范围本规定适用于公司、直属企业、基层单位及承包商。
1.3应用领域本规定应用于公司生产经营、工程建设、承包商服务存在潜在风险的活动或任务。
2术语和定义2.1危害因素一个组织的活动、产品或服务中可能导致人员伤害或疾病、财产损失、工作环境破坏、有害的环境影响或这些情况组合的要素，包括根源和状态，包括职业健康、安全和环境三方面的危害因素。
2.2危害因素辨识识别健康、安全与环境危害因素的存在并确定其特性的过程。
2.3风险某一特定危害事件发生的可能性与后果的组合。
2.4 风险评价评价风险程度并确定其是否在可承受范围的全过程。
3 职责3.1 质量安全环保处（保卫处）是危害因素辨识与风险评价的归口管理部门；负责组织制定、管理和维护本规定；负责对公司系统内危害因素辨识和风险评价工作的指导、监督。
3.2 公司职能处室负责本部门业务管理范围内危害因素辨识与风险评价工作的组织实施。
3.3 直属企业安全管理部门是本单位危害因素辨识与风险评价的主管部门；负责本单位危害因素辨识与风险评价工作的组织和指导。
3.4 直属企业职能管理部门、基层单位负责本部门（本单位）业务范围内危害因素辨识与风险评价工作的组织实施。
4 管理内容4.1 危害因素辨识4.1.1 危害因素辨识的范围危害因素辨识的范围必须覆盖公司所有生产经营活动的全过程，包括：a）常规和非常规的活动；b）所有进入工作场所的人员（包括承包方人员和访问者）的活动；c）工作场所（生产现场）的设施（包括本公司和由外界所提供）；d）事故及潜在的危害和影响；e）以往活动的遗留问题。
4.1.2 危害因素辨识应考虑的方面4.1.2.1 辨识职业健康和安全方面的危害因素应考虑：a) 职业健康和安全方面的法律、法规、标准及规程的执行情况；b) 本单位和其他同类单位发生的历史事故和事故险情；c) 现场设备设施存在的固有危险因素和预测可能发生的故障；d) 现场操作活动中存在的固有危险因素和预测可能发生的操作失常；e) 作业场所环境影响员工健康的危险因素。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
－no不明确之处是否正在被满意地解决？
－yes描述是否存在歧义或者缺少必要地解释
有效性
按照需求所开发出的产品能否真正满足客户的要求？
1.是否存在没有说明客户真正想要的需求？
－Yes你怎么解决这些问题？
2.你和客户对需求的理解是否一致？
－yes是否有一种方法确定上述问题？
5.充分的提出长期存在的问题吗？
组织
机构
清楚角色和报告之间的关系
1.时间进度的组织是有效的吗？
2.大家是否清楚他们自己及其他人在计划中的角色吗？
3.大家是否清楚每个人拥有的权利是什么吗？
管理
经验
是经理在软件开发、软件管理、应用领域、开发过程和大型计划中的经验。
1.是否有经验丰富的管理者（软件管理、软件开发、开发过程、应用领域、软件规模和复杂性等方面）
2.列出的单元测试是否充分？
3.是否有足够的时间去执行你认为应该做的单元测试？
4.如果有进度问题是否做了关于单元测试的进度承诺？
编码和单元测试
编码/实现
在编码和实现方面是否存在问题？
1.用来写代码的设计说明书是否足够详细？
2.当编写代码时设计是否有变更？
3.是否存在一些系统限制（内存、外部存储）给编写代码带来一定的困难？
2.外部接口是否会有变化？
完整性
需求是否有所遗漏或规定不够完整？
1.是否有你知道应该在需求说明书中写明，但却没有写的需求？
－yes你能够将这些需求融入到系统中吗？
2.客户是否有需求说明书中没有包括的需求或期望？
－yes是否有一种途径去获得这些需求？
3.是否完整地定义了外部接口？
清晰性
需求是否清晰或有必要的解释？
－yes a:该计划规定的过程是否清晰？
－yes b:开发人员是否熟悉此计划？
适应性
过程是否适合于开发模型（如瀑布、原型）
1.开发过程是否适应于产品？
2.开发过程是否由一组相互一致的规程、方法和工具所支持？
过程
可控性
软件开发过程是否得到强化实施、监督并用可度量的方法控制分布在不同现场的开发是否可协调
4.完成软件功能所使用的语言是否适合？
5.在程序中是否使用了多种语言？
－yes不同的编译器产生的代码接口是否兼容？
6.开发计算机是否同目标用户计算机相同？
－no开发计算机和目标用户计算机编译器是否存在差异？
如果使用了硬件环境
7.编写软件的硬件说明书是否充分？
8.当编写代码时硬件说明书是否发生变更？
环境
系统
支持
系统能否及时获得专家或供货商的支持？
1.使用开发工具的人是否获得过培训？
2.与运用某问题的反馈是否迅速？
可交
付性
为了把开发系统交付给用户，对可接受的需求进行定义是否还未计入预算？
提示：如果参加项目的人员对此不理解，或许从风险的观点看会漏掉一个问题。
1.是否将开发系统交付给了用户？
1.每位项目组成员都遵循开发过程吗？
－yes如何保证的？
2.能否度量出开发过程满足不满足预定的生产率目标和质量目标？
如果采用分布式开发，还需考察：
3.对于多场地的分布式开发，是否有足够的协调能力？
可理
解性
项目组成员是否具有实施过程的经验过程能否被所有成员所理解
1.项目组成员能否顺利实施开发过程？
产品
3.你怎样来确认需求（原型、分析、模拟）
可行性
从分析的观点看需求是不可行的？
1.是否有些需求在技术上难以实现？
－yes a:这些需求是什么？
－yes b:为什么这些需求实现是困难的？
－no是否为这些需求做了可行的研究？
－Yes你认为可行性研究中所做的假定是否可信
先例
需求所规定的内容你以前从没做过或者你所在的公司从没有做过？
－yes在这方面合同清楚阐述了吗？
集成测试
系统
系统集成过程中相互间的协调、接口定义、设备方面是否存在问题？
1.规定了足够的系统集成了吗？
2.在系统集成和测试方面是否分配了足够的时间？
3.所有合同商都是集成团队的一部分吗？
4.产品是否被集成到当前的系统中？
－Yes与当前系统是否有一个并行接入的时间段？
可控性
是否具有某些机制用以控制产品的变化？
1.是否存在需求跟踪机制，可使需求从原始说明一直跟踪到测试用例？
2.是否运用某种跟踪机制，用以评价需求变化对分析的影响？
3.是否存在正式的变更控制流程？
－yes它覆盖到已基线化的所有需求、设计、代码和文档的变更了吗？
4.任意级别上的变化是否都向上追溯到了系统级别、向下追溯到了测试级别？
2.如此规模的项目是否需要一个比通常更大的团队来完成？
功能
在满足功能性需求方面是否存在一些隐含的问题？
1.是否有规定的算法不能满足需求的情况发生？
－no是否存在勉强符合需求的算法和设计？
2.你是如何确定算法和设计的可行性的（原型、模型、分析、模拟）
难度
设计或实现是否存在困难？
1.是否存在依据不切实际和乐观的假定而得出的设计？
2.是否存在设计上有难度的需求或功能？
－no你是否有所有需求的解决方案？
－yes这些需求是什么为什么不易实现
设计
接口
是否详细定义并且控制了内部接口（硬件和软件）
1.是否详细定义了内部接口（软件和软件、软件和硬件）
2.是否有一种方法用来定义内部接口？
－yes对于内部接口的变化是否有一种控制方法？
3.硬件是否和软件一起并行开发？
计划
接口
和客户、承包商、高级或者同级经理的接口
1.上下的管理沟通是否存在问题？
2.和用户文档之间的问题是否及时得到解决？
3.在和用户的管理会议中有适当的做计划人员吗（如技术经理、开发人员、分析人员）
4.是否有管理机制确保用户代表可以针对功能和操作方面代表客户的意见。
1.需要时目标用户的硬件是否可得到？
2.接收标准是否与所有需求一致？
－yes是否有一个正式的协议？
3.外部接口是否被定义、文档化并且形成基线？
4.是否存在难于测试的需求？
5.所规定的产品集成是否充分？
6.是否分配了足够的时间用来产品集成和测试？
如果是商业现货软件
7.在验证分配给商业软件的需求时供货商的数据是否可接受？
－yes b.在设计和实现过程中是否有一个可用于跟踪性能的模型？
可测试性
测试产品是困难的或不可能的吗？
1.软件是否容易测试？
2.设计是否包括一些特性可以帮助测试？
3.测试人员是否参与了需求分析？
硬件限制
关于目标硬件是否存在一些限制？
1.硬件设备是否限制了你满足软件需求的能力（体系架构、内存容量、吞吐量、实时响应、响应时间、恢复时限、数据库性能、功能、可靠性、可用性）
附录风险分类体系表
风险分类体系表
风险分类体系表，按照产品工程类、开发规程和方法类、规划约束类三个类别，采用列举各类的不同来源和属性下的问题方法，帮助在项目中更好的识别风险来源和管理风险。
表产品工程类
产品工程类
来源
属性
问题
需求
支持性
需求的相关方是否对需求活动提供了足够的支持？
1.客户或用户能确保参与需求的获取活动吗？
与应用软件的接口存在问题
没有全面的测试
不能剔除所有的bug
可维护性不强
供货商响应速度缓慢
3.关于集成商业现货软件的补充资料和修订版你是否预见到什么问题？
可行性
实现设计是否是困难的或不可能的？
1.设计说明书是否全面定义了执行产品的所有部分？
2.选择的算法和设计容易去实现吗？
测试
1.在你验证关于设计的代码之前是否已开始了单元设计？
1.是否存在无先例的或代表当前最高技术水平的保密性需求？
2.是否是单机多用户系统？
3.是否实现了这种级别的保密性需求？
说明书
设计、实现和测试系统所用的文档是充分的？
1.用来设计系统的软件需求说明书是否是充分的？
2.设计和实现系统的硬件说明书是否是充分的？
3.外部接口需求是否很好的被定义？
4.测试说明书是否是充分的去全面测试系统？
2.分配给软件的需求是否包括了可用性方面的需求
－yes恢复时限方面是否有问题？
工程特性
安全性
安全性需求是不可行和无法验证的吗？
1.分配给软件的需求是否包括安全性方面的需求？
－yes在符合安全性需求的过程中你是否遇到了困难？
2.验证满足需求中安全性方面的需求时是否存在困难？
保密性
处理保密性方面的需求是否比编程经验更重要？
集成和测试环境是否准备充分？
1.是否有足够的硬件去做充分的集成和测试？
2.验证需求的开发现实际场景和测试数据是否存在问题（特定的数据通信、实时响应、异步事件处理、多用户接口）
3.你能否用设备去验证性能？
4.硬件和软件工具是否方便测试？
－yes所有的测试是否充分？
产品
接口定义、设施准备是否充分时间是否充足
－yes a.硬件说明书是否发生变更？
－yes b.所有的软件接口都被定义了吗？
－yes c.是否有可用于测试软件的工程设计模型？
性能
是否有关于响应时间或吞吐量方面的需求？
1.在软件性能方面是否存在问题（吞吐量、调度异步实时事件、实时响应、恢复时限、响应时间、数据库响应）
2.是否做了性能分析？
－yes a.对性能的分析你有多大的把握？
掌握性
设计人员对需求的内容准确掌握了吗？
1.设计人员对需求的内容能获得正确理解吗？
－no能通过培训或与需求人员的沟通解决这个问题吗？