TL9000标准50(中文草案).docx

TL 9000通信電子業品質管理系統

30 June 2009生效
Revision 5.0 (草案版)

第四章 品質管理系統
4.1 一般性要求
組織應按本標準的要求建立品質管理系統，形成文件，加以實施和維護，並持續改進其有效性。
組織應：
a) 決定品質管理系統所需的過程及其在組織中的應用（見1.2）;
b) 決定這些過程的順序和相互作用；
c) 決定為確保這些過程的有效運行和管制所需的準則和方法；
d) 確保可以獲得必要的資源和資訊，以支援這些過程的運行和對這些過程的監督；
e) 監視、測量(在適當時)和分析這些過程；
f) 實施必要的措施，以實現對這些過程策劃的結果和對這些過程的持續改善。
組織應按本標準的要求管理這些過程。
當組織選擇將任何會影響產品符合要求之部分過程外包時，這些外包過程的管制的型態與程度，應在品質管理系統內加以訂定。
註1：上述品質管理系統所需的過程應當包括與管理活動、資源提供、產品實現和測量、分析及改善等有關的過程。
註2 :「外包過程」就是經鑑別出為組織品質管理系統所需，但選擇由組織以外的單位來執行的過程。【新增】
註3 :確保外包過程之管制，不得免除組織符合所有客戶、法令及法規之責任。對於施行於外包過程的管制型態與程度可受下列因素影響：
a) 外包過程對組織提供符合要求產品能力的潛在衝擊；
b) 對該過程管制之分擔的程度；
c) 藉由標準7.4款要求之施行所能達到必要的管制的能力。【新增】
4.2 文件要求
4.2.1 總則
品質管理系統文件應包括：
a) 形成文件的品質政策和品質目標；
b) 品質手冊；
c) 本國際標準所要求的文件化程序和紀錄；
d) 組織確定為其過程之有效規劃、運作及管制所需的文件，包括紀錄；
註1：本標準出現“形成文件的程序”之處，即要求建立該程序，形成文件，並加以實施和維護。一份文件可包含一或多個程序要求；一項文件化程序的要求也可涵蓋一份以上的文件來對應。
註2:不同組織的品質管理系統文件的多少與詳略程度取決於：
a)組織的規模和活動的類型；
b)過程及其相互作用的複雜程度；
c)人員的能力。
註3：文件可採用任何形式或類型的媒體。

4.2.2 品質手冊
組織應編制和維護品質手冊，品質手冊包括：
a) 品質管理系統的範圍，包括任何刪減的細節與合理性（見1.2）;
b) 為品質管理系統編制的形成文件的程序或對其引用；
c) 品質管理系統過程之間的相互作用的表述。

4.2.3 文件管制
品質管理系統所要求的文件應予以管制。記錄是一種特殊類型的文件，應依據4.2.4的要求進行管制。
應編制形成文件的程序，以規定以下方面所需的管制：
a) 文件發佈前得到批准，以確保文件是充分與適宜的；
b) 必要時對文件進行審查與更新，並再次批准；
c) 確保文件的更改和現行修訂狀態得到識別；
d) 確保在使用處可獲得適用文件的有關版本；
e) 確保文件維護清晰、易於識別；
f) 確保組織所確定，為規劃與運作其品質管理系統所必須之外來原始文件被鑑別出來，並管制其分發;
g) 防止作廢文件的非預期使用，若因任何原因而保留作廢文件時，對這些文件進行適當的標識。

4.2.3.C.1 顧客提供文件和資料的管制
如果顧客提供的文件和資料影響到產品的實現和支援，則組織必須建立和維護一個形成文件的程序來管制所有這些文件和資料（例如:網路結構、拓撲、容量、安裝終端分配、圖紙及資料庫）。

4.2.4 記錄管制【文字改寫】
為提供品質管理系統各種要求之符合及有效運作的證據所建立之紀錄必須管制。
組織須建立書面化程序以確立記錄之識別、儲存、保護、調閱、保存期限、及清除所需的種種管制。
記錄必須保持清晰可讀、識別及可回復。
第五章 管理職責
5.1 管理承諾
最高管理者應通過以下活動，對其建立、實施品質管理系統並持續改進其有效性的承諾提供證據：
a) 向組織傳達滿足顧客和法律法規要求的重要性；
b) 制定品質政策；
c) 確保品質目標的制定；
d) 進行管理審查；
e) 確保資源的獲得。

