模板
教程
環境
性能
功能
管理
在醫療設備軟件中應用需求管理
在過去10 年中，醫療設備軟件開發的技術發展水平經歷了巨大的變化。從過去 10-15 年間的醫療軟件規格說明書中，FDA 已經意識到，規格說明書還有待于大幅度地改進。實際上，FDA 發現，這期間大約 44% 導致廠家自愿召回產品的質量問題，歸因于特殊醫療設備的設計錯誤或設計不足，而不是因為制造階段的錯誤。而且，似乎可以通過充分的設計控制來避免這些錯誤。
為了能夠隨著全球市場的不斷演進來規范化美國的標準，并且為了改進醫療設備開發的規格說明書，1990 年美國通過了啟用立法，來賦予 FDA 必要的職權范圍以管理醫療設備軟件的開發。啟用立法包含在 1990 年安全醫療設備法（SMDA）中，是 FDA 大幅度修訂其對醫療設備涉用軟件開發設計監督不足的動力。
安全醫療設備法的通過，對以前的 GMP 規范起到了大幅度的修訂作用。新的 GMP 規范剛剛通過批準，并且對醫療設備軟件產生巨大影響。簡而言之，新的 GMP 規范（現在也稱作 Quality System Regulation（QSM））在 1997 年 6 月到 1998 年 6 月期間的過渡時期生效。在過渡期結束前，所有的第二類（Class II）和第三類（Class III）醫療設備及其軟件開發，必須與 QSM 中規定的開發過程標準保持一致。
QSM 對建立現代軟件開發實踐起到了優秀的指導作用，這是個好消息。實際上，這些規定的實踐是通過 QSM 中的規章，經過細致工作而作出的，以便與您所熟悉的標準相一致。QSM 是為了遵從 IEEE 軟件工程標準或 ISO 9001、IEC 601 或 EN 46001中的全球化標準而特別編制的。還有一個更好消息，QSM 中沒有絕對要求的標準。因此，您可以根據現有的標準來塑造自己的開發過程，并且能夠調整過程模型使其滿足您特有的開發需要。
自從 1984 年以來，FDA 為建立設計控制（包括安全和效率），并將其作為整體質量過程的一部分，做出了艱苦的努力?，F在，隨著 QSM 的實施，醫療設備軟件開發的質量保證工作向前邁進了一大步。在本文的下一部分中，我們將探討一下需求管理工具（如RequisiteProTM）如何幫助您高效地自動完成 QSM 規定的許多任務，這些任務是世界級醫療設備和產品開發過程的一部分。
下面第 1 部分概述了醫療設備軟件開發過程要求的結構和文檔編制。在第 2 部分中，我們將探討一個醫療設備開發計劃實例，并且考查一下 RequisitePro 工具所提供的功能，以及該工具所提供的對設備需求自動化和管理的支持。
第1部分 制定可以接受的開發計劃從1997年中開始，Quality System Regulation（QSR）規定，應該建立可廣泛使用的、良構型計劃，用于依賴于軟件而工作的醫療設備軟件開發。盡管 QSR 規定了要建立計劃，但并未規定這樣的計劃或過程（通過該過程開發軟件）的內容。為了能得到這方面的深入見解，有必要熟悉另一個 Office for Device Evaluation （ODE）組織公布的新的 FDA 指導文檔："用于醫療設備涉用軟件上市前提交內容的 ODE 指導方針"（草案）。該文檔是一個指導性文檔，不具備規章效力。但是，該文檔包含大量關于如何制定計劃的實用建議，我們將這個文檔稱作"ODE Guidance"文檔（OG）。
OG 的附錄 A 定義了許多軟件開發生命周期中截然不同的階段。附錄 A 定義了以下主要的生命周期域：
需求分析和規格說明書 結構分析和規格說明書 設計和開發 驗證 確認 配置管理與變更控制 獨立驗證與確認在本白皮書中，將討論每個域的要點，從而建立過程和每個階段所需文檔的概要。在本白皮書第 2 部分中，將使用 RequisitePro 工具箱來自動處理用于支持這些階段的需求管理活動，并為這些需求管理活動提供支持。
需求分析和規格說明書
OG 的 A. 2 部分指出了確定和分析終端用戶的產品功能性需求和性能需求的重要性。Rational軟件的需求管理團隊是這方面的業內領袖，并且他們已經公布了一些文章和教程，為收集和分析需求信息的至關重要性提供支持4。為了組織和管理這項工作，許多醫療設備項目，都通過定義和使用這三種不同類型的文檔，獲取良好的服務，來收集和管理需求：產品需求文檔（PRD）、軟件需求規格說明書（SRS），以及危害分析（HA）。這些文檔形成了實現文件結構的頂層，其最初出現的形式如圖 1 所示。
產品需求文檔 (PRD)
通過 PRD 收集、分析和定義用于設備的產品功能和用戶需要。盡管沒有可用于該文檔的普遍采用的標準，但 RequisitePro 為產品需求文檔提供了一個模板，可作為管理項目需求的起點。
PRD 的編輯工作可以從企業市場開發工作和臨床專家的協同工作開始。它為市場部門提供了一個模板，用來記錄高級用戶需要，并且建立設備的臨床要求。
它還應該作為組織要素，重點用于安全特性、與標準保持一致性、臨床要求，甚至用于后續的市場抵壓品。
軟件需求規格說明書 (SRS)
通常，需求的收集工作開始時是非常抽象的，結束時能夠獲得一整套高級產品特性。這些特性記錄在上面討論過的 PRD 中，并通過 PRD 進行管理。SRS 是針對 PRD 中指定的依靠軟件實現的行為而編寫的。在現代醫療設備中，軟件可以出現在用來使設備運轉的嵌入式微控制器中，也可以作為某設備與其他設備接口中的一部分，或者設備可以包含外部的、獨立的軟件，用于數據后處理。無論軟件有何種功能，所有的軟件需求都應該記錄在一個或多個 SRS 中。
軟件需求提供了一個關于軟件必須做什么工作的詳細規格說明書，而不是用來說明如何設計或實現軟件。編輯軟件需求文檔時，可以遵照 201 Principles of Software Development （201 項軟件開發原則）第 3 章列出的原則清單。
編寫 SRS 時需要考慮的要點包括：
需求應該是完整的、具有一致性，并且不會產生岐義。 每項需求都應該能夠追溯到 PRD 中一項或多項功能，并且一直對其進行跟蹤，到低層需求，測試用例，以及實現模塊。 應該為每項需求分配一個"標簽"，以便將其作為項目的區分單元，進行識別、跟蹤和管理。IEEE 為正確編寫 SRS 提供了一個優秀的討論集和模板集。參見 IEEE 830-1993，Recommended Practice for Software Requirement Specifications（軟件需求規格說明書的推薦實踐）獲取更多信息。RequisitePro 將 IEEE 的推薦納入到其文檔格式的基本模板中，從而允許快速完成該文檔，并進入編輯需求文檔的工作。
危害分析 (HA)
危害分析（HA）是設計過程中一個重要的早期文檔。FDA 強調 HA 是改進醫療設備質量的關鍵要素。實際上，OG 的整個 2.8 節都在討論關于風險管理和危害分析的問題。危害分析是：
"以用戶和病人的視角，對設備進行的詳細檢查。危害分析的目的在于，發現潛在缺陷，即引起危害的錯誤可能性，從而使制造商能夠在設備投入使用之前改正這些錯誤。"
正如上面所提到的，HA 要求設計人員考慮產品中可能出現的，也是正要構建產品的各類和各種錯誤。隨著對每項危害進行檢查，并將其記錄到 HA 文檔中，設計人員能夠記錄潛在危害，然后提出能夠減輕危害的設計策略和功能需求。
隨著 OA 草案和 CGMP 的誕生，為傳統的危害分析方法中增加了新的、更完善的風險分析方法。
OG 的附錄 B 部分建議了 20 項事項，要求處理 HA 問題時進行詳細閱讀。FDA 發現，醫療設備產品開發涉及這些事項時，會引發特定的風險，我們建議把這些事項納入到 HA 中。
在產品開發生命周期的后期階段中，HA 將作為實際的文檔，來記錄潛在危害和用于防止危害發生的風險緩解策略。在后面的系統驗證階段，將對該文檔進行訪問，從而確認所有預期危害都已經被考慮到，并得到解決。
構架性分析與規格說明書
OG 的附錄 A.3 是實現過程的開始。在此階段中，功能性需求和安全需求被分配到產品的硬件和軟件方面。通過對比研究，有可能確定最有效的實現方法。
產品開發生命周期這個階段產生的關鍵文檔是配置管理計劃（CMP）?？梢栽诂F行標準 IEEE 828-1990，Standard for Software Configuration Management Plans 和 IEEE 1042-1987，Guide to Software Configuration Management 中，找到關于 CMP 的概念、設計和使用方面的精彩論述。
因為 CMP 是一個項目級指導文檔，因此它獨立于實現文檔樹。最初項目級文檔樹如圖 2 所示：
設計與開發
OG 附錄 A.4 討論了軟件需求由 SRS 轉化成源碼的過程。為了標準化這個實現過程，OG 推薦采用格式指南、編碼標準等。在該活動中，還推薦了走查測試和基準測試。通常，圍繞某類實現單元來組織軟件，例如代碼模塊、子例程、對象類等。因此，明確地，或隱含地建立了另一個文檔集，即實現單元集。
隨著實現文檔的逐漸可用，應該將其加到圖 3 所示的實現文檔編制的結構中、
OG 推薦，在實現單元和規格說明與該實現過程的 HA 之間，開發人員應嚴格堅持審計跟蹤。在第 2 部分討論可跟蹤性時，我們將討論如何完成這項工作
驗證
OG 附錄 A.5 包含驗證活動。IEEE 這樣定義"驗證"：
"它是用來評價某一系統或某一組件的過程，來判斷給定階段的產品是否滿足該階段開始時施加的條件。"
換句話說，驗證活動在很大程度上是一種普通的測試活動，要求您驗證每個開發階段（例如軟件某項需求或多項需求的實現）是否符合先前階段定義的需求。為了尋找一種驗證方法，您需要一個計劃。
經過合理組織的項目應該包含 Verification and Validation Plan（VVP）。通常，在 IEEE 1012-1987，IEEE Standard for Software Verification and Validation 和 IEEE 1059-1993，IEEE Software Guide for Verification and Validation Plans 中，IEEE 提供了優秀的指導，用于建立一個 VVP。注意 VVP 是用來建立驗證測試和確認測試規則的項目級文檔。因此，該文檔可以作為一個項目級文檔而"占據一方"，在這點上，它與前面曾提到的 ConfigurationManagement Plan (CMP) 相似。項目文檔編制樹如圖 4 所示。
OG 推薦，在驗證活動和產品規格說明書與該實現過程的 HA 之間，開發人員應嚴格堅持審計跟蹤。在第 2 部分討論可跟蹤性時，我們會探討這個問題。
確認
同樣，OG 附錄 A.6 推薦了多種確認活動。IEEE 這樣定義"確認"：
"它是開發過程中間或結束時對某一系統或某一組件進行評價的過程，以確定它是否滿足規定的需求"
換句話說，您需要確認已經實現的組件實際上按照規格說明書進行工作。通常，用測試來完成這項任務。再一次強調，確認計劃是必需的。按照慣例，確認計劃是前面討論過的 V 和 V 計劃（VVP）的一部分，
確認活動與測試同步進行。但是，好的測試計劃是什么樣的呢？幸運的是，IEEE 回答了這個問題。IEEE 829-1983, IEEE Standard for Software Test Documentation 提供了廣泛的內容，包括如何建立測試方法、進行測試、報告測試結果，以及如何解決異常問題。
注意進行軟件測試時，應從兩個角度確定被測部件的正確性：1）被測部件是否滿足實現單元規格說明書，并且 2）被測部件是否滿足其控制需求。也就是說，不僅要通過測試來確認部件能夠正確運行，而且要確認被測部件滿足原始規格說明書。測試文檔是實現文檔中的一部分?？紤]到測試文檔，實現文檔樹應如圖 5 所示。
OG 推薦，在確認/測試活動和產品規格說明書與該實現過程的 HA 之間，開發人員應嚴格堅持進行審計跟蹤。通過需求可跟蹤性的機制來提供這項審計跟蹤。
配置管理和變更控制
OG 附錄 A.7 規定了關于變更管理的一些事項。注意在前面的步驟中，您已經對 Configuration Management Plan (CMP) 有了一定了解，現在，您要確信 CMP 是變更管理領域中一個全面的管理計劃。
變更是現代軟件開發項目的一項規范，為高效管理變更，您必須：
明確變更來自多方因素，并了解這些因素是什么。 創建一個明確的流程來評審和分析所有的變更要求。 建立系統基線，以識別發生的變更。非常幸運，前面部分論述的 CMP 中，已對這些問題進行了詳細闡述。在本文第 2 部分中，我們將闡述用于分析和管理變更帶來的影響的技術和機制。
對實現結果加以驗證和確認
OG 附錄 A.8 推薦，驗證和確認（V&V）活動應由局外方進行。通常，從事日常開發工作的人員容易形成"盲點"，可能會忽略某個醫療設備設計和開發中的潛在問題。因此，FDA 推薦由技術上合格人員進行項目獨立評審，原則上，這些評審與您自己進行的 V&V 活動沒有差異。事實上，使外部評審員熟悉現有 VVP，將會提高評審效率，但您可能更加期望在開發新領域時，這些評審員能夠加入 VVP 中，并對其進行修訂。
與前面的 V&V 活動案例一樣，您應該就如何堅持在 V&V 活動（和相關文檔）到高級規范和 HA 之間進行跟蹤作出計劃，在第二部分中討論可跟蹤性時，將對這個問題進行討論。
關注級別
關注級別與上述生命周期部分無關。關注級別（LOC）是 OG 的一項特殊關注事項。簡單的說，LOC 參與識別設備錯誤的重要性和這些錯誤與病人安全之間的關系。也就是說，如果設備產生了錯誤，該錯誤會對病人造成嚴重傷害嗎？會對病人造成較小傷害嗎？或目前將對病人造成最小傷害嗎？LOC 是一項復雜問題，OG 草案尚未完全決定是否采用它，事實上，LOC 引發了一系列建議的草擬方法，FDA 也許會在最終發布 OG 時采用這些方法。
傳統的 LOC 方法傾向于將所有關于設備方面的內容集合到一個單個的 LOC 評估文檔中。在傳統方法中，設備最為安全攸關的功能，受到關注并用于建立一個 LOC 評估文檔。采用收集方法的劣勢在于，設備中一個單一的高安全級別方面促使生成一個高級別 LOC，進而，促使整個設備和所有組件，都作為高級別 LOC 來對待。事實上，這樣的設備通常有許多不是高級別 LOC 的功能，這些功能可以在更加寬松的 LOC 基礎上進行開發。
為避免產品低級別 LOC 部分開發中的資源浪費，在處理具有不同級別 LOC 的需求問題時，我們將更強調選擇性。以這種方式，可以按照與不同部分 LOC 一致的方式，區別地管理項目的不同部分。
為了有效地劃分項目，在 PRD 級采用逐項功能分析法，在 SRS 級（和HRS級）采用逐項需求分析法，來評估和分配 LOC。在第 2 部分中您會發現，RequisitePro 提供了功能和需求屬性，用來處理和管理項目的不同 LOC。
第 2 部分 作為開發計劃的一部分，實現軟件需求管理項目
為證明 RequisitePro 需求管理工具能夠提供管理功能，我們將考查一個簡略的醫療產品開發項目中的軟件開發過程。本例中設備是一個假想設備，稱為 Reverse Angioplasty Pump(RAP)。
創建一個產品需求文檔 (PRD)
為正確定義產品臨床功能和市場功能，用 RequisitePro 工具來創建一個產品需求文檔（PRD）。RequisitePro 為該文檔提供了一個模板，可以修改該模板以滿足特定的設備需要。RequisitePro 與 Word 無縫結合，使您可以創建最初的 PRD。另外，該工具允許文檔編輯人員在該文檔內部標識特定產品需求（PR）。圖 6 顯示了從 PRD 中節選的一小部分。
注
意 RequisitePro 工具允許通過雙下劃線或以用戶定義的樣式，來自動強調某些需求。強調方式是我們推薦的一種有力的可視輔助形式，用來幫助閱讀者快速定位特定行為問題、性能問題和安全問題等。
圖 6 既標識了硬件功能也標識了軟件功能，但為了簡化本文，我們將所有的功能都當作產生軟件需求的因素。這種做法不會忽略普遍性，但在實際的項目中，可以對硬件功能和軟件功能（在文檔中記錄這些功能）加以區分，從而創建更精確的需求文檔。
在標識產品需求時，RequisitePro 為每項產品需求分配唯一標識符（PR4, PR5等）；從而遵照第 1 部分中提到的 FDA 指南。
RequisitePro 還應該用來分配和維護屬性集和 PRD 中每項 PR 值。
現在，我們將使用 Attribute 功能，在逐項功能分析法基礎上，對關注級別（LOC）進行歸類。隨著每項功能被定義，可以插入屬性值，即我們為 PR 定義的 Concern 屬性?？梢杂?RequisitePro 定義屬性并定義可選值清單。然后，隨著功能被定義，您可以評估 LOC，并用 Concern 屬性來記錄評估結果。RequisitePro 提供了易于使用的選擇和排序功能，使您過后可以只選擇具有精選的 LOC 的那些功能，或選擇團隊感興趣的其他屬性和屬性值組合。
在項目的任意位置，都可以用 RequisitePro 來打印文檔，或顯示數據視圖，從而提供所有定義的 PR 的當前清單?？梢愿鶕煌瑢傩?，以特有角度，對該視圖進行過濾或排序。表 1 顯示了一個這類視圖的一個樣例。
創建軟件需求規格說明書 (SRS)
同樣，可以依據模板，用 RequisitePro 為產品創建、編輯、和維護軟件需求規格說明書（SRS）。圖 7 顯示了該文檔的一小段摘錄。
在 PRD 例中，我們已經強調過軟件需求（SR）。如前，標識軟件需求時，RequisitePro 為每項需求分配唯一標識符（SR1、 SR2等），從而遵照第 1 部分中提到的 FDA 指南。
RequisitePro 還應用于分配和維護屬性集和 SRS 中每項需求屬性值。注意可以為每類需求獨立地分配屬性和屬性值。注意我們已經通過與 PRD 中所用的相同屬性概念實現了關注級別問題，但我們還定義了與 PRD 不同的屬性。表 2 顯示了一個 SR 視圖樣例和它們的一些屬性。
與 PRD 例一樣，可以用 RequisitePro 的查詢引擎，對具有指定的屬性值集合的 SR 進行排序、摘錄和管理。
創建危害分析
同樣，可以用 RequisitePro 來為產品創建、編輯和維護危害分析（HA）。使用 RequisitePro 時，應創建一個 Word 文檔，來詳細記錄軟件（也可能是硬件）安全需求。
PRD、HA 和 SRS 一般完成后（不必等到批準"最終"版本），應開始建立這些文檔之間的關系。目的是了解某一文檔中的元素與另一文檔中的元素是何種關系，如圖 8 所示。
每個文檔中
的單個元素，應與另一文檔中的適當元素鏈接。也就是說，SRS 中每個 SR 項要與 PRD 中控制它的 PR 項關聯起來。反之，將每個 PR 項和它控制的 SR 項進行匹配。注意這項匹配可以是一對多，多對一，或多對多。
同樣，HA 項也要進行對應的關系鏈接。RequisitePro 未要求嚴格的關系分級結構。因此，允許所有的垂直關系（如 PR-to-SR）和所有的平行關系（如 HA -to-SR）。非分級結構關系是大多數開發項目的常見部分，并且不暗含特殊特征。
無論是何種關系，將相關項鏈接起來都非常重要。該鏈接過程稱作可跟蹤性。
可跟蹤性
優質軟件實現過程中一個重要因素是，跟蹤能力要貫穿整個實現過程，包括規格說明階段、構架階段、設計階段、實現階段，以及 V&V 階段。實際上，跟蹤關系的能力，并將這些關系與變更管理問題關聯起來，成為貫穿新的 OG 的關鍵線程。另外，CGMP 的 Design Controls 部分，即 CGMP 的 Subpart C 再次重申在產品開發生命周期范圍內，在不同工作產品之間建立關系跟蹤能力的重要性。IEEE 提供了兩種可跟蹤性的工作定義：
1）"在兩種或多種開發過程的產品之間建立關系的程度，特別是相互之間具有前后關系或主從關系的產品；例如，給定軟件組件的需求與設計之間的匹配程度"。
2）"某一軟件開發產品的元素存在原因的程度；例如，一個泡式圖的元素為需求提供參考的程度"。
可跟蹤性的一個要素是，對某一"可跟蹤性關系"意味著什么作出的定義。使用 RequisitePro 工具，可以按照簡單的"traced-to"和"traced-from"模型，方便地定義某種關系。例如，我們很容易設想，在系統中建立一個或多個軟件需求（SR），來支持產品需求（PR）中指定的某一給定功能。從而可以說，從一個或多個 PR，對 SR 進行跟蹤。在已建立的需求類型的環境中，可以賦予關系另外的意義。例如，如果從一個 SR 跟蹤到測試用例需求型，可以推出該軟件需求是"通過測試用例進行測試"，也就是"traced-to"型。從一個 SR 需求來跟蹤類描述，意味著需求是通過該類來實現的。使用 RequisitePro 工具，對可定義的需求類型沒有數量限制和類型限制。另外，給定類型的需求可以在任意文檔范圍內出現。例如，不必只有 SR 類型需求才能駐留在用于描述軟件需求的文檔中。
RequisitePro 提供了一個簡單的 user-guided 過程，通過可能存在于生命周期中兩個元素之間的關系，來"指向并點擊"（point and click）。在定義了 PR 和 SR 之間的關系后，RequisitePro 可以顯示 PR 和 SR 之間關系的矩陣圖，如圖 9 所示。
圖 9 中可跟蹤性矩陣是直接實現的。例如，可以考慮 PR8（遠程數據通信）和 SR1（調制解調器端口）的相交部分。在相交部分的網格中，" "箭頭表明，從 PR8 跟蹤到 SR1，可以得到某種關系。也就是說，SR1 來自 PR8 定義的某種功能，或者 SR1 以某種方式滿足 PR8 定義的功能。
用 RequisitePro 建立了所有已知的關系后，在 FDA 指南的有力支持一下，檢查可跟蹤性矩陣的以下兩個潛在錯誤是一項有益的需求管理活動：
1. 如果在某行中未能檢查到任何可跟蹤性關系（未檢查到"箭頭"），說明可能尚未為 PRD 要求的某項功能定義軟件需求。該功能如果通過軟件之外其他方式實現（例如，外殼由不易破碎的塑料制成），這種情況除外。盡管如此，空行意味著可能存在潛在錯誤，應該對其進行仔細檢查。RequisitePro 可以自動完成這類檢查。
2. 如果在某列中未能檢查到任何可跟蹤性關系，說明可能沒有已知的產品功能需要這項軟件需求。這表明對 SR 的任務可能存在誤解，或者表明原始 PRD 中存在弱點，或者表明 PRD 中存在死碼或不支持系統需求的代碼。不管是哪種情況，都要進行仔細檢查。
除提供了一套工具集來查詢已建立的關系之外，RequisitePro 還提供了一種簡單的方法來存儲查詢結果并且可以過后再調用它們。該項功能允許您過后再重新訪問建立的關系，也許在變更發生之后快速重新查詢關系，從而發現潛在的問題點。
簡單明確地應用上述技術，使您能夠把項目中許多元素關聯起來。您應該仔細考慮以下的鏈接和關聯
PR 到 SR。 SR 到 Implementation Units（實現單元）。 Implementation Units（實現單元） 到 測試計劃/規格說明/結果。 SRs 到測試計劃/規格說明/結果。 危害分析元素（HA）到 PR、SR、實現單元和測試。如上建議，把不同文檔中的不同元素鏈接起來之后，可以建立如圖 10 的關系。
RequisitePro 還提供了顯示項目中全部可跟蹤性關系集的功能。圖 11 顯示了這樣一個"樹"視圖。注意樹視圖（或部分樹視圖）允許同時查看項目所有關系。您應該利用樹視圖來幫助充分理解項目的總體關系。
例如，圖 11 的樹視圖表明，PR3（一個產品需求或功能）鏈接到 SR1（一個軟件需求），SR1 又鏈接到 TST4（一個測試規格說明）。
元素之間建立了鏈接之后，RequisitePro 將用于保持這些鏈接。利用 RequisitePro 的強大功能，可以任您所需地來檢查項目元素之間的關系。一項關鍵的需求管理活動為您提供了一種常規的檢查功能，那就是利用可跟蹤性關系來檢查項目中建議的變更、和已經實現的變更帶來的影響，該類活動在 OG 和 QSR 中稱為變更管理。
變更管理
變更管理實踐幫助您理解和管理以下項目開發的三個重要方面：
1. 如果某一元素建議進行變更（例如，一個單一的產品需求），那么按何種順序進行變更工作呢？換句話說，變更管理幫助您回答了當某一元素要發生變更時，如何確定重新工作所需的工作量。完成一項變更的工作量可能會對項目資源規劃和工作負載規劃造成顯著影響。
2. 如果某一元素建議進行變更，那么該項變更會對系統其他元素造成什么影響？這個論題無論對您的項目規劃還是對 FDA，都是備受關注的問題。經驗表明，軟件某項變更不可避免地將會對其他部分造成負面影響。這項問題對于設計和實現可靠的醫療產品尤為重要，FDA 特別要求將有組織的變更管理程序作為設計過程的一部分。
3. 進行中的項目不可避免地會發生順序錯誤。項目中將會有某一時刻，您想要"退回去"，檢查某項需求和某項需求在前面所作的修改。另外，記住為什么要進行修改和怎樣修改，對您很有幫助。換句話說，為每項需求建立審計跟蹤特別具有價值。這不僅有助于您的項目，而且 FDA 也要求把可審計性作為一部分納入設計過程中。
受變更影響的元素
建立了項目中可跟蹤性關系后，可跟蹤性鏈接可以用作一個變更管理工具。讓我們通過前面圖 9 顯示的可跟蹤性矩陣來檢驗一下這項功能。假設PR8（遠程數據通信）需要進行改動來反映修訂后的產品功能。使用 Word/RequisitePro 對 PRD中PR8 進行編輯后，我們發現前面圖 9 顯示的可跟蹤性矩陣通過 RequisitePro 自動發生改變，改變后如圖 12 所示。
在圖 12 中，注意網格中的對角線，這些對角線勾劃了 PR8 對應行中的可跟蹤性箭頭。這些對角線稱作"可疑鏈接"，是 RequisitePro 自動插入的，用于提醒您 PR8 的變更可能對 SR1、SR2、SR4、SR5 和 SR6 產生影響。
隨著項目的進展，您會發現，項目的很多方面都有變更提議。這些變更可能發生在項目的任何地方，從高級 PRD 一直到規格說明、實現過程和測試。無論變更何時發生，RequisitePro 都將自動插入可疑鏈接標記來提醒您可能受到變更影響的關系。當檢查交互作用時，您可能發現受到影響的元素可能發生變更，也可能不發生變更。變更管理活動通常包含以下兩個步驟之一：
1、如果受到影響的鏈接不會發生改變（例如，PR8 的變更不會影響到 SR1），那么只需用 RequisitePro 來清除可疑鏈接即可。請注意，過后的 PR8 變更可能在某一時刻再次將其標為可疑鏈接。
2、如果受到影響的鏈接發生了改變，可能需要為這些元素重新設置鏈接。例如，PR8 建議的變更可能要求對 SR2 進行重新說明。編輯完 SR2 后，將發現 RequisitePro 又自動插入了另外的可疑鏈接來提醒您可能受到 SR2 變更影響的元素（PR4，General ECG）。然后，需要檢查那些變更帶來的交互影響，等等。
RequisitePro 實際上提供了所有級別可跟蹤性關系的變更管理功能。也就是說，改變 PRD 中 PR 項可能對 SRS 中若干項 SR 產生影響，這些影響隨后又會對某些實現單元產生影響，而實現單元受到的影響隨后又會對一個或多個測試計劃產生影響。RequisitePro 還對可跟蹤性鏈接進行雙向跟蹤。例如，測試計劃規格說明書的變更可能需要回頭來檢查實現單元（IU）以確定是否對其產生影響。隨后，改變 IU 可能要求您復查受到影響的 SR，甚至要求復查高級 PR，這些 PR 都是通過已建立的可跟蹤性關系而最終進行鏈接的。
在所有情況下，RequisitePro 的跟蹤活動貫穿了可跟蹤性鏈接，并且在適當的地方插入可疑鏈接標記。這項強大功能為您提供了一個簡單的方法，來跟蹤項目中變更帶來的影響。
變更歷史記錄的審計跟蹤
RequisitePro 提供了一項強大功能，用來保持變更的審計跟蹤。這項功能的最大用途在于，對單個需求發生的變更自動進行跟蹤。RequisitePro 獨立管理每項需求，盡管需求包含在文檔中。這樣，RequisitePro 能夠自動捕獲每項需求發生的變更，并且您可以過后檢查和評審這些變更。
通過變更的歷史記錄來捕獲當前的需求說明，包括當前的所有需求屬性值。通過捕獲所有當前的需求參數，可以將歷史記錄用作查看所有需求參數的簡潔方法。這項功能類似于 RequisitePro 其他功能所提供的常用屬性查看方法。
變更的歷史記錄還使您能夠查看較早的需求變更的歷史記錄（這些記錄是按時間順序排列的），包括他們的屬性。RequisitePro 能夠自動捕獲某項需求所有的文本變更和需求屬性值的變更。
無論 RequisitePro 何時檢測到一項變更，它可以自動捕獲該項變更的背景情況。另外，RequisitePro 還可以自動捕獲某項變更的創建者（例如，用 RequisitePro 進行變更的人）和該項變更的日期和時間。然后，在過后的任何時間，按時間順序排列的變更和變更創建者可以作為歷史記錄的一部分來查看。
另外，RequisitePro 允許輸入一項變更描述來記錄該項變更。通常，用一兩句話來解釋為什么要進行變更，建立關于變更的項目備忘錄參考資料，等等。將變更記錄下來，可以得到令人滿意的基本的變更理由和相互參照，從而在后面做歷史記錄檢查時，可以充分地回想起某項變更的動機。在 FDA 評審那些影響到設備的臨床要求、效率和安全性的變更時，這是一項關鍵要素。
圖 13 顯示了部分 SRS 需求歷史記錄（SR7）樣例。注意變更的歷史記錄是按反向時間順序排列的，并且記錄了文本變更（#1.0006對 #1.0005）和所選屬性值（#1.0005）的變更。變更可能是非常細小的，例如 1.0005 和 1.0006 的文本變更，僅僅是改變了"cpu"的字母大小寫。即使如此，極小的變更也要作為一項變更，通過 RequisitePro 正確地記錄下來。
配置管理與變更管理
在使用 RequisitePro 工具進行管理的項目中，強大的變更歷史記錄功能有三個級別：
1. 在最好的細節級別上，變更歷史記錄對項目中每項單個的需求的所有變更進行記錄。圖 13 顯示了該細節級別。
2. 在中等細節級別上，RequisitePro 用于與常見的行業配置管理工具（包括 PVCS 和 Visual Source Safe）集成，從而自動保持每個已知項目文檔的類似的變更歷史記錄。
3. 在最普通的細節級別上，RequisitePro 用于與配置管理工具進行鏈接，從而自動保持整個項目的勒死的變更歷史記錄。在這種模式中，RequisitePro 還提供了安全訪問，來防止關鍵項目文檔的非授權變更。RequisitePro 還用于保持項目級的內置的項目存檔功能，從而允許您為處于特定開發形態中的項目進行"快照"。
借助于這些功能，RequisitePro 實現了與公共應用程序的自動且無縫集成，在配置管理任務中起到輔助作用，這些配置管理任務對于管理高可信度軟件項目至關重要。
結束語隨著最新的 FDA 規范的出臺，醫療設備制造商正在面臨著更加嚴格的醫療設備開發過程和醫療設備軟件開發過程的管理方針。預計這種趨勢將不斷加深。不良的設計控制不僅意味著產品不能通過 FDA 評審，而且也無法滿足客戶的期望，還可能導致項目超過日程計劃一半，以及相關的成本超支，而且最嚴重的后果將導致項目終止。
同時，我們正在開發復雜性不斷增加的系統，要求對項目組成組件有更好的了解。不斷出現的用戶要求，促使形成了一個系統的設計控制的方法，該方法是完全有必要的。了解需求管理過程，并且將其用于開發醫療設備，是實現成功的項目設計、測試和管理的根本所在。
通過以原有形式輸入需求文檔和對其進行評審這兩個功能的結合，并且鏈接到中心庫（庫內容包括需求、規格說明、屬性和它們之間的可跟蹤性鏈接），可以建立一個可以控制的機制，用以確保一致性和設計質量。通過使用 RequisitePro，使項目團隊能夠管理設備的設計過程，改進團隊之間的交流，更清楚地定義項目基線，以及更高效地管理資源。另外，RequisitePro 提供了需求可跟蹤性和變更管理的自動支持功能，從而降低了開發成本，并且通過消除許多人工活動易范的錯誤，而提高了產品質量。
將 RequisitePro 整合到醫療設備團隊的設計控制過程中，可以提供一個更加自動化的方法，來開發能夠按期交付的、預算內的產品，從而滿足客戶的真正需要，并且確保病人的安全。
建議閱讀Software Requirements - Objects, Functions, & States, Davis, Alan M., Englewood Cliffs, NJ: Prentice Hall, 1993.
Exploring Requirements - Quality Before Design, Gause, Donald C., and G. Weinberg, New York, NY Dorset House Publishing, 1989
如需訂購這些書目，或加入網上論壇來討論需求管理問題，請與 Rational 軟件集團公司聯系，4900 Pearl East Circle, Suite 106, Boulder, CO 80301，電話：(303)-444-3464，傳真：(303)-444-3413，電子郵件：information@rational.com
縮寫詞匯表510(k) 關于上市的醫療設備（與市面上已有的醫療設備相似）方面控制立法的組織的簡寫。用法類似于用來指聯邦管理下的公司儲蓄計劃時的"401(k)"。
CDRH Center for Devices and Radiological Health
CGMP Current Good Manufacturing Practices
CMP Configuration Management Plan
FDA Food & Drug Administration
EU European Union
GMP Good Manufacturing Practices
HA Hazard Analysis
HRS Hardware Requirement Specification
IEC International Electrotechnical Commission
IU Implementation Unit
IEEE Institute of Electrical and Electronic Engineers
ISO International Standards Organization
LOC Level Of Concern
MDA Medical Device Amendments
ODE Office of Device Evaluation
OG "Office of Device Evaluation Guidance for the Content of Premarket Submission for Medical Devices Containing Software (draft document)"
PRD Product Requirements Document
QSR Quality System Regulation
SMDA Safe Medical Device Act
SRS Software Requirement Specification
V&V Verification and Validation
VVP Verification and Validation Plan
原文轉自：http://www.anti-gravitydesign.com
