基本設計書サンプル・書き方

基本設計は、顧客の要件を実現するためのシステム構成や機能を具体化する工程だ。

基本設計工程では、画面・帳票・テーブルなどの設計した後に「基本設計書」としてまとめるが、どのような資料を作るのか不安を感じるエンジニアも多いと思う。

そこで、今回は基本設計書の書き方を簡単に説明する。

はじめに

基本設計のことを「外部設計」と呼ぶ場合もあるが、当サイトでは「基本設計」に統一して記載している。

基本設計は、要件定義の結果を受けて、具体的なシステム構成や機能を設計する工程だ。

基本設計書には、下記の４つを検討のうえ成果物としてまとめる。
　・業務設計
　・システム方式設計
　・アプリケーション機能設計
　・非機能要件設計

要件定義書と同じく、企業によっては記載内容やテンプレートを整備している企業もあるので、まずは自社のルールを確認することをお勧めする。

※当サイトでは、情報処理推進機構（以下、IPA）や行政機関の資料を参考に記載している。

基本設計書のサンプル

私が参考にした基本設計書のサンプルを紹介する。

IPA『機能要件の合意形成ガイド』

農林水産省『システム構成図』

国立研究開発法人『見守り情報管理システム 基本設計書』

国立研究開発法人『eコミマップ 基本設計書』

上記の中でも、IPAの資料は、具体的な書き方や検討のコツも紹介されているので、特に参考になると思う。

基本設計書の目次（成果物一覧）

それでは、ここからは基本設計書の書き方を説明していく。

プロジェクトの特性にもよるが、基本設計書には下記の内容を記載する。

これらを簡単に説明していく。

業務設計

業務設計は下記５つの成果物を整理する。

多くの資料は、要件定義でまとめているはずなので、基本設計で新たに作成する資料は少ない。

（要件定義での検討が不足していると、基本設計で苦労することになる）

システム化の背景・目的

システム化が必要な背景と目的を説明した資料。

要件定義書にもまとめられているはずなので、基本設計で新しく記載する必要はないだろう。

システム化の対象範囲

プロジェクトのシステム化の対象範囲を記載する。

後述の「業務機能構成表」や「アプリケーション機能構成図」に記載する場合もある。

こちらも要件定義書から転記すれば良い。

システム化業務一覧

出典：IPA『ユーザのための要件定義ガイド』,p.109

業務機能構成表に対して、システム化対象業務を選定した資料。

要件定義書から転記する。

上記のサンプルのように、業務機能構成表に「システム化対象」という区分を設ける場合が多い。

新業務フロー

出典：IPA『ユーザのための要件定義ガイド』,p.112

開発するシステムを適用し、新しい業務の流れを図解した資料。

要件定義書から転記することになるが、アプリケーション機能を具体化していく中で修正が必要になる場合もある。

システム化業務説明

出典：IPA『機能要件の合意形成ガイド～システム振舞い編～』,p.28

システム化の業務について、詳細な内容を記載した資料。（”ユースケースシナリオ“という呼び方をした方がいいかもしれない）

利用者のアクションに対して、システムがどうアクションをするのかを記載する。

基本的な流れ「基本シナリオ」、基本外の流れ「代替シナリオ」に分けて整理していくと良い。

代替はシステム異常とは違うので注意。

下記のように、基本的な流れでは無いものの、一般的に起こる可能性のあるシナリオのことだ。

システム方式設計

システム方式設計では、下記の成果物を整理する。

性能や信頼性などの非機能要件をもとに，システム全体の構成を検討する作業だ。

システム構成は、要件定義段階でほぼ決定しているはずなので、設計の結果を反映させることが主な作業となる。

ハードウェア構成図

出典：農林水産省『ハードウェア構成図』

今回のシステムを実現するうえでのハードウェア構成を明確にする資料。

要件定義のハードウェア要件をもとに、基本設計で検討した内容を反映させる。

ソフトウェア構成図

出典：農林水産省『ネットワーク構成図』

今回のシステムを実現するうえでのソフトウェア構成を明確にする資料。

要件定義のソフトウェア要件をもとに、基本設計で検討した内容を反映させる。

ネットワーク構成図

出典：農林水産省『ネットワーク構成図』

今回のシステムを実現するうえでのネットワーク構成を明確にする資料。

要件定義のネットワーク要件をもとに、基本設計で検討した内容を反映させる。

アプリケーション機能構成図

出典：IPA『機能要件の合意形成ガイド～システム振舞い編～』,p.19

開発するシステム機能が階層的に分かる資料。

要件定義書から転記しつつ、基本設計の検討結果を反映させよう。

アプリケーション機能設計

アプリケーション機能設計では下記の成果物を整理する。

基本設計のメインとなる作業だ。

