7.2.2.C2 合同評審
組織必須建立和保持以合同評審過程，并應(yīng)該包括：
a) 產(chǎn)品接受準則和準則評審過程，
b) 處理在產(chǎn)品接受后發(fā)現(xiàn)的問題方法，包括顧客抱怨，
c) 在適用的保質(zhì)期后或在產(chǎn)品合同約定的維護期內(nèi), 不合格的移去和/或糾正計劃，
d) 可能不可預(yù)計費用和風險識別，
e) 針對產(chǎn)權(quán)信息足夠的防護，
f) 組織與外包工作有關(guān)的職責定義，
g) 由顧客執(zhí)行的活動，包括顧客在要求,規(guī)范和接受中的作用；
h) 由顧客提供的裝置，工具和軟件項目，和
i) 所有參考的標準和程序。
7.2.2.C 2注：適當時，產(chǎn)品接受準則應(yīng)該包括：
a）文件化測試程序，
b）測試用例，
c）測試數(shù)據(jù)，
d）測試職責，
f）包含的資源，
g）規(guī)定的接受測試報告。
7.2.3.C.1 問題的嚴重度分類
除了嚴重程度水平報告特別除外的那些產(chǎn)品, 組織必須根據(jù)本手冊中的術(shù)語定義中對關(guān)鍵，嚴重和輕微問題報告定義對客戶的影響來確定客戶報告問題的嚴重度，必須根據(jù)這嚴重程度來確定組織作出反必須的及時程度。
7.2.3.C.1 - 注1 ：客戶與組織應(yīng)該共同決定解決客戶報告問題的優(yōu)先次序。
7.2.3.C.1-注 2: 在報告NPR4的產(chǎn)品類型單獨注冊的組織不需要通知豁免此要求。
7.2.3.C.2 問題的提升
組織必須建立一文件化提升程序以解決客戶報告問題。
7.2.3.C.3 問題報告反饋
組織必須及時和系統(tǒng)地向客戶對其問題報告提供反饋。
7.2.3.HS.1 產(chǎn)品追回
組織必須建立并保持文件化程序以識別和追回不適合繼續(xù)服務(wù)的產(chǎn)品。
7.2.3.HS.2 設(shè)計開發(fā)過程質(zhì)量測量數(shù)據(jù)報告
按顧客要求，溝通必須包括共同認可的設(shè)計開發(fā)過程測量的報告和評價。
7.2.3 HS.3 關(guān)鍵問題報告的通知
組織必須建立一文件化程序，通知可能由關(guān)鍵問題報告影響到的所有顧客。
7.2.3.V.1 關(guān)鍵服務(wù)中斷通知
組織必須針對影響到的顧客建立和保持一方法，獲取關(guān)于目前中斷的實時信息。
7.2.3.V.1-注 1: 此要求僅適用于提供服務(wù)給最終客戶的組織。
7.3.1.C.1 項目計劃
組織的序幕策劃活動必須根據(jù)已規(guī)定的產(chǎn)品生命周期模式建立并保持項目計劃（見7.1.C.1）。計劃應(yīng)該包括：
a) 項目組織結(jié)構(gòu);
b) 項目團隊的作用，職責和義務(wù);
c) 相關(guān)團隊或個人在組織內(nèi)外部的作用，職責和義務(wù)，在他們和項目團隊之間的接口，
d) 時間計劃，跟蹤，問題解決和報告的方法;
e) 項目因素估算;
f) 準備使用的方法，標準，文件化程序和工具的標識(假如此項目是被清晰的定義作為產(chǎn)品生命周期模式的部分，參考生命周期模式是可以的)，
g) 與其它相關(guān)計劃的連接(例如：風險管理，開發(fā)，測試，配置管理和質(zhì)量)，
h) 項目特定開發(fā)或服務(wù)交付環(huán)境和物質(zhì)資源的考慮(例如：去描述開發(fā),用戶文件， 檢測, 操作,規(guī)定的開發(fā)工具,安全計算環(huán)境,試驗空間,工位等的資源)，
I) 針對X(DFx)設(shè)計計劃適合于產(chǎn)品的生命周期;
j) 項目質(zhì)量的管理，包括合適的質(zhì)量測量，
k) “X”計劃設(shè)計適合產(chǎn)品生命周期(計劃例子包括,但不限于:可加工性,可靠性,法規(guī)性,適用性,
安全性,耐久性,和可試驗性)
l) 來自先前項目一流分析的課程，
m) 風險管理和應(yīng)急計劃 (例如，工作風險, 現(xiàn)場低可靠性, 缺陷, 資源和時間計劃)，
n) 項目特定的培訓要求，
o) 規(guī)定的認證，(例:產(chǎn)品認證或員工的技術(shù)認證)
p) 專利權(quán)，使用權(quán)，所有權(quán)，保證期和許可證權(quán)限，和
q) 項目完成后的分析和改進活動，包括學習的項目課程根本原因分析，和在將項目中排除重復(fù)發(fā)生而采取的糾正措施。
7.3.1.C.1- 注 1: 項目計劃和任何其它相關(guān)計劃都可以是一個獨立的文件或是另外一份文件的一部分或是幾份文件的組合.
7.3.1.C.1 – 注 2: 對所有開發(fā)項目都通用的，規(guī)定任務(wù)和職責的通用作業(yè)指導書不需要重復(fù)作為項目計劃的一部分。
7.3.1.C.1-注 3:項目因素的估計應(yīng)該包括產(chǎn)品的規(guī)模,復(fù)雜性,要求變更,工作量,雇工,計劃,成本,質(zhì)量,可靠性,和產(chǎn)率.來自估算過程的數(shù)據(jù)應(yīng)該和比較先前估算到實際進行分析.
7.3.1.C.1-注 4: DFx 例子包括可加工性，可靠性，法規(guī)，可維修性和可試驗性。參見DFx 在TL9000.org 針對例子和其他信息的指南文件。
7.3.1.C.2 要求的可追溯性
組織必須建立并保持一方法以追溯每一個設(shè)計和檢測過程中文件化的要求。
7.3.1.C.2 - 注 ：
組織應(yīng)該建立溝通方法以傳達產(chǎn)品要求和要求的更改，給項目計劃中識別的所有受影
響相關(guān)方。
7.3.1.C.3 測試策劃
測試計劃必須文件化，并應(yīng)該包括:
a) 測試范圍 (例如, 單元, 特征, 集成, 系統(tǒng), 驗收,電場,轉(zhuǎn)移和回歸);
b) 需要進行的測試種類 (例如, 功能, 極限, 使用性, 性能, 回歸, 相互操作性,超載);
c) 對要求的可追溯性;
d) 測試環(huán)境 (例如, 有關(guān)客戶環(huán)境, 操作使用);
e) 測試覆蓋范圍; ( 驗證產(chǎn)品功能程度的測試，有時用功能測試百分比來表示)，
f) 期望結(jié)果;
g) 數(shù)據(jù)的定義和數(shù)據(jù)庫的要求;
h) 測試裝置, 測試實例 (輸入, 輸出, 測試準則) 和文件化測試程序;
i) 外部測試的使用，和
j) 報告和解決缺陷的方法。
k) 顧客測試要求
l) 預(yù)定義的退出準則.
測試結(jié)果和其后的采取的措施必須被記錄(參見4.2.4).
7.3.1.C 4 風險管理策劃
組織必須開發(fā)和文件化一個針對會影響成本, 進度, 產(chǎn)品質(zhì)量或產(chǎn)品業(yè)績方面的項目識別, 分析和風險控制的計劃。
7.3.1.C.4 注：
風險管理應(yīng)該在所有的產(chǎn)品開發(fā)階段被執(zhí)行，可以包括：
a) 確定風險資源,分類和優(yōu)先順序;
b) 關(guān)鍵和致命特性和失效模型,包括顧客的期望，
c) 被用于界定風險優(yōu)選和任何計分的原理的風險參數(shù)定義(例如:發(fā)生的可能性,影響的程度)被應(yīng)用(例如:FEMA, Failure Mode Effect Analysis)，
d) 風險如何被管理(例如:使用的工具,降低風險的措施,遷移決策,監(jiān)視和報告的要求)，
e) 來之合適的功能性學科的輸入，
f) 針對獲取和應(yīng)用學習課程的機制。
7.3.1.C.5 集成策劃
組織必須開發(fā)并文件化一計劃去集成硬件，軟件和/或服務(wù)部分進入到產(chǎn)品中，以確保達到設(shè)計要求。計劃必須包括：
a) 方法和文件化程序，
b) 職責，
c) 集成的時間計劃， 和
d) 測試要求。
7.3.1.HS.1 遷移策劃
當一個系統(tǒng)，硬件或軟件產(chǎn)品將要從一個舊環(huán)境遷移到一個新操作環(huán)境，組織必須開發(fā)和文件化遷移計劃，假如老的環(huán)境不再被支持，用戶必須給出轉(zhuǎn)移計劃和活動，包括新環(huán)境獲得日期的通知，以及其他支持選擇的獲得描述，包括一旦老環(huán)境支持被移去。這個計劃也應(yīng)該包括：
a) 要求分析和遷移的定義，
b) 遷移工具的開發(fā)，
c) 產(chǎn)品和數(shù)據(jù)的轉(zhuǎn)換，
d) 遷移的執(zhí)行，
e) 遷移的驗證，和
f) 今后對舊環(huán)境的支持。