要件定義、基本設計、詳細設計、プログラム設計、テスト、運用というシステム構築の手順が一般的に浸透しているが、このプロセスは 実践ではほとんど守られておらず、要件定義の中で、ユーザと一緒に一部分を掘り下げて行っているうちに混合されることが多い。 ここではその区別について考える。ただし、実践手順が多少、イレギュラーに設計されるのは全体の合理化を促進しようとするためであり、必ずしも良くないこととは言い切れない。 基本的には必要とされるアクターを考えることが重要だと思われる。

外部設計（システム設計）　＝システム方式設計+ソフトウェア設計
内部設計　　　　　　　　　　　＝コンポーネント設計
詳細設計　　　　　　 　　　　 ＝プログラム設計                                    　　　（IPA）

システム方式設計

１．システム方式の決定：アーキテクチャーとして、H/W、S/W、N/W手作業を明確化し、文書化する。２．．システム方式の評価：要件定義とその実現の可能性を個々の設計、ソフトウェアにて実現できるか評価する。３．システム方式設計書の作成と共同レビュー：本システム方式設計書を作成しユーザと共同レビューを実施する。４．市販パッケージの評価５．システムのテスト方針の設定：適格性確認要求事項を設定６．詳細業務フローの作成：システム化の範囲と手作業の範囲の振り分けに基づき業務の流れ、入出力、処理、出力、担当など詳細業務フローを作成する。７．業務運用の詳細作成：業務の組織、要員、運用体制、運用手順など業務運用詳細について検討し、文書化する。業務運用手順の作成と共同レビュー：ユーザ業務及び入出力作業を含むコンピュータ操作手順からなる業務運用手順の詳細を検討し、業務運用マニュアル（利用者マニュアル概要版）として文書化する。

ソフトウェア設計

１． ソフトウェア要求事項の定義：性能・物理特性、実行に対する環境条件を含む機能および性能仕様　周辺とのインターフェース　データ定義およびデータベースに対する要求事項セキュリティ仕様　人間工学的仕様　利用者文書、利用者の運用および、実行に関する要求事項　適格性確認要求事項　導入および受け入れに対する要求事項　利用者の保守に　関する要求事項ソフトウェア要求事項の評価　ソフトへの要求に対し、実現の可能性を評価する。　

２．フトウェア設計書の作成と共同レビュー　コード、論理データ、画面、帳票、外部システムとのI/Fを記述したソフトウェア設計書を作成し、共同レビューする。

３．ソフトウェア適格性確認テスト方針の設定ソフト品目の適格性確認テストの方針を文書化する。

設計フェーズ

必要アクター

主目的

要件定義

開発者

見積工数算出　ユーザ要求の把握が主目的

基本設計

ユーザ

要求の反映を相互に確認するのが主目的

詳細設計

開発者

システム詳細を→製作者へ伝えるのが主目的

問）基本設計と詳細設計、外部設計と内部設計というのをよく混合するが、どう違うのか？ 一般的に外部設計を基本設計とよび、内部設計を詳細設計とよばれているようであるが？

→「外部設計はお客さんから観られる仕様の決定を行う。」と考える。考え方としては、システム概要、機能一覧、インターフェース、H/W、S/W、開発費、プログラム言語の決定などを設計図であることが自然と明らかになる。内部は反対に「ユーザからは見えないけど。。。」という考え方であり、主にプログラマ向けに作成されるものである。　つまり、システムを分割してサブシステムに分割し機能を策定する。その後サブシステム間の処理と流れを明瞭化し、要はプログラムができるレベルまで持っていくことである。従って、基本設計とは　基本計画,要求定義,要求分析を含み　システムを実現する可能性､問題点を調査､分析する。よって詳細設計が外部と内部に分かれるという考えのエンジニア理解が多い。ただ、外部設計は　概要設計または基本設計と近似であり、内部設計は詳細設計のことであるという誤解のまま実践しているエンジニアも少なからず見受けられる。 IPAでの分類は上記のように詳細設計というとプログラム設計を意味する。これらのように用語の散在と一般的な用語から類推される意味あいでの流通が混乱の元になっているのは待ちがいないようである。それでもちゃんとシステムが動いてメンテナンスしているうちに修正が加わり完成されればよいのであろうが。ドキュメントがないと、今度は引き継ぎができなくなるという大手ポータルサイトもあり、焦って後からドキュメンテーションを作っているというところもあるようである。

