建立可測試核實(shí)的需求
如何去寫(xiě)需求的心得，GAMP5中概述起來(lái)說(shuō)有三個(gè)關(guān)鍵詞：
定義完整---Fully Defined
可被核實(shí)---Verifiable
目標明確---Objective
01、用戶(hù)需求不是拍腦袋定義出來(lái)的
應該是基于以下的幾點(diǎn)考慮：
1）對產(chǎn)品工藝知識、業(yè)務(wù)流程、對產(chǎn)品質(zhì)量屬性的理解，任何自動(dòng)化的系統都是為了支持工藝或者業(yè)務(wù)流程的。
從產(chǎn)品的角度上來(lái)講，產(chǎn)品有哪些關(guān)鍵的質(zhì)量屬性，這些關(guān)鍵的質(zhì)量屬性會(huì )受到哪些關(guān)鍵工藝參數的影響，對這些工藝參數要求控制的范圍是什么，都是對自動(dòng)化系統設計的輸入；從業(yè)務(wù)流程的角度去講，GAMP5用了一個(gè)很好的詞，challenge against，這不是指人員之間的互掐，而是指對每一條需求的表述都要精心推敲，看和業(yè)務(wù)流程的要求是否匹配；
2）明確職責：
在起草需求的過(guò)程中，各方面的職責是不同的，概述起來(lái)說(shuō)，終端的用戶(hù)部門(mén)負責人或者技術(shù)部門(mén)應該側重于工藝知識的理解，并將工藝知識的理解轉化成需求；供應商對于客戶(hù)所提出的需求應該進(jìn)行初步的把關(guān)，看自己的設備能否從技術(shù)上滿(mǎn)足用戶(hù)需求，或者結合自己產(chǎn)品的特點(diǎn)，給用戶(hù)提一些改進(jìn)的建議，而不能單純?yōu)榱速u(mài)出產(chǎn)品而進(jìn)行忽悠；質(zhì)量部門(mén)應該把握企業(yè)有哪些內部要求和外部法規要求，重點(diǎn)看驗證的過(guò)程是否合規，而不是把質(zhì)量部門(mén)變成所有領(lǐng)域的專(zhuān)家；
3）推敲每一條需求，做到需求的完整和準確，技術(shù)上可行，邏輯上合理，易于理解。
02、采用基于風(fēng)險的決策法
基于風(fēng)險的方法是GAMP5所一直強調的，盡管GAMP5中這段表述其實(shí)并不完全符合質(zhì)量風(fēng)險管理的理念：
基于風(fēng)險：對于驗證文件可以有不同的審核輪次及深度的要求，可以決定是否需要進(jìn)行源代碼審核，可以觸發(fā)供應商評估的活動(dòng)，可以決定測試內容的深度，可以決定系統變更如何有效管理，對備份和恢復流程如何界定，可以決定在授予系統權限前需要哪些必要的培訓，對于周期性回顧的要求也基于風(fēng)險有所不同。
基于風(fēng)險的主要目的不是說(shuō)定義哪些事情不做，而是應該側重在哪些事情應該花更多的時(shí)間和精力，更有效的去做。
03、用供應商的輸入
對于在哪些情況下可以采用供應商的文件，GAMP5給出了幾點(diǎn)建議，需要對供應商進(jìn)行如下的評估，包括對供應商的質(zhì)量體系，技術(shù)能力以及供應商的一些項目的經(jīng)驗和能力評估。
GAMP5提出的一種觀(guān)點(diǎn)其實(shí)還是比較新穎的，對于供應商的文件，企業(yè)的質(zhì)量體系應該有一定的包容度，不要去過(guò)多糾結文件的格式而要關(guān)注內容本身。
04、引用企業(yè)現有的驗證文件做參考
GAMP5中反復強調提可以盡可能多的采用供應商的驗證文件支持驗證活動(dòng)，在如何讓驗證活動(dòng)更有效這一章節，提出了企業(yè)本身的驗證文件也可以供參考的說(shuō)法，比如對于一個(gè)與老的系統類(lèi)似的系統，可以借鑒之前的風(fēng)險評估文件，用戶(hù)需求標準文件，驗證計劃或測試計劃，測試標準以及設計審核等，常見(jiàn)的例子包括實(shí)驗室的設備，第二臺同類(lèi)的生產(chǎn)設備以及包裝設備。
同時(shí)，對于一臺新的設備而言，我們一直說(shuō)風(fēng)險評估應該基于已有的工藝知識，對已有的對工藝的理解也應在驗證的過(guò)程中參考。
05、更加有效的測試
測試往往是驗證生命周期中主要的活動(dòng)之一，同時(shí)也比較耗時(shí)，所以GAMP5有如下的幾點(diǎn)建議：
1）重新考慮合理使用之前的測試結果
FAT并不是法規要求的活動(dòng)，但在供應商處進(jìn)行的FAT過(guò)程中的一些測試，可以被確認活動(dòng)所引用，前提是企業(yè)能夠提前的將相關(guān)的要求溝通到供應商，同時(shí)有些非GMP法規要求的測試活動(dòng)，比如安全相關(guān)的測試，財務(wù)相關(guān)的要求，如果法規要求的測試和這些測試重復，也可以考慮使用而不是單純的重復。
2）測試的內容應該綜合考慮
有很多不同的測試類(lèi)型，比如Normal Case，Invalid Case，重復性測試，性能測試，負載測試，回歸測試，結構測試等，這些不同的測試類(lèi)型在后面會(huì )有詳細的解讀，用戶(hù)需求對于企業(yè)而言，更多的是通過(guò)正確的安裝以及系統接收測試實(shí)現的，其他的不同層次的測試要求應該取決于不同的風(fēng)險，如果這些測試已經(jīng)執行過(guò)，并且經(jīng)過(guò)了企業(yè)相關(guān)的SME的審核，對于關(guān)鍵的與病人安全，產(chǎn)品質(zhì)量以及數據完整性相關(guān)的項目，也經(jīng)過(guò)了質(zhì)量部門(mén)的批準，那么在測試的過(guò)程中也可以被引用。
3） 盡可能少采用紙質(zhì)的測試證據
企業(yè)應該對相關(guān)的測試證明保存的方式進(jìn)行明確的定義，很多企業(yè)要求提供驗證過(guò)程中的截圖，并且這些截圖是以打印的形式存在做為證據，但實(shí)際上GAMP5的建議是僅在關(guān)鍵的步驟采用截圖做為證明，同時(shí)如果系統有很好的審計追蹤功能，以電子的形式記錄下相關(guān)的系統操作，那么對于SME而言，審核這些電子的審計追蹤也可以取代部分截圖的操作。
4） 是否所有的測試都需要第二人復核
這其實(shí)是一個(gè)很值得考慮的問(wèn)題，如果任何事情都需要兩個(gè)人去做，那么無(wú)論是對企業(yè)而言，還是對系統的供應商而言都意味著(zhù)成本的增加，是否需要第二人在測試時(shí)進(jìn)行復核需要考慮的一個(gè)重要的因素在于測試者本身的能力，如果測試者本身有豐富的經(jīng)驗，那么就不一定在測試的過(guò)程中需要安排第二個(gè)人如影隨形，但是如果在設備的操作過(guò)程中，需要一個(gè)人在控制間中控制設備，一個(gè)人在設備前進(jìn)行操作，那么這種情況下第二人的參與又必不可少，同時(shí)對于測試結果的審核，可以采取離線(xiàn)的SME的審核流程或者更多的借助系統中的審計追蹤審核的過(guò)程，而不是在測試的過(guò)程中安排兩個(gè)人同時(shí)進(jìn)行測試。
06、管理好系統移交的活動(dòng)
系統的移交應該有預先定義的標準，尤其應該明確運維階段的職責，同時(shí)對項目階段的問(wèn)題及偏離應該有必要的追溯，在系統移交的時(shí)候還應該考慮到系統移交對于業(yè)務(wù)的影響，以及是否有可能退回到之前的版本的系統，關(guān)于系統的文件、培訓、以及不同部門(mén)之間的溝通，變更的影響也都應該在移交的時(shí)候進(jìn)行前瞻性的考慮。
07、有效的管理變更
1）需要有書(shū)面的關(guān)于變更的描述以及變更帶來(lái)的好處；
2）需要對現有的資源進(jìn)行確認；
3）需要分析變更的影響，包括基礎架構，人員培訓，以及文件；
4）需要結合項目初始階段的風(fēng)險評估，識別出新的風(fēng)險點(diǎn)，包括必要的回歸測試；
5）從財務(wù)，合規以及技術(shù)的角度對變更進(jìn)行評估；
6）對于變更的決策進(jìn)行溝通及記錄；
7）執行并確認變更，將變更相關(guān)的內容追溯到相應的測試；
8）及時(shí)關(guān)閉變更
常見(jiàn)的變更過(guò)程中容易犯的錯誤包括：
1）變更管理與變更的復雜程度不匹配，比如小的系統變更以及常規的基礎架構變更管理過(guò)重；
2）變更管理過(guò)程中的步驟執行管理不恰當或者順序不合適；
3）對于可避免的變更沒(méi)能防止；
4）沒(méi)有及時(shí)將標準保持更新；
5）沒(méi)有綜合采用現有的文件，包括風(fēng)險分析，追溯矩陣等；
6）變更關(guān)閉時(shí)必要的跟蹤項跟蹤不力；
7）IT變更與業(yè)務(wù)變更采用獨立的變更體系導致變更中部分活動(dòng)重復；
8）對于相似替換的變更原則不恰當的應用；
9）對于供應商進(jìn)行的變更沒(méi)有很好的管理，導致驗證生命周期文件和配置管理記錄沒(méi)有及時(shí)更新；
10）緊急變更管理不當；
08、有效的預測數據歸檔及遷移的需求
1） 對于相同數據架構的數據，如果要求有不同的保留時(shí)間，很難對數據有不同的保留時(shí)間，這就要求在設計數據結構的時(shí)候就要考慮數據的保留；
2）數據的格式如果采用自定義的格式則在進(jìn)行數據遷移的時(shí)候會(huì )造成不必要的麻煩；
3）靜態(tài)數據與動(dòng)態(tài)數據的混合
