この（リスク管理）プロセスは，文書化されるべきである．この中で，リスクに対する対抗手段の（有効性についての）理由を提供し，要求の進化を支援するためである．即ち，要求を変更することにより，リスクが変わる可能性があり，これによって別の対抗手段が必要になるかもしれない．(p.101)
リスクに関する文書は，各リスクに対して，理想的には次を含むことが望ましい．
- リスクの顕現を特徴付ける条件ないしは事象
- 推定したリスクの頻度
- 生じ得る原因と結果
- 推定頻度と，生じた場合の重大さ
- 各リスクを減らす方法とともに考えたリスク対抗手段
- 実装を選択したサブセットとなる対抗手段
医療機器のソフトウェアについては，有名な規格に ANSI/AAMI/IEC 62304:2006（以下単にIEC 62304） 1がある．この中に，リスク管理ファイルという概念がある．このファイルの定義は，以下である．
RISK MANAGEMENT FILE
set of records and other documents, not necessarily contiguous, that are produced by a RISK MANAGEMENT PROCESSリスク管理ファイル
記録と他の文書の組．必ずしも連続している必要はない．このファイルは，リスク管理プロセスにおいて作られる
IEC 62304 は，医療機器ソフトウェアのライフサイクルプロセスについての規格であるが，興味深いことに，リスク管理と問題解決に焦点を絞っている．普通は，これらプロセスは，各開発プロセス（分析や設計．．）などと並列に置かれる 2．IEC62304では，いわゆるISO/IEC 12207で定義するSLCPを，リスク管理と問題管理の視点から説明するのである．
このときの，文書化の中心となるのが，上記のリスク管理ファイルになる．
ISO 26262 の場合は，どうだろう．各アクティビティ・タスクレベルで，詳細な文書が定義されているものの，リスク管理という観点から，横断的に定義されている文書はない．唯一，近いのはセーフティケースである．セーフティケースについては，これまで何度（例えば，ここ或いはこちら）か書いてきたし，これからも書くと思うので，省略する．
セーフティケースは，先行していたMISRAの以前のガイドラインでは，明示的にライフサイクル横断で使用することを要求していた．V字モデルを厳格に適用した，ISO 26262ではなじまないということか．
(nil)