システム設計書の書き方とは｜設計書・仕様書の書き方を解説

要件定義によって、ユーザーの要求のどの範囲を、どのようにシステムで実現していくかを定義します。まずはユーザー部門から業務要件やシステム要件を引き出し、システムに実装するべき機能を整理します。次に、整理した内容をもとに「システム構成図」「業務フロー」「機能一覧」「画面・帳票イメージ」「機能概要」「非機能概要」「データストア一覧」などを作成し、開発スコープを確定させていきます。
要件定義書は、ユーザーが望んでいる機能や仕様などの概略をまとめたものであり、外部設計のインプットとなる成果物を作成する必要があります。なお、要件定義書はユーザーも確認するため、専門知識が無くても読めるように意識しましょう。
各成果物についての簡単な説明は以下のようになります。

システム構成図によって、システム開発対象の範囲（スコープ）とスコープ外とのインタフェースを明確にします。対象システムについては、サブシステムまたは業務単位の括りで連携が分かるようにします。
「システム化対象範囲」「データの流れ」「関連システム」「対象業務」などの関係性は、凡例を作成してわかりやすく表現しましょう。

業務フローには、対象の業務、処理、担当部署、処理手段（手作業、コンピュータ処理）等を記載します。システムによる処理だけでなく手作業も対象とし、手段に依存しない目的レベルの業務を明確にしましょう。機能グループ単位で記載し、フローの中でシステム化する範囲を明確にすることで、その位置づけが明確になり、システム化する処理内容を共有することができます。
業務フローによって、ユーザーと開発者は開発対象システムの範囲とその構成要素（システム化業務）の名前、種別、ボリュームなどを合意できます。特に、ユーザー間およびユーザーと開発者との間で、用語の違いによる認識齟齬を防止できる点が重要となります。

なお、業務フローは書き手によって表現方法がまちまちであり、読み手に正しく伝わらないことがあるため、システム概要図と同様にわかりやすい凡例を用意するようにしましょう。近年では、自由形式の業務フローを使用するのではなく、誰が読んでも同じ意味として伝わるよう、国際標準（ISO19510）のビジネスプロセス・モデルと表記法に則った「BPMN（Business Process Model and Notation）」を用いるケースも増えてきているようです。

システム化業務を整理してその全体像を明確にし、業務と対応づけてシステム化業務を一覧化します。
機能一覧には、以下のレベル１～5の各項目を記載します。
・レベル１：システム
・レベル２：サブシステム
・レベル３：業務単位
・レベル４：機能グループ単位
・レベル５：画面・帳票単位

機能の使い方をすべて記載し、処理の流れを表現します。業務フローで表現できている箇所は省略してもいいでしょう。
概略図を用いて、システムによって自動化される業務の処理の流れや、その処理で作成される成果物を記号で記載したり、機能ごとの特筆すべき内容は特記事項として記載しましょう。

業務実現のための機能要件以外の要件を「非機能要件」といいます。システム基盤に関する非機能要求を明確化し、ユーザーとの認識を共有化することで、適切な情報システムを構築し、安定的なサービスを提供できるようにします。
非機能要件には「可用性」「性能」「拡張性」「運用」「保守性」「セキュリティ」など様々なものがあります。案件ごとに一から考えるのではなく、標準的なテンプレートを用意しておくと良いでしょう。

個々の画面・帳票の見栄えと操作が視覚的・直感的にわかるようにし、ユーザーへの見え方（デザイン・イメージ）を表現します。また、画面に関しては操作方法を画面部品（ボタン、入力出力項目など）で表現します。
見栄えに関しては、以下のことを意識しましょう。

・単票／一覧形式が判断ができること
・ヘッダー／明細が判断ができること
・重要な項目（キー項目など）が記載されていること
・操作の分かるボタン名称であること（登録、検索、変更、削除など）

実業務の管理対象や業務ルール等を分析し、受注、顧客、商品といった業務を構成する「もの」や「こと」で表現します。
データストアの概要と、利用用途、発生タイミングやライフサイクル等を記載し、業務で扱うデータの意味が分かるよう表現しましょう。

要件定義で定められた要件を実現するため、システムに関連するハードウェアやソフトウェア、ネットワーク、外部I/Fなどを定義することを「方式設計」と呼びます。一般的には要件定義から基本設計工程にかけて実施されます。
方式設計が終わったら基盤の実装を行い、プロトタイプ開発を通して検証します。

