要求定義でDFDを利用する人は多いだろう。しかし，見よう見まねで書かれたDFDに出会うことも多く，業務の真の姿をとらえて構造化できていないケースも少なくない。
使えるDFDを書くにはどうしたらよいか。DFDの特徴に着目すると，上手な書き方が見えてくる。
「誰が」を記載しないこと
DFDは，UMLのユースケース図と同様，対象となる業務の範囲を把握するのを主な目的として使われる図である。要求定義の初期段階で，システム化して解決したい問題領域を可視化することができる。要求定義でDFDをうまく書くには，DFDでは何が記述でき，何は記述されないのかをよく知っておくことが大切である。
ユースケース図と比較すると，DFDの特徴が浮かび上がってくる。（図1）の×印（図に記述しない対象）に注目してみよう。共通で×印が付いているのは「処理の順序やタイミング」だ。DFDとユースケース図は，これらが分からなくても書けることを意味している。それぞれもう一つずつ×印が付いている。その内容は異なり，ユースケース図は「データの流れ」に関する情報が分からなくても書ける，DFDは「誰」がその業務や処理を行うかは明確になっていなくても書ける，という特徴がある。
 |
| 図1●DFDとユースケース図の特徴 |
思い描く場面を共有する
効率的なDFDの作成手順を見ていこう。四つのステップがある。
1.シナリオを作る
エンドユーザーにヒアリングしながら，いきなりDFDを描こうとすると，なかなかまとまった図にならない。調査を担当したITエンジニアの思い描いた場面と，ヒアリングされたエンドユーザーの思い描いた場面が微妙に異なることが多いため，うまくコミュニケーションをとれなくなることもある。そこで，「シナリオ」を作ることから始めるとよい。シナリオとは，業務でよくあるケースを文章で具体的に記述したものである。あまり汎用化しないで，いかにもありそうな具体的な場面を設定するのがポイントだ（図2）。
 |
| 図2●シナリオの例 |
シナリオを書くことによって，双方が同じ場面を想定してコミュニケーションができるようになり，通常業務の流れなのかどうか，どの程度例外的な処理が表現されているのか，などエンドユーザーとの間で（ヒアリングの）前提条件を共有できる。
2.データの発生と利用を把握する
DFDは，データの流れに着目することで業務の全容を把握する図である。そこで，いつどこでデータが発生するか，どこで利用されるかを先に把握すると描きやすい。
図2のシナリオを例に取ると，データの発生は受注センターが顧客から注文を受けて見積もりを回答したところと，メーカーから商品を受け入れて入庫するところである。データの利用は，物流センターに出荷指示をして業務サイクルが終わるところである。
