宮崎肇之
日立製作所 情報・通信グループ プロジェクトマネジメント統括推進本部

 画面は,システムの利用者が直接触れる部分。設計書のレビューに,利用者自身が参加することも多い。そのため他の設計書に比べて,利用者への配慮が特に必要となる。

 図2に画面設計で作成する成果物と,その関係を示した。大きく五つのステップがあり,7種類の設計書を作成する。要件定義で作成した「アプリケーション機能一覧」「非機能要件一覧」「制約条件一覧」「代表画面ラフスケッチ」を事前に用意しておく。図3が記述のポイントなので,これと照らし合わせて読んでほしい。

図2●画面設計の成果物とその関係<br>個々の画面の構造(画面レイアウトと入出力項目)を決定する「単一画面設計」と,画面間の関係を決定する「画面遷移設計」,画面遷移の役割を決定する「アクション設計」を実施。画面設計を円滑に進めるための統制・管理も必要となる
図2●画面設計の成果物とその関係
個々の画面の構造(画面レイアウトと入出力項目)を決定する「単一画面設計」と,画面間の関係を決定する「画面遷移設計」,画面遷移の役割を決定する「アクション設計」を実施。画面設計を円滑に進めるための統制・管理も必要となる
[画像のクリックで拡大表示]
図3●画面設計で作成する設計書の例と記述のポイント
図3●画面設計で作成する設計書の例と記述のポイント
[画像のクリックで拡大表示]

画面遷移は左上から右下へ

 いきなり画面の設計を始める人がいるが,それでは後で混乱する。まずやるべきは,画面のデザインと操作性にかかわる共通事項や制約条件を「画面設計基準」としてまとめることである((1)設計基準作成)。早い段階でルールを確立しておけば,メンバー全員が共通認識を持って設計に臨める。画面設計基準に従って,(2)単一画面設計→(3)画面遷移設計→(4)アクション設計を実施する。

 単一画面設計では,一つひとつの画面の内容を明確にする。「画面レイアウト」で画面の視覚的(物理的)な構造を示し,「入出力項目」で内部的(論理的)な構造を表す。記述のポイントは,仕様変更が入りにくい画面を先に設計することだ。確かな画面を一つ作り上げれば,それを手本にして他の設計を円滑に進められる。ここでは,代表画面ラフスケッチを使うとよい。代表画面ラフスケッチとは,要件定義で作成した基本画面のサンプルである。既にユーザーと合意が取れているので,大きな仕様変更も入りにくい。

 (3)画面遷移設計では,アプリケーション機能一覧に記述された業務を実現する「画面遷移」を明らかにする。画面遷移とは「画面の操作によって,どの画面に表示が切り替わるか」を矢印(遷移矢線)で示したもの。矢印が入り組むと混乱するので,矢印は左上から右下に流れるように書くとよい。

 画面遷移ではさらに,個々の画面と,それらの内容を定義した画面レイアウトおよび入出力項目の対応関係も明確にする。画面遷移を作成する段階で,すべての画面レイアウトと入出力項目があるとは限らない。画面遷移を作成している途中で対応関係が崩れないよう,識別番号などで対応付ける。

 遷移矢線には説明を付ける。これをアクションと呼ぶ。(4)アクション設計では,操作するデータ,処理内容,役割を終えたときの遷移先画面を「アクション仕様」として書く。

 アクションには正常系だけでなく,エラー処理も記述する。ユーザーが誤った操作をしたときにどんな応答を画面に返すかを,ここで明らかにする。この情報はテストにおけるテストケースにもなる。異常系を含めて考えられるパターンをすべて洗い出し,アクション仕様に記述しよう。

 (2)~(4)の結果を受けて随時「画面一覧」や「アクション一覧」を見直す((5)一覧管理)。画面やアクションを一覧化することで,抜けや漏れを確認できる。属性や名称を付ける際の参考にもなるはずだ。