条件分岐・例外処理
DFDでは、条件分岐も表現しません。これは、フローチャートに慣れた人にはかなり違和感があるものです。UMLのシーケンス図においても、条件分岐を表現する記法は存在しています。しかし、DFDでは条件判定によって後続のデータの流れる先が分岐した場合でも、同じレベルで表現します。
例外処理も、「正常に処理ができなかったら」という条件分岐の1つとみなして構いません。
図1.2.1の「2.支払い」プロセスにおいて、「決済失敗通知」の情報が顧客に向かって流れていますが、これは顧客から受け取った決済情報（クレジットカード情報や口座情報）に基づく決済処理が正常に行われなかった場合に通知するケースを表現したものです。
プロセス内で判断される分岐の条件は、ミニ仕様書に記述します。デシジョン・テーブル（決定表）やデシジョン・ツリー（決定木）、フローチャートなどを活用して、その条件と結果が明確になるように整理します。
処理の親子関係
プログラムを開発していれば、プロセスからプロセスを呼び出したり、メソッドからメソッドを呼び出したりすることは当然のことです。ですから、その実装をイメージして、その親子関係を表現したくなります。
先ほどの「同期／非同期」の話とも関連しますが、同期的呼び出しにおける呼び出し元、呼び出し先をDFDでは表現しません。それは、DFDが「データの流れ」に焦点を置いて表現するのに対し、プロセスの親子関係は「処理の流れ」の話になるからです。
実際にDFDの記号を用いて、処理の親子関係、呼び出し関係を表現しようとすると、「プロセス同士がデータフローの矢印で接続」「データフローで引数を表現」「呼び出し元に再び矢印が接続され、戻り値を表現」が繰り返されることになります。これで一応DFDでも処理の親子関係を表現できたように思えますが、先に述べたとおり、DFDでは「実行順序」を表さないので、相互に直接接続されたプロセス同士はどちらが呼び出し元でどちらが呼び出し先か、表現できません。
処理の単位
DFDでは、データフローとして流れてくるデータや、プロセスで処理されるデータの「件数・処理単位」を表現しません。１件ずつの処理であろうと、複数件まとめた処理であろうと、表記上は全く違いがありません。
業務分析段階でDFDを使用して表現するとしましょう。この際、1人の担当者が書類を1件ずつ受け取って処理をするか、複数の書類をまとめて受け取って処理をするか、その処理結果を1件ずつ次へ回すか、複数件まとめて次へ回すか、あるいは同じ業務を担当する複数の担当者で処理をするのか、いずれの処理であってもDFD上の表記は同じで、書類の種類が1種類である限り、データストア記号1つで表現しますし、何人の担当者で実施していても1つのプロセスで表現します。
設計段階でDFDを使用して表現する場合も同様です。プログラムの実装上、プロセスに相当するモジュールが1回起動されると、1件だけ入力して処理する場合があります。複数件を処理するためには、何度もその処理を起動する必要があるかもしれません。
一方で、モジュールが1回起動されると、処理可能なデータがある限りすべてを処理する場合もあります。ただし、これらの違いがあってもDFD上での表記に差異はありません。
フローチャートでは、書類・帳票を表す記号として単体と複数のものが存在していますが、DFDではこうした区別はしないのです。
処理の単位は、その処理がいわゆるオンライントランザクションを扱うアプリケーションとして実現されるべきなのか、バッチ処理として実現されるべきなのか、また、トランザクション単位をどう扱うかという情報が重要になってきます。
このような認識の齟齬を起こさないよう、「ミニ仕様書」などに記述しておくべきです。
