今回は、設計 DFD の作成の概要についてです。
今回のまとめ
設計 DFD のおおまかな作成プロセス：
- 要求 DFD のコンテキストダイアグラムを設計 DFD のコンテキストダイアグラムとして引き写す
- コンテキストダイアグラムを始点として設計 DFD の各階層を作成していく（要求 DFD の各階層を参考にするのはアリ）
- 新規要素技術等の検証含め、必要に応じ実現可能性と実用性の検討のために試作を作成
- 試作結果を分析評価し、修正点があれば修正し（2 に戻る）、問題が無ければ設計 DFD の作成は終了
以下長い解説というか戯言
設計 DFD は、設計プロセス中もしくは設計プロセスの結果得られる DFD です。設計プロセスへの入力物としてはいろいろありますが要求分析プロセスで要求 DFD が作成されているなら、これのコンテキストダイアグラムはそのまま設計 DFD のコンテキストダイアグラムとして引き写されます。そして、以後適切な変更管理を経ずに、このコンテキストダイアグラムを変更することはありません。
この設計 DFD のコンテキストダイアグラムを変更するということは、要求 DFD と根底（コンテキスト）から違うものを作るということですから、本来要求分析結果の変更を伴います。
適切なエンジニアリングプロセスが存在するなら、要求の変更に相当することですから、変更管理プロセスに係わる話になります。
話が少し逸れましたが、設計 DFD の特徴は、
- 表現されたものが実現可能性があること
- 実現されたものが実用上使える可能性があること
の二点で要求 DFD と異なります。もっとも要求 DFD でも要求分析の後半で実現可能性検討などを行っているはずなので、このあたりの違いの線引きはあいまいです。
最終的な設計 DFD は、実現可能性の検討の上で、それを実現したら実用上使えるかどうかを検討し、さらに実現するためのコストと照らし合わせて、そもそもの要望（要求）に応えられるかの検討を経たものです。
「最終的な」という言葉を太字・下線付きにしているのは、上記の検討過程中の設計 DFD もあるからです。実現可能性にしても実用性にしても（作成のコストもですが）、モノができていない時点では可能性にすぎないので、いくばくかの「できない可能性」もあるわけです。
設計というプロセスは、この「できない可能性」を減らすプロセスとも言えます。
実際に手間隙が掛かり、お金も掛かってしまう、実際のモノの製作（実装、コーディング・・・）に掛かる前に、より抽象度が高く、変更容易なモデル上での対象物の表現（設計モデル）を操作することを以て低コスト、短リードタイムで「可能性」を高めるプロセスです。
「実際のモノの製作（実装、コーディング・・・）に掛かる前に」とは書きましたが、設計の過程での試作はあります。よほど手馴れた（ほとんどルーチンワークに近い、定数の変更程度の設計作業で終わる）モノを対象にしている場合でも無い限り、なんらかの試作は必須です。
全体の大まかなフローの試作や、モジュール間の連携の確認のための試作、各モジュールの要素技術の確認のための試作など、いろいろなレベルで試作が行われ、ふるいにかけられた設計モデルが生き残って最終的な設計モデルが出来上がります。
不幸にしてふるいにかけたらどうやっても「できない」モデルというのもありえて、この場合は要求に戻って変更を掛けるか、それでも「できない」場合はご破算にするしかないわけです。
ある程度の規模の対象に対しては設計に試作が大概伴うのは推測できることだと思います。これに対し、設計中にコードを書くのを禁止するのは「試作を禁止」する行為と等しくなりますから、試作を設計プロセスから分離したエンジニアリングプロセスでもない限り、設計プロセスが満足に機能しなくなります。本コードを書くのを禁止するのは、まだ分かりますけれどね。
モノとしての見かけ（表現形式）は、要求 DFD も設計 DFD も一緒です。ただその存在意義、目的が若干異なっているため、表現が異なっている。
最終の要求 DFD や最初期の設計 DFD は、ちょうどソースコードにおいてコンパイルは無事通るコードみたいなものです。ある程度の実現可能性は確保されて（シンタックスエラーが無い）いるかもしれないけれど、ちゃんと動かない（バグがあるとか期待した動作をしないとか、死ぬほど遅いとか・・・）コードと一緒。そういうコードでもたまたまちゃんと動くこともないわけじゃありませんが・・・
ちなみにソースコードは厳密に解釈するなら設計の最終成果物であって、実装されたものではありません。ただ、世間一般で昔からソースコードを書くコーディングフェーズを実装とか言っていたのが引き継がれ、いまだにソースコードは実装物であるかのように思われ、言われることが多いのです。
でも実際に最終的に欲しいものは実行コードであって、それはソースコードをコンパイルしてリンカーでライブラリなどと結合するビルドフェーズを経て得られるものです。で、このビルドフェーズは現在多くの場合自動化され、コンピューター上で処理されてしまいます。なのでほとんど人の関与する作業じゃなくなっていますが、プロセスとしては存在するし、大昔は人が手で行っていた部分でもあるわけです。この作業を本来は実装と呼ぶべきでしょうけれど、この作業は現在あまりにも人手を介さないために実装フェーズのコストが異常に低下しているように見えてしまいます。ここを実装と称すると下手したら設計半年、実装３分なんてことが平気で起こる。
でもそれでなにか都合が悪いのでしょうかね？言葉尻のことだけといえば言えますが、若干気にかかるところです。おそらくですが、多くの場合でコーディング、デバッグのプロセスが結構お金＝工数が掛かるから、これを他のプロセスと区別したいような気分になって、まあ適当に「実装」と言っているような気もします。
もう一度書きますが、ソースコードは設計の最終成果物であって、作るモノの大半を書き記したものです（残りの一部はリンカーへの指示などビルディングの指示書：make コマンドであればメイクファイルの記載内容）。
ぶっちゃけてしまえば、エンジニアリング的にやる必要性が無く、説明責任もなく、要求仕様からぱっとソースコードが書けるなら、設計としてはソースコードを書いてしまっても良いでしょう。ただし、仕事として行うと多くの場合で何かあった際に（経験上何もなかったことは希少です）説明しないといけないので説明責任は生じてきたりするので、この場合はエンジニアリング的にやる必要性が無く、要求仕様から要求仕様を満たしていると説明可能ならばソースコードを直接書いてしまっても良いでしょう（関係者がそれを認めてくれる前提で）。
これらの場合については、設計 DFD は作成しなくても問題ないわけです。そもそもいわゆる構造化手法をとらないなら DFD は必要ないわけではありますが。