問）工程定義とは？

システムの全工程について成果物として提出するもの（例　詳細設計では詳細設計書、Ｉ／Ｆ設計書、ファイル設計書、共通関数設計書、業務行通機能（バッチ）JOB一覧、フロー、運用バッチJOB一覧、フロー、業務共通機能（オンライン）詳細設計書、画面詳細設計書、テーブル設計書）をプロジェクト立ち上げ時にほぼ決定しておいたほうがプロジェクトはスムーズに流れるので必須である。

NO

DBS

概要

RFP

 RequestForProposal（提案依頼書）ユーザー企業に提出す提案書の元資料となるもの。これを元に提案書を作成する。
※但し、往々にしてRFPがないことも多く、口頭でのヒアリングなどから提案書を起こすと言うケースも多い。特別な資料形式はないがユーザの思いつき要件のようなものと思っても間違いはない。例としては　画面はこんな感じ。このような機能が欲しい、システムはここを使いたい。納期は。。などである。厳密には「概要と目的」「必要な機能」「求められるシステム条件」「サービスレベル」「予算」「納期」「契約条件」「評価プロセスと評価基準」「調達方針」「環境」などが優先度高である。また「提案書の形式」「提出期限」「提出先」「提出方法」などが指定される。

提案書

RFPを受けてユーザーにPRするための資料のことを言う。この段階では営業が中心に作業を行う。提案書の段階では概要を作成する（要件）必要があるが、主に提案者側が自社の特徴と差別化を中心に記載する必要がポイントとなる。主に技術者より営業が主軸になり作業が行われる。

見積書

工数見積は作業概要を提案書段階で租借してはじき出さなければならないが、それらについても現場の意見をよく聞かないと、思惑にはずれる見積となる。見積作業はSEが中心に行い。工数とWBSを平行して提出する。

各工程共通資料

ドキュメント標準：概要設計、詳細設計、プログラム設計、テスト仕様書兼報告書などの記載項目を掲示

アプリケーション開発手順書：概要設計、詳細設計、プログラム設計、開発単体テスト、結合テスト、総合テストについてインプット、アウトプット、作業内容を記述

ネーミング規約：

開発環境遷移図：開発にあたり、ソース、バイナリ、設定スクリプトなどはどのように更新され保管（リポジトリ）されるかの図を書くことがある。

工程定義

システム全工程での成果物一覧定義

要件定義書

見積工数算出とユーザ要求の把握が主目的となる。※厳重注意すべきは「早く」とか「遅く」の曖昧な言葉は禁止は禁止。工数についてはステップの考え方は設計書を書き込む必要がある過程でのステップは1人月700から１ｋが相場である。

システム化目的方針

次世代構築するシステムについての目標や方針について

要求機能一覧

業務機能一覧、ビジネスルール、サブシステム間のやりとり方針と主要課題などを記述

検討課題一覧

課題・新要件の一覧

業務機能マトリクス

次世代システムの要件一覧とそれに当てはまる機能一覧を対応させたマトリックスおよびDFD

方式設計基本要件

品質、性能という切り口で各要求事項とそれについての対応方針を記述したもの

新業務定義

新業務フロー一覧

新業務フローの一覧

新業務フロー

フローであるがシステム化対象を明確にするのが目的となり、システム間インターフェースも記述する

新業務フロー概要説明

フローの内容を説明する記述　ユースケース（商品を登録するetc）

新業務フロー変更説明

旧システムと新システムとの変更部分を記述

概念モデル

概念エンティティ一覧

エンティティ（システム構築上、管理対象となるオブジェクト）を明確にする

分析クラス図

エンティティモデルのメンバーを明らかにし、コントローラのメソッドも明らかにする。

分析パッケージ図

サブシステムの定義と構造、それからサブシステムの関連を示す。

ER図

分析クラス図をO-Rマッピングし、DBへの対応の検討

エンティティ一覧

クラス図で機材されている内容を一覧にしたもの

エンティティ定義

エンティティの定義を記述

ドメイン定義