5.2 以顧客為關注焦點
最高管理者應以增強顧客滿意為目的，確保顧客的要求得到確定並予以滿足（見7.2.1和8.2.1）。
5.2.C.1 顧客關係開發
最高管理者必須證明他們積極主動參與建立和維持組織和顧客間的互利關係。
5.2.C.2 顧客溝通方法
組織應建立及維持一些方法以對選擇之客戶作溝通，共同分享的期望，以確保產品品質的提升。客戶溝通的結果應產生問題解決的行動及提供客戶滿意改善的機會。[4]
5.2.C.2-註 1：眾所周知組織不可能和所有顧客做同樣程度的溝通。溝通的程度取決於顧客的業務量、問題的歷史、顧客的期望以及其他因素。（見文件“與顧客溝通指南”，參考http://tl9000.org/handbooks/links.html）。
5.3 品質政策
最高管理者應確保品質政策：
a) 與組織的宗旨相適應；
b) 包括對滿足要求和持續改進品質管理系統有效性的承諾；
c) 提供制定和審查品質目標的框架；
d) 在組織內得到溝通和理解；
e) 在持續適宜性方面得到審查。
5.4 策劃
5.4.1 品質目標
最高管理者應確保在組織的相關職能和層次上建立品質目標，品質目標包括滿足產品要求所需的內容【見7．1a】。品質目標應是可測量的，並與品質政策維護一致。
5.4.1.C.1 品質目標
品質目標必須包括TL 9000 品質管理系統測量手冊中規定的 TL 9000測量的目標。
5.4.2 品質管理系統策劃
最高管理者應確保：
a) 對品質管理系統進行策劃，以滿足品質目標以及4.1的要求。
b)在對品質管理系統的變更進行策劃和實施時，維護品質管理系統的完整性。

5.4.2.C.1 長期和短期品質策劃
組織的品質策劃活動必須包括長、短期計畫，其目的是改進品質及提高顧客滿意。這些計畫必須含有與組織及其顧客相關的營運因素，包括與選定客戶共同制訂之績效目標。績效目標成果應監控和呈報最高管理者。
5.4.2.C.1-註1：計畫可考慮的因素例如：
a) 週期
b) 客戶服務
c) 培訓
d) 成本
e) 交貨承諾
f) 產品可靠度；和
g) 可持續性。

5.4.2.C.1註2：最高管理者應該證明他們積極主動參與了長期和短期品質策劃。

5.4.2.C.2 顧客輸入
對於品質策劃活動，組織必須實施徵求及考慮顧客對品質策劃活動輸入的方法。組織應該與顧客一起建立共同的品質改進計畫。[4]

5.4.2.C.3 供應商輸入
對於品質策劃活動，組織必須實施徵求及使用供應商品質策劃活動輸入的方法。[4]

5.5 職責、許可權與溝通
5.5.1 職責和許可權
最高管理者應確保組織內的職責、許可權得到規定和溝通。

5.5.2 管理者代表
最高管理者應在組織的管理人員中指定一名管理代表，無論該成員在其他方面的職責如何，應具有以下方面的職責和許可權：
a) 確保品質管理系統所需的過程得到建立、實施和維護；
b) 向最高管理者報告品質管理系統的績效和任何改進的需求；
c) 確保在整個組織內提高滿足顧客要求的意識。
註：管理者代表的職責可包括與品質管理系統有關事宜的外部聯絡。

5.5.3 內部溝通
最高管理者應確保在組織內建立適當的溝通過程，並確保對品質管理系統的有效性進行溝通。
5.5.3.C.1 組織績效回饋
組織必須把其品質績效和顧客滿意水準通知員工，包括品質管理系統審查的結果。[4]
5.5.3.C.1註：敏感的組織訊息可以從這一個要求被排除。【新增】
5.6 管理審查
5.6.1 總則
最高管理者應按策劃的時間間隔審查品質管理系統，以確保其持續的適宜性、充分性和有效性。審查應包括評價品質管理系統改進的機會和變更的需要，包括品質政策和品質目標。
應維護管理審查的記錄（見4.2.4）。

5.6.2 審查輸入
管理審查的輸入應包括以下方面的資訊：
a) 稽核結果；
b) 顧客回饋；
c) 過程的績效和產品的符合性；
d) 預防和矯正措施的狀況；
e) 以往管理審查的跟蹤措施；
f) 可能影響品質管理系統的變更；
g) 改進的建議。

5.6.3 審查輸出
管理審查的輸出應包括與以下方面有關的任何決定和措施：
a) 品質管理系統及其過程有效性的改進；
b) 與顧客要求有關的產品的改進；
c) 資源需求。
第六章 資源管理
6.1 資源提供
組織應確定並提供以下方面所需的資源：
a) 實施、維護品質管理系統並持續改進其有效性；
b) 通過滿足顧客要求，增強顧客滿意。

