IEC62304における安全性クラスと要求される実施項目との関係
| 4 一般要求事項 | |||||
|---|---|---|---|---|---|
| プロセス | 項番号 | アクティビティ | 要求項目 | ||
| 4.1 品質マネジメントシステム | ○ | ||||
| 4.2 リスクマネジメントシステム | ○ | ||||
| 4.3 ソフトウェア安全クラス分類 | ○ | ||||
| 4.4 レガシーソフトウェア | ○ | ||||
| 5 ソフトウェア開発プロセス | |||||
| プロセス | 項番号 | アクティビティ | 安全性クラス | ||
| A | B | C | |||
| 5.1 ソフトウェア開発計画 | 5.1.1 | ソフトウェア開発計画 | ○ | ○ | ○ |
| 5.1.2 | ソフトウェア開発計画の継続更新 | ○ | ○ | ○ | |
| 5.1.3 | ソフトウェア開発計画におけるシステム設計及びシステム開発の引用 | ○ | ○ | ○ | |
| 5.1.4 | ソフトウェア開発規格，方法及びツールの計画 | ○ | |||
| 5.1.5 | ソフトウェア結合及び結合試験計画 | ○ | ○ | ||
| 5.1.6 | ソフトウェア検証計画 | ○ | ○ | ○ | |
| 5.1.7 | ソフトウェアリスクマネジメント計画 | ○ | ○ | ○ | |
| 5.1.8 | 文書化計画 | ○ | ○ | ○ | |
| 5.1.9 | ソフトウェア構成管理計画 | ○ | ○ | ○ | |
| 5.1.10 | 管理が必要な支援アイテム | ○ | ○ | ||
| 5.1.11 | 検証前のソフトウェア構成アイテムのコントロール | ○ | ○ | ||
| 5.2 ソフトウェア要求事項分析 | 5.2.1 | システム要求事項からのソフトウェア要求事項の定義及び文書化 | ○ | ○ | ○ |
| 5.2.2 | ソフトウェア要求事項の内容 | ○ | ○ | ○ | |
| 5.2.3 | リスクコントロール手段のソフトウェア要求事項への包含 | ○ | ○ | ||
| 5.2.4 | 医療機器のリスク分析の再評価 | ○ | ○ | ○ | |
| 5.2.5 | システム要求事項の更新 | ○ | ○ | ○ | |
| 5.2.6 | ソフトウェア要求事項の検証 | ○ | ○ | ○ | |
| 5.3 ソフトウェアアーキテクチャの設計 | 5.3.1 | ソフトウェア要求事項のアーキテクチャへの変換 | ○ | ○ | |
| 5.3.2 | ソフトウェアアイテムのインタフェース用アーキテクチャの開発 | ○ | ○ | ||
| 5.3.3 | SOUPアイテムの機能及び性能要求事項の指定 | ○ | ○ | ||
| 5.3.4 | SOUPアイテムが要求するシステムハードウェア及びシステムソフトウェアの指定 | ○ | ○ | ||
| 5.3.5 | リスクコントロールに必要な分離の特定 | ○ | |||
| 5.3.6 | ソフトウェアアーキテクチャの検証 | ○ | ○ | ||
| 5.4 ソフトウェア詳細設計 | 5.4.1 | ソフトウェアアーキテクチャのソフトウェアユニットへの分解 | ○ | ○ | |
| 5.4.2 | ソフトウェアユニットごとの詳細設計の開発 | ○ | |||
| 5.4.3 | インタフェース用詳細設計の開発 | ○ | |||
| 5.4.4 | 詳細設計の検証 | ○ | |||
| 5.5 ソフトウェアユニットの実装及び検証 | 5.5.1 | 各ソフトウェアユニットの実装 | ○ | ○ | ○ |
| 5.5.2 | ソフトウェアユニット検証プロセスの確立 | ○ | ○ | ||
| 5.5.3 | ソフトウェアユニットの合否判定基準 | ○ | ○ | ||
| 5.5.4 | 追加のソフトウェアユニット合否判定基準 | ○ | |||
| 5.5.5 | ソフトウェアユニットの検証 | ○ | ○ | ||
| 5.6 ソフトウェア結合及び結合試験 | 5.6.1 | ソフトウェアユニットの結合 | ○ | ○ | |
| 5.6.2 | ソフトウェア結合の検証 | ○ | ○ | ||
| 5.6.3 | 結合したソフトウェアの試験 | ○ | ○ | ||
| 5.6.4 | 結合試験の内容 | ○ | ○ | ||
| 5.6.5 | 結合試験手順の検証 | ○ | ○ | ||
| 5.6.6 | レグレッションテストの実施 | ○ | ○ | ||
| 5.6.7 | 結合試験記録の内容 | ○ | ○ | ||
| 5.6.8 | ソフトウェア問題解決プロセスの使用 | ○ | ○ | ||
| 5.7 ソフトウェアシステム試験 | 5.7.1 | ソフトウェア要求事項についての試験の確立 | ○ | ○ | |
| 5.7.2 | ソフトウェア問題解決プロセスの使用 | ○ | ○ | ||
| 5.7.3 | 変更後の再試験 | ○ | ○ | ||
| 5.7.4 | ソフトウェアシステム試験の検証 | ○ | ○ | ||
| 5.7.5 | ソフトウェアシステム試験記録の内容 | ○ | ○ | ||
| 5.8 ソフトウェアリリース | 5.8.1 | ソフトウェア検証の完了確認 | ○ | ○ | |
| 5.8.2 | 既知の残留異常の文書化 | ○ | ○ | ||
| 5.8.3 | 既知の残留異常の評価 | ○ | ○ | ||
| 5.8.4 | リリースしているバージョンの文書化 | ○ | ○ | ○ | |
| 5.8.5 | リリースしたソフトウェアの作成方法の文書化 | ○ | ○ | ||
| 5.8.6 | アクティビティ及びタスクの完了確認 | ○ | ○ | ||
| 5.8.7 | アクティビティ及びタスクの完了確認 | ○ | ○ | ||
| 5.8.8 | ソフトウェアリリースの反復性の確保 | ○ | ○ | ||
| 6 ソフトウェア保守プロセス | |||||
| 6.1 ソフトウェア保守計画の確立 | ○ | ○ | ○ | ||
| 6.2 問題及び修正の分析 | 6.2.1 | フィードバックの文書化及び評価 | ○ | ○ | ○ |
| 6.2.2 | ソフトウェア問題解決プロセスの使用 | ○ | ○ | ||
| 6.2.3 | 変更要求の分析 | ○ | ○ | ○ | |
| 6.2.4 | 変更要求の承認 | ○ | ○ | ○ | |
| 6.2.5 | ユーザ及び規制当局への通知 | ○ | ○ | ○ | |
| 6.3 修正の実装 | 6.3.1 | 確立したプロセスを使用した修正の実装 | ○ | ○ | ○ |
| 6.3.2 | 修正ソフトウェアシステムの再リリース | ○ | ○ | ○ | |
| 7 ソフトウェアリスクマネジメントプロセス | |||||
| プロセス | 項番号 | アクティビティ | 安全性クラス | ||
| A | B | C | |||
| 7.1 危険状態を引き起こすソフトウェアの分析 | 7.1.1 | 危険状態の一因となるソフトウェアアイテムの特定 | ○ | ○ | |
| 7.1.2 | 危険状態の一因となるソフトウェアアイテムの潜在的原因の特定 | ○ | ○ | ||
| 7.1.3 | 公開された SOUP 異常リストの評価 | ○ | ○ | ||
| 7.1.4 | 潜在的原因の文書化 | ○ | ○ | ||
| 7.1.5 | イベントシーケンスの文書化 | ○ | ○ | ||
| 7.2 リスクコントロール手段 | 7.2.1 | リスクコントロール手段の選択 | ○ | ○ | |
| 7.2.2 | ソフトウェアに実装するリスクコントロール手段 | ○ | ○ | ||
| 7.3 リスクコントロール手段の検証 | 7.3.1 | リスクコントロール手段の実装の検証 | ○ | ○ | |
| 7.3.2 | 新しいイベントシーケンスの文書化 | ○ | ○ | ||
| 7.3.3 | トレーサビリティの文書化 | ○ | ○ | ||
| 7.4 ソフトウェア変更のリスクマネジメント | 7.4.1 | 医療機器ソフトウェアの安全性に関わる変更の分析 | ○ | ○ | ○ |
| 7.4.2 | ソフトウェア変更が既存のリスクコントロール手段に与える影響の分析 | ○ | ○ | ||
| 7.4.3 | 分析に基づくリスクマネジメントアクティビティの実行 | ○ | ○ | ||
| 8 ソフトウェア構成管理プロセス | |||||
| 8.1 構成識別 | 8.1.1 | 構成アイテム識別手段の確立 | ○ | ○ | ○ |
| 8.1.2 | SOUPの特定 | ○ | ○ | ○ | |
| 8.1.3 | システム構成文書の特定 | ○ | ○ | ○ | |
| 8.2 変更管理 | 8.2.1 | 変更要求の承認 | ○ | ○ | ○ |
| 8.2.2 | 変更の実装 | ○ | ○ | ○ | |
| 8.2.3 | 変更の検証 | ○ | ○ | ○ | |
| 8.2.4 | 変更のトレーサビリティを実現する手段の提示 | ○ | ○ | ○ | |
| 8.3 構成状態の記録 | ○ | ○ | ○ | ||
| 9 ソフトウェア問題解決プロセス | |||||
| 9.1 問題報告の作成 | ○ | ○ | ○ | ||
| 9.2 問題の調査 | ○ | ○ | ○ | ||
| 9.3 関係者への通知 | ○ | ○ | ○ | ||
| 9.4 変更管理プロセスの使用 | ○ | ○ | ○ | ||
| 9.5 記録の保持 | ○ | ○ | ○ | ||
| 9.6 問題の傾向分析 | ○ | ○ | ○ | ||
| 9.7 ソフトウェア問題解決の検証 | ○ | ○ | ○ | ||
| 9.8 試験文書の内容 | ○ | ○ | ○ | ||
IEC62304 /FDAガイダンス要求事項対照表
| IEC62304 | Description | FDA Guidance | Description | |
|---|---|---|---|---|
| 1. |
Software Safety Classification(4.3) ソフトウェアの安全性分類 |
4.3 ソフトウェアの安全性分類（A,B,C） クラス A ⇒ 傷害又は健康被害の可能性がない。 クラス B ⇒ 重大でない傷害の可能性がある。 クラス C ⇒ 死亡又は重大な傷害の可能性がある。 ⇒リスクマネジメントファイルに記録する。 |
Level of Concern 懸念レベル |
軽減策の効果を評価する前のソフトウェア機器の懸念レベルの記述とその根拠の説明 その判断の論拠となる文書を含め、判断プロセスをFDA に明確に示すことがと望ましい。 ⇒ 記述は（軽/中/重度）に共通に必要 |
| 2. |
Software RequirementsAnalysis (5.2) ソフトウェア要求事項分析 |
5.2 ソフトウェア要求事項分析 5.2.1 ソフトウェア要求事項定義（A,B,C） 5.2.2 ソフトウェア要求事項の内容（A,B,C） ⇒設計のインプット 5.2.3 リスク管理策のソフトウェア要求事項の内容への包含（B,C） ⇒医療機器ソフトウェアアイテムごとに医療システム要求事項から、ソフトウェア要求事項を明確にして記録する。 5.2.4 リスク分析の再評価 （A,B,C） ⇒要求事項の検証をし、記録する。 5.2.5 ソフトウェア要求事項の更新（A,B,C） ⇒要求事項の検証をし、記録する。 5.2.6 ソフトウェア要求事項の検証（A,B,C）記録を残す。 |
Software Description ソフトウェアの記述 |
ソフトウェアの機能特性の説明と操作環境 ⇒ソフトウェアで制御される機器の特性を総合的に記述し、意図された操作環境をパラグラフ形式に情報を記述すること。 ⇒記述は（軽/中/重度）に共通に必要操作上重要なソフトウェアの特性を明示すること。（プログラム言語、ハードウェアプラットフォーム、OS、市販用ソフト） |
| 3. |
Analysis of Software Contributing to Hazardous Situations (7.1) 危険状態を誘発するソフトウェアの分析 |
7 ソフトウェアリスクマネジメントプロセス ⇒ISO14971 に基づくリスクマネジメントの中でハザード・危険状態を明確化する。 7.1. 危険状態を誘発するソフトウェアの分析 7.1.1 危険状態を誘発するリスクアイテムの特定 ⇒ISO14971 に基づいたリスクマネジメントの中でハザード・危険状態を明確にし、その中で原因となりうるソフトウェアアイテムを特定する。 7.1.2 危険状態の誘発潜在的原因の特定 7.1.3 公表されている SOUP 異常リストの評価 7.1.4 潜在的原因の文書化/記録 ⇒リスクマネジメントファイルに記録する。 7.1.5 一続きの事象の文書化/記録 ⇒リスクマネジメントファイルに記録する。 |
Device Hazard Analysis 機器ハザード分析 |
重度評価と軽減措置を含む特定されたハードウェアとソフトウェアのハザードに関する表形式に記述 ハードウェアとソフトウェアの用途に伴う全ての機器のハザードを考慮することが望ましい。この書類は総合リスク管理書類からのソフトウェア関連条項の抜粋でもよい。例えば ISO14971 に述べられているリスク管理要約 ⇒ 記述は（軽/中/重度）に共通に必要 |
| 4. |
Software RequirementsAnalysis (5.2) ソフトウェア要求事項分析 |
5.2 ソフトウェア要求事項分析 5.2.1 ソフトウェア要求事項定義（A,B,C） 5.2.2 ソフトウェア要求事項の内容（A,B,C） 5.2.3 リスク管理策のソフトウェア要求事項の内容への包含（B,C） ⇒医療機器ソフトウェアシステムごとに医療機器 システム要求事項から、ソフトウェア要求事項を明確にする。（2.1,2.2,2.3） 5.2.4 リスク分析の再評 （A,B,C） 5.2.5 ソフトウェア要求事項の更新（A,B,C） 5.2.6 ソフトウェア要求事項の検証（A,B,C） ⇒要求事項の検証をし、記録する。 |
Software Requirements Specification(SRS) ソフトウェア要求仕様 |
要求仕様書(SRS)から機能要求の概要の記述ソフトウェアに対する要求を記載する。 ◆ハードウェア要件：マイクロプロセッサ、メモリ、センサー、安全機能 ◆プログラム言語：プログラムサイズ要求、制限も含む ◆インタフェース要求：システムコンポーネント間の通信/ユーザとの通信 ◆ソフトウェア性能と機能要求： 治療、診断、監視、警報のアルゴリズム又は制御特性根拠となる臨床データも含む。 ◆ソフトウェア性能と機能要求 ソフトウェアによる機器の限界 社内テストとチェック、エラーと割り込み処理、傷害検知/許容誤差/回復特性、安全要求、タイミングと必要メモリの情報も含む。 ⇒概要の記述のみ（軽度） ⇒要求仕様書一式の提出（中/重度） |
| 5. |
Software Architectural Design(5.3) ソフトウェアアーキテクチャの設計 |
5.3 ソフトウェアアーキテクチャの設計 5.3.1 ソフトウェア要求事項のアーキテクチャへの変換（B,C） ⇒ソフトウェアアイテムのインタフェースの開発と文書化 ◆ソフトウェアアイテム外のコンポーネントとの間 ◆ソフトウェアアイテム同士の間 |
Architecture Design Chart アーキテクチャ設計図表 |
ソフトウェア主要機能ユニット間の関係を詳細な記述とフローチャートと状態図の記述 ネットワーキングのようなハードウェアとの関係、データフローとの関係も含む。SRS にこの情報が含まれる場合は、その旨を記述する。 ⇒提出不要（軽度） ⇒提出要(中度/重度) |
| 6. |
Software Detailed Design(5.4) ソフトウェア詳細設計 |
5.4 ソフトウェア詳細設計 5.4.1 ソフトウェアアーキテクチャからユニットへ（B,C） 5.4.2 ユニットの詳細開発 (C) 5.4.3 インタフェースの詳細開発 (C) 5.4.4 詳細設計の検証 (C) ⇒ソフトウェアアーキテクチャがソフトウェアユニットで表現されるまでを精度化する ⇒各ソフトウェアユニットの詳細設計を開発し、記録する。 ⇒インタフェースの詳細設計を開発し、記録する。 ⇒詳細設計を検証し、記録する。 |
Software Design Specification (SDS) ソフトウェア設計仕様 |
ソフトウェア設計仕様に関する書類 ソフトウェア機器に対する要求をどのように実施、履行したかを記述 書類はソフトウェアの用途、機能性、安全性、有効性についてのソフトウェア要求を実行する計画も審査できるような情報を呈示すること。 ⇒ 提出書類不要(軽度） ⇒ 提出書類要（中度/重度） |
| 7. |
Throughout IEC62304 (5.1.1, 5.2.6, 5.7.4, 7.3.3,8.2.4) ソフトウェア開発計画 ソフトウェア要求事項の検証 トレーサビリティの文書化 変更管理・変更管理 |
5.1.1 ソフトウェア開発計画 ⇒ （クラスＡ/B/C に要求） 5.2.6 ソフトウェア要求事項の検証 ⇒ 記録 5.7.4 ソフトウェアシステムの試験の検証 ⇒ 統合ソフトウェア試験と同じ内容 7.3.3 トレーサビリティの文書化 以下が ISO14971 に追加： 危険状態 ソフトウェアアイテム ソフトウェアアイテム ソフトウェアの原因 ソフトウェアの原因 リスクコントロール方法 リスクコントロール方法 その検証 8.2.4 変更管理（変更要求を承認、変更要求に指定されているように変更、その検証、記録） |
Traceability Analysis トレーサビリティ分析 |
ソフトウェア要求、仕様、特定されたハザード及びその軽減、確認及び妥当性確認におけるトレーサビリティ 製品の設計要求と設計仕様とテスト要求を互いに関連付ける書類であり、マトリックス形式のものが望ましい。 ⇒提出要（軽/中/重度） |
| 8. |
Software Development Plan(5.1) ソフトウェア開発計画 |
5.1 ソフトウェア開発プランニング （全クラス A,B,C に該当） 5.1.1 ソフトウェア開発計画 ⇒ ソフトウェア開発計画を策定することが要求事項 5.1.2 ソフトウェア開発計画の更新 ⇒策定したソフトウェア計画は必要に応じて更新しなければならない |
Software Development Environment Description ソフトウェア開発環境に関する記述 |
ソフトウェアライフサイクル開発計画の要約 開発工程で作成された管理文書の注釈付リスト ⇒ 提出要(中/重度) 構成管理と変更管理 ⇒市販後のソフトウェア機器に追加された変更 は重要な管理の対象であり、明確な仕様と適切な 場合は回帰テストを含む試験計画を必要とする。 ⇒開発環境の説明：ソフトウェア開発ライフサイ クルの側面を取り扱う構成管理と保守計画は必 須である。 ◆ソフトウェア開発工程に関する説明も必要⇒ 重度の場合 ◆構成管理と保守計画の要約⇒中程度の場合 |
| 9. |
Throughout IEC62304 (5.2.6, 5.3.6, 5.4.4, 5.5.5,5.6.3, 5.6.7, 5.7.5, 7.3.1,9.7,9.8) ソフトウェア要求事項の検証 ソフトウェアアーキテクチャの検証 詳細設計の検証 ソフトウェアユニットの検証 統合ソフトウェアの試験 ソフトウェアシステム試験記録の内容 リスクコントロール策の検証 ソフトウェアシステム試験記録の内容 リスクコントロール策の検証 ソフトウェア試験文書の内容 ソフトウェア問題解決の検証 |
5. ソフトウェア開発プロセス 5.2 ソフトウェア要求事項分析 5.2.6 ソフトウェア要求事項の検証 ⇒要求事項の検証し記録に残す（A,B,C） 5.3 ソフトウェアアーキテクチャの設計 5.3.6 ソフトウェアアーキテクチャの検証 ⇒検証結果を記録する。(B,C) 5.4 ソフトウェアの詳細設計 5.4.4 詳細設計の検証 ⇒検証結果を記録する。（C） 5.5 ソフトウェアユニット実現及び検証 5.5.5 ソフトウェアユニットの検証 ⇒検証し記録する。（B,C） 5.6 ソフトウェア統合及び統合試験 5.6.3 統合ソフトウェアの試験 ⇒統合計画に従って試験、結果を記録する。（B,C） 5.6.7 統合試験記録の内容 (B,C) ⇒試験結果を文書化する。（合否と異常リスト） 5.7 ソフトウェアシステム試験 5.7.5 ソフトウェアシステム試験記録の内容 （B,C） ⇒試験結果を文書化する。（合否と異常リスト） ⇒再試験を可能とする記録 ⇒試験者 7.3.1 リスクコントロール策の検証 ⇒検証結果を記録に残す。 9.7 ソフトウェア問題解決の検証（A,B,C） ⇒解決策を検証し、問題報告書が終了したか ⇒悪い傾向が収まったか ⇒変更要求がソフトウェア機器又は活動で実施されたか ⇒別の新たな問題が生じたか ⇒変更後のソフトウェアアイテム及びシステム試験、再試験を実施する際に以下のことを記入する。 9.8 試験文書の内容 (A,B,C) ⇒試験結果、発見された異常、試験を行ったソフトウェアバージョン、ハードウェアとソフトウェアの試験構成、試験ツール、試験を行ったデータ、試験者名 |
Verification and Validation Documentation 確認作業とバリデーション |
◆システムレベルテスト、機器レベルテスト又は適切な場合は統合テストの書類を提出する ⇒軽度の場合 ◆確認作業とバリデーション作業とその結果を要約したリストを提出する。合格/不合格基準も入れた方が望ましい。トレーサビリティ分析によってこれら作業と結果が設計仕様と仕様が有効的に結び付けられていることを確認すること。 ⇒中程度の場合 ◆中程度の記述に加え、不合格のテストに対応した修正事項とその修正事項が効果的であることを示す結果の書類を含めるのが望ましい。書類の中にはユニット統合テストの例と結果の要約を含める。 ⇒重度の場合 |
| 10. |
Configuration StatusAccounting (8.3) 構成状態の記録 |
8 ソフトウェア構成管理プロセス 8.2 変更管理 ⇒変更要求の承認、変更の実装、変更の検証 8.3 構成状態の記録 (A,B,C) |
Revision Level History 改訂レベル履歴 |
開発中に発生したソフトウェア改訂履歴を含む。⇒軽/中/重度 開発サイクル中にソフトウェアに発生した重大な変更、日付、バージョン番号、旧バージョンに追加された変更の簡単な記述を表にした形式。 記載されなければならないのは、ソフトウェアのテスト版とリリース版との相違点又はその違いが機器の安全性と有効性に与える効果についての評価である。 |
| 11. |
Maintain Records of Software Problem Resolution(9.5) 記録の維持 |
9.問題報告書の作成 (B,C) ⇒ソフトウェア機器で発見された問題ごとに報告書（種類、範囲、重要性を含む）を作成する。 9.5 記録の維持：問題報告書及びその検証を含めた解決の記録を維持する。 |
Unsolved Anomalies(Bugs or Defects) 未解決の異常 |
未解決のソフトウェアの異常・問題、機器の動作に対する影響を全てリストして提出する。 ◆オペレータの仕様や人的要因による問題 ◆機器安全性と異常に関する評価・処理を実施するための委員会によって作成される。 ◆未解決の異常に対する軽減策や対処の仕方を含める。 |
IEC62304及びFDA適合立証文書の関連性
| IEC62304 要求文書 | FDA 要求文書 | ||
|---|---|---|---|
| Risk Management File |
リスクマネジメントファイル SOUP の評価 |
Level of Concern | 懸念レベル評価表 |
| Software Development Plan | ソフトウェア開発計画書 | Software Description | ソフトウェアの記述 |
| Risk Management File | リスクマネジメントファイル | Device Hazard Analysis | 機器ハザード分析 |
| Software Requirement Specification | ソフトウェア要求仕様書 | Software Requirements Specifications | ソフトウェア要求仕様 |
| Software Architectural Design | ソフトウェアアーキテクチャ設計書 | Architecture Design Chart | アーキテクチャ設計図法 |
| Software Detailed Design | ソフトウェア詳細設計書 | Software Design Specification | ソフトウェア設計仕様書 |
| Software Traceability Matrix | トレーサビリティマトリックス | Traceability Analysis | トレーサビリティ分析表 |
|
Software Development Plan ・Software Development Plan ・Software Release ・Control for Configuration and Maintenance |
ソフトウェア開発計画： (ソフトウェア開発計画書) (ソフトウェアリリース文書) (ソフトウェア構成管理) |
Software Development Environment Description | ソフトウェア開発環境に関する記述 |
|
・Software Requirements Process Reports ・Software Unit Testing ・Software System Testing |
・要求仕様・アーキテクチャ・詳細設計・単体/システム試験計画プロセス検証報告書 ・ソフトウェア単体試験報告書 ・ソフトウェアシステム試験報告書 |
Verification & Validation Documents | 確認作業とバリデーションに関する文書 |
| Configuration Status Accounting | ソフトウェア構成管理状態を示す記録 | Revision level History | 改訂レベル履歴 |
| Maintain Records of software Problem Resolution | バグ報告書 | Unsolved Anomalies | 未解決のバグ |
出典:「参考資料」（経済産業省）（http://www.meti.go.jp/committee/kenkyukai/shoujo/iryou_software/pdf/report_001_04.pdf）（2018年1月15日に利用）
「参考資料」（経済産業省）（http://www.meti.go.jp/committee/kenkyukai/shoujo/iryou_software/pdf/report_001_04.pdf）よりIEC62304関連記事を抜粋しました。