1.前回記事
前回記事はこちらです。
システム開発時の詳細設計書系ついて①（画面設計書について）
https://qiita.com/yu-F/items/1b7510d6f43707b09535
詳細設計書としての必要な資料一式について
① 画面設計書（画面のレイアウト＋部品の説明＋DBの付き合わせ）
② 画面に対してのビジネスルール
③ API設計書
④ OpenAPIを使用してのSwagger EditorのIF設計書
前回は、「 システム開発時の詳細設計書系ついて①（画面設計書について）について記事を書きました。今回は「② 画面に対してのビジネスルール」について書きます。
2.各資料の役割について（画面に対してのビジネスルール）
1. 処理一覧
「No」、「イベント名」、「処理概要」を連動させて書く。
→Noは、当イベントの項番を記載する。（上から１、２、３、・・・）
→イベント名は、基本的には①の画面設計書の（3.【イベント情報】イベント名）の内容を記載し、画面設計書のイベント名と連動させる。
→処理概要は、基本的には①の画面設計書の（3.【イベント情報】処理概要）の内容を記載し、画面設計書の処理概要と連動させる。気持ち的には①の画面設計書の処理概要よりは少し肉付けした内容で記載する。
例）「No」、「イベント名」、「処理概要」
→ No：２、
→ イベント名：検索ボタン押下時
→ 処理概要：検索条件の各値を取得し、パラメータとして、API「顧客情報検索」を呼出。
APIからの戻り件数0件の場合は、ヘッダーのみ表示する。
1件以上の場合は、ヘッダーとデータを表示する。
2. 処理詳細
(1. 処理一覧)のイベント名ごとに大分類の項番を分ける。
・上記の項番をさらに細分化していき、処理の概要を細分化していく。
・細分化時に、さすがにプログラムのステップごとに細分化はできないが、ある程度の最小の処理単位で分けていくことを意識する。ここで細分化していき、最終的には処理概要に記載した内容が実現できるようにすること。
※細分化していく際に、前半と後半で流れに矛盾がでないように気を付ける。
例）
2.2 検索ボタン押下時
2-2-1. バリデーションチェックとして、以下のチェックを行う。
①対象年月、対象週が必須で入力されていること。
②対象年月がYYYY/MM形式であること。
③対象週が数値かつ、1～5の数値のいずれかであること。
④顧客名が30桁以内であること。
※上記のチェック結果を画面上部に表示する。
2-2-2. API「顧客情報検索」を呼び出す（API情報は別ブック_API情報を参照）
2-2-3.【2-2-2】で取得した結果が存在する場合は、レスポンスの内容を対象週(FROM)～対象週(TO)とデータ部へ設定する。
2-2-4.【2-2-3】で取得した結果がない場合は、対象週(FROM)～対象週(TO)とヘッダーのみを表示させる。
2-2-5.【2-2-4】で取得した結果のうち、データが10件を超える場合は、最初の10件を表示させ、残りは10件ずつ別の領域に保管してページングリンクを表示させる。
３. 実例
以下、２を踏まえのフォーマットとなります。
次回、③ API設計書へ続く。。