データドメイン定義となるシステムで使用する全名称、カテゴリ、桁数、表示形式、チェック内容の統一を 図る。この時点では、名称、タイプ、のみ確定、ここに、区分、・フラグ・コード・番号定義を含める。

単語辞書

システムで使用する。データ単語名と対応する英語名の統一を図る。★データ項目名称「注文日」を構成するのは「注文」と「日」になる。

入出力概念設計

画面一覧

画面一覧の記述

帳票一覧

帳票一覧の記述

ファイル一覧（IF）

ファイル一覧の記述、周辺のI/F(インターフェース）も記述する

画面フロー概要

画面の階層構造を記述したもの

画面概要

画面の主要項目、ラフデザインを記述したもの

帳票画用

帳票の主要項目、ラフデザインを記述したもの

システム機能定義

機能一覧

サブシステム毎の機能を定義、業務機能をどのように実現するかを定義する

処理概要

システムの機能を概要レベルで記述したもの

セッション課題一覧

非機能要求一覧

 機能一覧以外の要求一覧と詳細（セキュリティ要求もここに入れる）

テスト計画書

本編

システム全体のテストの目的・範囲・基準の記述。各工程別に実施するテストを記述する

テスト方針

目的と範囲、進め方、リスク、環境要件、評価基準、開始終了基準などを記述したもの

テストスケジュール

マイルストンを意識したシステムテストの概要のスケジュールを記述

妥当性確認テスト方針

目的、範囲、進め方、リスト、環境要件、評価基準、開始終了基準などを記述した妥当性確認テスト方針

妥当性確認テストスケジュール

マイルストンを設定し、テストの概要スケジュールを記述したもの

結合テスト方針

目的テスト範囲、進め方、リスク、環境要件、評価基準、開始終了基準など記述したテスト方針

移行計画書

移行方針

移行についての基本方針を記述する。詳細は外部設計のデータ移行書に記載する。

方式設計書

はじめに

目的・範囲・前提の記述

実施処理方式

アプリケーションの制御基盤となるフレームワークの処理方式、運用基盤、周辺I/F基盤を記述

システムプラットフォーム構成

ネットワーク、H/W、S/W構成図、構成機器一覧を記述

運用方式

運用基本方式について記述する。

運用システム全体

運用基本方式をどう実現するか定義する。またスコープおよびスコープの内容も記述する。

業務運用における機能

業務運用フローを実現するための各運用機能を記述する。各運用ごとに（方針、対象・範囲、実現方法、実現するためのツール、開発概要、手順化内容、検討課題）などを記述する

機械運用における機能

機械運用フローを実現するための各運用機能を記述する。各運用ごとに（方針、対象・範囲、実現方法、実現するためのツール、開発概要、手順化内容、検討課題）などを記述する

セキュリティ実現方式

APL,H/W、S/Wなどに分けてセキュリテイ実現方針を記述する。

処理分散設計

負荷分散構成、複数拠点への配置によっての分散の実現方法を記述

データ分散設計

アーキテクチャ、負荷分散構成、複数拠点でのデータ配置を実現し同期をとる方法を記述

システム開発標準

開発方式、実行処理方式、運用方式に基づき、具体的に制定したシステムの開発基準

システム全体標準

システム全体で守るべき標準

ネーミング・ID標準

ネーミング、IDの基準

ユーザインターフェース標準

画面、帳票、IFでの標準

プログラミング標準

プログラミングルールを記述

アプリケーション設計ガイド

アプリケーションの設計ガイド

コンポーネント設計指針

コンポーネントの定義や方向性、サンプルなどを記述

データ関連ガイド

データベースおよびデータの設計に関するガイド

開発環境とツール

開発環境の構成、各種ガイド、手順書を作成する

設計標準

設計上の標準ルールを記述

環境設計

本番環境、テスト環境などを定義する

災害対策処理方式

災害対策基本要件に基づき、実現する方式を記述

プロトタイプ実施計画書

プロトタイプ開発の実施計画、検討課題、解決へのアプローチを記述

プロトタイプ結果報告書

プロトタイプにて開発、測定結果内容を評価する。

先行開発実施計画書

先行して開発する業務、目的を明示して実施計画を記述

開発計画書

本編

開発方針、日程計画、工程定義、開発体制、見積工数などを記述

品質管理計画

品質目標、達成評価方法を明示、品質管理活動に対する方針、評価指標を定義、成果物の検証、工数審査にかんして計画する

プロジェクト運営基準

進捗管理、問題課題管理、問い合せ管理などのプロジェクト運用基準を記述する。

要件定義成果物の検証記録

要件事項に対して満たしているかの検証結果および必要な処理があればその処理を記録する

要件定義審査報告書

工程の終了判定の内容と結果、顧客目線での妥当性確認が終わっていることの確認、処理記録等

モックアップ

ＨＴＭＬの具体的なものを作成し、画面、データ更新などのイメージ確認用に使う

■外部設計（概要設計書）

概要設計書

 全体概要、機能概要及び外部IF概要を記載する。

全体概要

要件概要

要件をセレクトしその概要、要件に対応する方針を記載し、要件決定までの経緯も記載する。

全体概要図

全体概要図を作成する。

全体機能（業務）一覧

要件から決定した分割機能一覧と詳細を記載する。

機能概要

機能一覧（機能名）

機能一覧と機能名を記載する。

機能概要

機能概要を記載する。

機能詳細

各機能詳細を記載する。

外部IF概要

IF名称

IFの名称を記載し、サーバ名、プロセス名も入れる。

送信元(from)

 ファイル送信元を記載する（ネットワークシステムの場合の項目）

受信元（to）

 ファイル受信元を記載する（ネットワークシステムの場合の項目）

IF種別

ファイル（ファイル形式、媒体名、形式（テキスト、CSV,バイナリなど）

データ量

1回あたりのMAX件数、期間あたりの件数を記載する。

IFサイクルタイミング

IFサイクル、タイミング　※例　不定期、毎晩10時　など

IF概要説明

IFの概要を説明する。

画面説明書

画面遷移図

画面遷移図

画面遷移図

画面一覧

画面名

画面概要

画面機能仕様

 画面単位に実現できる機能について機能概要を記載し、画面単位の全ての機能を網羅する。

帳票設計

帳票一覧

帳票仕様

帳票レイアウト

帳票項目定義

イメージ設計

イメージ一覧

イメージの種類ごとの一覧を作成する。

イメージ定義

イメージ取得時の検索条件やセキュリティの制御、業務DBとの紐付キーとして利用するためにイメージに設定する属性情報について項目を定義する。

メッセージ一覧

システム処理の定義中に必要なメッセージ一覧を作成し、IDを採番する。

DBアクセス条件定義

CRDUマトリックス

オンラインメニュー体系一覧

データ項目一覧

環境設計書

方式設計で確定したプラットフォームに対し、各フェーズで必要となる環境について詳細を確定する。

新業務定義書

新業務フロー(プロセス定義版）一覧

新業務フロー(プロセス定義版）

新業務フロー(プロセス定義版）概要

新業務フロー(プロセス定義版）変更

アクセス権限一覧

ワークフロー設計書

ワークフロー一覧

ワークフロー仕様

ワークフロー遷移図

ワークフロープロセス定義

ハードウェア、ソフトウェア設定書

結合テスト計画書

結合テスト方針

目的とテスト範囲、進め方、リスク、環境要件、評価基準、開始終了基準などを記述した結合テスト方針

結合テストスケジュール

マイルストンレベルに記述した結合テストの概略スケジュール

運用規定書

運用設計書

全体

業務運用設計書

機械運用設計書

次工程検討課題一覧

外部設計で工程ないで解決できなかった項目の残課題を記述

外部設計成果物の検証記録

外部設計工程の成果物のレビュー記録、品質管理計画に則り、インプットとなる要求事項を満たしているのかどうかを確認し、その検の結果及び必要な処理があればその処理を記述する

外部設計審査報告書

工程の終了判定の内容とその結果、及び最終判定と必要ならば処理を記録したもの

フレームワーク設計書

フレームワークの設計を記述する

基盤テスト計画書

基盤環境のテスト方針・計画を記したもの

内部設計

機能設計

機能一覧

外部設計で作成した機能一覧に、リソースの準備・管理ために必要な情報を追記

機能詳細

外部設計で作成した機能一覧詳細に追加情報を記載する。結合テストをターゲットとする。

プログラム関連図

プログラム関連図

 外部設計の機能一覧に呼応連携したプログラム、テーブル、キューの関連を記載

プログラム一覧

プログラム関連図に合わせて必要と思われるプログラムの一覧をプログラムID、プログラム名、処理概要、IOデータ、備考欄などにて表にして記載する。

プログラム処理概要

各々のプログラムの入力データ、処理概要、出力データを図示し、処理概要を記載する。

IF設計書

システム稼動に必要なもの一式を一覧にする

IFフォーマット

 項目名（通番）、データラベル（time[6][6]）、データ型（B(4)）、内容説明など

ファイル設計

ファイルフォーマット設計書

項目ID、項目名、属性、備考

業務共通機能詳細設計書（コンポーネント）

プログラムフロー

 プログラム、テーブル、キューなどの関連フロー

 条件書

機能概要、プログラム実行処理条件、特記事項、内部関数別処理内用

内部関数相関図

 内部関数間の相関を記載

内部関数一覧

内部関数ID,内部関数名称

 共通関数設書

 共通関数設計書

 ファンクション名、関数名、概要、例外処理、モジュールインターフェース（引数）、引数の型、引数項目ID、引数分類（戻り値、引数（入力、出力）、引数説明、使用上注意、下位構成（ファンクション名、関数名）、補足説明）

 条件書

 関数機能概要、関数実行の条件、関数別処理内用詳細

業務共通機能（バッチ）運用バッチJOB

ファイル仕様

JOB一覧

 （エンティティ（テーブル日本語名）、オブジェクト名（テーブルID）、起動シェル機能、

親JNWジョブフロー

子NWジョブフロー

孫NWジョブフロー

条件書

（プログラムの機能概要、プログラム実行条件、特記事項、処理内容詳細）

画面設計

画面一覧（テーブル設計）

外部設計の画面一覧にヘルプ、項目説明、印刷有無など指定する。

画面仕様

画面フロー

外部設計の画面フローに単体テストケースを記述する。

画面レイアウト

外部設計の画面レイアウトに単体テストケースを記述する。

イベント設計

外部設計のイベント設計を更新する。

画面入出力項目定義

外部設計の画面入出力項目定義を更新する。

帳票設計

帳票一覧

外部設計に出力プリンタ、AFP定義体名を指定する項目を記述

帳票仕様

帳票レイアウト

外部設計にレイアウトに単体テストケースを記述する

帳票項目定義

単体テストケースを記述する

メッセージ一覧

DB物理設計書

ER図

外部設計のERに物理レイアウトを定義

表定義

表一覧と項目定義の2部構成で、物理名・データ型・桁数などを定義する。外部設計のエンティティ定義を更新する。

索引定義

INDEXの設計を記述する

DB物理設計補助情報

各テーブルの件数、ライフサイクルを定義する。

表アクセス順序定義

各機能のテーブルへのアクセス順を定義する。本書のアクセス順を遵守することでデッドロックの発生を抑制する。本書は外部設計のCRUDマトリクスを利用して、精度向上を行う。

表物理情報定義

表領域に定義された各物理情報をテーブル・区分単位で出力する。

索引物理情報定義

索引領域に定義された各物理情報を索引、索引区分単位で出力する。

業務運用設計書

業務運用仕様

オンライン機能を一覧化し、開閉局時間を記述する。

開閉局一覧

ネットジョブ一覧

ネット関連図

ネットジョブ定義

環境設計書

DBアクセス条件定義

ハードウェア・ソフトウェア設定書

単体テスト計画書

単体テスト方針

単体テストガイド

単体テストケース

単体テストケース(システム機能）

システム機能単位のテストケース内容、想定結果、検証物、入力データ定義

単体テストケース（モジュール）

テストケースの内容、想定結果、検証物、入力データの定義

共通テストデータ

共通テストデータ定義

共通テストデータ

結合テスト計画書

結合テスト方針

結合テストスケジュール

結合テストケース

結合テストケース一覧

システムテスト計画書

システムテスト方針

システムテストスケジュール

システムテストケース

システムテストケース一覧

運用ツール設計書

設計課題一覧

内部設計成果物の検証記録

内部設計審査報告書

CRUDマトリックス

システム間インターフェース設計書

システム間インターフェース一覧

システム間インターフェース概要図

システム間インターフェース仕様

システム間インターフェースレイアウト

外部設計レイアウトに単体テストケースを当てはめる

サブシステム間インターフェース設計書

サブシステム間インターフェース一覧

サブシステム間インターフェース概要図

サブシステム間インターフェース仕様

サブシステム間インターフェースレイアウト

メール設計書

システムで利用されるメールを一覧にし、件名、本文レイアウトや送信情報などの設定

　　パフォーマンスチューニング　　

Webシステムの処理要素　　
JAVAスクリプトなどWEBブラウザ内処理　→　パフォーマンスモニタ　
ユーザ側回線　→　ネットワーク管理ツール、パケットモニタリングツール
インターネット 　→　ネットワーク管理ツール、パケットモニタリングツール
システム内ネットワーク機器 →　ネットワーク管理ツール、パケットモニタリングツール
WEBサーバのキュー　→　ログファイル、パフォーマンスモニタ、（UNIX系　SAR、vmstat、iostar）
WEBサーバのキャッシュ　→　
WEBサーバプラグイン　→
HTTP通信（プラグインからの転送）　→　ネットワーク管理ツール、パケットモニタリングツール
WEBコンテナ（サーブレット）のキュー　→　ログファイル、パフォーマンスモニタ、 （UNIX系　SAR、vmstat、iostar）、プロファイラツール
WEBコンテナ（サーブレット）のJVM　
WEBコンテナ（サーブレット）内のアプリケーション処理
RMI/IIOP通信（リモートメソッド呼び出し）　→ネットワーク管理ツー、パケットモニタリングツール
EJBコンテナのキュー　→　ログファイル、パフォーマンスモニタ、 （UNIX系　SAR、vmstat、iostar）、プロファイラツール
EJBコンテナのJVN
EJBキャッシュ
クライアントセッション管理
トランザクション管理
認証とアクセス制御
永続性
EJBコンテナ内のアプリケーション処理
DB接続ツール
JDBC　→　ネットワーク管理ツール、パケットモニタリングツール
DBサーバのキュー
DB接続、検索、更新時間 　 →　ログファイル、パフォーマンスモニタ、 （UNIX系　SAR、vmstat、iostar）、プロファイラツール

■コードレビューツールによる分析（富士通　SIMPLIA/JF　Kiyacker)　　　

初心者があやまりがちなコーディングロジック
性能劣化の要因となりそうなJAVAコーディングロジック
業務上、プログラム開発者が使用してはいけないロジック
実現方式（ｉアプリやＤＢアクセスなど）により利用してはいけないロジック　　　

■負荷測定に使えるツール（フリー）概要　　　

ＪMeter　DBに対する負荷テスト　GUIベースで設定、テストを実施可能
TestMaker　テストケースはスクリプト（Jythron）で記述する。スクリプトのテスト実行をGUIで作成が可能
JUnit JAVAにおけるユニットテストスイートとして有名　http://www.junit.org

負荷
テスト

Jmeter　Assam 　WebBench WebApplicationStressTool 　　Webload LoadRunner e-load

プロファイラツール

Optimizeit　Jinsite　JProbeSuite　TrueTime　RationalQuantityforWindowNT

DBチューニングツール

OraXplmini　PerformanceInsight　PreciseEnterprize　　DBObserver

コードレビュー支援

SIMPLIA/JFKiyacker　InspectEyes

ネットワーク関連

SnifferPro　DSS/RMONPro　MRTG SiriusNetkidsiMark　DBS　Treno　Netperf　tcptrace　InetSpy　

考え方

機能詳細一覧：外部設計のサブシステムの明確化されおり機能分割が完成されていることを前提とする
機能分割・構造化（コンポーネント設計：コンポーネント＝結合テストの単位を目標とする。）               
              ・コンポーネント一覧：全サブシステムの機能要件を完全に満たしたコンポーネント一覧群を明示する。                          
              ・個別コンポーネント：各コンポーネントの業務ロジックを正確に文書化する。                              
              ・I/F：コンポーネント間，他のシステムとのインターフェースを明確に文書化する。                                      
              ・共通機能：コンポーネント間の共通機能や統合化などを抽出する。（サブシステム単位）                             
物理データ設計                                                                                                                                          
               ・物理データベース設計　外部設計のERやデータをもとに論理モデルを物理モデルに変換する。つまり、CLASSオブジェクトを中心に考えた論理的なつながりを実際のDBやシステム全体のH/W,S/Wに照らし合わせて設計する。                                                                    
入出力詳細設計                                                                            
               ・プロトタイプ作成：プロトタイプ開発手続き、テスト結果、改善案などが文書化され、目的と範囲が定義されており、ユーザの期待値を反映していること。                                                        
         ・画面設計：外部設計を元に画面項目説明まで記載された一式                                                            
         ・帳票設計：外部設計を元にした設計を元に項目説明まで記載された一式
         ・メッセージ設計：プログラムメッセージ仕様一式
         ・ログ設計：ログ設計（優先度など）一式
         ・コンフィグファイル：プログラムレベルではなく主にシステムとして運用が必要な設定ファイル一覧
         ・更新仕様書：システム、プログラムの更新方法の仕様書
         ・コンポーネントテスト仕様書の作成：テスト仕様書はコンポーネント自体を設計した時に簡単に作成しておくことが望ましいと考える。

プログラム関連図

機能設計書に基づき機能概要とプログラム構成（全コンポーネント）を文書化する。
�@機能詳細：外部設計にて対応していれば項目のみを文書化する。
�Aプログラム関連図（処理概要図）：機能詳細を実現するための、プログラム、テーブル、トランザクションの関連図を文書化する。。
�Bプログラムプロセス構成図：プログラムのスレッド構成とデータIOとの相関を文書化する。
�Cプログラム一覧：�Aで表示したプログラムの一覧と各々のプログラムが何をするかの一覧を文書化する。

IO関連図（DFD）

詳細設計書で表示された各機能（コンポーネント）についての処理とDFD（IO関連図）などにて明示する。（DFDorUML）
�@IO関連図：Inputデータ（データ形式（例csvなど）、処理　OUTPUTデータ（画面、帳票）を文書化する。
�A処理説明：処理詳細についての内容説明を文章で文書化する。※マスターの分散が懸念される場合はUMLが望ましい。

（処理フローチャート）

DFDでは時間表示が困難なためIO関連図でIOを明確するのと同時に、ループ処理や繰り返し処理など時間的な表示が必要な部分は処理フローで文書化する。（本紙はIO関連図と同じ図に記載すると表記が複雑化するので別作成が望ましい）
�@処理フロー：処理のタイミング、分岐、ループを中心に条件もふまえてIOの流れを文書化する。
�A処理実施条件：イベントトリガー、初期条件として必要な前段のメソッドや変更点などを条件として文書化する。

ファイル仕様書

ファイル仕様について記載する。（外部IFインターフェース含む）　データベースの場合は基本設計のERを元にテーブル仕様書を文書化する。�@ファイル仕様書

共通関数設計書

コンポーネントについて共通関数を設計する。また、外部コンポーネント、ライブラリAPIを利用する場合はその仕様についてを文書化する。
�@共通関数設計　関数名、関数区分、関数仕様

コンポーネント一覧

機能を実現するためのコンポーネント（DBの場合はBL単位）の一覧を明確にし、ファイル仕様書に定義されるファイル形式と正確に対応している一覧を文書化する。
�@コンポーネント一覧：NO、コンポーネント名、機能、対応IO、処理規制

画面設計

外部設計にて作成してあれば項目詳細（データ形式、データ長、初期値、入力規則など）を中心に文書化する。

帳票設計

外部設計にて作成してあれば項目詳細（データ形式、データ長、初期値、入力規則など）を中心に文書化する。

メッセージ設計

プログラムに関連つけるメッセージについて文書化する。
�@メッセージ種類、発生のタイミング、内容、メッセージ出力方法、保存方法、保存期間一覧

設定ファイル

内部管理されるデータ、運用にて更新が必要なデータ、設定データと形式、更新のタイミングなどの一覧を文書化する。
�@設定ファイル一覧(コンフィグファイル)

更新方法

更新方法について文書化する。