7.2.2.C2 合同评审
组织必须建立和保持以合同评审过程，并应该包括：
a) 产品接受准则和准则评审过程，
b) 处理在产品接受后发现的问题方法，包括顾客抱怨，
c) 在适用的保质期后或在产品合同约定的维护期内, 不合格的移去和/或纠正计划，
d) 可能不可预计费用和风险识别，
e) 针对产权信息足够的防护，
f) 组织与外包工作有关的职责定义，
g) 由顾客执行的活动，包括顾客在要求,规范和接受中的作用；
h) 由顾客提供的装置，工具和软件项目，和
i) 所有参考的标准和程序。
7.2.2.C 2注：适当时，产品接受准则应该包括：
a）文件化测试程序，
b）测试用例，
c）测试数据，
d）测试职责，
f）包含的资源，
g）规定的接受测试报告。
7.2.3.C.1 问题的严重度分类
除了严重程度水平报告特别除外的那些产品, 组织必须根据本手册中的术语定义中对关键，严重和轻微问题报告定义对客户的影响来确定客户报告问题的严重度，必须根据这严重程度来确定组织作出反必须的及时程度。
7.2.3.C.1 - 注1 ：客户与组织应该共同决定解决客户报告问题的优先次序。
7.2.3.C.1-注 2: 在报告NPR4的产品类型单独注册的组织不需要通知豁免此要求。
7.2.3.C.2 问题的提升
组织必须建立一文件化提升程序以解决客户报告问题。
7.2.3.C.3 问题报告反馈
组织必须及时和系统地向客户对其问题报告提供反馈。
7.2.3.HS.1 产品追回
组织必须建立并保持文件化程序以识别和追回不适合继续服务的产品。
7.2.3.HS.2 设计开发过程质量测量数据报告
按顾客要求，沟通必须包括共同认可的设计开发过程测量的报告和评价。
7.2.3 HS.3 关键问题报告的通知
组织必须建立一文件化程序，通知可能由关键问题报告影响到的所有顾客。
7.2.3.V.1 关键服务中断通知
组织必须针对影响到的顾客建立和保持一方法，获取关于目前中断的实时信息。
7.2.3.V.1-注 1: 此要求仅适用于提供服务给最终客户的组织。
7.3.1.C.1 项目计划
组织的序幕策划活动必须根据已规定的产品生命周期模式建立并保持项目计划（见7.1.C.1）。计划应该包括：
a) 项目组织结构;
b) 项目团队的作用，职责和义务;
c) 相关团队或个人在组织内外部的作用，职责和义务，在他们和项目团队之间的接口，
d) 时间计划，跟踪，问题解决和报告的方法;
e) 项目因素估算;
f) 准备使用的方法，标准，文件化程序和工具的标识(假如此项目是被清晰的定义作为产品生命周期模式的部分，参考生命周期模式是可以的)，
g) 与其它相关计划的连接(例如：风险管理，开发，测试，配置管理和质量)，
h) 项目特定开发或服务交付环境和物质资源的考虑(例如：去描述开发,用户文件， 检测, 操作,规定的开发工具,安全计算环境,试验空间,工位等的资源)，
I) 针对X(DFx)设计计划适合于产品的生命周期;
j) 项目质量的管理，包括合适的质量测量，
k) “X”计划设计适合产品生命周期(计划例子包括,但不限于:可加工性,可靠性,法规性,适用性,
安全性,耐久性,和可试验性)
l) 来自先前项目一流分析的课程，
m) 风险管理和应急计划 (例如，工作风险, 现场低可靠性, 缺陷, 资源和时间计划)，
n) 项目特定的培训要求，
o) 规定的认证，(例:产品认证或员工的技术认证)
p) 专利权，使用权，所有权，保证期和许可证权限，和
q) 项目完成后的分析和改进活动，包括学习的项目课程根本原因分析，和在将项目中排除重复发生而采取的纠正措施。
7.3.1.C.1- 注 1: 项目计划和任何其它相关计划都可以是一个独立的文件或是另外一份文件的一部分或是几份文件的组合.
7.3.1.C.1 – 注 2: 对所有开发项目都通用的，规定任务和职责的通用作业指导书不需要重复作为项目计划的一部分。
7.3.1.C.1-注 3:项目因素的估计应该包括产品的规模,复杂性,要求变更,工作量,雇工,计划,成本,质量,可靠性,和产率.来自估算过程的数据应该和比较先前估算到实际进行分析.
7.3.1.C.1-注 4: DFx 例子包括可加工性，可靠性，法规，可维修性和可试验性。参见DFx 在TL9000.org 针对例子和其他信息的指南文件。
7.3.1.C.2 要求的可追溯性
组织必须建立并保持一方法以追溯每一个设计和检测过程中文件化的要求。
7.3.1.C.2 - 注 ：
组织应该建立沟通方法以传达产品要求和要求的更改，给项目计划中识别的所有受影
响相关方。
7.3.1.C.3 测试策划
测试计划必须文件化，并应该包括:
a) 测试范围 (例如, 单元, 特征, 集成, 系统, 验收,电场,转移和回归);
b) 需要进行的测试种类 (例如, 功能, 极限, 使用性, 性能, 回归, 相互操作性,超载);
c) 对要求的可追溯性;
d) 测试环境 (例如, 有关客户环境, 操作使用);
e) 测试覆盖范围; ( 验证产品功能程度的测试，有时用功能测试百分比来表示)，
f) 期望结果;
g) 数据的定义和数据库的要求;
h) 测试装置, 测试实例 (输入, 输出, 测试准则) 和文件化测试程序;
i) 外部测试的使用，和
j) 报告和解决缺陷的方法。
k) 顾客测试要求
l) 预定义的退出准则.
测试结果和其后的采取的措施必须被记录(参见4.2.4).
7.3.1.C 4 风险管理策划
组织必须开发和文件化一个针对会影响成本, 进度, 产品质量或产品业绩方面的项目识别, 分析和风险控制的计划。
7.3.1.C.4 注：
风险管理应该在所有的产品开发阶段被执行，可以包括：
a) 确定风险资源,分类和优先顺序;
b) 关键和致命特性和失效模型,包括顾客的期望，
c) 被用于界定风险优选和任何计分的原理的风险参数定义(例如:发生的可能性,影响的程度)被应用(例如:FEMA, Failure Mode Effect Analysis)，
d) 风险如何被管理(例如:使用的工具,降低风险的措施,迁移决策,监视和报告的要求)，
e) 来之合适的功能性学科的输入，
f) 针对获取和应用学习课程的机制。
7.3.1.C.5 集成策划
组织必须开发并文件化一计划去集成硬件，软件和/或服务部分进入到产品中，以确保达到设计要求。计划必须包括：
a) 方法和文件化程序，
b) 职责，
c) 集成的时间计划， 和
d) 测试要求。
7.3.1.HS.1 迁移策划
当一个系统，硬件或软件产品将要从一个旧环境迁移到一个新操作环境，组织必须开发和文件化迁移计划，假如老的环境不再被支持，用户必须给出转移计划和活动，包括新环境获得日期的通知，以及其他支持选择的获得描述，包括一旦老环境支持被移去。这个计划也应该包括：
a) 要求分析和迁移的定义，
b) 迁移工具的开发，
c) 产品和数据的转换，
d) 迁移的执行，
e) 迁移的验证，和
f) 今后对旧环境的支持。