6.2 人力資源
6.2.1 總則
應以適當的教育、訓練、技術和經驗為基礎，使執行會影響產品要求符合性之人員能勝任其工作。
註：對產品要求之符合性，會受到執行任何品質管理系統中的工作的人員直接或間接的影響。

6.2.2 能力、意識和培訓
組織應：
a) 決定執行影響產品要求符合性的人員所必須的能力；
b) 適當時，提供訓練或採取其他措施，以達成所需之能力；
c) 評價所採取措施的有效性；
d) 確保員工認識到所從事活動的相關性和重要性，以及如何為實現品質目標做出貢獻；
e) 維護教育、培訓、技能和經驗的適當記錄（見4.2.4）。

6.2.2.C註:教育與培訓需求因組織的活動、個體責任、組織階段及個人發展性質。提供的方法可包括在職培訓、交叉培訓、工作輪替，顧客經驗、電腦教學、遠距教學及其它培訓可為內訓或外訓且應對職務再加強任用。

6.2.2.C.1 內部課程開發
當組織有發展內部培訓課程的責任時，組織必須制定及建立確認課程計畫，發展及提供的一般性的方法。[4]
6.2.2.C.2 品質及流程改進概念
對產品的品質有直接影響的員工，包括最高管理者，都必須增加在持續改進、解決問題及顧客滿意等基本概念方面接受培訓及應用。[4]
6.2.2.C.3 產品品質培訓機會認知
對培訓會影響產品品質而需要時，組織必須具有方法確保員工能參與。方法應包括：
a)對培訓機會的傳達
b)培訓的存在。 [4]
6.2.2.C.4 防靜電保護(ESD)培訓
所有參與易受防靜電保護（ESD）傷害產品的搬運、貯存、包裝、防護或交付的員工，在開始工作之前都必須接受防靜電保護（ESD）防護的培訓。組織應定義ESD再訓練的方式與頻率。
6.2.2.C.5 高級品質培訓
組織必須提供適當等級的高級品質培訓。高級品質培訓的實例可包括在統計技術、過程能力、統計抽樣、資料收集和分析、問題識別、問題分析及問題根源分析。[5]
6.2.2.C.6 危害狀況培訓內容
在有潛在危險情況存在的地方，培訓內容必須包括：
a) 任務的執行；
b) 人員的安全及適當的防護設備；
c) 危險環境的意識；
d) 設備防護。
6.2.2.HV.1 人員資格
組織必須建立對所有有關過程的員工資格和再確認資格要求。資格要求至少必須提出員工教育、經驗、培訓、和技術的證實。[4]
6.2.2.HV.1-註：例如在繞線、焊、焊接、光電之電流及實驗室程序等流程需人員資格及再確認資格。
6.3 基礎設施
組織應確定、提供並維護為達到產品符合要求所需的基礎設施。適用時，基礎設施包括：
a) 建築物、工作場所和相關的設施；
b) 過程設備（硬體和軟體）；
d) 支援性服務（如運輸、通訊或資訊系統）。
6.3.C.1 設施
組織必須辨識設施中關鍵區域並提供此地區適當的安全保護。[5]
6.4 工作環境
組織應確定並管理為達到產品符合要求所需的工作環境。
備註：名詞“工作環境”指的是執行工作的情況，包括物理的、環境的及其它因素(例如噪音、溫度、濕度、照明及氣候)
6.4.C.1 工作區域
對於影響產品品質的用於產品的搬運、貯存和包裝的區域必須乾淨、安全且有條理以確保它們不會對品質或人員的績效帶來不利影響。

第七章 產品實現
7.1 產品實現的策劃
組織應策劃和開發產品實現所需的過程。產品實現的策劃應與品質管理系統其他過程的要求相一致（見4.1）。
在對產品實現進行策劃時，組織應確定以下方面的適當內容：
a) 產品的品質目標和要求；
b) 針對產品建立明確的過程和文件及提供資源的需求；
c) 產品所要求的驗證、確認、監視、量測、檢驗和測試活動，以及產品接收準則；
d) 為實現過程及其產品滿足要求提供證據所需的記錄（見4.2.4）。
策劃的輸出形式應適合於組織的運作方式。
註1：對應用於特定產品、專案或合同的品質管理系統的過程（包括產品實現過程）和資源作出規定的文件可稱之為品質計畫。
註2：組織也可將7.3的要求應用於產品實現過程的開發。
7.1.C.1 生命週期模式
組織必須建立並維護一整套覆蓋其產品生命週期的方法。適當時，這套方法必須包含產品的概念、定義、開發、導入、生產、運行、維護及處置中的過程、活動及任務、客戶的文件及培訓，跨越（spanning）產品的生命。[9]

