DDPプロセスを，次のように云うことができる．行きたい場所を決め，その途中で何を得るかを考え，どうやってその場所に行くかを決めることである.ここで行きたい場所は，要求の木のことを指し，途中で得るのは，故障モードの木である ．
この項は，DDP（Defect Detection Prevention approach, 欠陥検知防止アプローチ）を中心に説明している．少し，補足する．DDPは，NASAのジェット推進研究所で使われているというリスク管理の方法である．ここでは，一般とは少し異なった用語の使い方がなされている．ちなみに，PACTとは，以下の頭文字である：予防手段・分析・プロセス制御・テスト．故障モードは，いわゆるFTA（故障木分析）でいう故障モードに限定されない．
| 一般的用語 |
DDPでの用語 |
| 目的 |
要求 |
| リスク |
故障モード |
| 対抗手段 |
PACT |
従って，冒頭の文は，「（ミッションの）目的を決め，どういうリスクがあるかを考え，対応しながら進む」ということになる．
さて，DDPの動機は，次の点にある．宇宙機のような信頼性を要求されるシステムでは，様々なPACTが実施される（特に，昔はミッション成功のために多額の費用が認められていた）．全てのPACTは，本当に役立っているのか？というのがスタートラインである．信頼性の確保は重要である．しかし，いわゆる費用対効果を見極めようという，きわめて健全なアプローチである．
最初に示しているのが，リスクー結果表である．縦方向が，システムの目的であり，重み付けがなされている．左右方向が，リスクで，顕現しやすさと共に示されている．これは，図書館問題の嶺である．
DDP：リスク結果表
この表から，各目的毎のリスクを加味した値や，各リスク毎の目的に対する影響を知ることができる．「本をいつでも利用できる（利用可能性）」のリスクの重大さは0.22で，「蔵書が揃っている」ということに対するリスクの重大さの10倍となっている．特に寄与しているのは，盗難・紛失リスクで，ここに対策することで，リスクの重大さは大きく減少することが分かる．
同様に，対策の効果，対策の費用に関して類似の計算を行うことで，費用対効果に優れ，システムに目的に合致したシステムを作成することができるというのが， DDP のねらいである．
(nil)
この（リスク管理）プロセスは，文書化されるべきである．この中で，リスクに対する対抗手段の（有効性についての）理由を提供し，要求の進化を支援するためである．即ち，要求を変更することにより，リスクが変わる可能性があり，これによって別の対抗手段が必要になるかもしれない．(p.101)
リスクに関する文書は，各リスクに対して，理想的には次を含むことが望ましい．
- リスクの顕現を特徴付ける条件ないしは事象
- 推定したリスクの頻度
- 生じ得る原因と結果
- 推定頻度と，生じた場合の重大さ
- 各リスクを減らす方法とともに考えたリスク対抗手段
- 実装を選択したサブセットとなる対抗手段
医療機器のソフトウェアについては，有名な規格に ANSI/AAMI/IEC 62304:2006（以下単にIEC 62304） がある．この中に，リスク管理ファイルという概念がある．このファイルの定義は，以下である．
RISK MANAGEMENT FILE
set of records and other documents, not necessarily contiguous, that are produced by a RISK MANAGEMENT PROCESS
リスク管理ファイル
記録と他の文書の組．必ずしも連続している必要はない．このファイルは，リスク管理プロセスにおいて作られる
IEC 62304 は，医療機器ソフトウェアのライフサイクルプロセスについての規格であるが，興味深いことに，リスク管理と問題解決に焦点を絞っている．普通は，これらプロセスは，各開発プロセス（分析や設計．．）などと並列に置かれる ．IEC62304では，いわゆるISO/IEC 12207で定義するSLCPを，リスク管理と問題管理の視点から説明するのである．
このときの，文書化の中心となるのが，上記のリスク管理ファイルになる．
ISO 26262 の場合は，どうだろう．各アクティビティ・タスクレベルで，詳細な文書が定義されているものの，リスク管理という観点から，横断的に定義されている文書はない．唯一，近いのはセーフティケースである．セーフティケースについては，これまで何度（例えば，ここ或いはこちら）か書いてきたし，これからも書くと思うので，省略する．
セーフティケースは，先行していたMISRAの以前のガイドラインでは，明示的にライフサイクル横断で使用することを要求していた．V字モデルを厳格に適用した，ISO 26262ではなじまないということか．
(nil)
前回の，製品とプロセス（プロジェクト）のリスク評定をしただけでも，行動が変わる可能性があり，意味がある．しかし，やはり，リスクの顕現に備えるべきである．
このとき，製品リスクに対しては，要求の変更が必要になる．プロセスリスクに対して対抗策をとれば，プロジェクト計画書が変更になる（プロジェクト計画書は変更されない文書の代表的なものだが）．
この項には，幾つかのリスク削減戦略が書かれている．
生じやすさを減少する
プロダクトリスクの例として，自動車の操縦支援が挙げられている．操縦支援により，事故になる率を減らす．
リスクを回避する
プロダクトリスクの例として，インターロックを挙げている．
リスクが顕現する割合を減らす
プロダクトリスクの例としては，走行中にドアが間違って開いても，そのことをアラームによって運転手に知らせる機構があれば，実際の危害「乗客が走行車両から落ちる」は減少できるとしている．
顕現した被害を避ける
列車の位置と速度情報が不正確と考えられる場合，衝突しないこととする．ここでは，仕様書にもれなく記載するということでしかないのだが．
顕現した被害を緩和する
会議管理システムにおいて，重要な参加メンバが出席できなくなった．仕様にビデオ会議システムを追加することによって，緩和できるとしている．
対向手段の例は，あくまで例である．本格的なリスク対抗手段は，詳細になり，ドメインに深く依存してしまう．例の役目を果たさない，かもしれない．
(nil)