3．メニュー体系図の作成

全体の画面構成・遷移をドキュメント化する。
トップページからの展開図、またはフロー形式で表す。

主な役割を示すような画面名を付ける。

この作業の前段階として以下の作業を行い、また、作業に必要な情報として以下のものや情報等を用意しておく。

この前の作業	事前情報、他
・メニュー体系検討、調整	・メニュー体系案・（作成に使う）ツールの知識

図は、画面遷移が上から下へ、または左から右へ進むようにする。  
（紙の上側、または左側に、システムのトップ画面が配置される形。）

矢印で、画面の遷移を表す。

画面の切り替え方法・表示方法が混在する場合は、矢印や枠の書き方を工夫するなど、分かりやすくする。

紙１枚におさめるのが一番分かりやすいが、システムによっては画面／帳票数がかなり多くなることもある。  
おさまらない場合は、（複雑になりそうな）サブ機能ごと別紙に展開する書き方もある。

画面／帳票名だけで「それが何をする画面／帳票か」が分かる場合もあるが、  
必要に応じて、その画面／帳票で扱う主なデータ項目や文言なども合わせて書くと分かりやすい。

この作業で以下の成果物を出す。または完成イメージの状態にする。それをこの後の作業につなげる。

成果物、完成イメージ、他	この後の作業
・メニュー体系図	・共通デザイン定義・画面設計

システム全体を表すものなので、ユーザも見るし、これから設計・製造を担当する技術者も見る。

ドキュメントは、ぱっと見て全体を理解できるようにする。

（どこからでも色々な画面にジャンプして何でもできる、など）矢印が四方八方に入り乱れたりすると、便利かもしれないが、わけが分からなくなることも多い。
図として煩雑なだけでなく、操作手順が混乱したり実装が難しくなるなど、操作面・技術的実装面での問題も出る。
紙の図としてもシステムとしても、分かりやすいものを目指す。

メニュー体系・画面遷移を一度完成させても、この後の設計作業（共通デザイン定義、各画面設計など）を進めていくと、  
構成や遷移に変更・追加が出ることも多い。

一度ドキュメント化したものに変更が入った場合は、必ずドキュメントも更新する。
最新の状態に更新しないまま放っておくと、システムとドキュメントとで違いが出たり、ドキュメントの各箇所で違いが出たりする。
後で見返した時、（どれが正しいのか判断できずに）わけが分からなくなる。
詳細部分の検討を進めた上での変更・追加は、ある程度やむを得ない（ほんとうは、ないのが理想だが、なかなかそうもいかない）。

results matching ""