基本設計における成果物一覧と書き方(基本設計書サンプルあり)




基本設計書の書き方(サンプル付き)

基本設計は、顧客の要件を実現するための機能を具体化する工程だ。

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

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

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

基本設計の目的

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

要件定義では業務要件・機能要件・非機能要件について整理したが、基本設計では「機能要件」を中心に具体化していく。(業務要件や非機能要件を修正加筆することもある)

 

プロジェクトによっては要件定義の成果物が不十分あるいはほとんど無い状態で基本設計工程に入ることもある。そういう場合はプロジェクト終盤で大きな手戻りにならないように、基本設計工程でも要件定義の内容(業務要件や非機能要件)を確認した方がいいだろう。

基本設計書のサンプル

それでは、基本設計工程の最終的なアウトプットである「基本設計書」のサンプルを紹介する。

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

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

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

 

特に、情報処理推進機構(以下、IPA)の下記資料は、具体的な書き方や検討のコツも紹介されているので参考になると思う。

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

基本設計書の目次(成果物一覧)

ここからは基本設計書の書き方を解説していく。

ここで紹介するのは大規模システム開発もサポートできる手堅い資料であるため、人によっては資料の多さに驚くかもしれない。

システム開発の規模に比例して作成する資料は多くなるが、逆に規模が小さければ資料も少なくて良い。紹介する資料の中から必要なものを選んで作成すると良いだろう。

なお、ここで取り上げる資料はあくまでサンプルであるため、実際の業務ではあなたの部署の過去資料を参考にすることをお勧めする。

 

基本設計書としてまとめる資料は下記の通り。

基本設計書の目次

1.業務要件(※1)
 1-1.システム化の目的・背景・狙い
 1-2.ビジネスプロセス関連図
 1-3.業務機能構成表
 1-4.ビジネスプロセスフロー
 1-5.システム化業務フロー
 1-6.業務処理定義書

2.機能設計
 2-1.システム方式
  2-1-1.ハードウェア構成図
  2-1-2.ソフトウェア構成図
  2-1-3.ネットワーク構成図
  2-1-4.アプリケーション機能構成図
 2-2.画面設計
  2-2-1.画面一覧
  2-2-2.画面遷移図
  2-2-3.画面レイアウト
  2-2-4.画面入出力項目一覧
  2-2-5.画面アクション定義
 2-3.帳票設計
  2-3-1.帳票一覧
  2-3-2.帳票概要
  2-3-3.帳票レイアウト
  2-3-4.帳票出力項目一覧
  2-3-5.帳票編集定義
 2-4.バッチ設計
  2-4-1.バッチ処理一覧
  2-4-2.バッチ処理フロー
  2-4-3.バッチ処理定義
 2-5.テーブル・ファイル要件
  2-5-1.テーブル関連図
  2-5-2.テーブル・ファイル一覧
  2-5-3.テーブル・ファイル定義
  2-5-4.CRUD図
 2-6.外部インターフェース設計
  2-6-1.外部システム関連図
  2-6-2.外部インターフェース一覧
  2-6-3.外部インターフェース定義書
  2-6-4.外部インターフェース処理概要

3.非機能要件(※1)
 3-1.可用性
 3-2.性能・拡張性
 3-3.運用・保守性
 3-4.移行性
 3-5.セキュリティ
 3-6.システム環境・エコロジー

※1業務要件と非機能要件は、要件定義書が無い場合に基本設計工程にて整理する。要件定義書に書かれている場合は作成不要。

1.業務要件に関わる成果物

業務要件の認識に違いがあると、機能追加や修正の発生するリスクが高くなってしまうため、本来は要件定義工程で業務要件を整理することが望ましい。

設計を進めていく中で業務要件の修正加筆が発生することもあるが、そういう場合はユーザー企業とITベンダとの双方合意の元で、要件定義書を修正するのが正しい流れである。

 

一方で、業務要件が整理できていない場合は、基本設計工程で要件を確認しなければならないため見積りブレのリスクは高くなる。だが整理できていないものは仕方ないので基本設計工程からでも要件を整理したい。

業務要件は下記5つの資料でまとめられる。

1.業務要件
 1-1.システム化の背景・目的
 1-2.システム化の対象範囲
 1-3.システム化業務一覧
 1-4.新業務フロー
 1-5.システム化業務説明

これらの資料の書き方やサンプルについては、下記の要件定義の記事をご覧いただきたい。基本設計工程での説明は割愛させていただく。

>> 要件定義における成果物一覧と書き方 〜業務要件〜

 

2.機能設計に関わる成果物

基本設計の主な作業である機能設計。

要件定義書の機能要件を具体化していく作業のため、要件定義の機能要件と同じ資料が並ぶ。

