プロセス
プロセスはその名前のとおり、処理・手続きを表します。概要レベルのDFDにおいては、1つのプロセスの記号が複数の役割、機能を持った状態となりえます。これは構造化分析のプロセスにのっとり、段階的に詳細化していく中で分解されていくものです。
プロセスは、円形または楕円形で表現します。プロセスに対する入力を表すデータフロー、プロセスからの出力を表すデータフローのいずれか、あるいは両方を必ず持ちます。
入力を表すデータフローによる接続のないプロセスは、「無から何かを生み出している」ことになります。逆に、出力を表すデータフローの接続がないプロセスは、「何も生み出していない」ことになります。このような図が描かれている場合、作成途中でない限り、何らかの課題が隠れていると考え、注視する必要があります。
図形の中には、そのプロセスを端的に表す名称を記入します。分析段階、論理設計段階では、より実世界に近い言葉で表現します。業務やサービスを表す言葉となるでしょう。とくにこの段階では「～する」という動詞で表すことが推奨されます。実装に近い段階では、機能名、プロシージャ／ファンクション名に置き換わることもありえます。
構造化分析に基づく詳細化のステップを踏む中で、レベル間の関係をわかりやすくするために、プロセスにIDとなる数字をつけることが一般的です。このとき、番号体系は、ドットが詳細レベルの階層を示すようにします。図のように、概要レベルで「1.集計レポートを作成する」とした場合、このプロセスの詳細は、「1.1」「1.2」のように、概要レベルのどのプロセスを分解詳細化したものかがわかるように対応づけます。
プロセスからプロセスへデータフローが直接接続されることについては、禁止されていません。トム・デマルコもその著書の中で多用している表現です。ただし、必ずプロセス以外の「外部エンティティ」や「データストア」を介して接続する図にした方が、表したい内容をより明確に表現できるでしょう。とくに、プロセスAからプロセスBに接続するような矢印を描くと、読み手は「プロセスコール」「プロセスの親子関係」のように読み取る可能性が高いです。そして、描いている技術者自身も、そのような表現をしたい欲求に駆られることがしばしばあります。しかし、DFDにおいては、プロセス間の呼び出しや親子関係を表現することはありません。
UMLのユースケース図における「ユースケース」を表す楕円と、ほぼ同等の意味を持つと考えてもよいですが、ユースケース図において「アクタ」との接続は「関連」を表すのみであり、入出力の向きや内容を示すものではないという違いに注意してください。また、UMLではユースケース同士の関係として「汎化（generalization）」「包含（include）」「拡張（extend）」を表現することがありますが、DFDのプロセスにおいてこのような表現をすることはありません。
プロセスは図解上、非常にシンプルな表現を用いていますが、情報量としては乏しく、その処理の具体的な内容を表現できません。そのため、この図解とは別に、各プロセスに対応する「ミニ仕様書」と呼ばれるドキュメントを書き起こし、処理詳細を記述することで補完します。UMLのユースケース図におけるユースケースの記号が、それ単体では極めて抽象度が高く、より具体的な情報を記述するために「ユースケースドキュメント」を記述するのと同様です。
ミニ仕様書
『構造化分析とシステム仕様』の中で、プロセス仕様を記述するドキュメントを「mini-spec」からとって訳したため、「ミニ仕様書」という用語が使われることが一般的です。
実際にはその仕様書の大きさを示すわけではなく、処理手順を表すフローチャートや処理条件を表すデシジョン・テーブルなど、プロセスの詳細を定義するうえで必要な情報を記載した付帯資料の呼称して使われており、本書もこれにならって「ミニ仕様書」という名称を使用しています。
