8.1.3.13 项目采购管理
针对项目采购管理，必须应用8.4规定的要求。 8.1.4 配置管理
8.1.4.1 组织必须建立、实施和保持一个文件化的适于其产品的配置管理过程。
注：配置管理过程适于硬件和软件。
该过程必须考虑，至少在：a)技术状态管理策划； b)产品分解结构直至最低可更换单元； c)确定技术状态项，至少有关安全件；
d)建立技术状态基线，最低为“设计”、“建造”和“维护”； e)对技术状态的变更控制依据8.1.5； f)技术状态纪实；
g)可追溯性标识的准则（如序列、批次号）； 组织必须保留有关成文信息。 8.1.4.2该过程应：
a)考虑定期内部技术状态审核；
b)整合外部提供方的技术状态管理体系（如数据转移接口）；
c)作为技术状态项，考虑在设计、开发、生产和维护中所用工具和软件； d)由一个应用软件支持。 8.1.4.3 注：见ISO10007 指南。 8.1.5 变更管理
8.1.5.1 组织必须建立、实施和保持文件化过程以管理变更。这些过程必须包括：a)在这个标准中规定的要求，如：1)在8.2.4用于产品和服务要求； 2)在8.3.6用于设计和开发变更； 3)在8.5.6用于生产和服务提供； b)变更申请；
c)原因分析，当变更源于失效； d)变更影响分析，考虑风险和机会；
e)对所建议的变更予以验证，以避免不利影响；
f)通知并与顾客、外部提供方和授权机构达成协议，基于准则至少包括变更影响到他们的要求；
注1：变更影响到顾客要求可引发一个偏差许可；
注2：当顾客批准该变更时，来自一个偏差许可的所规定变更申请可以关闭。
g)为变更批准指派职责和权限（如变更控制委员会）； h)实施前变更的批准； i)实施变更；
j)实施和跟踪的验证。
这些过程必须由一个应用软件支持。
8.1.5.2这些过程应包括： a)策划措施以将变更影响降到最低； b)由一个应用软件支持变更的可追溯性；
8.1.5.3对产品和服务技术变更，这些过程必须还包括：a)一个变更影响分析，在
1)已经交付的组件和产品； 2)顾客规范和技术状态；
3)有关成文信息（如质量保证计划、FMEA报告）
b)重新评价功能，非功能和集成要求； c)再确认活动基于影响分析的结果；
d)要求保留关于被变更产品和服务的序列号和/或日期的成文信息。
注：变更可能引起可靠性的缺乏、老化（产品或外部提供方）、标准/规程/法律/运行需求的进化、成本优化、或特定事件：事故、差错、天气或顾客工程变更通知单。 8.1.5.4 对产品和服务技术变更，这些过程应还包括重新评估运行和集成成熟度。 8.1.5.5 变更管理要求必须应用到：a)项目管理（见8.1.3）； b)产品和服务的要求（见8.2.4）； c)产品和服务的设计开发（见8.3.6）；
d)外部提供过程、产品和服务的控制（见8.4）；
e)生产和服务提供（见8.5.6），包含生产过程、生产设备、生产程序（软件）和生产地点。
注1：变更发动可能是外部提供方或组织为了改进或纠正设计，或顾客工程变更通知单。 注2：启动变更过程的触发点是被批准的成文信息的预期变更。 8.2 产品和服务的要求 8.2.1 顾客沟通
与顾客沟通的内容应包括：a)提供有关产品和服务的信息； b)处理问询、合同或订单，包括更改；
c)获取有关产品和服务的顾客反馈，包括顾客投诉； d)处置或控制顾客财产；
e)关系重大时，制定应急措施的特定要求。 8.2.1.1 顾客沟通–补充
当预计延误且不能避免（如延误来自外部提供方），组织必须向顾客沟通。 8.2.2 产品和服务要求的确定
a) 在确定向顾客提供的产品和服务的要求时，组织应确保：产品和服务的要求得到规定，包括：
1）适用的法律法规要求； 2）组织认为的必要要求。
b)提供的产品和服务能够满足所声明的要求。 8.2.2.1 产品和服务要求的确定–补充
8.2.2.1.1当确定要求时，组织必须考虑：a)功能、非功能和集成要求； b)RAMS/LCC要求。
8.2.2.1.2当确定要求时，组织应考虑：a)来自类似产品/投标/项目的经验； b)产生于市场分析的要求；
c)老化要求（如来自市场、外部提供方、法规的信息）； d)关键产品特性；
e)有关产品寿命结束的要求（如处置、再循环）。 注：与外部提供方一起的老化管理可依据IRIS老化指南。 8.2.3 产品和服务要求的评审
8.2.3.1组织应确保有能力向顾客提供满足要求的产品和服务。在承诺向顾客提供产品和服务 之前，组织应对如下各项要求进行评审： a)顾客规定的要求，包括对交付及交付后活动的要求；
b)顾客虽然没有明示，但规定的用途或已知的预期用途所必需的要求； c)组织规定的要求；
d)适用于产品和服务的法律法规要求； e)与以前表述不一致的合同或订单要求。
组织应确保与以前规定不一致的合同或订单的要求已得到解决。
若顾客没有提供成文的要求，组织在接受顾客要求前应对顾客要求进行确认。
注：在某些情况下，如网上销售，对每一个订单进行正式的评审可能是不实际的，作为替代方法，可评审有关的产品信息，如产品目录。
8.2.3.2适用时，组织应保留与下列有关的成文信息：a)评审结果； b)产品和服务的新要求。 8.2.4 产品和服务要求的更改
若产品和服务要求发生更改，组织应确保相关的成文信息得到修改，并确保相关人员知道已 更改的要求。 8.2.5 –补充
组织必须建立、实施和保持一个文件化过程以管理产品和服务要求。 该过程必须：a)考虑8.2规定的要求； b)应用于：
1)在投标之前满足市场预期的新产品和服务的设计开发（如平台、产品系列）； 2)投标管理（提交标书、接受合同或订单）； 3)项目执行（如接受合同或订单变更）； 4)变更控制（见8.1.5）。
注：该过程可以包括在项目管理过程中。
c)通过多方论证方法执行，适用时包括内部和外部干系人； d)至少包括这些步骤：
1)确定（见8.2.2）； 2)评审（见8.2.3）； 3)验证； 4)确认；
e)确保要求是：1)分别逐项检查； 2)评估和考虑； 3)评价有关风险和机会；
4)由相关人员适当的转换、理解、共识、逐层分解和承诺； 5)完整、明确、可验证和可行的； 6)技术要求被文件化在需求说明书中； 注：需求说明书可以由顾客提供或组织编制。 更新如发生变更。
8.3 产品和服务的设计和开发 8.3.1总则
组织应建立、实施和保持适当的设计和开发过程，以确保后续的产品和服务的提供。 8.3.1.1 总则–补充
8.3.1.1.1在8.3规定的要求应用于新技术的设计开发或引进（如复合材料制品、激光焊 接）。
组织为新技术的落实必须执行过程FMEA。 设计和开发过程必须：
a)考虑8.3.2, 8.3.3, 8.3.4, 8.3.5, 8.3.6描述有关策划、输入、控制、输出和变更的要求； b)文件化；
c)结合IEC62278（EN50126）或等同标准的与安全有关的产品，依据IEC62425（EN50129）或等同标准规定安全案例；
8.3.1.1.2组织必须确定设计开发人员的必要能力和相应级别，有关：
a)需求管理； b)技术状态管理； c)质量保证方法。 8.3.2 设计和开发策划
在确定设计和开发的各个阶段和控制时，组织应考虑：
a)设计和开发活动的性质、持续时间和复杂程度； b)所需的过程阶段，包括适用的设计和开发评审；
c)所需的设计和开发验证、确认活动； d)设计和开发过程涉及的职责和权限；
e)产品和服务的设计和开发所需的内部、外部资源； f)设计和开发过程参与人员之间接口的控制需求； g)顾客及使用者参与设计和开发过程的需求； h)对后续产品和服务提供的要求；
i)顾客和其他有关相关方期望的对设计和开发过程的控制水平； j)证实已经满足设计和开发要求所需的成文信息。 8.3.2.1 设计和开发策划–补充
8.3.2.1.1 在确定设计和开发的阶段和控制时，组织必须考虑：
a)每个过程阶段的目标； b)产品构造（如产品分解结构）； c)技术状态控制，见8.1.4；
d)在产品架构的规定层级上进行设计评审、验证和确认（如首先从部件设计评审、接着 子系统设计评审、然后上升为系统设计评审）； e)针对特殊过程的设计评审、验证和确认；
设计和开发的阶段和控制必须文件化（如在一个质量保证计划中）。
注：设计可以是方案设计、初步设计、最终设计。
8.3.2.1.2在确定设计和开发的阶段和控制时，组织应考虑：
a)每个设计和开发阶段满足目标的质量保证方法（如规定在一个质量保证计划）； b)控制非功能、功能、性能和集成要求的方法； c)控制集成和运行成熟度的方法。
注1：如果特殊过程要求作为设计输入，依据IRIS特殊过程指南，这些特殊过程的风险评估是设计和开发过程的一部分。
注2：和外部行业协作可以考虑作为外部提供服务（见8.4）。
8.3.3 设计和开发输入
组织应针对所设计和开发的具体类型的产品和服务，确定必需的要求。组织应考虑：
a)功能和性能要求；
b)来源于以前类似设计和开发活动的信息； c)法律法规要求；
d)组织承诺实施的标准或行业规范； e)由产品和服务性质所导致的潜在失效后果。
针对设计和开发的目的，输入应是充分和适宜的，且应完整、清楚。 相互矛盾的设计和开发输入应得到解决。 组织应保留有关设计和开发输入的成文信息。