7.1.C.1-註 1：一個生命週期模型可以包括考量和被評估對選擇標準的替代解決方案的發展。【新增】

7.1.C.1-註2：生命週期模型應該考量持續性的做法，例如能源和資源消耗的減少、生態上－有責任的處理和適當的壽期結束處置。【新增】

7.1.C.1-註3：新產品介紹計畫應該包括以下各種計畫的條款：品質和可靠性預測研究、樣件生產、要求和產量研究、銷售和服務人員培訓、顧客文件及培訓及新產品引入後的評價。
7.1.C.2 災害恢復
組織必須建立並維護災害回復和安全恢復(見6.3.C.1)的文件化計畫，以確保組織在產品整個生命週期內重建和修復產品的能力。災害回復計畫應該包括在一個最小量、危機管理、商務連續性和資訊技術。災害回復及安全恢復計畫應該和適當的管理階層定期評估其有效性和審查。[9]

7.1.C.2-註：重建能力的種類應包括一連串相關危害恢復的行動敍述。例如含：通知誰、在什麼狀況下通知，誰有權執行、與誰將協調計畫中步驟。

7.1.C.3 產品生命終止規劃
組織必須為因製造和/或支援的中斷，建立並維持文件化的程序。形成文件的程序應該包括：
a) 在某一段時間之後全部或部分停止支援；
b) 將產品文件及軟體存檔；
c) 對未來任何遺留的支持方面的事項的責任；
d) 如適用的話，向新產品的轉換；
e) 資料檔案複製件的可獲得性；和
f) 組織的零件和組件的安排。 [9]

7.1.C.4工具管理
組織必須確保在產品生命週期中，內部開發的軟體與／或使用的工具，附合適當品質方法。

7.1.C.4-註 :所要考慮的工具包括：設計及開發、測試、型態管理、文件、手稿、客製化、消滅、標記、夾具和診斷的工具，及用於製造與測試產品的軟體。

7.1.HS.1技術狀態管理(型態管理)計畫
組織必須建立並維護技術狀態管理計畫，它應該包括：
a) 技術狀態管理活動的標識和範圍；
b) 完成這些活動的進度；
c) 技術狀態管理工具；
d) 技術狀態管理方法和形成文件的程序；
e) 委派給他們的組織和職責；
f) 每一個技術狀態專案需要的管制水準；
g) 將各個專案置於技術狀態管理下的起始點。[9]

7.1.HS.1-註 1：技術狀態管理計畫不需要包含在單一文件內。

7.1.V.1 服務提供計畫
負責提供或執行服務的組織必須符合7.3.1.C.1和7.3.1.C.4專案計畫和風險管理要求。

7.2 與顧客有關的過程
7.2.1 與產品有關的要求的確定
組織應確定：
a) 顧客規定的要求，包括對交付及交付後活動的要求；
b) 顧客雖然沒有明示，但規定的用途或已知的預期用途所必需的要求；
c) 產品適用的法律法規要求；
d) 組織考量為必要的任何附加要求。
註：「交付後活動」包括，例如保固及合約責任內提供之活動，如維修服務和附加服務如回收或最終處理等。

7.2.2 與產品有關的要求的審查
組織應審查與產品有關的要求。審查應在組織向顧客作出提供產品的承諾之前進行（如：提交標書、接受合同或訂單及接受合同或訂單的更改），並應確保：
a)產品要求得到規定；
b)與以前表述不一致的合同或訂單的要求已予解決；
c)組織有能力滿足規定的要求。
審查結果及審查所引起的措施的記錄應予維護（見4.2.4）。
若顧客提供的要求沒有形成文件，組織在接受顧客要求前應對顧客要求進行確認。
若產品要求發生變更，組織應確保相關文件得到修改，並確保相關人員知道已變更的要求。
註：在某些情況下，如網上銷售，對每一個訂單進行正式的審查可能是不實際的。而代之對有關的產品資訊，如產品目錄、產品廣告內容等進行審查。

7.2.2.C.1結案追蹤
全部自需求審查產生的行動結果，必須追蹤至結束。

7.2.2.C.2：合約審查
組織必須建立並維持一合約審查流程，其內容應含：
a) 產品驗收準則及審查過程準則；
b) 在產品驗收後處理發現的問題的方法，包括客顧抱怨；
c) 在保固期或合約產品維護期中，對不合格的消除並/或矯正的計畫；
d) 辨識的風險及可能的應變；
e) 適當的智慧財產的保護；
f) 關於外包組織的責任定義；
g) 顧客進行的活動，包括顧客在需求、規格及驗收的角色；
h) 顧客提供的設施、工具及軟體項目；和
i) 全部參考標準及程序[8]