要件定義のざっくりとした内容を元に、システムを実装できるレベルまで具体的に記載しよう。

画面一覧

出典：IPA『機能要件の合意形成ガイド～画面編～』,p.17

プロジェクトで開発する画面を一覧にまとめた資料。

要件定義書から転記しつつ、基本設計の検討結果を反映させよう。

画面遷移図

出典：IPA『機能要件の合意形成ガイド～画面編～』,p.22

画面の流れが分かる資料。

要件定義書から転記しつつ、基本設計の検討結果を反映させよう。

画面レイアウト

出典：IPA『機能要件の合意形成ガイド～画面編～』,p.26

画面の具体的なイメージを明確にする資料。

要件定義書から転記しつつ、基本設計の検討結果を反映させよう。

画面入出力項目一覧

出典：IPA『機能要件の合意形成ガイド～画面編～』,p.30

画面の入出力項目が具体的に分かる資料。

出力項目は、どのテーブルの、どの項目から値をセットするかまで記載が必要だ。

なお、入力項目でも、プルダウン（コンボボックス）のような選択項目の場合は、どこから値をセットするのか検討が必要となる。

画面アクション定義

出典：IPA『機能要件の合意形成ガイド～画面編～』,p.30

画面上の動作が具体的に分かる資料。

基本設計では、ユーザーがどのようなアクションをしたときに、システムがどのようなアクションを返すのかを具体的に記載する必要がある。

例えば、上記サンプルでは、ログインボタンが押下されたときに「UsernameとPasswordの入力チェック」とだけ書いているが、どのようなチェックをするかまで具体的に書く必要がある。

ちなみに、入力チェックをクライアント側に実装するのか、それともサーバー側で実装するのかは、次の工程である「詳細設計（内部設計とも言う）」にて検討する。

帳票一覧

出典：IPA『機能要件の合意形成ガイド～帳票編～』,p.21

プロジェクトで開発する帳票を一覧にまとめた資料。

要件定義書から転記しつつ、基本設計の検討結果を反映させよう。

帳票概要

出典：IPA『機能要件の合意形成ガイド～帳票編～』,p.25

帳票の出力場所や使い方を記載した資料。

要件定義書から転記しつつ、基本設計の検討結果を反映させよう。

・出力タイミング
・改ページ条件
・データ上の保管期間
など

帳票レイアウト

出典：IPA『機能要件の合意形成ガイド～帳票編～』,p.28

帳票の具体的なイメージを明確にする資料。

要件定義書から転記しつつ、基本設計の検討結果を反映させよう。

帳票出力項目一覧

出典：IPA『機能要件の合意形成ガイド～帳票編～』,p.31

帳票レイアウトを元に、印字する項目が具体的に分かる資料。

画面の出力項目と同じく、どのテーブルの、どの項目から値をセットするかまで記載が必要だ。

帳票編集定義

出典：IPA『機能要件の合意形成ガイド～帳票編～』,p.34

帳票に印字するデータの編集方法を記載した資料。

シンプルな帳票は「帳票出力項目一覧」で十分だが、複雑な編集方法を持つ帳票については、当資料を作成する。

バッチ処理一覧

出典：IPA『機能要件の合意形成ガイド～バッチ編～』,p.19

プロジェクトで開発するバッチ機能を一覧にまとめた資料。

要件定義書から転記しつつ、基本設計の検討結果を反映させよう。

バッチ処理フロー

出典：IPA『機能要件の合意形成ガイド～バッチ編～』,p.23

バッチ処理の流れが分かる資料。

業務部門の利用者にとっては理解しづらい資料であるものの、画面や帳票との関係が深いため、基本設計でまとめておくべき資料である。

バッチ処理定義

出典：IPA『機能要件の合意形成ガイド～バッチ編～』,p.27

バッチ処理の具体的な入出力と処理内容が分かる資料。

この資料も業務部門の利用者にとっては理解しづらい資料であるものの、基本設計で検討しておく資料だ。

テーブル関連図(ER図)

出典：IPA『機能要件の合意形成ガイド～データモデル編～』,p.16

今回開発するシステムで用いるテーブルの関係性が分かる資料。

要件定義では業務上の主要なテーブルのER図を作成するが、基本設計では、システムを実現する上で必要なテーブルを全て書き出す。

要件定義書に記載したテーブルはもちろんのこと、バッチ処理内で一時的に利用するテーブル（ワークテーブル）等の記載も書き出そう。

テーブル・ファイル一覧

出典：IPA『機能要件の合意形成ガイド～データモデル編～』,p.19

今回開発するシステムで用いるテーブルやファイルの一覧資料。

前述のER図に記載したテーブルを一覧にまとめるだけでなく、機能の入出力で用いるファイル（txtやcsv等）についても記載する。

