要件定義・外部(基本)設計・内部(詳細)設計の一部について知識整理

この記事で何が分かるか

以前、
ウォーターフォール型アプリ開発における設計の概要
という記事にて設計の概要を説明しました。

今回は各論として、
タイトルの通り、設計の成果物の内一部を扱っています。
それがどの成果物かについては、右手の目次をご覧ください。
それぞれの中身とその目的をまとめています。

要件定義編

外部設計での重要なインプットとなる
ユースケース分析と概念モデリングの概念を整理しました。

ユースケース分析

何のためのもの？

• 画面や外部システムI/Fなどの外部仕様を判断する際のインプット

これは何？

• システムに触れる人々のニーズに基づき、それに応じたシステムの振る舞いを表現したもの。
• 接続する外部システムに対して、それに応じたシステムの振る舞いを表現したもの。
• 例：リマインダーアプリのユースケース
  

-　ビジネスルール
業務システムなどの場合、企業がその業務を遂行するために従わねばならない独自のルールや制約

概念モデリング

これは何?

• ユースケースに登場した概念について、概念の名前、関連、関連の多重度を表現する。

例：

• ユースケースはシステムの時間順序に沿った振る舞いを表現する。それに対して概念モデリングはシステムの静的な&データ構造を表現する
• ユースケース記述、画面設計、外部システムI/Fに登場する概念は表現されていることが必要だろう
• 実際は画面設計などの時にモレている概念が発見され、概念モデリングが更新されることがある

何のためのもの?

• システム内で、概念構造/データ構造を適切に捉える。
  そして、それを表現する。
  このデータ構造に合わせてデータベースを設計する。それによりデータの重複を避けたり独立したデータを分離したりしやすくなる。(児玉, 2010)
• 概念モデリングはデータベース論理設計のインプットとなる

外部設計編

画面設計のみを扱います。

画面設計

前提：

• Webを使って画面を作成する場合のプロセスを扱います。
• 画面設計というとwebデザイナーも関与しますが、ここではシステム担当者のスコープの画面設計を扱います。

参考：システム担当者とデザイン担当者のスコープ

システム担当者	デザイン担当者
画面項目、ボタン、リンク、画面遷移、配置	色、画像、フォント、配置

これは何?

以下を作成すること

• UI設計ポリシー

• 画面遷移図

• 画面一覧

• 画面モックアップ

• 画面入力チェック仕様書

• 各種の設計の間の関係は以下の通り。
  矢印の根本の設計が、先端の設計にとってのインプット情報です。
  

UI設計ポリシー

• 何のためかというと、画面間でデザインが一貫している方がシステムを使いやすいから、統一のためのポリシーを定義する。

• 画面設計の際に置いておく前提条件を定義する

  • ブラウザ
  • ディスプレイの解像度
  • 画面レイアウト幅
  • 文字コード

• 画面レイアウトパターンを定義する

  • サイドメニューはどう表示するか、パンくずリストは表示するか、メインメニューはどこかなど。(Qiitaだとヘッダが最上部、メインメニューがその下にある)

• 機能ごとの画面のパターンを定義する

  • 検索用の画面、登録・更新用の画面、削除用の画面などごとに決める。
  • LINEだと個チャでもグルチャでも同じ場所に入力バーはある。

• 項目のパターンを定義する

  • 入力項目、表示項目の形式を定義する。
    例：電話番号は3つの入力項目に分割するか、1つにするか。

画面遷移図

• 何のためのもの？：
  • ユースケース記述を実現する画面と画面遷移を定義するため
  • ユーザビリティに良い画面遷移を定義するため
    (例えば下の病院の診察予約をするウェブページでは、確認画面から申し込み画面に戻れないという設計にすると困ることがあるでしょう)
    
• 画面遷移図は右側の図が一つの例

画面一覧

• これは何？：画面を一覧にまとめる。
• インプットは画面遷移図。そこに登場する画面を整理する。

画面モックアップ

• これは何？：具体的な画面のイメージ。入力しても動かないけど見た目はリアル.

• インプット：UI設計ポリシー、画面遷移図、概念モデリング

• 何のためのもの？：

  • 画面上の項目を特定する
  • それらの項目の配置を定義する
  • 想定している画面遷移が良いかを確認する
  • 画面イメージを確認する

• 余談：モックアップがないと、システムの表現が設計書にある文字列と図だけですが、画面のおかげで何を作ろうとしているのか想像しやすくなると感じます。

画面入力チェック仕様書

• これは何？：各入力項目に対してどのようなチェックを行うかを定義する
• インプット：画面モックアップ
• 例：入力する文字列の最大文字数、入力項目のデフォルト値、必須/任意入力の定義

内部設計編

画面プログラム設計のみ扱います。

画面プログラム設計

前提：Spring Bootを使用する。MVCモデルを用いる。

これは何？

1. 画面遷移図からControllerを抽出する。

2. それらのControllerで行う処理を設計する。
   設計するもの：

   • リクエストパラメーターのバリデーション
   • リクエストパラメーターの取得
   • ビジネスロジックの呼び出し
   • レスポンスへのデータ設定
   • 画面遷移
     

3. UI設計ポリシー、画面項目定義書から、画面間で共通の部品を設計する。
   例：共通ヘッダー、共通メニュー

4. HTTPセッションの設計

• インプット：画面遷移図、画面モックアップ、画面項目定義書

さいごに

設計について一部をまとめました。
なぜこれらの設計をピックアップしたかというと、自分の業務でよく読む設計書だからでした。
自分の業務について詳細はこちら：BAについての記事

見慣れた設計書たちでしたが、今回体系的な知識を学んだことで、
お互いの関係やそれぞれの役割に自覚的になりました。
今後の仕様の調査の時の判断に役立てて行けたらと思います。

参考資料

• 『はじめての設計をやり抜くための本 第2版』
• 児玉(2010) 情報システム設計における概念モデリング