7.2.2.C.2-註：適當時，產品驗收計畫應該包括：(原為7.2.2.C-註修訂)
a) 測試程序文件；
b) 測試環境
c) 測試情況；
d) 測試資料；
e) 測試職責
f) 所用資源；和
g) 要求的驗收測試報告。[9]

7.2.3 顧客溝通
組織應對以下有關方面確定並實施與顧客溝通的有效安排：
a) 產品資訊；
b) 間詢、合同或訂單的處理，包括對其修改；
c) 顧客回饋，包括顧客抱怨。

7.2.3.C.1 問題通知
組織必須建立和維護形成文件的程序，在一項重要問題報告出現時，通知所有可能會受到影響的顧客。[5]

7.2.3.C.2 問題嚴重度分類
除非產品有排除問題等級；組織必須在對顧客的影響的基礎上確定顧客所回報問題的嚴重程度，這要依照本手冊術語表中的對關鍵、嚴重和一般問題報告的定義。應根據這種嚴重程度來確定組織做出反應的及時程度。[10]

7.2.3.C.2-註 1：顧客和組織應該共同確定解決顧客報告問題的優先順序。

7.2.3.C.3 問題的升級（escalation）
組織必須建立和維護形成文件的升級程序以解決顧客彙報的問題。[10]

7.2.3.C.4 問題報告回饋(原為顧客回饋)
組織必須及時向顧客對其問題報告及時並有系統地提供回饋。

7.2.3.HS.1 產品替換(原為組織的回收程序)
組織必須建立並維護形成文件的程序以識別和替換不適合繼續服務的產品。

7.2.3.HS.2設計和開發過程品質測量資料報告
當顧客要求時，溝通必須包括一互相同意的設計和開發過程測量報告和評估。

7.3 設計和開發
7.3.1 設計和開發規劃
組織應對產品的設計和開發進行策劃和管制。
在進行設計和開發策劃時，組織應確定：
a) 設計和開發階段；
b) 適合於每個設計和開發階段的審查、驗證和確認活動；
c) 設計和開發的職責和許可權。
組織應對參與設計和開發的不同小組之間的介面進行管理，以確保有效的溝通，並明確職責分工。
隨設計和開發的進展，在適當時，規劃的輸出應予更新。
註：設計和開發審查、查證及確認各有明確之目的。它們可被分別處理和紀錄，或是以任何方式組合；總之以適合於產品及組織為準。

7.3.1.C.1 專案計畫
組織必須建立並維護一個以規定的產品生命週期模式(7.1.C.1)為基礎的項目計畫活動。該計畫應該包括：
a) 專案的組織結構；
b) 專案團隊的角色、責任及職責；
c) 相關團隊在組織內及外的角色、責任及職責，他們與專案團隊的介面；
d) 安排進度、跟蹤、解決問題及提出管理報告的方法；
e) 與專案活動有關聯的預算報告、人員配備和進度安排；
f) 辨識使用的方法、標準、文件及程序、工具(若這些已在產品生命週期模式中定義，只需指引至生命週期模式則可)；
g) 涉及的有關計畫（例如，風險管理、開發、試驗、技術狀態管理和品質）；
h) 特定專案發展或服務提供的環境、與其物理資源的考慮(例如：開發的資源、使用者文件、測試、操作、需要的開發工具、電腦的保全環境、實驗室空間、工作站等)；
i) 在產品的生命週期中，顧客、用戶及供應商的參與（例如，聯合審查、非正式會議及批准）；
j) 專案品質的管理，包括適當的品質量測；
k) 設計對" x" 計劃於適當的產品生命週期，計劃範例包括但不侷限於製造能力、可靠度、管制的、服務能力、安全性、持續性和測試能力。
l)
m) 課程的學習從先前計畫後的分析；
n) 專案特性訓練需求；
o) 要求的認證(例如：產品證明或員工技術證明)；
p) 專利權、使用權、所有權、保證期及特許權；和
q) 專案後分析和改進活動，包括專案課程學習的根源分析，和被拿來預先排除在未來計畫重複的矯正措施。[9]

7.3.1.C.1-註 1：項目計畫和任何有關計畫可以是一個獨立的文件或另一個文件的一部分或幾個文件的組合。

7.3.1.C.1-註 2：對所有開發專案都通用的、規定任務和職責的通用作業指導書毋需重複作為專案計畫的一部分。

7.3.1.C.2 要求的可追溯性
組織必須建立並維護一種通過設計和試驗追溯文件化要求的方法。[10]

7.3.1.C.2-註 1：組織應該對專案計畫中識別的所有有關方，建立傳播產品要求和要求更改的溝通方法。

