「システム開発地図」で画面はどう設計する? 第5回:もう迷わないシステム開発(2/3 ページ)
システム開発を進める上での強力なトレーサビリティーツール「システム開発地図(System Development Map)」を解説。第5回は、システム要件定義における重要事項である画面設計について、システム開発地図に落とし込みながら進める方法を解説します。
画面一覧を作成する
ユースケース記述のアクターとシステムのやりとりの記述を基に、画面候補を抽出します。画面が抽出される典型的な記述例は以下のようなものです。
- 「アクターは、〜〜を入力する」
- 「アクターは、〜〜を指示する」
- 「システムは、アクターに〜〜」
- 「システムは、〜〜画面を表示する」
画面候補は、ロバストネス図のバウンダリーに対応するため、適宜整合性を取るようにロバストネス図も見直します。画面候補が出たら画面一覧に追記していきます。
画面イメージを作成する
入力項目、表示項目、ボタンなどを要素とする画面イメージを作成します。項目一覧などの補助資料を作成してもよいでしょう。
ユーザーインタフェース標準があれば、既存の画面モックツールやキュメントのテンプレートが利用できるでしょう。ない場合は、必要最小限の簡素な表現に留めましょう。
このフェーズでユーザーと合意すべきことは、「業務に必要な情報が足りているか」「どの項目が必須であるか」「どのような形式で表示・入力するのか」というところです(注4)。UI部品のスタイルなどに目が行ってしまって、議論が発散してしまい、要件定義が進まないとなると本末転倒です。スタイルも適用されていないモックで実施したいところです。
ここで表示したい項目がドメインモデルやエンティティモデルに現れているのか、確認が必要です。もしなければフィードバックします。
画面遷移モデルを作る
次に画面遷移モデルを作成します。画面イメージの遷移図として表現しても、UMLステートマシン図などで表現してもよいでしょう。
画面遷移なのか、ポップアップなのかで、業務効率が変わってきます。ポップアップなどはさまざまな画面から呼び出されるので、ステートマシン図では画面遷移と区別してノートなどで記すとすっきりします。
ユーザーインタフェース標準
ユーザーインタフェース標準は、設計者に対する指針となるとともに、アプリケーション開発者が使用する画面フレームワークの仕様の一部になります(注5)。特に大きいプロジェクトでは、画面設計の標準化とともに進め、設計者向けにガイドを提供するのが理想的です。
注4: 桁数やフォーマットなどは設計フェーズで「画面項目定義書」などの設計書で詳細化することが多いため、要件定義フェーズでは業務上のデータフローに注目して進めるとよいでしょう。
注5: 画面フレームワークの仕様としては、他に、画面遷移方式、画面間で保持すべき情報やその生存期間などがあります。
関連記事
- 「システム開発地図」でトレーサビリティーを導入しよう! 第1回
システム開発を進める上で強力なトレーサビリティーツールとなる「システム開発地図(System Development Map)」について解説します。第1回目は、システム開発にトレーサビリティーの導入が必要な背景やメリットを考察します。 - 第4回 フロー図で理解するセキュリティインシデントの対応
情報セキュリティにかかわるインシデントが起きれば、どうすればいいのだろうか。担当者や対応方法は決まっているだろうか? 今回はこの「インシデント対応」について考えてみたい。 - 「システム開発地図」の使い方と作り方 第3回
システム開発を進める上で強力なトレーサビリティーツールとなる「システム開発地図(System Development Map)」について解説。第3回は、地図の見方と、業務フローを記述する具体的な手順を解説します。 - ドメインモデル作成の5つの注意点 第4回
システム開発を進める上で強力なトレーサビリティーツールとなる「システム開発地図(System Development Map)」について解説。第4回は、概念モデル、用語集、ドメインモデルの話を中心に、システム開発地図の成果物間にあるフィードバック関係にフォーカスします。
Copyright © ITmedia, Inc. All Rights Reserved.