方式設計では、要件定義書の内容をもとに「画面・帳票の標準化」「ＦＷ設計（オンライン・バッチ）」「共通部品設計」「障害設計」「リラン方式」「排他方法」「ハードやミドルウェア等のシステム基盤」「アプリケーション処理基盤」などを確定させます。
非機能要件と同じく、方式設計で設計すべき項目も多岐にわたるため、こちらも標準的なテンプレートを用意して進めると良いでしょう。
主な考慮点としては、以下のようなものが挙げられます。

・システム形式
・実行環境
・開発環境
・命名規則
・用語辞書
・区分定義
・システム権限
・アプリケーション配布
・複数言語対応

・開発標準
　‐システム基盤
　‐ユーザ認証
　‐システム日時
　‐文字コード
　‐例外処理
　‐ログ出力

‐データベース
　‐画面
　‐帳票
　‐バッチ
　‐ファイル出力標準

方式設計にて定義されたフレームワーク、共通部品等の実装を行います。

画面標準・帳票標準に準じたモックアップ、フレームワークの利用手順となるサンプルなどを作成して検証します。

基本設計は要件定義で定めた機能や仕様などを明確にするものであり、詳細設計工程のインプットとなるドキュメントを成果物として作成します。
各成果物の概要と、記載すべき定義内容としては以下のものが挙げられます。

システムで使用される「ドメイン」を定義します。ドメインによって共通の意味を持つデータ項目を一元化し、値の範囲や制約を定義します。

・ドメインID
・ドメイン名
・データ型（文字列、数値、日付等）
・桁数
・精度
・全角／半角
・必須
・デフォルト値
・フォーマット
・制約式
・コメント
・データベースタイプ（Oracle、SQL Server、PostgreSQL、MySQL等）
・物理データ型（※データベースタイプに沿ったデータ型）

要件定義で洗い出した、システムで使用される製品の種類やデータの状態といった、値と名称の組合せを定義します。

（例：「権限区分」0：管理者／1：閲覧者／2：更新者）
・区分定義ID
・区分定義名
・区分（値）
・名称
・コメント

要件定義で定義したデータストアを元に、テーブル構成や管理する項目を定義します。

【基本情報】
　・概要
　・特記事項
【項目定義】
　・テーブル項目ID
　・テーブル項目名
　・データ型
　・桁数
　・精度
　・制約（PKEY、NotNull等）
　・デフォルト値
【インデックス・制約】
　・インデックス・制約ID
　・インデックス・制約名
　・制約式

ER図には「IE記法」や「IDEF1X記法」などの表記法があるため、ルールに則って記載する必要があります。

テーブルと同様にファイルの定義も行います。

【基本情報】
　・概要
　・ファイル形式
　・特記事項
【項目定義】
　・ファイル項目ID
　・ファイル項目名
　・データ型
　・桁数
　・精度
　・デフォルト値
　・フォーマット
　・関連テーブル
　・関連テーブル項目

機能設計として、画面や帳票、バッチの設計などを行います。

【画面レイアウト】
　・画面イメージ
　・画面概要説明
　・特記事項
【画面項目定義】
　・画面項目ID
　・画面項目名
　・種別（ラベル、テキストボックス、ボタン等）
　・タブ順
　・データ型
　・桁数
　・表示／非表示
　・活性／非活性
　・必須
　・全角／半角
　・最小値／最大値
　・デフォルト値
　・フォーマット
　・関連テーブル
　・関連テーブル項目
　・コメント
【画面イベント】
　・イベント
　・処理
【帳票レイアウト】
　・帳票イメージ
　・タイトル
　・サイズ
　・方向（縦／横）
　・帳票概要説明
　・特記事項
【帳票項目定義】
　・帳票項目ID
　・帳票項目名
　・種別（ラベル、テキストフィールド、レコード等）
　・データ型
　・桁数
　・全角／半角
　・フォーマット
　・計算式
　・関連テーブル
　・関連テーブル項目
　・コメント
【バッチ処理フロー】
　・処理フロー
　・関連テーブルID
　・関連テーブル名
【問合せ】
　・問合せID
　・問合せ名
　・コメント
　・問合せ（SQL文）
【問合せ項目移送】
　・移送先
　・移送元
　・コメント
【起動パラメータ】
　・項目ID
　・項目名
　・データ型
　・デフォルト値
　・コメント
【更新項目】
　・更新項目ID
　・更新項目名
　・区分（追加／更新／削除）
　・コメント
　・更新テーブル名
　・更新テーブルID
　・テーブル別名
　・属性ID
　・属性名
　・更新内容
　・更新条件
【変数・定数】
　・項目ID
　・項目名
　・種別（変数／定数）
　・データ型
　・デフォルト値
　・コメント
【処理定義】
　・処理ID
　・処理名
　・処理概要
　【処理パラメータ / 戻り値】
　　‐項目ID、項目名
　　‐IN / OUT
　　‐データ型
　　‐必須
　　‐デフォルト値
　　‐関連テーブル
　　‐関連テーブル項目
　　‐コメント
　【処理変数・定数】
　　‐項目ID、項目名
　　‐種別（変数／定数）
　　‐データ型
　　‐デフォルト値
　　‐関連テーブル
　　‐関連テーブル項目
　　‐コメント
　・処理詳細
【ライブラリ】
　ライブラリの概念がない環境の場合は記載不要。
　・概要
　・特記事項
　・関数ID／クラスID
　・関数名／クラス名
　・種別（関数／クラス）
　・コメント
【クラス定義】
　クラス毎に以下の項目を記載する。
　・クラスID
　・クラス名
　・継承元クラスID
　・継承元クラス名
　・概要
　・特記事項
　・変数／定数
　・処理