2.機能設計
 2-1.システム方式設計
  2-1-1.ハードウェア構成図
  2-1-2.ソフトウェア構成図
  2-1-3.ネットワーク構成図
  2-1-4.アプリケーション機能構成図
 2-2.画面設計
  2-2-1.画面一覧
  2-2-2.画面遷移図
  2-2-3.画面レイアウト
  2-2-4.画面入出力項目一覧
  2-2-5.画面アクション定義
 2-3.帳票設計
  2-3-1.帳票一覧
  2-3-2.帳票概要
  2-3-3.帳票レイアウト
  2-3-4.帳票出力項目一覧
  2-3-5.帳票編集定義
 2-4.バッチ設計
  2-4-1.バッチ処理一覧
  2-4-2.バッチ処理フロー
  2-4-3.バッチ処理定義
 2-5.テーブル・ファイル要件
  2-5-1.テーブル関連図
  2-5-2.テーブル・ファイル一覧
  2-5-3.テーブル・ファイル定義
  2-5-4.CRUD図
 2-6.外部インターフェース設計
  2-6-1.外部システム関連図
  2-6-2.外部インターフェース一覧
  2-6-3.外部インターフェース定義書
  2-6-4.外部インターフェース処理概要

 

2-1.システム方式

システム方式設計はプラットフォーム設計とも呼ばれ、システムの稼働環境を中心に整理する。こちらの資料も見積りへの影響が大きいため、要件定義工程で整理すべき資料である。

2-1.システム方式
 2-1-1.ハードウェア構成図
 2-1-2.ソフトウェア構成図
 2-1-3.ネットワーク構成図
 2-1-4.アプリケーション機能構成図

もちろん要件定義工程で整理している場合は無駄に作成する必要は無いため作成は不要である。

システム方式の書き方やサンプルは要件定義の記事をご覧いただきたい。当記事では割愛させていただく。

>> 要件定義における成果物一覧と書き方〜システム方式〜

 

2-2.画面設計

画面一覧や画面遷移については、要件定義工程で整理したものから修正されることはあまり無い。(一覧や画面遷移が修正されると見積りへの影響が大きい)

画面レイアウトはより具体化し、画面入力項目一覧、画面アクション定義といった資料を基本設計工程にて新たに整理する。

2-2.画面設計
 2-2-1.画面一覧
 2-2-2.画面遷移図 ☆
 2-2-3.画面レイアウト ☆
 2-2-4.画面入出力項目一覧 ★
 2-2-5.画面アクション定義 ★

☆:基本設計工程で具体化する資料
★:基本設計工程で新規作成する資料

2-2-1.画面一覧

 

開発する画面の規模感が分かる資料。

基本設計工程で画面が追加や削減されることはあまり無いため、要件定義書の資料のままとなることが多い。

 

2-2-2.画面遷移図

 

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

要件定義では正常な画面遷移のみを記載するが、基本設計ではエラー時の遷移先などを細かく取り決めていくことになる。

 

2-2-3.画面レイアウト

 

画面のイメージを共有するための資料。

要件定義ではざっくりとした画面イメージで良かったが、基本設計では曖昧な部分がないように確実に決めていく。

 

2-2-4.画面入出力項目一覧

 

画面の入出力を明確にする資料。

項目毎に下記のような内容を整理する。

画面入出力項目で整理する内容
 入力制御:入力無効(disabled)制御
 表示桁数:表示桁数
 入力桁数:入力可能な最大桁数
 データ型:データ型を記述(文字列や数値)
 文字種 :全角または半角
 入力制約:値範囲や入力文字制約等
 初期表示:初期表示有無、表示値
 出力仕様:計算式、色装飾等
 必須入力:必須かどうか

 

2-2-5.画面アクション定義

 

画面操作におけるシステム動作を明確にする資料。

マウスイベントや入力チェック等の動作を決める。

画面アクションでよく使われるイベント
・要素がクリックされた時
・要素にマウスカーソルが乗った時
・要素からマウスカーソルが離れた時
・右クリックされた時
・ページ読み込みが完了した時

 

2-3.帳票設計

帳票設計として整理する資料は下記の5つ。
帳票一覧や帳票概要は要件定義で整理したものから大きな変更は無い。(要件定義で整理していなければ基本設計で整理したい)

基本設計では「レイアウト決定」、「出力項目一覧の整理」、「編集定義の決定」の3つが主な作業となる。

2-3.帳票設計
 2-3-1.帳票一覧
 2-3-2.帳票概要
 2-3-3.帳票レイアウト ☆
 2-3-4.帳票出力項目一覧 ★
 2-3-5.帳票編集定義 ★

☆:基本設計工程で具体化する資料
★:基本設計工程で新規作成する資料

2-3-1.帳票一覧

 

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

要件定義で一覧表を作っていれば基本設計では流用するだけだが、もし作っていなければこのタイミングでも一覧を整理しておきたい。

 

2-3-2.帳票概要

 