テーブル・ファイル定義

出典：IPA『機能要件の合意形成ガイド～データモデル編～』,p.22

各テーブルやファイルの項目名・データ型・長さ等が分かる資料。

CRUD図

出典：IPA『ユーザのための要件定義ガイド』,p.140

各テーブルについて、どの機能で、作成・参照・更新・削除がされるかをまとめた資料。

上記図は、「テーブルと機能のCRUD図」だが、下記図のように「テーブル項目と機能とのCRUD図」を作成する場合もある。

出典：IPA『ユーザのための要件定義ガイド』,p.140

外部システム関連図

出典：IPA『機能要件の合意形成ガイド～外部インタフェース編～』,p.20

関連システムとのデータのやりとりを図解した資料。

外部インターフェース一覧

出典：IPA『機能要件の合意形成ガイド～外部インタフェース編～』,p.17

関連システムとやりとりするデータを一覧にまとめた資料。

外部インターフェース項目定義

出典：IPA『機能要件の合意形成ガイド～外部インタフェース編～』,p.23

関連システムとやりとりするデータについて、主要なデータ項目を一覧にまとめた資料。

外部インターフェース処理概要

出典：IPA『機能要件の合意形成ガイド～外部インタフェース編～』,p.26

外部システムとやりとりするデータについて、その方法を記載した資料。

システム間のデータ連携については、下記の記事が参考になる。

>> ＠IT『システム間連携のアーキテクチャ、4つの基本パターンと正しい適用のポイント徹底解説』

非機能要件設計

非機能要件設計では下記の成果物を整理する。

非機能要件設計の各資料には方針や考え方を記載し、具体的な設計内容は、アプリケーション機能や基盤設計の各資料に反映することとなる。

性能設計

要件定義の性能要件に対して、対応方針や評価方法を記載する。

信頼性設計

要件定義の可用性と完全性の要件に対して、対応方針を記載する。

拡張性設計

要件定義の拡張性要件に対して、対応方針を記載する。

セキュリティ設計

要件定義のセキュリティ要件に対して、対応方針を記載する。

・情報（データ）や情報システムへのアクセスを制限するために、利用者IDの管理（パスワードの管理など）を行う。

・重要な情報に対するアクセス権限の設定を行う。

・インターネット接続に関わる不正アクセス対策（ファイアウォール機能、パケットフィルタリング、ISP サービス 等）を行う。

・無線LANのセキュリティ対策（WPA2 の導入等）を行う

・ソフトウェアの選定や購入、情報システムの開発や保守に際して、情報セキュリティを前提とした管理を行う。

出典：IPA『中小企業における組織的な情報セキュリティ対策ガイドライン』,pp.7-8

テスト方針

要件定義のテスト要件に対して、テスト方針を記載する。

単体テスト・結合テスト・総合テスト・運用テストといった各テスト工程について、プロジェクトの特性に応じて、下記のような観点を記載する。

移行方針

要件定義の移行要件に対して、移行方針を記載する。

システム機能だけでなく、データ移行や新業務への移行等、プロジェクトの特性に応じて移行方法を記載する。

運用保守設計

要件定義では、定常運用・臨時運用・障害時運用における要件を記載したが、基本設計段階では、各要件を実現するに当たっての運用保守業務設計、および必要な環境や機能の設計を行う。

下記に具体的な検討内容例を紹介する。

運用保守業務に入る本番移行前〜フォロー期間にて詳細な内容を検討し、運用保守契約を締結することとなる。

さいごに

基本設計工程の成果物を紹介してきた。

最初に述べたように、作成する成果物やテンプレートや書き方は、企業の標準としてまとめられている場合もあるので確認してほしい。

また、過去案件の成果物を流用するのも良いだろう。

以上、参考になれば幸いだ。

要件定義工程の関連記事はこちら。

要件定義工程の成果物一覧

2019年6月4日

要件定義工程の進め方

2019年6月2日

【結論】要件定義の目的は「プロジェクトの失敗を減らすこと」

2019年6月2日

要件定義書サンプル・書き方

2019年6月2日

機能要件・非機能要件の書き方【サンプル有り】

2018年8月17日

参考文献

IPA『共通フレーム2013』

IPA『機能要件の合意形成ガイド』

IPA『中小企業における組織的な情報セキュリティ対策ガイドライン』

農林水産省『システム構成図』

国立研究開発法人『見守り情報管理システム 基本設計書』

国立研究開発法人『eコミマップ 基本設計書』

日経xTECH『今こそ基本設計のスキルを見直す』

日経xTECH『機能要件設計書だけで20種類』

＠IT『システム間連携のアーキテクチャ、4つの基本パターンと正しい適用のポイント徹底解説』