この記事で何が分かるか

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

要件定義編

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

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

例：

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

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

前提：

参考：システム担当者とデザイン担当者のスコープ
システム担当者	デザイン担当者
画面項目、ボタン、リンク、画面遷移、配置	色、画像、フォント、配置

以下を作成すること

何のためかというと、画面間でデザインが一貫している方がシステムを使いやすいから、統一のためのポリシーを定義する。
画面設計の際に置いておく前提条件を定義する
- ブラウザ
- ディスプレイの解像度
- 画面レイアウト幅
- 文字コード
画面レイアウトパターンを定義する
- サイドメニューはどう表示するか、パンくずリストは表示するか、メインメニューはどこかなど。(Qiitaだとヘッダが最上部、メインメニューがその下にある)
機能ごとの画面のパターンを定義する
- 検索用の画面、登録・更新用の画面、削除用の画面などごとに決める。
- LINEだと個チャでもグルチャでも同じ場所に入力バーはある。
項目のパターンを定義する
- 入力項目、表示項目の形式を定義する。
  例：電話番号は3つの入力項目に分割するか、1つにするか。

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

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

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

4. HTTPセッションの設計

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

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