概要
設計書関係についての知識がなく、どんな種類がありどんな内容なのかがわからなかった。
内容が分からないと書くことが出来ないため、概要だけでも簡単に理解をするために作成。
目次
- 提案書
- 要件定義書
- 外部設計書（基本設計）
- 内部設計書（詳細設計）
- プログラム設計書
- テスト仕様書
1．提案書
システムの提案を行う際に、クライアントに対して提出する書類が「提案書」です。
提案書を作成する最大の目的は、クライアントに提案を採用してもらいシステム開発の案件を受注すること。
また、システム開発に関する基本的な事項について、クライアントとの認識を一致させることも目的の1つです。
提案書の内容
- クライアントの現状・課題
- システム導入背景や目的、その効果について
- 実現の方針や方法
- システム導入の対象となる業務範囲
- 導入するシステムの構成や導入後の業務フロー
- 開発プロジェクトの進めかた
- 開発体制やスケジュール
- コスト見積もり
2．要件定義書
提案書に基づいて作成するクライアントと合意するための書類です。
合意書であるため、クライアントにも「どういったシステムなのか」を理解してもらわなければいけません。
IT分野にくわしくない人でも理解できるように、専門用語をできるだけ使わずに記載することが必要です。
要件定義書の内容
- システム化の対象となる業務
- システムを使った業務の全体像
- 「ハードウェア」「ソフトウェア」「ネットワーク」の構成
- システムを使った業務の流れ
- 業務を構成する作業の一覧や作業手順
- 業務を遂行するために要求される機能
- セキュリティを保護するための要求事項
- システムに要求される性能や品質
3．外部設計書（基本設計）
要件定義書を基盤にして作られた設計書。
ユーザー向けに、システムの機能や構造についてわかりやすく記述
しなければいけないのが特徴です。
外部設計書の内容
- システムで使われるデータの種類
- システムに入力されるデータと入力方法
- データの処理方法
- データの保管場所や保管されるデータ
項目
①システム構成仕様
-システム情報（名称・システムの目的・使用言語・DB・使用ツール・開発方法その他備考）
-稼働環境（稼働サーバー、稼働OS、稼働場所、監視、運用サイクル、バックアップ、クライアント環境、クライアント台数、その他備考）
②システム構成図
③業務フロー
④システムフロー（なくてもよい）
⑤機能一覧（機能名「大/中/小」、利用者、機能概要）
⑥画面遷移図（すべての画面を記載）
4．内部設計書**（詳細設計）**
外部設計書を基に作られた設計書。
設計者は内部設計書に基づいてプログラム設計を行う
ため、より詳細に作成されるのが特徴です。
内部設計書の内容
- ソフトウェアの動作や処理
- ソフトウェアの構造
- ソフトウェア間でのデータの受け渡し方法
項目
①機能概要（機能前提、処理フロー、データIO）
②画面設計（画面イメージ、名称、タイプ、桁数、文字種、I/O、非表示、活性、必須、初期値、フォーマット、備考）
③機能仕様（アプリ画面処理、クライアント処理、サーバー処理）
5．プログラム設計書
コーディングの基盤として作成する設計書です。
プログラム設計書の内容
- モジュールの処理内容や動作内容
- 入力データ、出力データ
- データ内容全般
プログラム設計書があることにより
①スムーズなプログラミング作業の実現
プログラム設計書を読み込むことで
- 着手前に完成後のシステムをイメージできる
- 作業手順や記述すべきコードをスムーズに理解できる
- 調査や調整が減りプログラミングに集中できる
- 情報共有・進捗状況の共有が容易となる
②エラーの防止
プログラム設計書が存在しない状態でプログラミングを行うと、プログラマ個人の裁量でコードを書く部分が発生し、設計者が意図しないコードや無駄なコードを書いてしまう可能性があります。
③保守管理の負担軽減
プログラム設計書があれば、システムの仕様やソースコードを瞬時に理解できるため、障害調査・障害対応もスムーズに行うことができます。
開発に携わったメンバーと、保守管理に携わるメンバーは一致しないことも多く、たとえ同一メンバーであったとしても、過去のシステムの仕様やソースコードはまず覚えていないでしょう。そのため、プログラム設計書が無いと、軽微な修正や些細な障害でも膨大な時間と労力が必要となる場合があります。
6．テスト仕様書
システムを実装した後にどのようなテストを行うかを記載した書類。
プログラミング設計書通りに実装したプログラムに問題がないかどうかを確認
するための仕様書です。