• 預期用途所需的SOUP項目的功能和性能要求

• 讓SOUP項目正常運行所需的系統硬件和軟件的生產規范

• 證明醫療器械架構能夠讓任意SOUP項目正常運行所需的詳情

大多數情況下，SOUP項目是作為源代碼提供的，但是不帶設計文件，這樣就很難分析它們。使用現代測試工具有助于實現早期代碼設計可視化。

不論它是否應用于語句模塊、進程(或類)、應用和/或系統，現代測試工具提供的系統可視化設施功能都非常強大。應用和系統實體的分層示意圖如圖3a 內的靜態調用圖所示;圖3b內的靜態流程圖展示了整個程序模塊的控制流程。利用彩色編碼圖對于了解SOUP極有好處。這類調用圖和流程圖只是綜合分析代碼內使用的所有參數和數據對象的一部分優勢。

圖3

圖3 靜態調用圖(a)和流程圖(b)以圖形的形式分別說明了代碼的結構和邏輯。

需求管理和跟蹤已經證明了它們在軟件開發生命周期內的優勢，能夠確保實現所有需求和所有開發成果都可以追溯到一個或多個需求。同樣的，需求管理與跟蹤可以保證根據系統要求添加和驗證SOUP項目。

RTM在架構設計和SOUP項目之間實現了可追蹤性。由于這些項目都包含在源代碼內并且現在需要按照IEC 62304的要求進行系統級合規性測試，所以代碼驗證就成了制造商的責任。

大多數SOUP項目都不嚴謹，從而為系統集成商提高了嚴格驗證與風險分析要求。由于SOUP驗證非常耗時，所以開發人員一開始通常需要滿足一系列編碼標準，再逐漸采用其他規則。雖然測試工具只辨別而不糾正代碼內存在的違規之處和本征誤差，但是它們確實通過指出問題所在而加快了代碼糾正速度。

IEC 62304希望醫療器械制造商評估SOUP項目供應商提供的軟件異常列表，以便確定已知異常是否會引發事件，進而導致出現危險情形。

測試工具的靜態分析能力能夠確定異常及其對軟件系統的影響。如果確定了SOUP供應商提供的列表以外的任何其他異常，則應告知相應供應商以解決問題。