7.3.1.C.3 試驗規劃
試驗計畫必須形成文件。試驗計畫應該包括：
a) 試驗範圍（例如，單件、特徵、集成、系統、驗收、增加良率、移轉及老化）；
b) 需要完成的試驗類型（例如，壓力、功能試驗、邊界條件試驗、可用性試驗、性能試驗、回歸試驗、相互可操作性試驗）；
c) 對要求的可追溯性；
d) 試驗環境（例如，相關顧客環境、操作使用）；
e) 試驗覆蓋範圍（試驗驗證產品功能的程度，有時以新試驗功能的百分數表示）；
f) 預期結果；
g) 資料定義及資料庫要求；
h) 試驗設定，試驗案例（輸入、輸出、試驗準則）之可重複性及形成文件的試驗程序；
i) 外部試驗的使用；
j) 報告和解決缺陷的方法；
k) 顧客測試的要求；和
l) 預先定義退出準則。[10]
測試結果及後續行動必須加以記錄。 (見4.2.4)

7.3.1.C.4風險管理計劃【新增】
對會衝擊成本、時程、產品品質或產品績效的專案，組織必須對風險的鑑別、分析和管制，開發和文件化一份計劃。

7.3.1.C.4-註：風險管理可在產品開發的各階段被執行，且可包括：
a) 決定風險來源、種類和優先性；
b) 重要或關鍵特性和失敗模式的確認，包括消費者經驗；
c) 風險參數的定義(如：發生的可能性，衝擊的嚴重性)被使用於決定風險優先和任何被使用的得分機制(如FMEA-失效模式效應分析)；
d) 風險將如何被管理(如被使用的工具、減少風險的活動、緩和策略、監視和報告需求)；
e) 來自適當的功能紀律之輸入，和
f) 一個取得和運用課程學習的機制。【新增】

7.3.1.HS.1 轉換策劃
當計畫將一個系統，硬體或軟體產品，從一個舊環境轉換到一個新環境去時，組織必須制定一個轉換計畫並將之文件化。若舊環境不再被支持，使用者必須被通知有關轉換計畫與活動，這必須包括對新環境的生效日期與其他相關支援可提供之時程，若在舊環境失效時。轉換計畫應該包含：
a) 轉換的要求分析和定義；
b) 轉換工具的開發；
c) 產品和資料的轉換；
d) 轉換的執行；
e) 轉換的驗證；
f) 未來對舊環境的支持。[9]

7.3.1.HS.1 註1：操作環境由產品取決於的硬體、軟體或者系統組成，包括哪個客戶分別由組織或其他供應商購買及安裝。由舊環境改換至新的軟體操作環境，如OS、資料庫、介面的更新，硬體操作環境的更新如原有硬體裝在新架構或更新設備、無論硬體或軟體的轉換必對軟體或硬體元件或系統做成影響，所以應有轉換計畫涵蓋所有可能性。

7.3.1.HS.1 註2：若不再支援舊環境，應考慮已往資料的索取，或相關舊資料的保護、查核備全法規及合約需求。

7.3.1.HS.2設計和開發過程品質測量策劃及實施
在設計開發計畫階段，組織必須建立並維持一些方法以選擇及報告專案的適切設計開發過程的品質測量，建議在此階段，量測系統必須因應專案適切地執行。量測應涵蓋計劃時程的區域(生命週期階段轉換或里程碑監控)、測試執行，和測試階段缺失的監控。

7.3.1.HS.2-註：見文件”設計過程測量系統的安裝與操作”參考在http://tl9000.org/handbooks//links.html指引協助挑選及制訂專案適切的設計與開發過程測量。

7.3.1.C.5集成策劃【原為軟體類改為共通類】
組織必須開發一項計畫並將之文件化，用來將各硬體、軟體和/或服務元件集成到產品中去以確保它們按設計相互作用。這項計畫必須包含：
a) 方法和形成文件的程序；
b) 職責；
c) 集成的進度；和
d) 試驗要求。[9]

7.3.1.C.6 估算【原為軟體類改為共通類】
組織必須建立並維護一個在相對於專案計畫貫通專案生命週期時用來估算和追蹤項目參數的方法。[10]

7.3.1.C.6-註：需要考慮的專案因數應該包括產品規模、複雜性、需求的改變、做出的努力、人員、進度、成本、品質、可靠性和生產力。來自最初的估計到實際估算過程的資料應該被分析比較。

7.3.1.S.1電腦資源【原為S.3】
組織必須建立並維護用於為目標電腦估計和追蹤關鍵性的電腦資源的方法，軟體將運用於此電腦上。 [10]

7.3.1.S.1-註: 這些固化軟體資源例如存貯器的利用、吞吐量、即時性能及I/O通道。

