建立可測試核實的需求

如何去寫需求的心得，GAMP5中概述起來說有三個關鍵詞：

定義完整---Fully Defined

可被核實---Verifiable

目標明確---Objective

01、用戶需求不是拍腦袋定義出來的

應該是基于以下的幾點考慮：

1）對產品工藝知識、業務流程、對產品質量屬性的理解，任何自動化的系統都是為了支持工藝或者業務流程的。

從產品的角度上來講，產品有哪些關鍵的質量屬性，這些關鍵的質量屬性會受到哪些關鍵工藝參數的影響，對這些工藝參數要求控制的范圍是什么，都是對自動化系統設計的輸入；從業務流程的角度去講，GAMP5用了一個很好的詞，challenge against，這不是指人員之間的互掐，而是指對每一條需求的表述都要精心推敲，看和業務流程的要求是否匹配；

2）明確職責：

在起草需求的過程中，各方面的職責是不同的，概述起來說，終端的用戶部門負責人或者技術部門應該側重于工藝知識的理解，并將工藝知識的理解轉化成需求；供應商對于客戶所提出的需求應該進行初步的把關，看自己的設備能否從技術上滿足用戶需求，或者結合自己產品的特點，給用戶提一些改進的建議，而不能單純為了賣出產品而進行忽悠；質量部門應該把握企業有哪些內部要求和外部法規要求，重點看驗證的過程是否合規，而不是把質量部門變成所有領域的專家；

3）推敲每一條需求，做到需求的完整和準確，技術上可行，邏輯上合理，易于理解。

02、采用基于風險的決策法

基于風險的方法是GAMP5所一直強調的，盡管GAMP5中這段表述其實并不完全符合質量風險管理的理念：

基于風險：對于驗證文件可以有不同的審核輪次及深度的要求，可以決定是否需要進行源代碼審核，可以觸發供應商評估的活動，可以決定測試內容的深度，可以決定系統變更如何有效管理，對備份和恢復流程如何界定，可以決定在授予系統權限前需要哪些必要的培訓，對于周期性回顧的要求也基于風險有所不同。

基于風險的主要目的不是說定義哪些事情不做，而是應該側重在哪些事情應該花更多的時間和精力，更有效的去做。

03、用供應商的輸入

對于在哪些情況下可以采用供應商的文件，GAMP5給出了幾點建議，需要對供應商進行如下的評估，包括對供應商的質量體系，技術能力以及供應商的一些項目的經驗和能力評估。

GAMP5提出的一種觀點其實還是比較新穎的，對于供應商的文件，企業的質量體系應該有一定的包容度，不要去過多糾結文件的格式而要關注內容本身。

04、引用企業現有的驗證文件做參考

GAMP5中反復強調提可以盡可能多的采用供應商的驗證文件支持驗證活動，在如何讓驗證活動更有效這一章節，提出了企業本身的驗證文件也可以供參考的說法，比如對于一個與老的系統類似的系統，可以借鑒之前的風險評估文件，用戶需求標準文件，驗證計劃或測試計劃，測試標準以及設計審核等，常見的例子包括實驗室的設備，第二臺同類的生產設備以及包裝設備。

同時，對于一臺新的設備而言，我們一直說風險評估應該基于已有的工藝知識，對已有的對工藝的理解也應在驗證的過程中參考。

05、更加有效的測試

測試往往是驗證生命周期中主要的活動之一，同時也比較耗時，所以GAMP5有如下的幾點建議：

1）重新考慮合理使用之前的測試結果

FAT并不是法規要求的活動，但在供應商處進行的FAT過程中的一些測試，可以被確認活動所引用，前提是企業能夠提前的將相關的要求溝通到供應商，同時有些非GMP法規要求的測試活動，比如安全相關的測試，財務相關的要求，如果法規要求的測試和這些測試重復，也可以考慮使用而不是單純的重復。

2）測試的內容應該綜合考慮