帳票の出力場所や業務上の用途が分かる資料。

こちらも要件定義工程で整理している資料だが、もし整理できていなければ基本設計工程で整理したい。

発行タイミングや発行量(ページ数)は、システム機能設計をするうえでも考慮すべきポイントになってくる。

 

2-3-3.帳票レイアウト

 

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

要件定義ではざっくりとしたイメージでも良かったが、基本設計では項目の位置を後述の「帳票出力項目一覧」と合うように決める必要がある。

 

2-3-4.帳票出力項目一覧

 

帳票に表示する項目の内容を具体的に述べた資料。

下記のような内容を項目毎に整理する。

フォント種類:印字される文字フォント種類(例:MSゴシック)
フォントサイズ:印字される文字フォントサイズ
文字揃え:文字の配置(例:左揃え、中央揃え、右揃え)
表示桁数:表示桁数(最大)
内部桁数:非表示部分を含めた総桁数
フォーマット:表示フォーマット(例:YYYY/MM/DD)
出力編集:出力ルール(例:計算方法等)

出力ルールが複雑な項目は後述の「帳票編集定義」に記載する。

 

2-3-5.帳票編集定義

 

帳票の編集方法を述べた資料。

改ページ:ページ替えを行うための条件

ヘッダー・フッター:ヘッダー・フッターの出力条件

項目編集:項目の編集ルール。テーブル項目を単純に表示する場合は前述の「帳票出力項目一覧」を見ればいいので、ここには項目一覧では書けない複雑なルールのある項目に限定して記載する。

 

2-4.バッチ設計

バッチ設計として整理するのは下記3つ。
バッチ処理一覧は要件定義で整理すべき資料だが、整理できていない場合は基本設計で一覧表にまとめたい。基本設計では「バッチ処理フロー」「バッチ処理定義」が主な作業となる。

2-4.バッチ設計
 2-4-1.バッチ処理一覧
 2-4-2.バッチ処理フロー ★
 2-4-3.バッチ処理定義 ★

★:基本設計工程で新規作成する資料

2-4-1.バッチ処理一覧

 

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

 

2-4-2.バッチ処理フロー

 

バッチ処理の流れにおける入力・処理機能・出力を整理した資料。

処理をどう分けるかを検討することになるが、下記のようにデータ抽出・加工・更新といったように機能を分けておくと、テストをする際にデータベースを都度戻さなくてよいので効率が良くなる。

① Aテーブルから単純にデータを抽出(テーブル更新無し)
② ①のデータ加工(テーブル更新無し)
③ ②のデータをBテーブルに更新

 

2-4-3.バッチ処理定義

 

バッチ処理フローの1つ1つの処理について、入力・処理・出力を整理した資料。

基本設計ではなく、詳細設計で作成する場合もある。

 

2-5.テーブル・ファイル設計

基本設計のテーブル・ファイル関連で作成する資料は下記の通り。

2-5.テーブル・ファイル設計
 2-5-1.テーブル関連図(ER図)
 2-5-2.テーブル・ファイル一覧
 2-5-3.テーブル・ファイル定義 ☆
 2-5-4.CRUD図 ★

☆:基本設計工程で具体化する資料
★:基本設計工程で新規作成する資料

要件定義で主要なテーブルを整理したER図や一覧資料については、設計を進めるにつれて処理に必要なテーブルを追記することもある。

基本設計工程ではテーブル定義やCRUD図の整理が主な作業となる。CRUD図は整理する組織と整理しない組織が大きく分かれる印象があるが、整理しておくと機能漏れやデッドロックの防止につながる。

 

2-5-1.テーブル関連図(ER図)

 

システムで取り扱うテーブル関係が分かる資料。

要件定義では主要なテーブルのみを記載したが、基本設計では機能実現に必要なテーブルをきっちりと書き出していく。一方で、プログラミングをしていく中で必要となるテーブルも出てくるので、その場合は別途資料を修正することになる。

 

2-5-2.テーブル・ファイル一覧

 

前述したテーブル関連図をもとに、主要なテーブルを一覧にまとめた資料。

下記のように作られ方からテーブルを分類しておくとCRUD図を整理する際に役立つ。種別の意味合いは下記の通り。

イベント系
受注、発注などの業務活動によって発生・増加する情報を管理するテーブル

リソース系
商品マスタ・倉庫マスタ等、イベント系テーブルから参照される実際に存在するモノを管理するテーブル

サマリ系
売上高など、業務活動によって発生した情報の集計結果を管理するテーブル

 

2-5-3.テーブル・ファイル定義

 

前述したテーブル一覧を元にテーブル内の主要なデータ項目を一覧にまとめた資料。

要件定義では主要な項目のみで良かったが、設計工程では機能実現に必要な項目をきっちりと書き出していく。