7.3.1.S.2回歸試驗策劃【原為S.4】
若需執行回歸試驗，試驗計畫必須指明哪些試驗是回歸與哪些特徵(特性)和功能涵蓋在這些回歸試驗內。

7.3.2 設計和開發輸入
應確定與產品要求有關的輸入，並維護記錄（見4.2.4）。這些輸入應包括：
a) 功能和性能要求；
b )適用的法律、法規要求；
c) 適用時，以前類似設計提供的資訊；
d) 設計和開發所必需的其他要求。
應對這些輸入進行審查，以確保輸入是充分與適宜的。要求應完整、清楚，並且不能自相矛盾。

7.3.2.C.1 顧客和供應商輸入
組織必須建立並維護一些方法以在開發新的或經修訂的產品要求過程中徵求並利用顧客及供應商的輸入。[4]

7.3.2.C.1-註：組織也應該考慮從競爭分析的結果，連同顧客和供應商輸入。【新增】

7.3.2.C.2 設計和開發要求
設計和開發要求必須加以規定並形成文件，並應該包括
a) 品質和可靠性要求；
b) 產品的功能和能力；
c) 業務的、組織的及用戶的要求；
d) 安全的、環境的、持續性及保安的要求；
e) 可製造性、可安裝性、使用性、互通性及維修性的要求；
f) 設計約束條件；
g) 試驗要求；
h) 為目標電腦需要的電腦資源；和
i) 先前專案的課程學習。[9]

7.3.2.C.2-註：設計和開發需求應該被定義和專注於避免錯誤。【新增】

7.3.2.C.3要求的分配
組織必須將產品要求分配至產品結構中的情況形成文件。[9]

7.3.2.C.3-註：需求的例如：軟體的回應時間，硬體的散熱，服務的回應時間。

7.3.2.H.1要求的內容
設計要求必須包括。但不限於：
a) 標稱值（Nominal values）及公差；
b) 維修性需求；
c) 最終產品包裝要求。[5]

7.3.2.S.1軟體要求的識別
組織必須確定，分析系統的軟體單元（component）的要求並形成文件。[9]

7.3.3 設計和開發輸出
設計和開發的輸出應以能夠針對設計和開發的輸入進行適當驗證的方式提出，並應在放行前得到批准。
設計和開發輸出應：
a) 滿足設計和開發輸入的要求；
b) 給出採購、生產和服務提供的適當資訊；
c) 包含或引用產品接收準則；
d) 規定對產品的安全和正常使用所必需的產品特性。
註：生產與服務供應的資訊可包括產品保存的詳細說明。
7.3.3.HS.1設計和開發輸出
軟體設計和開發輸出應該包括，但不限於：
a) 系統結構；
b) 系統詳細設計；
c) 源代碼；
d) 用戶文件。[8]

7.3.3.V.1 服務設計和開發輸出
來自服務設計和開發要求的輸出必須包括對擬提供的服務的完整和精確的說明。設計和開發輸出必須包括但不限於：
a)服務提供程序；
a) 資源和技能要求；
b) 對供應商的依賴；
c) 需接受顧客評價的服務特性；
d) 每一項服務特性的接受標準。[12]

7.3.4 設計和開發審查
在適宜的階段，應依據所策劃的安排（見7.3.1）對設計和開發進行系統的審查，以便：
a) 評價設計和開發的結果滿足要求的能力；
b) 識別任何問題井提出必要的措施。
審查的參加者應包括與所審查的設計和開發階段有關的職能的代表。審查結果及任何必要措施的記錄應予維護（見4.2.4）。

7.3.5 設計和開發驗證
為確保設計和開發輸出滿足輸入的要求，應依據所策劃的安排（見7.3.1）對設計和開發進行驗證。驗證結果及任何必要措施的記錄應予維護（見4.2.4）。

7.3.5.C.1 文件驗證
組織必須在產品交付前驗證提供顧客及/或用戶的文件。

7.3.5.HS.1 壓力（極限）測試
組織必須在壓力（極限）條件下測試產品，包括但不局限於，超出界限範圍及無效輸入條件，大量及最大負荷之模擬、及操作錯誤。

7.3.5.HS.2 異常狀況
組織必須適切的在異常狀況下測試產品，包括：
a)硬體錯誤；
b)軟體錯誤；
c)操作、行政、維護及外務(OAM&P)錯誤；
d)超載；
e)無效使用者之輸入；
f)失效後系統的復原。

7.3.5.S.1 系統試驗
每套軟體發行必須按照一文件化系統試驗計畫進行系統試驗。[14]