有很多不同的測試類型，比如Normal Case，Invalid Case，重復性測試，性能測試，負載測試，回歸測試，結構測試等，這些不同的測試類型在后面會有詳細的解讀，用戶需求對于企業而言，更多的是通過正確的安裝以及系統接收測試實現的，其他的不同層次的測試要求應該取決于不同的風險，如果這些測試已經執行過，并且經過了企業相關的SME的審核，對于關鍵的與病人安全，產品質量以及數據完整性相關的項目，也經過了質量部門的批準，那么在測試的過程中也可以被引用。

3） 盡可能少采用紙質的測試證據

企業應該對相關的測試證明保存的方式進行明確的定義，很多企業要求提供驗證過程中的截圖，并且這些截圖是以打印的形式存在做為證據，但實際上GAMP5的建議是僅在關鍵的步驟采用截圖做為證明，同時如果系統有很好的審計追蹤功能，以電子的形式記錄下相關的系統操作，那么對于SME而言，審核這些電子的審計追蹤也可以取代部分截圖的操作。

4） 是否所有的測試都需要第二人復核

這其實是一個很值得考慮的問題，如果任何事情都需要兩個人去做，那么無論是對企業而言，還是對系統的供應商而言都意味著成本的增加，是否需要第二人在測試時進行復核需要考慮的一個重要的因素在于測試者本身的能力，如果測試者本身有豐富的經驗，那么就不一定在測試的過程中需要安排第二個人如影隨形，但是如果在設備的操作過程中，需要一個人在控制間中控制設備，一個人在設備前進行操作，那么這種情況下第二人的參與又必不可少，同時對于測試結果的審核，可以采取離線的SME的審核流程或者更多的借助系統中的審計追蹤審核的過程，而不是在測試的過程中安排兩個人同時進行測試。

06、管理好系統移交的活動

系統的移交應該有預先定義的標準，尤其應該明確運維階段的職責，同時對項目階段的問題及偏離應該有必要的追溯，在系統移交的時候還應該考慮到系統移交對于業務的影響，以及是否有可能退回到之前的版本的系統，關于系統的文件、培訓、以及不同部門之間的溝通，變更的影響也都應該在移交的時候進行前瞻性的考慮。

07、有效的管理變更

1）需要有書面的關于變更的描述以及變更帶來的好處；

2）需要對現有的資源進行確認；

3）需要分析變更的影響，包括基礎架構，人員培訓，以及文件；

4）需要結合項目初始階段的風險評估，識別出新的風險點，包括必要的回歸測試；

5）從財務，合規以及技術的角度對變更進行評估；

6）對于變更的決策進行溝通及記錄；

7）執行并確認變更，將變更相關的內容追溯到相應的測試；

8）及時關閉變更

常見的變更過程中容易犯的錯誤包括：

1）變更管理與變更的復雜程度不匹配，比如小的系統變更以及常規的基礎架構變更管理過重；

2）變更管理過程中的步驟執行管理不恰當或者順序不合適；

3）對于可避免的變更沒能防止；

4）沒有及時將標準保持更新；

5）沒有綜合采用現有的文件，包括風險分析，追溯矩陣等；

6）變更關閉時必要的跟蹤項跟蹤不力；

7）IT變更與業務變更采用獨立的變更體系導致變更中部分活動重復；

8）對于相似替換的變更原則不恰當的應用；

9）對于供應商進行的變更沒有很好的管理，導致驗證生命周期文件和配置管理記錄沒有及時更新；

10）緊急變更管理不當；

08、有效的預測數據歸檔及遷移的需求

1） 對于相同數據架構的數據，如果要求有不同的保留時間，很難對數據有不同的保留時間，這就要求在設計數據結構的時候就要考慮數據的保留；

2）數據的格式如果采用自定義的格式則在進行數據遷移的時候會造成不必要的麻煩；

3）靜態數據與動態數據的混合