お題そのままです。
例えば、下のようなものは一見再帰を表現できそうですが、
本来の再帰呼び出しならデータA とデータA’ は同じもののはずですし、データA’ の遷移から戻るデータB に当たるものがありません。末尾再帰最適で一気にデータB の方へ遷移しているんですよと言うなら、データA’ のフローは不可解なので、データA との絡みも考えれば、データA’ のフローは無しにしてプロセスのミニスペックで説明した方がましでしょう。
あと余談ながらデータA の源泉とデータB の吸い込み先は同じプロセスにならないと再帰呼び出し的には気持ちが悪い。
こんなのであればまあ許容できそうですが、ここまでやってまで再帰呼び出しをDFDで表現する必要はなさそうで、やはりミニスペックで表せば良いように思えます。
ことに要求DFDでとなると、この辺のことはかなり実現方法に近くなってくるので、あまりこだわって描く必要は無いように思えてきます。
あと個人的には、要求DFDなどでは制御的な流れは表現しない方が分かりやすいし、設計の自由度も上がる気がするので、制御系プログラムが対象とか言う場合を除いて制御は表現しない方が良いでしょう。
じゃあ制御系プログラムではどうするのだ？というのは、そもそもDFDが使用表現形式として妥当かさえ疑問がある。
某講師はDFDに制御を描くなと言っていた。どうしてもと言うなら点線で区別してと。そうまでしても点線で重ねて描いたら見にくくなるから私は素直にあきらめる。決定表なんかを試してみてうまく行かぬならそんとき考える。
実際のところ、どこまでが制御的でどこからが制御的じゃないのかが判別難しいところです。
いわゆる関数呼び出しも手続き型プログラミング言語的か関数プログラミング言語的かで印象が異なり、多分にグレーゾーンが存在しそう。
とはいえ、厳密に考えていくと確かに再起呼び出しの構造は制御的ですから、DFD で表現しない方が良いですね。
逆説的ですが、DFD で表現しづらいものは制御的なものかもしれないと考え、DFD のレベルでは描かないという潔い方向の方が分かりやすいでしょうね。