7.3.6 設計和開發確認
為確保產品能夠滿足規定的使用要求或已知的預期用途的要求，應依據所策劃的安排（見7.3.1）對設計和開發進行確認。只要可行，確認應在產品交付或實施之前完成。確認結果及任何必要措施的記錄應予維護（見4.2.4）。

7.3.6.C-註1：在不同確認階段，組織應該適當讓顧客或第三方參與。

7.3.6.S.1 版本管理
組織必須建立並維護方法以管制軟體產品和文件的發佈和交付；這些相關文件在管制條件下進行，方法應該包括提供給顧客：
a) 在版本發佈之前，充分的版本策劃資訊；
b) 產品介紹和版本發佈進度表；
c) 所交付產品特點的詳細說明，體現在新軟體產品或版本中的任何更改；
d) 將目前的相關建議或依合約已策劃好的更改。(7.3.7.C.2)[10]

7.3.7 設計和開發更改的管制
應識別設計和開發的更改，並維護記錄。適當時，應對設計和開發的更改進行審查、驗證和確認，並在實施前得到批准。設計和開發更改的審查應包括評價更改對產品組成部分和已交付產品的影響。
更改的審查結果及任何必要措施的記錄應予維護（見4.2.4）。

7.3.7.C.1 變更之管理過程
組織必須建立並維護一個過程以確保在產品生命週期中對隨時可能發生的要求和設計的更改以一種系統化的、及時的方式管理和跟蹤，而不會對品質、可靠性以及設計意圖產生負面影響。組織應確認任何會造成與客戶議定的品質、可靠度、功能條件影響的變更在核准前得到客戶的審查。
更改的管理應該包括：
a) 影響分析；
b) 策劃；
c) 實施；
d) 試驗；
e) 文件化；
f) 溝通；
g) 審查及批准。[5]

7.3.7.C.1 註：在生命週期中當需要一更改管理過程時，過程中的管理可依生命週期階段而定，例如：在設計階段，組織應可快速回應客戶的更改需求，及爭取先進科技以更改管理過程響應，在產品出售後之更改管理過程範圍應考慮操作和維護的更改相對對已安裝的客戶及股權者的影響，考慮應包括品質，可靠性及緊急功能。
7.3.7.C.2 通知顧客
組織必須建立並維護一套形成文件的程序以確保當設計更改影響到合同中的承諾時顧客會得到通知。[5]

7.3.7.C.3 問題的解決的技術狀態管理
組織必須在問題的解決和技術狀態管理之間建立一個介面，以確保問題的解決體現在未來的修訂版中。[10]

7.3.7.H.1 元件更改
組織必須具備形成文件的程序以確保材料或元件的替換或更改不會對產品需求的符合性或性能帶來不利的影響。這些形成文件的程序應該包括：
a) 功能性試驗；
b) 合格試驗；
c) 應力試驗；
d) 批准的零件清單；
e) 關鍵零件清單。

7.4 採購
7.4.1 採購過程
組織應確保採購的產品符合規定的採購要求。對供應商及採購的產品管制的類型和程度應取決於採購的產品對隨後的產品實現或最終產品的影響。
組織應根據供應商按組織的要求提供產品的能力評價和選擇供應商。應制定選擇、評價和重新評價的準則。評價結果及評價所引起的任何必要措施的記錄應予維護（見4.2.4）。

7.4.1.C.1 採購程序
組織必須建立並維護一文件化的採購程序以確保：
a) 產品要求已清楚定義；
b) 風險已明白和管理；
c) 合格準則已建立；
d) 接受標準已建立；
e) 合同已確定；
f) 專有權、使用權、所有權、保證書及特許權需滿足；
g) 策劃好對產品未來的支援；
h) 進行中的供應基地的管理和監控已建立；和
i) 供應商的選擇準則已確定。[9]

7.4.1.C.1-註 1：形成文件的程序應該適用於現貨市場產品。典型的，這包括製造中應用的原設備製造廠（OEM）產品和用於軟系統的現貨市場（COTS）產品。

7.4.1.C.2供應商績效管理【新增】
組織必須規劃和實施供應商管理和開發活動，以便
a) 供應商有資格確定的標準；
b) 在供應商選擇活動期間評估結果被考慮；
c) 使用建立的準則對供應商定期再評估；
d) 追蹤供應商品質績效，且回饋提供以驅使供應商持續改善；
e) 鑑別關鍵的供應商，對於供應商的產品應調整朝向符合TL 9000 需求和測量或其他的適當品質管理系統，優先選擇朝向 TL 9000。

7.4.1.C.2註1：供應商績效管理計劃和活動應該連同8.5節組織持續改進過程。【新增】

7.4.1.C.2註2：一個組織要對所有的供應商提供相同水準的互動是不可