もちろんプログラミングをするなかで必要となる内部処理用の項目が追加されることも多いので、その場合は別途資料を修正する。

 

2-5-4.CRUD図

 

各テーブルの作成・参照・更新・削除を整理した資料で、機能漏れやデッドロックの防止が期待できる。

基本設計ではなく詳細設計で整理する場合もあるし、組織によってはソースコードを元に自動生成する場合もある。

 

2-6.外部インターフェース設計

システムを構築する上で必要な外部システムとの連携(インターフェース)について整理する。

見積りへのインパクトが大きくなりがちなので要件定義で関連図や一覧表については整理すべきだが、もし整理できていなければ基本設計工程にでも整理したい。

2-6.外部インターフェース設計
 2-6-1.外部システム関連図
 2-6-2.外部インターフェース一覧
 2-6-3.外部インターフェース定義書 ☆
 2-6-4.外部インターフェース処理概要 ★

☆:基本設計工程で具体化する資料
★:基本設計工程で新規作成する資料

要件定義で作成した外部インターフェース定義書については、機能を実現するうえで必要な項目を追加していく。また処理概要の資料には送受信に関する双方の取り決めを整理する。

2-6-1.外部システム関連図

 

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

 

2-6-2.外部インターフェース一覧

 

関連システムとのデータ連携を一覧にまとめた資料。
見積りに影響しやすいので5W2Hで整理しておきたい。

5W2Hの観点
 What:データ形式等(XML、TEXT等)
 Who:入出力するのはどの機能か
 When:送受信の頻度やタイミング
 Where:入出力するのはどのシステムか
 Why:なぜ必要なデータなのか
 How:送受信手段(API、FTP、HULFT等)
 How many:データ量

 

2-6-3.外部インターフェース定義書

 

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

要件定義では主要な項目のみで良かったが、基本設計では送受信の識別やデータ破損識別(レコード長等)といったチェック用の項目も漏れなく書き出していく。

 

2-6-4.外部インターフェース処理概要

 

外部システムとのデータ連携について、手順やチェック方法等を取り決めた資料。

例えば下記のようなことを整理する。

・送受信ファイル名
・受信時のチェック内容
・エラー時の処理内容
・送信時のリトライ回数
・バックアップ方法
など

 

3.非機能要件に関わる成果物

非機能要件は軽視されがちだが事業に大きな影響を与える可能性があるため、要件定義の重要な検討事項として位置付けられている。

一方で、要件定義で検討ができていない場合は、基本設計工程で要件を確認しなければならないため見積りブレのリスクは高くなる。だが整理できていないものは仕方ないので、基本設計工程からでも非機能要件を整理したい。

非機能要件は下記6つの資料でまとめられる。(IPAによる非機能グレードを活用)

3.非機能要件
 3-1.可用性
 3-2.性能・拡張性
 3-3.運用・保守性
 3-4.移行性
 3-5.セキュリティ
 3-6.システム環境・エコロジー

これらの資料の書き方やサンプルについては、下記の要件定義の記事をご覧いただきたい。基本設計工程での説明は割愛させていただく。

>> 要件定義における成果物一覧と書き方 〜非機能要件〜

 

資料作成に役立つアイコン提供サイト

基本設計で整理すべき資料(主に機能設計)について成果物の一例を紹介してきた。ここで資料作成に役立つサイトを紹介しておく。

下記は図解に役立つアイコンを無料で提供してくれているサイト。

icooon-mono
業務フロー作成のアイコンに便利

CISCO『Network Topology Icons』
ネットワーク構成図のアイコンに便利

 

さいごに

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

要件定義工程の資料作成ができていないと基本設計工程で大きな苦労をすることになるため、できれば事前に資料は整理しておきたい。

また、冒頭に述べたようにどんな資料をつくるのかはプロジェクト特性や組織のルールによって異なるため、まずは部署の過去資料を確認してほしい。

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

 

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

要件定義の進め方

要件定義工程の進め方

2021年2月7日
要件定義の目的

要件定義の目的は「プロジェクト5W2Hを明確にして失敗を減らすこと」

2021年2月6日
要件定義工程の成果物

要件定義における成果物一覧と書き方(要件定義書サンプルあり)

2021年2月5日
機能要件と非機能要件の書き方〜サンプル付き

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

2018年8月17日

参考文献

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

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

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

経済産業省『LPガス保安技術者向けWebサイト 管理更新システム』

ThinkIT『令和時代の設計書の基本方針』

IPA『機能要件の合意形成ガイド~画面編~』

IPA『機能要件の合意形成ガイド~帳票編~』

IPA『機能要件の合意形成ガイド~バッチ編~』

IPA『機能要件の合意形成ガイド~データモデル編~』

IPA『機能要件の合意形成ガイド~外部インタフェース編~』






コメントを残す

メールアドレスが公開されることはありません。

CAPTCHA