システムで出力するメッセージ内容を記載します。メッセージ内容については、発生した事象と対処方法を明確にし、システム全体で統一性のあるメッセージ設計を行う必要があります。

画面間の遷移や帳票の呼び出しなどを画面遷移図に記載し、流れを明確にします。

・画面遷移図
・概要
・特記事項

要件定義で洗い出しを行った、システム中で使用するデータに対して、照会や更新の権限の管理方法を定義します。

外部システムとのインターフェースで連携するファイル、データベースなど方式、項目やサイクルを定義します。

【インターフェース定義】
　・概要
　・接続方向（送信／受信／送受信）
　・連携先システム
　・作成者
　・作成タイミング（日時、週次、月次等）
　・削除者
　・削除タイミング
　・文字コード
　・作成場所
　・エラー時の取扱
　・ファイル形式（CSV、JSON、タブ区切り、XML、固定長等）
　・区切り文字
　・囲い文字
　・改行コード
　・ヘッダ行有無
【項目定義】
　・項目ID
　・項目名
　・データ型
　・桁数
　・精度
　・デフォルト値
　・フォーマット
　・関連テーブル
　・関連テーブル項目

各定義に対して、それぞれ一覧を作成します。

【テーブル定義一覧】
　・テーブル名
　・テーブルID
　・概要
　・保存期間
　・最大件数
【ファイル定義一覧】
　・ファイル定義名
　・ファイル定義ID
　・概要
　・件数
　・保存期間
【画面一覧】
　・画面ID
　・画面名
　・概要
【帳票一覧】
　・帳票ID
　・帳票名
　・概要
【バッチ一覧】
　・バッチID
　・バッチ名
　・概要
【メッセージ一覧】
　・言語区分（日本語、英語、等）
　・メッセージID
　・種別（E：Error、W：Warning、Q：Question、I：Information等）
　・メッセージ
　・バインド変数
【インターフェース一覧】
　・ファイルID
　・ファイル名
　・作成タイミング
　・作成者
　・連携先システム
　・概要

詳細設計工程では、基本設計書をさらに詳細化して、製造工程のインプットとなるドキュメントを成果物として作成します。
基本設計工程は画面・帳票のようなユーザーインターフェース部分など、ユーザーの目に触れる範囲が主な対象となるため、ユーザーが理解できる粒度の設計が行われますが、詳細設計工程はユーザーの目に触れない範囲が対象となります。
「クラス図」や「シーケンス図」など、詳細設計工程で新たな詳細資料を起こす場合もありますが、基本設計と全く異なる設計書を新規で作成するというより、ユーザー向けだった基本設計書を開発者向けに詳細化して詳細設計書を作成するというのが、詳細設計工程のメイン作業になってきます。

ご覧いただいた通り、工程ごとに作成すべき設計書、設計書内に記載すべき定義にはとても多くの種類が存在します。必要な情報を漏れなく、且つ一定のルールに沿ったフォーマットで作成するには、手作業ではどうしても限界があるはずです。
システム設計ツール「Verasym System Designer（VSSD）」は、システム設計に必要な20種類以上の設計書を統一されたフォーマットで作成でき、設計変更時の影響参照や変更反映を簡単に行えるなど、システム設計を便利にする機能が数多く搭載されています。
設計工程の中で最も労力を要するのは、当然のことですが「設計」を行うことです。作成すべき設計書の選定や定義すべき項目の列挙といった本筋ではない作業に時間を割くのではなく、ツールにできることはツールに任せることで、もっとも重要な設計作業に注力できる環境を整えてはいかがでしょうか。