##要件定義書
※背景や理由を記載しておくと後々議事録を追わなくて済む
1.業務要件
1-1.システムの概要
　※例）ファッション系の通販サイト。海外販売も行う。
1-2.ユースケース
　※使用者、管理者などで分けて。ユースケース図などを使って。
　　例）使用者は会員登録・注文ができる。管理者は商品ページの編集ができる。
2.機能概要
2-1.アプリの種類
　※例）WEBアプリケーションのみ。アプリは不要など。不要なものも明記。
2-2.機能一覧
　※使用者、管理者などを機能（画面）単位で一覧にする。必須かどうかの欄も
　　例）マイページ（ログイン・会員登録内容変更・注文履歴確認）
2-3.外部システム連携
　※例）外部の決済APIを使用するなど
3.非機能要件
3-1.インフラ構成
　※例）EC2XXX台、S3など。
3-2.キャパシティプランニング
　※例）想定使用者数など。
3-3.性能要件
　※例）画面表示は何秒以内など
3-4.可用性
3-5.死活監視
3-6.セキュリティ要件
　※暗号化するなど
3-7.バックアップ計画

##基本設計書（外部設計書）
※顧客向けの資料なので、理解できる単語で説明。
　顧客と認識合わせできる最終資料。
　背景や理由を記載しておくと後々議事録を追わなくて済む
1.目次
2.機能一覧
　※要件定義での機能一覧に加えて裏側で必要なバッチ機能なども追加。
　　CRUDを記載したりする。
3.システム構成
　※例）AWSの構成図など。
　　draw.ioなどの作成ツールがある。
　　▼参考
　　https://ferret-plus.com/8408
4,画面設計
　※画面と要素。どのボタンでどこに遷移するなど。
　　prottのようなモックアップツールを使うのもよい。紙芝居なので顧客のイメージがわきやすい。
　　https://prottapp.com/ja/
5.帳票設計
　※印刷物の画面設計。メール文面や、出力ファイルなど、そういうものも項目を切り出して記載したらいい。
6.バッチ設計
　※日次などのスケジュール実行プログラム
　※例）クレジットカード月額課金バッチなど。目的。トリガー。処理フロー。
　　顧客に分かるレベルで。
7.データ移行設計
　※旧⇒新のデータ移行が必要な場合
　　テーブルのデータのマッピングなどを記載。
　　また、旧⇒新の場合は、機能一覧等に旧のこれが新のどれにかわるみたいなのを記載したほうが、
　　顧客はわかりやすい。廃止機能もわかりあとあとのもめごとがへる。

##詳細設計書（内部設計書）
※プログラマー向けの資料。

クラス図やシーケンス図など書き方はいろいろあるが、
正確に伝わるならなんでもよい。

##単体テスト仕様書
機能単位（関数単位や画面のパーツ単位）

##結合テスト仕様書
機能同士の組み合わせ
※例）マスメン登録してフロントを見ると、登録内容が表示されているなど

##総合テスト（システムテスト）
本番環境＋本番データ
全体をシナリオでテスト。
※例）ユーザーが会員登録して注文して注文履歴見る。
　　　月末にクレジットカードの引き落としが動くなど。

##その他参考
・設計書の項目など。
　https://pm-rasinban.com/