木村さんが指南するDFDの上手な書き方

要求定義でDFDを利用する人は多いだろう。しかし，見よう見まねで書かれたDFDに出会うことも多く，業務の真の姿をとらえて構造化できていないケースも少なくない。 使えるDFDを書くにはどうしたらよいか。DFDの特徴に着目すると，上手な書き方が見えてくる。 「誰が」を記載しないこと DFDは，UMLのユースケース図と同様，対象となる業務の範囲を把握するのを主な目的として使われる図である。要求定義の初期段階で，システム化して解決したい問題領域を可視化することができる。要求定義でDFDをうまく書くには，DFDでは何が記述でき，何は記述されないのかをよく知っておくことが大切である。 ユースケース図と比較すると，DFDの特徴が浮かび上がってくる。（図1）の×印（図に記述しない対象）に注目してみよう。共通で×印が付いているのは「処理の順序やタイミング」だ。DFDとユースケース図は，これらが分からなくても

[Mikatsuki]

モデルの違い

[dekasasaki]

“DFDでは何が記述でき、何は記述されないのかをよく知っておくことが大切である。”たまにDFDで処理順序とか聞いてくる人がいるけど、困る。そういう図じゃない。

[chago]

データフロー図

[Chisei]

DFDの上手な書き方。

[yuchi]

どうしても、ヒアリング→UMLに落とすだけじゃ抜けるんだよね。文章でもかけるようにしないと。

[january]

アクティビティ図と比較すればいいのに

[arimaster]

DFDの書き方

[hurvinek]

「「シナリオ」を作ることから始めるとよい。シナリオとは，業務でよくあるケースを文章で具体的に記述したものである。」

[kura-2]

DFDとユースケースからファンクションポイントを見積もってる場合、DFDの良し悪しは見積もりに響きますねえ

[backbeat]

koko