最新的TL9000要求手册R63中文版.docx
《最新的TL9000要求手册R63中文版.docx》由会员分享，可在线阅读，更多相关《最新的TL9000要求手册R63中文版.docx（23页珍藏版）》请在冰豆网上搜索。
最新的TL9000要求手册R63中文版
2021年最新的TL9000要求手册R6.3中文版
本TL9000要求手册按R6.3版翻译，红色字体是R6.3的修改之处。
R6.32021年10月1日生效
4组织环境
4.1:
理解组织环境：
无
4.2:
理解相关方要求：
无.
4.4质量管理体系范围
4.3.C.1要求手册和测量手册适用性声明
组织必须在它的注册界面中声明确定不适用的要求和任何声明的测量豁免。
注解1:
假如要求（手册）是在组织已经选择的TL9000注册专项之外的范围,对组织而言,声明TL9000不适用不是必须的。
同样,当要求本身或相关的注解要求表明针对组织的产品或服务类型不适用,对组织而言,声明不适用也不是必须的。
注解2:
参见测量手册中的测量豁免定义。
4.3.C.2TL9000概况和范围
4.3.C.2TL9000概况和范围组织寻求认证,必须与认证机构协调,确定:
--TL9000的范围描述；--ISO9001的范围描述；--不适用的要求决定；--测量的豁免；--注册的专项选择；--NACE的编号--产品类别；--位置和地址；--ISO9001的版本；--TL9000要求和测量的版本，和--监督审核和再认证程序（ASRP）的应用。
所有注册必须在QF注册管理系统（RMS）的注册概况中记录和维护。
TL9000管理者必须把相关信息给认可的认证IAF数据库。
被认证公司发行的证书必须参考在概况创建时，TL9000管理者分配的TL编号注册管理系统（RMS）的注册概况。
范围描述必须包括：
a）组织被注册的身份，可以包括整个组织，一个组织的单元，或多个单元的结合，和
b）被注册所覆盖的产品/产品线，假如不是所有产品/产品线包括的注册中，那么包括或排除的产品
/产品线必须被列出；
范围描述不需要包括：
a）产品类型的编号,
b）位置或地址；,
c）ISO9001,要求手册和测量手册的版本；,
d）注册专项的选择，和
e）其他在注册概况中被定为个别行业的特征；
4.4质量管理体系及其过程：
无
5领导力
5.1领导力和承诺
5.1.1总则：
无
5.1.2客户为中心
5.1.2．C.1客户沟通方法
组织必须建立并保持方法以与选定的客户沟通分享期望，并确保产品质量的改进。
顾客沟通的结果应该针对解决识别的问题而产生措施,提供顾客满意改进机会.
5.1.2.C.1–注：
众所周知,组织不可能向所有客户提供同样程度的沟通。
沟通的程度可取决于与客户的业务量，问题的历史，客户的期望，和其它因素，见文件，“与客户的沟通指南”（tl9000.org）。
5.2方针：
无；
5.3组织的角色、职责和权限：
无。
6策划
6.1确定风险和机遇的措施：
无；
6.2质量目标和达成的策划
6.2.1
6.2.1．C.1TL9000测量目标
质量目标必须包括TL9000测量手册中规定的目标。
6.2.2.C.1顾客输入
组织必须实施方法以征求和考虑客户在质量策划活动方面和客户合作输入。
组织应该与选定的客户建立共同的质量改进项目。
6.2.2
6.2.2.C.2外部供方输入
组织必须实施方法以征求和考虑供方在质量策划活动方面和外部提供者合作的输入。
.
6.2.2.C.3长期和短期策划
组织的质量策划活动必须包括达到长短期的质量目标的计划。
计划必须描述到相关组织和它的顾客业务方面因素，包括与选定顾客一起建立业绩目标。
这些目标的业绩必须被监视和报告给最高管理者。
最高管理者必须举证他们积极参与到长短期质量策划中。
6.2.2.C.1注1:
策划的事例可以考虑如下:
a）周期时间，b）客户服务，
c）培训，d）成本，e）交货承诺和f）产品可靠性，和;g）安保和隐私，h）耐久性
6.3变更策划：
无。
7支持
7.1资源
7.1.1总则
7.1.1.C.1业务连续性策划
组织必须建立和保持针对运行、灾害恢复、基础设施和安保复原的文件化持续性计划，确保组织有持续支持它的产品和服务的能力。
业务连续性计划至少必须包含:
危机管理、灾害恢复和IT技术。
该计划必须被针对其有效性进行周期性评估和适当级别的管理层评审。
7.1.1．C.1注1:
恢复能力类型应该包括相关于描述灾害恢复一系列措施.例子包括:
谁在什么情况下被通知了,谁有权限行施动作，谁协调在计划中描述的步骤。
7.1.1.C.1注:
2:
业务连续性策划可以考虑来自安全事件的恢复，比如：
网络安全，恶意软件和勒索软件攻击。
7.1.2人员：
无
7.1.3基础设施
7.1.3.C．1基础设施安保
组织必须确定、提供和保持基础设施的安保。
7.1.4运行过程环境：
无；
7.1.5监视和测量资源
7．1.5.2设备标识
监控和测量装置在不使用时或不适合使用时必须被明显标识和不再使用。
所有不需要校准的监控和测量装置必须被标识。
7.1.6组织知识：
无。
7.2能力
7.2.C.1内部课程开发
当组织负责开发内部培训课程时，必须建立并保持一方法以确保策划，开发和交付这些课程一致性。
7.2.C.2质量和过程改进概念
对与产品和服务质量有直接影响的员工，包括最高管理层，必须在持续改进，问题解决和客户满意的基本概念和应用接受培训。
7.2.C.3产品质量培训机会和意识
当影响产品或服务质量的培训需要时,组织必须实施方法确保员工能参于,方法应该规定:
a）培训机会的沟通，和
b）培训可获得。
7.2.C.4静电培训
所有职能包括静电敏感产品的搬运，储存，包装，防护或交付的员工都必须在进行工作前接受静电防护的培训。
ESD再培训的类型和频率必须被组织规定。
7.2.C.5高级质量培训
组织必须提供适当程度的高级质量培训。
7.2．C．5注：
高级质量培训可以包括：
统计技术，过程能力，统计抽样，数据收集和分析，问题识别，问题分析，根本原因分析和授权工具。
7.2.C.6危险情况培训内容
在潜在危险情况存在的地方，培训内容必须包括以下:
a）任务的执行，
b）人员安全，
c）对危险环境的意识，和
d）设备防护。
7.2.HV.1操作者个人资格
组织必须识别针对操作人员资格和再认可资格的活动。
资格和再认可资格要求必须
针对识别的活动被建立。
至少，这些要求必须描述教育，经验，培训和可证实的技能。
组织必须和所有那些涉及到的对象沟通这些信息。
7.2.HV.1注:
需要个人资格和再认定资格过程的例子包括绕线,光纤熔接，焊接,烧结,叉车操作和高楼攀爬。
7.3意识：
无；
7.4沟通
7.4．C．1组织绩效反馈
组织必须通知员工关于他们的质量绩效和客户满意程度水平，包括管理评审的结果
（见:
9.3）。
注：
敏感的组织信息可以被排除。
7.5文件化信息
7.5.3.2.C.1客户提供的文件和数据的控制
假如客户提供的文件和数据对产品或/和服务的实现和/或支持会产生影响，组织必须控制所有顾客提供的文件和数据（如，网络结构，拓扑学，容量，安装终端分配，图纸和数据库等）。
8运行
8.1运行策划和控制
8.1.C.1生命周期模式
8.1.C.1生命周期模式组织应建立并保持覆盖产品和服务生命周期的文件化信息。
该文件化信息应包括，适当时，产品或服务终止在概念、定义、开发、导入、生产、运行、维护及处置中的过程、活动和任务。
8.1.C.1注1：
生命周期模式宜考虑可持续性的实践，比如：
提升能源绩效和资源消耗，负责任的生态处理和合适的生命终止处理。
生命周期评估宜考虑促进分析有关的环境议题。
有关需要考虑的环境问题的例子，请参阅术语表中的可持续性。
8.1.C.1注2：
新产品或服务导入方法应该包括提供质量和可靠性预研究、试生产、需求和能力的研究、销售和服务人员的培训、客户文件和培训、新产品或服务导入后期评价。
8.1.C.1产品和服务安保
组织必须通过产品生命周期建立和保持为产品和服务安全风险和薄弱点而识别和分析的方法。
风险分析的结果必须用安全薄弱点的预防或减轻方式在产品设计和运行控制中支持网络安全运行。
设计和运行控制持续的有效性必须通过产品生命周期由合适的安全测量选择和使用被评估。
NOTE1:
此要求通过沟通和/或用户/产品和服务操作者的接口，关注有关于薄弱点可能利用的风险;
NOTE2:
按ISO27001定义，一个运行控制是一种管理风险的方法，包括：
方针、信息、指
南、实践或组织结构，本质上可能是行政、技术、管理或法律上的。
运行控制的例子包括：
授权和移去进入（包括物理的和逻辑的）到系统、文件化运行信息、变更控制信息和控制
在运行系统上的软件安装信息;
NOTE3:
安全测量指南文件参考tl9000.org/links.html，可以用于合适的产品安全测量选择和建立的方法。
8.1.C.2生命策划中止
组织必须针对制造和/或产品和服务支持终止建立文件化信息。
文件化信息应该包括：
a）在某一时期后停止全部的或部分的支持，
b）产品文件和软件的存档，
c）有关任何将来遗留问题的责任，
d）转换到新产品和/或服务,如适用，
e）存档数据备份的可获取性，和
f）组织的部件和装配的处置。
8.1.C.3工具管理
组织必须确保内部开发的用于产品和服务生命周期的软件和/或工具是遵循合适的质量方法。
8.1.C.4注：
被考虑工具例子包括：
设计和开发，测试，配置管理，文件，模具，压模，治具和诊断工具，包括手稿和定制，和用于建立和测试产品的软件。
8.2.1.C.1问题的严重度分类
除了严重程度水平报告特别除外的那些产品,组织必须根据本手册中的术语定义中对关键，严重和轻微问题报告定义对客户的影响来确定客户报告问题的严重度，必须根据这严重程度来确定组织作出反必须的及时程度。
8.2.1.C.1-注1：
客户与组织应该共同决定解决客户报告问题的优先次序。
8.2.1.C.2问题的提升
组织必须保持一文件化信息以消除和解决客户报告问题。
8.2.1.C.3问题报告反馈
组织必须及时和系统地向客户对其问题报告提供反馈。
8.2.1.HS.1产品追回
组织必须建立并保持文件化信息以识别和追回不适合继续服务的产品。
8.2.1.HS.2关键问题报告的通知
组织必须建立保持文件化信息，通知可能由关键问题报告影响到的所有顾客。
8.2.1.V.1关键服务中断通知
组织必须针对影响到的顾客建立和保持一方法，获取关于当前中断的实时信息。
8.2.1.V.1-注1:
此要求仅适用于提供服务给最终客户的组织。
8.2.2产品和服务要求的确定:
无;
8.2.3产品和服务要的评审
8.2.3.1.C.1合同评审
组织必须建立和保持以合同评审过程，并应该包括：
a）产品接受准则和准则评审过程，
b）处理在产品接受后发现的问题方法，包括顾客抱怨，
c）在适用的保质期后或在产品合同约定的维护期内,不合格的移去和/或纠正计划，
d）可能不可预计费用和风险识别，
e）针对产权足够的防护，
f）组织与外包工作有关的职责定义，
g）由顾客执行的活动，包括顾客在要求,规范和接受中的作用；
h）由顾客提供的装置，工具和软件项目，和
i）所有参考的标准和信息。
8.2.3.1.C.2注：
适当时，产品接受准则应该包括：
a）文件化测试信息，
b）测试用例，
c）测试数据，
d）测试职责，
f）包含的资源，
g）规定的接受测试报告。
8.2.4产品和服务要求的变更:
无.
8.3.2.C.1项目计划
组织的项目策划活动必须根据已规定的产品生命周期模式建立并保持项目计划（见
8.1.C.1）。
项目计划应该包括：
a）项目组织结构;
b）项目团队的作用，职责和义务;
c）相关团队或个人在组织内外部的作用，职责和义务，在他们和项目团队之间的接口，
d）时间计划，问题解决，和报告和客户报告的方法;
e）项目因素估算;
f）计划中的担当；
g）项目活动相关的预算、雇员和安排；准备使用的方法，标准，文件化信息和工具的标识（假如此项目是被清晰的定义作为产品和服务生命周期模式的部分，参考生命周期模式是可以的），
h）与其它相关计划的连接（例如：
风险管理，开发，测试，配置管理和质量），
i）项目特定开发或服务交付环境和物质资源的考虑（例如：
去描述开发,用户文件，检测,操作,规定的开发工具,安全计算环境,试验空间,工位等的资源），
j）包含在产品和服务说明周期中的顾客、用户、和外部供方（例如：
合作评审、正式会议和批准）；
k）项目质量的管理，包括合适的质量测量，
l）针对X（DFx）设计计划适合于产品的生命周期；
m）来自先前项目后分析和回顾的学习课程，包括根本原因分析和在将来项目中排除重复发生而采取的纠正措施；
n）项目特定的培训要求；
o）规定的认证，（例:
产品和服务的认证或员工的技术认证），和
p）专利权，使用权，所有权，保证期和许可证权限。
8.3.2.C.1-注1:
工作指导（书）定义的任务和职责，通常针对所有开发项目，不需要被重复描述在项目计划中。
8.3.2.C.1-注2:
项目因素的估计应该包括产品的规模,复杂性,要求变更,工作量,雇工,计划,成本,质量,可靠性,和产率.来自估算过程的数据应该和比较先前估算到实际进行分析.
8.3.2.C.1-注3:
DFx例子包括可加工性，可靠性，法规，可维修性，安全和可持续性，安保，隐私，和可试验性。
参见DFx在TL9000.org针对例子和其他的指南文件。
8.3.2.C.2风险管理策划
组织必须开发和文件化一个针对会影响成本、进度、产品质量或产品业绩方面的项目识别,分析和风险控制的计划。
8.3.2.C.2注：
风险管理应该在所有的产品和服务开发阶段被执行，根据项目的范围和复杂性，可以包括：
a）确定风险资源,分类和优先顺序;
b）关键和致命特性和失效模型,包括顾客的期望，
c）被用于界定风险优选和任何计分的原理的风险参数定义（例如:
发生的可能性,影响的程度）被应用（例如:
FEMA,FailureModeEffectAnalysis），
d）风险如何被管理（例如:
使用的工具、降低风险的措施、迁移决策、监视和报告的要求），
e）来之合适的功能性学科的输入，
f）针对获取和应用学习课程的机制。
8.3.2.C.3要求的可追溯性
组织必须建立并保持文件化信息方法以追溯每一个设计和检测过程中文件化的要求。
8.3.2.C.4测试策划
测试计划必须文件化，并应该包括:
a）测试范围（例如,单元,特征,集成,系统,验收,电场,转移和回归）;
b）需要进行的测试种类（例如,功能,极限,使用性,性能,回归,相互操作性,超载）;
c）对要求的可追溯性;
d）测试环境（例如,有关客户环境,操作使用）;
e）测试覆盖范围;（验证产品功能程度的测试，有时用功能测试百分比来表示），期望结果;
f）数据的定义和数据库的要求;
g）测试装置,测试实例（输入,输出,测试准则）和文件化测试信息;
h）外部测试的使用，和
i）报告和解决缺陷的方法。
j）顾客测试要求
k）预定义的退出准则.
测试结果和其后的采取的措施必须被保留文件化信息。
.
8.3.2.C.5集成策划
组织必须开发并文件化一计划去集成硬件，软件和/或服务部分进入到产品中，以确保达到设计要求。
计划必须包括：
a）方法和文件化信息，
b）职责，
c）集成的时间计划，和
d）测试要求。
8.3.2.HS.1配置管理计划
组织必须建立并保持配置管理计划，计划应该包括：
a）配置管理活动的标识和范围，
b）进行这些活动的时间计划，
c）配置管理工具，
d）配置管理方法和文件化信息，
e）委派给他们的组织和职责，
f）对每一配置项目所需要的控制水平，
g）将各个项目置于配置管理下的起始点。
8.3.2.HS.2产品计算机资源
组织必须建立和保持针对由产品用到的目标计算设备的评估和跟踪的关键绩效参数的方法。
7.3.1.HS.2-Note:
这些资源的例子是内存,容量,时间效率,I/O通道.固件例子包括处理器,内存,I/O通道.
8.3.2.HS.3开发过程质量测量
在设计开发策划的各个阶段，组织必须建立和保持项目选择和报告合适的设计开发过程质量测量的方法。
在此阶段推荐，测量系统必须针对项目被恰当地实施。
测量应该覆盖项目进度的区域（生命周期阶段转移或里程碑监视），测试实施和缺陷监视测试阶段。
根据顾客要求，沟通必须必须包括设计和开发过程测量的共同协议报告和评估。
8.3.2.HS.3注：
见在TL9000注册指南章节文件”建立和运行系统”，可帮助选择和建立合适的项目设计开发过程测量。
8.3.2.HS.4迁移策划
当一个系统，硬件或软件产品将要从一个旧环境迁移到一个新操作环境，组织必须开发和文件化迁移计划，假如老的环境不再被支持，用户必须给出转移计划和活动，包括新环境获得日期的通知，以及其他支持选择的获得描述，包括一旦老环境支持被移去。
这个计划也应该包括：
a）要求分析和迁移的定义，
b）迁移工具的开发，产品和数据的转换，
c）迁移的执行，
d）迁移的验证，和
e）今后对旧环境的支持。
8.3.2.HS.4注1：
操作环境由和顾客分别从或者组织或者供方采购，产品所需要的安装硬件，软件或系统组成的，从老的到新的软件操作环境变更例子包括升级到操作系统,数据库或沟通协议，从老的到新的硬件操作环境变更例子包括使用线路，包含在新的机架或用新的控
制器，或者升级计算机硬件。
8.3.2.HS.4注2:
假如老的环境不再被支持，针对使用的或连接老环境的进入，数据防护和审核目的应该被考虑，以符合法规和合同要求。
8.3.3.C.1顾客与外部供方的输入
组织必须建立并保持方法，以在开发新的或更改产品和服务要求时，和征求和考虑顾客与外部供方合作的输入。
8.3.3.C.2设计和开发要求
设计和开发要求应被确定并文件化，并应该包括：
a）质量和可靠性的要求，
b）产品和服务的功能和性能，
c）业务的、组织的和用户的要求，
d）安全，环境，可持续性、（信息）安全和隐私的要求，
e）可生产性、安装性、使用性、互用性和可维护性的要求，
f）设计限制/约束，和
g）测试要求，
h）产品的计算机资源。
i）来自以前项目的课程学习和回顾（经验教训）；
j）硬件包装要求（包括环境议题）。
备注：
有关需要考虑的环境问题的例子，请参阅术语表中的可持续性。
8.3.3.C.3要求配置
组织必须文件化针对产品和服务架构的要求配置。
注：
被配置的要求例子应该针对软件的响应时间，硬件的热耗散和服务的响应时间。
8.3.4设计和开发的控制
8.3.4.C注:
在各种确认的阶段,组织可以包括顾客和第三方;
8.3.4.C.1用户文件验证
组织必须在产品交付前验证顾客和/或使用者的文件。
8.3.4.HS.1过载测试
组织必须在过载的条件下测试产品，包括但不限于:
a）超边界条件和非法输入情况;
b）高流量和模拟峰值运载;
c）误操作;
8.3.4.HS.2异常条件
组织必须在异常条件下测试产品，确认期望的产品运行，适当时，应包括：
a）硬件错误，
b）软件错误，
c）操作,管理,维护和提供（OAM&P）的错误，
d）过载通量，
e）非法使用者进入，
f）来自中断的系统恢复。
8.3.4.HS.3系统测试
每一个产品发行必须服从于系统测试，符合文件化系统测试计划。
8.3.4.HS.4发行管理
组织必须保持文件化信息以确保产品和有关文件的发行和交付是在受控条件下被实施。
文件化信息应该提供顾客如下交付：
a）产品信息和发行的时间计划，
b）新和现存的软件产品或发行中，详细的交付产品特征描述和包含任何的更改，和
c）涉及到有关合同项目的目前或策划变更咨询（参见8.3.6.C.2）
8.3.5.HS.1产品设计和开发输出
设计和开发输出应该包括但不仅限于:
a）系统结构;
b）系统详细设计;
c）原始代码;和
d）用户文件.
8.3.5.V.1服务设计和开发输出
服务设计和开发的输出要求必须包含所提供服务的完整和精确的描述.设计和开发输出
应该包括但不仅限于：
a）文件化服务交付信息；
b）资源和技能要求；
c）外部供方的依靠；
d）受到客户评价的服务特性，和
e）每项服务特性的接受标准。
8.3.6.C.1更改管理过程
组织必须保持一文件化信息,以确保在产品生命周期中随时可能出现的所有要求和设计更改,以适合生命周期阶段方式均被系统地和及时地管理和跟踪，组织必须确保针对质量，可靠性和功能目的不利影响的变更，在批准前与顾客进行评审和认可。
更改管理应该包括：
a）影响分析，
b）策划，
c）实施，
d）测试，
e）文件化，
f）沟通，和
g）评审和批准。
8.3.6.C.1注：
当生命周期中的变更管理过程被规定时，在哪个过程中的控制可以依据生命阶段。
例如：
在设计过程中,组织应该有能力对快速变更顾客要求作出反应，利用突出技术响应变更管理过程。
在量产后变更管理过程范围应该考虑对产品运行和服务和维护及它的安装基础的变更如何影响顾客和相关方的整体性。
考虑的因素应该包括质量，可靠性和功能意图。
8.3.6.C.2通知设计变更的客户
组织必须确保当设计更改影响到合同承诺时的客户被通知。
8.3.6C.3问题解决配置管理
组织必须确保配置管理系统跟踪解决问题和整合这些解决在未来的更改版本中。
8.3.6H.1零件更改
组织必须保持文件化信息，以确保材料或零件的替代或更改不会负面影响产品要求的符合性或性能。
文件化信息应该包括：
a）功能测试，
b）认可测试，
c）负载测试，
d）合格部件清单，和/或
e）关键部件清单。
8.4外部提供过程、产品和服务的控制
8.4.1总则
8.4.1.C.1采购过程
组织应保持文件化的采购信息，确保：
a）产品和服务要求被清晰地定义，
b）风险被了解和管理，
c）认可准则被建立，
d）接收准则被建立，
e）合同被规定，
f）专利权、使用、所有权、担保书（质保期）和许可证得到满足，
g）产品和服务未来的支持被策划，
h）持续的供方管理和监控是适当的，
i）外部供方的选择准则被规定。
8.4.1.C.1注：
在选择外部供应商时，宜考虑可持续性要求比如，但不限于供应商的可持续性表现、供应原则或行为守则，或国际公认的标准。
8.4.1.C.2外部供方业绩管理
组织必须策划和执行外部供方业绩管理和开发活动，以便：
a）外部供方的质量绩效被跟踪，并反馈给外部供方，推动持续改进；依据建立的准则的合格供方，和
b）针对识别的关键供方，当外部供方的产品和服务发生时，推动TL9000要求和测量，或其他合适的质量管理体系,TL9000优先考虑。
8.4.1.C.2注1：
外部供方业绩管理策划和活动应该联系组织的10改进过程，
8.4.1.C.2注2：
应该认识到,就一组织而言，对所有外部供方提供一种影响程度水准是不可能的，该水准可以根据外部供方的业务量，产品的重要程度，问题的历史，组织的期望，供应链中供方的重要性或其他因素。
7.4.1.C.2注3:
针对合适的质量管理体系的例子可以包括:
a）调查,
b）外部供方问卷,
c）涉及到符合
升级会员 