(データモデル編)
ver. 1.0
２００８年７月
独立行政法人 情報処理推進機構
ソフトウェア・エンジニアリング・センター
<ガイドラインをご使用になる前にお読みください> 発注者ビューガイドライン（以下、「本ガイドライン」といいます。）を利用することをもって、以下に記載する使用条件（以下、「本使用条件」といいます。）に同意したものとさせていただきます。 本ガイドラインの著作権は、独立行政法人 情報処理推進機構が保有しています。 以下の利用可能な行為を除き、本ガイドラインの一部または全部を著作権法の定める範囲を超え、許可なく改変、公衆送信、販売、出版、翻訳、翻案等をすることは営利、非営利など目的の いかんに関わらず禁じられています。 ＜本ガイドラインの目的＞ 本ガイドラインは、外部設計工程における、発注者にわかりやすい仕様の記述方法及び合意方法を世の中に広く普及することを目的としています。 ＜利用可能な行為＞ 本ガイドラインは、以下の著作権表示を明記した上で、 著作権表示 ： Copyright©2008 IPA 情報システム開発に携わる方が本目的のために ・本ガイドラインの全部または一部を無償で複製すること、 ・本使用条件を配布先に遵守させることを条件に本ガイドラインの複製物を無償で再配布すること、 により利用することができます。 独立行政法人 情報処理推進機構は、本ガイドラインが第三者の著作権、特許権、実用新案権等の知的財産権に抵触しないことを一切保証するものではなく、また、本ガイドラインの内容に 誤りがあった場合でも一切責任を負うものではありません。 独立行政法人 情報処理推進機構は、上記の利用可能な行為を除き、第三者の著作権、特許権、実用新案権等の知的財産権に基づくいかなる権利も許諾するものではありません。 独立行政法人 情報処理推進機構は、本ガイドラインのシステム開発への利用、開発したシステムの使用及びシステムの使用不能により生じるいかなる損害についても、なんら責任を負うも のではありません。 本ガイドラインを海外へ持ち出し、または外国籍の人に提供する場合には、「外国為替及び外国貿易法」の規制及び米国輸出管理規則等外国の輸出関連法規を確認の上、必要な手続きを 行ってください。 本ガイドラインへのお問い合わせについては、独立行政法人 情報処理推進機構 ソフトウェア・エンジニアリング・センターまでご連絡下さい。 ＪａｖａおよびすべてのＪａｖａ関連の商標およびロゴは、米国およびその他の国における米国 Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．の商標または登録商標です。 その他、本書に記載されている会社名、製品名などは各社の商標または登録商標です。 なお、本資料では、™ または® の表記は省略しております。
目次（1/2）
序
第1部 表現
はじめに
第1部 - 2
第1章 工程成果物の定義
第1部 - 4
¾
1.1 ER図
第1部 - 5
¾
1.2 エンティティ一覧
第1部 - 6
¾
1.3 エンティティ定義書
第1部 - 7
¾
1.4 CRUD図
第1部 - 8
第2章 設計書記述のポイント
第1部 - 9
¾
2.1 表現のコツ一覧
第1部 - 10
¾
2.2 ER図の表現のコツ
第1部 - 11
¾
2.3 エンティティ一覧／定義書の表現のコツ
第1部 - 16
¾
2.4 CRUD図の表現のコツ
第1部 - 21
¾
2.5 データのフロー等の表現のコツ
第1部 - 26
第2部 記述確認
はじめに
第2部 - 2
第1章 設計方針のチェックリスト
第2部 - 3
第3部 レビュー
はじめに
第3部 - 2
第1章 レビューの進め方
第3部 - 4
¾
1.1 「分類」の考え方
第3部 - 5
¾
1.2 レビューの考え方
第3部 - 6
第2章 レビューのポイント
第3部 - 10
¾
2.1 レビューのコツ一覧
第3部 - 11
¾
2.2 エンティティ・属性を抽出するコツ
第3部 - 14
¾
2.3 データモデルの概要を説明するコツ
第3部 - 18
¾
2.4 データモデルの詳細を説明するコツ
第3部 - 21
¾
2.5 データの変化を確認するコツ
第3部 - 33
¾
2.6 業務とデータの関係を確認するコツ
第3部 - 36
¾
2.7 他システムとやりとりするデータを確認するコツ
第3部 - 39
¾
2.8 業務量を確認するコツ
第3部 - 43
第4部 レビュー時の確認
はじめに
第4部 - 2
第1章 レビュー時のチェックリスト
第4部 - 3
あとがき
序では、発注者ビューガイドラインの位置づけや構成について説明します
i.
はじめに
(1)
発注者ビューガイドラインとは
(2)
発注者ビューガイドラインの利用方法
ii.
発注者ビューガイドライン作成の背景
(1)
情報システム開発における課題
(2)
課題へのアプローチ
(3)
発注者ビューの位置づけ
iii.
発注者ビューガイドラインの対象範囲
(1)
対象工程
(2)
想定するシステムとガイドラインとの対応
iv.
発注者ビューガイドラインの前提
(1)
工程成果物
(2)
設計書
v.
発注者ビューガイドライン（データモデル編）の前提
(1)
データモデル編における工程成果物の定義
(2)
データモデル編におけるレビュー時期の想定
vi.
発注者ビューガイドライン（データモデル編）の構成
(1)
各部の構成
(2)
発注者ビューガイドライン（データモデル編）の記述範囲外の事項
(1) 発注者ビューガイドラインとは
発注者ビューガイドラインは、「画面編」「システム振舞い編」「データモデル編」の3編により構成されます
本ガイドラインは、発注者ビューガイドライン（データモデル編）です
発注者ビューガイドラインは、発注者と開発者との認識の齟齬や、互いの意図とは異なる理解をしたことに気づかないま
ま開発が進んでしまう状態を防止することを目的として、発注者視点での設計書などドキュメントの記述やレビューに関
する「コツ」を集約・整理したものです。なお、「コツ」は、次の2つの観点に絞り、開発現場の設計事例から抽出しました
¾誤った理解を防ぐ、あるいは見つけ出すためのポイント ¾誤った理解に誘導したり、誤りの発見を困難にするポイント
発注者ビューガイドラインは、以下に示す情報システム開発に携わる関係者を対象として書かれています
¾情報システム開発を請け負う側である、SIベンダの従事者 ¾情報システム開発を発注する側である、ユーザ企業の情報システム部門、および業務部門の各ユーザ(2) 発注者ビューガイドラインの利用方法
発注者ビューガイドラインは、以下の利用方法が考えられます
①
各社の開発標準に沿った設計業務を補足するコツ集として
設計に関するドキュメントを介して、SIベンダの開発担当者間、あるいは開発担当者とユーザ企業の情報システム部門ユーザとの間のス ムーズな意思疎通をはかるために利用する②
各社の教育コンテンツとしての活用に向けた素材集として
SIベンダやユーザ企業の情報システム部門を中心に、各社の教育コンテンツとしての活用に向けた素材集として利用する③
レビューに臨む際の心得として
情報システム開発のステークホルダ間のコミュニケーションを円滑にするために、レビューのコツを利用するi. はじめに
(1) 情報システム開発における課題
情報システム開発には多様な関係者が絡み合っており、誤解や仕様のぬけ・誤りを防止し、開発を円滑に進めるために
はこれらの関係者間における十分な意思疎通が不可欠です。設計書には標準的な記述方法も使われますが、これらは
情報システム開発における開発者の視点が主体であるために、発注者との意思疎通は必ずしも円滑であるとはいえず、
プロジェクトごとに不足事項を適宜補完しているのが現状です
特に、開発者の説明が発注者にうまく伝わらないと、さまざまなトラブルが発生するだけでなく、情報システム開発が
失敗してしまいます
特に、開発者の説明が発注者にうまく伝わらないと・・・ さまざまなトラブルが発生するだけでなく、 情報システム開発が失敗してしまいますさまざまな
トラブル
設計書説明の ための多大な 労力 手戻りの発生 発注者の 不満 解釈の相違 仕様のぬけや 誤りの発覚開発者
発注者
？
ご説明
いたします
(2) 課題へのアプローチ
受発注者相互の合意を得るためには、目標とする情報システム像に対する認識を一致させることが必要です。しかし、
立場の違いによって、「見えるもの」「わかるもの」は異なり、開発者の書いた設計書がそのまま「発注者にとって見える
もの」であるわけではなく、受発注者間における認識の齟齬が起こりやすいのが現状です
そこで、発注者にとってわかりやすい仕様の記述方法、合意方法を検討する「実践的アプローチに基づく要求仕様の
発注者ビュー検討会」を発足させ、活動を開始しました。この検討会では、開発者の視点で書いた設計書を、発注者に
とって「見えるもの」「わかるもの」とするために、情報システム開発の各現場で行われている設計書の記述やレビュー
の工夫点を集約・整理しました
目標とする
情報システム像
発注者
の視点で見る開発者
の視点で書く 専門用語や図が使われた設計書発注者の視点で
"見える"・"わかる"
もの
認識の一致
目標とする
情報システム像
ii. 発注者ビューガイドライン作成の背景
(3) 発注者ビューの位置づけ
実践的アプローチに基づく要求仕様の発注者ビュー検討会では、開発者の視点で書いた設計書を発注者にとって「見
えるもの」「わかるもの」にする記述やレビューの方法を「発注者ビュー」と位置づけ、以下のとおり定義しました
発注者ビューの目的は次のとおりです
¾
発注者および開発者が「目標とする情報システム像」を共有すること
¾
発注者における「目標とするシステム像」との相違が後工程で発見されることを未然に防ぐために、 発注者
および開発者がシステムの外部設計を理解し、業務要件との不整合を発見し、是正結果を確認することを
促進すること
発注者ビューとは、外部設計工程における各種設計書に対する
発注者の理解容易性に貢献する伝達手段である
発注者ビューとは、外部設計工程における各種設計書に対する
発注者の理解容易性に貢献する伝達手段である
(1) 対象工程
発注者ビューガイドラインでは、受発注者の接点が大きい外部設計の工程に着目し、これを対象工程としました
SEC BOOKS 「経営者が参画する要求品質の確保」 では、「システム設計」のプロセスにおける、「画面・帳票などの
検討」「設計（外部）」の工程に該当しています
外部設計工程の設計要素には、業務の処理や流れなどのプロセスや、データ、インターフェースなどの機能要件や
運用、操作などに関する非機能要件が挙げられます。本ガイドラインでは、発注者との関わりが大きい設計要素とし
て、以下の3つの項目に着目しました
① 画面 z 画面および操作に関する外部設計要素 ② システム振舞い z 業務アプリケーションシステムが利用者または他システムに提供する機能および、それらの間の相互作用に関する 外部設計要素 ③ データモデル z 業務アプリケーションシステムで使用するデータに関する外部設計要素 システム化の方向性 システム設計 外部設計 内部設計 【情報システム開発のプロセス】 システム化計画 要件定義 システム開発 テスト 【発注者ビューガイドライン】 画面 画面 データモデル データモデル システム振舞いシステム振舞いiii. 発注者ビューガイドラインの対象範囲
(2) 想定するシステムとガイドラインとの対応
発注者ビューガイドラインでは、Webベースのアプリケーションシステムを想定し、「画面」「システム振舞い」「データモデ
ル」の3つの項目において設計書や関連する資料の表現や確認方法、レビューの方法を「コツ」として集約しました
■システム形態
Webベースの
アプリケーションシステム
Webベースを中心とした
サーバアプリケーション
データモデル
データモデル
「データモデル」の技術検討
「システム振舞い」の技術検討
「画面」の技術検討
(1) 工程成果物
発注者ビューガイドラインでは、情報システムの開発工程において作成され、発注者と合意する際に用いられる成果
物のことを「工程成果物」と称しています
外部設計工程の「工程成果物」は、現時点では標準とされる工程成果物が存在しません。このため、発注者ビュー
ガイドラインでは、 「画面編」「システム振舞い編」「データモデル編」の各編が対象とする工程成果物をそれぞれ定
義しました
(2) 設計書
要求仕様に基づき、設計したドキュメントは発注者に対し「設計書」として提示します。設計書は、受発注者間で合意
した方法や様式で記述されるため、設計書の作成単位や構成が、発注者ビューガイドラインで前提としている工程
成果物のそれと一致しないことがあります
¾ 例えば、発注者ビューガイドライン（データモデル編）では、工程成果物として「ER図」、「エンティティ一覧」、「エンティティ定義書」を定 義していますが、プロジェクトでは、これらを合わせて1つの「データモデル設計書」として記述する場合があります データモデル設計書 データモデル設計書 エンティティ定義書発注者
発注者
ER図 ER図 エンティティ一覧 エンティティ一覧 エンティティ定義書 エンティティ定義書 確認【工程成果物】
【設計書】
データモデル設計書iv. 発注者ビューガイドラインの前提
データモデル
データモデル
(1) データモデル編における工程成果物の定義
データモデル編では、以下の4種類の工程成果物を定義しました
¾データモデルを補足する説明資料やデータモデルを作成する上での規則などをその他資料として記述しています ¾工程成果物、およびその他資料以外にコツで取り上げる資料は、各コツで説明しています データ辞書 ユーザ企業内で利用するデータ をモデル化して表現したもの エンティティとリレーションを表現 するシンボルを用いて作図する ユーザ企業内で利用するデータに 関する規則集 ER図 データの最小単位である データ項目を定義 ドメイン一覧／定義書 データ項目定義書 コード一覧／定義書 データ項目をカテゴリ分け するための基準 データの内部構造や値が 決まっているデータ項目 の仕様を定義 その他資料 エンティティ一覧 エンティティの一覧 項番 エンティティ名 説明 1 顧客 ・・・ 2 商品 ・・・ 3 受注 ・・・ 項番 エンティティ名 説明 1 顧客 ・・・ 2 商品 ・・・ 3 受注 ・・・ エンティティ名およびエン ティティごとの属性の一 覧 エンティティ定義書 エンティティ名商品 項番 属性名 型 桁 PK 説明 1 商品番号 X 10 P・・・ 2 商品名 X 100 ・・・ 3 商品区分コードX 3 ・・・ ・・・ エンティティ名商品 項番 属性名 型 桁 PK 説明 1 商品番号 X 10 P・・・ 2 商品名 X 100 ・・・ 3 商品区分コードX 3 ・・・ ・・・ 業務とエンティティの関係を表 現したもの CRUD図 エンティティ 顧客 受注 受注 明 細 機能 顧客登録 受注登録 受注明細登録 顧客検索 C R R R C R C 製品 R エンティティ 顧客 受注 受注 明 細 機能 顧客登録 受注登録 受注明細登録 顧客検索 C R R R C R C 製品 R ファイル一覧／定義書 システム間でやりとりされ るデータファイルの一覧／ 詳細(2) データモデル編におけるレビュー時期の想定
データモデル編では、レビューによる合意形成の成熟度の観点から、以下の3つのレビューの時期を想定しました
充実期
完成期
仕掛期
外部設計
要件定義
内部設計
合意の成熟度の観点から見て前期、
合意形成を開始、
レビュー対象となる工程成果物の量
が大幅に増加するフェーズ
合意の成熟度の観点から見て中期、
合意形成が大幅に成熟、
工程成果物の量は小幅に増加、
バグ発見と修正が主となるフェーズ
合意の成熟度の観点から見て後期、
合意の成熟を達成、
工程成果物の量や修正数は安定、
承認が主となるフェーズ
v. 発注者ビューガイドライン（データモデル編）の前提
(1) 各部の構成
ガイドラインは、「第1部 表現」 「第2部 記述確認」 「第3部 レビュー」 「第4部 レビュー時の確認」の4部から構成され
ています
「第1部 表現」は、データモデルに関する工程成果物や補足資料の記述方法についてのコツをまとめたものです
第1章では、データモデルで扱う工程成果物について解説しています。また、第2章では、工程成果物ごとにコツを記
述しています
「第2部 記述確認」は、設計書の記述や表現に注意すべき事項を一覧表にまとめています
「第3部 レビュー」は、発注者と開発者とで実施するデータモデルのレビューについてのコツをまとめたものです
レビューについてのコツは、設計活動の観点で分類しています。第1章では、分類に用いた設計活動を解説していま
す。また、第2章では、分類ごとにコツを記述しています
「第4部 レビュー時の確認」は、発注者と開発者とのレビュー時に確認しておくべき事項を一覧表にまとめています
¾コツの具体例については、その説明に適した題材を用いて記述しています(2) 発注者ビューガイドライン（データモデル編）の記述範囲外の事項
発注者に対して、開発側でまとめた仕様を提示する際の、設計書の作成単位や構成には多様な組み合わせが考え
られますが、本ガイドラインではこれら設計書のバリエーションを網羅していません。設計書の単位を工程成果物と
一致させるのか、および、設計書の内容構成については個々のプロジェクトにおける判断が必要です
本ガイドラインを作成するにあたって複数の既存の手法を参考にしていますが、本ガイドラインは、特定のデータモ
デリング手法やデータモデリング用のツールを推奨するものではありません
vi. 発注者ビューガイドライン（データモデル編）の構成
はじめに
「第1部 表現」は、データモデルの工程成果物の記述方法についてのコツをまとめていま
す
第1章では、工程成果物について説明します
第2章で説明する表現のコツの見方は下記のとおりです
【コツの分類】
コツを適用する工程成
果物を記述しています
【コツの目的】
コツを適用する目的を
記述しています
【コツの説明】
コツの内容を記述して
います。また、コツに
はそれぞれ番号を付
加しています
【コツの補足】
コツの補足を記述しています
【コツの適用例】
コツを具体的に適用し
た記述例です
【コツの補足】
コツの補足を吹き出し
で記述しています
第1章 工程成果物の定義
情報のまとまりを「エンティティ(Entity)」、情報の相互関係を
「リレーションシップ(Relationship)」で表したものである
エンティティ一覧、エンティティ定義書と共に、業務で取り扱うデータ構造を発注者に
確認できる
¾
ER図は「エンティティ」を表す図形をその「リレーションシップ」を示す線で連結した表現が基本であるが、
厳密には数多くの表記が存在する。現在よく用いられるのがIE(Information Engineering)表記と
IDEF1X(ICAM DEFinition Language)表記である。本ガイドラインではIDEF1X表記を用いる
製品 製品番号 製品名 製品単価 製 品 分 類 番 号 ( F K ) 受注明細 受 注 番 号 ( F K ) 受注明細番号 製 品 番 号 ( F K ) 数量 受注価格 受注 受注番号 受注年月日 顧 客 番 号 ( F K ) 顧客 顧客番号 顧客名 住所 電話番号 製品分類 製品分類番号 製品分類名
ER図の例
1.2 エンティティ一覧
エンティティを識別する名称の一覧である
ER図やエンティティ定義書の目次的な位置づけとなり、エンティティ毎の簡単な説明を補足できる
¾
エンティティ名とその定義を記述する
¾
エンティティの性質を表す分類や、主管理部門、データが発生するタイミングなど、プロジェクトの性質に応じて
補足する説明を記述する
¾
エンティティの個数によらず極力作成した方が良い
エンティティ一覧の例
システム名
○○○○○○○
No.
エンティティ名
エンティティ種別（注）
定
義
1 顧客
リソース系
2 製品分類
リソース系
3 製品
リソース系
4 受注
イベント系
5 受注明細
イベント系
顧客の個人情報
受注の基本情報
受注における明細部分
各製品の基本情報
製品分類コードの定義
（注） イベント系エンティティ：受注、発注などの業務活動によって発生・増加する情報を管理するエンティティ リソース系エンティティ：商品マスタ、倉庫マスタなど、イベント系エンティティから参照される、実際に存在するモノを管理するエンティティ
エンティティの格納単位毎のレイアウトと従属する項目内容を表したものである
属性の説明といったエンティティ毎の詳細情報を記述し、発注者に確認できる
¾
属性名と属性の定義を記述する
¾
属性の型、長さ、設定される条件など、プロジェクトに応じて補足する説明を記述する
エンティティ定義書の例
システム名
エンティティ名
○○○○○○○
製品
No.
属 性 名
型
長さ
精度 必須 主キー
属 性 説 明
1 製品番号
数値型
10
0
Y
1
2 製品名
テキスト型
255
0
Y
3 製品単価
数値型
8
0
Y
4 製品分類番号 (FK) 数値型
10
0
Y
製品の単価
この製品の分類番号
エンティティ説明
製品情報を管理する
製品毎に１レコードを用意する
最新情報のみが格納される
製品毎に振られた識別子
製品名称
1.4 CRUD図
エンティティのインスタンスがどの機能で作成：Create､参照：Read､更新：Update､削除：Delete
されるかを、エンティティと機能とのマトリックスで表現したものである
エンティティ、あるいは機能のもれを効率よく発見できる
¾
エンティティと機能との組み合わせだけでなく、業務や組織とのマトリックスとして、異なる視点で整理できる
顧
客
製
品
受
注
受
注
明
細
顧客登録
C
顧客検索
R
受注登録
R
R
C U
C
受注検索
R
R
R
エンティティ
機
能
※一般にCRUD図そのものを発注者に対しレビューをすることは少ないが、これを用いた検証結果が
レビュー対象となることを考慮し、本ドキュメントでは工程成果物として取り上げる
CRUD図の例
2.1 表現のコツ一覧
コツID コツの説明 コツの分類 MD1001 エンティティをタイプ分けして、色で表現する ER図中のエンティティにインスタンスの作成、および更新の時期を記述する 業務単位にER図を作成する イベント系エンティティをデ－タの発生順で記述する エンティティ一覧にデ－タの主管部署を記述する エンティティ一覧に業務名、エンティティの種別を記述する エンティティ一覧にデ－タ件数や保存期間などを記述する エンティティおよび属性の抽出元を記述する エンティティ一覧において旧システムのデ－タモデルからの変更点を明記する CRUD図のCreate,Read,Update,Delete記述欄を固定する CRUD図のエンティティをイベント系エンティティとリソ－ス系エンティティに分離し て記述する CRUD図のビジネスプロセスを実際の業務の時系列順に並べる CRUD図のイベント系エンティティをエンティティを作成する順番に沿って並べる デ－タフロ－図にイラストを使用する 処理で利用するデ－タの入出力を図を利用して記述する 処理の間を流れるデ－タとその状態を記述した図表を作成して説明する ER図の表現のコツ ER図の表現のコツ ER図の表現のコツ ER図の表現のコツ エンティティ一覧／定義書の表現のコツ エンティティ一覧／定義書の表現のコツ エンティティ一覧／定義書の表現のコツ エンティティ一覧／定義書の表現のコツ エンティティ一覧／定義書の表現のコツ CRUD図の表現のコツ CRUD図の表現のコツ CRUD図の表現のコツ CRUD図の表現のコツ デ－タのフロ－等の表現のコツ MD3001 MD3002 MD3003 MD3004 MD4001 MD4002 デ－タのフロ－等の表現のコツ デ－タのフロ－等の表現のコツ MD4003 MD1002 MD1003 MD1004 MD2001 MD2002 MD2003 MD2004 MD2005
工程成果物に着目した設計書の表現のコツは次のとおり
Z Z P P Z 発注 発注番号 仕入先番号 (FK) 社員番号 (FK) 発注区分 受注(注文)明細 受注明細番号 受注番号(注文番号) (FK) 商品番号 (FK) 受注数量 値引き額 消費税額 金額計 仕入先 仕入先番号 社員 社員番号 社員氏名 営業所 営業所コード 営業所名 受注(注文) 受注番号(注文番号) 受注ユーザID (FK) 出荷先ユーザID (FK) 受注社員番号 (FK) 受注営業所コード (FK) 受注日 納入希望日 顧客先注文番号 税込合計額 出荷/売上明細 売上明細番号 売上番号 (FK) 商品番号 (FK) 出荷数量 商品原価 入荷/仕入 入荷番号 倉庫番号 (FK) 仕入先番号 (FK) 社員番号 (FK) 受注_発注 受注番号(注文番号) (FK) 発注番号 (FK) 発注_入荷 発注番号 (FK) 入荷番号 (FK) 受注_出荷 受注番号(注文番号) (FK) 売上番号 (FK) 登録ユーザ ユーザID 顧客名 顧客郵便番号 顧客住所 顧客電話番号 出荷/売上 売上番号 倉庫番号 (FK) 社員番号 (FK) 出荷指示番号 倉庫 倉庫番号 倉庫名 倉庫住所 倉庫電話番号 倉庫FAX番号 倉庫区分 社員_営業所 営業所コード (FK) 社員番号 (FK)
ER図をわかりやすく表現するには
MD1001：エンティティをタイプ分けして、色で表現する
¾
レビューのポイントとなるタイプにピンクや赤など、インパクトのある色を用いて、視覚的に概観を掴みやすくする
¾
分類するタイプとしては、各種方法論にて多様な定義が存在する。下記に例をあげる
z例１ イベント／リソース系エンティティ（あるいはリソース系エンティティを組織・場所・モノまで詳細に分けたもの）といった 業務に依存しない分類 z例２ 販売・出荷・支払といった業務依存の分類無色のER図の例
緑 ：リソース
イベント／リソースに分類し、イベントをピンクにした例
ピンク：イベント
Z P P Z Z 発注 発注番号 仕入先番号 (FK) 社員番号 (FK) 発注区分 受注(注文)明細 受注明細番号 受注番号(注文番号) (FK) 商品番号 (FK) 受注数量 値引き額 消費税額 金額計 仕入先 仕入先番号 社員 社員番号 社員氏名 営業所 営業所コード 営業所名 受注(注文) 受注番号(注文番号) 受注ユーザID (FK) 出荷先ユーザID (FK) 受注社員番号 (FK) 受注営業所コード (FK) 受注日 納入希望日 顧客先注文番号 税込合計額 出荷/売上明細 売上明細番号 売上番号 (FK) 商品番号 (FK) 出荷数量 商品原価 社員_営業所 営業所コード (FK) 社員番号 (FK) 入荷/仕入 入荷番号 倉庫番号 (FK) 仕入先番号 (FK) 社員番号 (FK) 受注_発注 受注番号(注文番号) (FK) 発注番号 (FK) 発注_入荷 発注番号 (FK) 入荷番号 (FK) 受注_出荷 受注番号(注文番号) (FK) 売上番号 (FK) 登録ユーザ ユーザID 顧客名 顧客郵便番号 顧客住所 顧客電話番号 出荷/売上 売上番号 倉庫番号 (FK) 社員番号 (FK) 出荷指示番号 倉庫 倉庫番号 倉庫名 倉庫住所 倉庫電話番号 倉庫FAX番号 倉庫区分イベントに着目すると、受注⇒発注⇒入荷⇒出荷／売上という
業務の流れが読み取れる
2.2 ER図の表現のコツ
ER図の理解を促進させるには
MD1002：ER図中のエンティティにインスタンスの作成、および更新の時期を記述する
¾
業務とエンティティのおおよその関係が把握可能となる
ER図に作成、および更新の時期を記載した例
出版社 出版社ID 出版社名 出版社住所 改訂 ISB N ( F K) 改訂版 改訂日 販売 ISB N ( F K) 店舗ID ( F K) 販売数 最終販売日 書籍 ISBN 書籍名 著者 初版発行日 販売価格 出版社ID ( F K) 店舗 店舗ID 店舗名 店舗住所 ・書籍販売時 ・改版実施時 ・書籍登録時 ・書籍登録時 ・書籍販売時 ・店舗登録時書籍販売時、店舗情報
も登録することがわかる
書籍登録時、出版社情報
も登録することがわかる
ER図の理解を促進させるには
MD1003：業務単位にER図を作成する(1/2)
¾
エンティティの関係が深いものどうしでグルーピ
ングしているので、業務に関係があるエンティ
ティに集中できる
業務名
受注業務と調達業務
業務名
受注業務
業務名
調達業務
受注 受注NO 受注登録者 ( F K) 出荷手配 出荷手配NO 手配登録者 ( F K) 受注N O ( F K) 受注明細 受注N O ( F K) 受注明細NO 商品コ ー ド ( F K) 出荷手配明細 出荷手配N O ( F K) 出荷手配明細NO 商品コ ー ド ( F K) 出荷実績明細 出荷実績N O ( F K) 出荷実績明細NO 商品 商品コード 商品名 出荷実績 出荷実績NO 出荷手配N O ( F K) 従業員マスタ 従業員番号 従業員氏名 発注 発注NO 従業員番号 ( F K) 入荷 入荷NO 従業員番号 ( F K) 発注N O ( F K) 発注明細 発注N O ( F K) 発注明細NO 商品コ ー ド ( F K) 入荷明細 入荷N O ( F K) 入荷明細NO 商品コ ー ド ( F K) 従業員マスタ 従業員番号 従業員氏名 商品 商品コード 商品名 発注 発注NO 従業員番号 ( F K) 受注 受注NO 受注登録者 ( F K) 出荷手配 出荷手配NO 手配登録者 ( F K) 受注N O ( F K) 出荷実績 出荷実績NO 出荷手配N O ( F K) 受注明細 受注N O ( F K) 受注明細NO 商品コ ー ド ( F K) 出荷実績明細 出荷実績N O ( F K) 出荷実績明細NO 商品 商品コード 商品名 発注明細 発注NO ( F K) 発注明細NO 商品コ ー ド ( F K) 入荷明細 入荷N O ( F K) 入荷明細NO 商品コ ー ド ( F K) 従業員マスタ 従業員番号 従業員氏名 入荷 入荷NO 従業員番号 ( F K) 発注N O ( F K) 出荷手配明細 出荷手配N O ( F K) 出荷手配明細NO 商品コ ー ド ( F K)受注、調達業務を1つのER図に記載した例
重複して記載しておく
重複して記載しておく
業務単位にER図を分けて作成する
受注、調達業務毎にER図を分けて記載した例
（画面、帳票などの情報から）ER図を作成する過程で、
ともするとER図が複雑になり、見にくくなってしまう
2.2 ER図の表現のコツ
ER図の理解を促進させるには
MD1003：業務単位にER図を作成する(2/2)
¾
業務単位に分割するため明確なルールはないが、以下のような点に着目するとよい
業務との関連に着目する
同一業務の中で、生成、使用されるイベント系エンティティを中心に、関連するエンティティをグルーピングする
同一業務の中で、さらにイベント系エンティティが生成されるサイクル（日次、月次など）に着目し、関連するエ
ンティティをグルーピングする
全体の構造に着目する
データ構造の関連性から、エンティティの関連が希薄な箇所で切り分ける
エンティティの数が、20～30(A3一枚に記述できる範囲）を目安とする
エンティティの数が少ないならば、グルーピング毎に背景色を変えることでER図を見やすくする
【ER図分割の観点】
顧客 顧客番号 顧客名 住所 電話番号 受注 受注番号 顧客番号 (FK) 受注年月日 商品 商品番号 商品名 商品単価 受注明細 受注番号 (FK) 商品番号 (FK) 受注数量 納品 納品番号 受注番号 (FK) 納品年月日 納品明細 納品番号 (FK) 商品番号 (FK) 受注番号 (FK) 販売計画 販売計画番号 製品番号 販売予定数量 販売実績 商品番号 販売年月日 販売数量 合計金額
ER図に業務の流れを反映するには
MD1004：イベント系エンティティをデータの発生順で記述する
¾
ER図上のエンティティを意味のある配置にすることで、システム化業務フローに沿ったデータの発生順が理解し
やすくなる
ER図の例
計画
受注
納品
データを出力するシステ
ム化業務の順序
集計
2.3 エンティティ一覧／定義書の表現のコツ
データモデルに業務の担当を反映するには
MD2001：エンティティ一覧にデータの主管部署を記述する
¾
データを作成／削除する部署を限定することで、データへアクセスする機能の分散／重複を防止できる
¾
設計時のデータ要件まとめ部署、および運用時のデータ主管部署が明確になる
項番 エンティティ名 説明 ・・・ 担当部署 １ 社員 自社の社員をあらわす 人事 ２ 組織 社員が所属する組織をあらわす 人事 ７ 出荷明細 出荷の明細情報をあらわす 販売 ８ 販売計画 販売の年間予測をあらわす 販売企画 ３ 顧客 取引先企業をあらわす 営業 ４ 受注 受注の基本情報をあらわす 販売 ５ 受注明細 受注の明細情報をあらわす 販売 ６ 出荷 出荷の基本情報をあらわす 販売エンティティ一覧の例
データの責任所在を記述する
エンティティの性質をエンティティ一覧で表現するには
MD2002：エンティティ一覧に業務名、エンティティの種別を記述する
エンティティ一覧記載例
項番 エンティティ名 エンティティ説明 受注 受注の基本情報を表す 0002 受注明細 受注の明細情報を表す 販売 イベント系エンティティ 0003 商品マスタ 販売を目的とした財を表す 在庫 リソース系エンティティ 生産財は含まない 0004 発注 発注情報を表す 調達 イベント系エンティティ 0005 倉庫マスタ 商品を保管する場所を表す 在庫 リソース系エンティティ 0006 商品別売上高 商品別売上集計情報を表す 損益 サマリ系エンティティ 0007 取引先別売上高 取引先別売上集計情報を表す 損益 サマリ系エンティティ 業務名 エンティティ種別（注） 備考 0001 販売 イベント系エンティティデータの移行、試験データ作成などの計画策定に必要な情報となる
（注） イベント系エンティティ：受注、発注など業務活動によって発生・増加する情報を管理するエンティティ リソース系エンティティ：商品マスタ、倉庫マスタなど、イベント系エンティティから参照される、実際に存在するモノを管理するエンティティ サマリ系エンティティ：売上高など、業務活動によって発生した情報の集計結果を管理するエンティティ一覧に記載した種別とER図の色分けやグルーピングと相違しないこ
とを確認すると、エンティティの性質をより理解できる（MD1001参照)
2.3 エンティティ一覧／定義書の表現のコツ
データモデルに業務量を反映するには
MD2003：エンティティ一覧にデータ件数や保存期間などを記述する
¾
データの保存期間（削除のタイミング）が、データ構造を決めるひとつの根拠となる
¾
データ件数の初期値、最大値、増加率を記述し、データを格納するリソース量の見積もり、データの運用設計の
入力情報にする
項番 エンティティ名 説明 ・・・ 保存期間 理由 １ 社員 自社の社員をあらわす 永年 永年 永年 ５年 ５年 ５年 ５年 － ２ 組織 社員が所属する組織をあらわす － ７ 出荷明細 出荷の明細情報をあらわす 社内規則２０ ３ 顧客 取引先企業をあらわす － ４ 受注 受注の基本情報をあらわす 社内規則１０ ５ 受注明細 受注の明細情報をあらわす 社内規則１０ ６ 出荷 出荷の基本情報をあらわす 社内規則２０エンティティ一覧の例
法律やユーザ企業内の規則など保存
期間を設定した理由を併記すること
が望ましい
エンティティ抽出の根拠を示すには
MD2004：エンティティおよび属性の抽出元を記述する
¾
発注者は、現行システムで利用している用語でデータの意味を理解している
項番 エンティティ名 説明 ・・・ 抽出元 １ 社員 自社の社員をあらわす 社員（テーブル） ２ 組織 社員が所属する組織をあらわす 社員（テーブル） ３ 顧客 取引先企業をあらわす 受注伝票（ファイル） ４ 受注 受注の基本情報をあらわす 受注伝票（ファイル） ５ 受注明細 受注の明細情報をあらわす 受注伝票（ファイル）エンティティ一覧の例
抽出元 項番 属性 型 桁 ・・・ テーブル／ファイル 属性 社員（テーブル） 社員（テーブル） 社員（テーブル） 社員（テーブル） 社員（テーブル） １ 社員番号 ＩＤ ２ 社員名 氏名 ３ 生年月日 生年月日 ４ 性別 性別 ５ 組織コード 組織名エンティティ定義書の例
新システムを開発する際、対象とす
る業務の現行システムが存在する
場合に、現行システムでの帳票や
台帳、テーブルを記述する
2.3 エンティティ一覧／定義書の表現のコツ
データモデルの変更点を確認するには
MD2005：エンティティ一覧において旧システムのデータモデルからの変更点を明記する
¾
データモデルの変更が軽微なシステムの更新時に適用
¾
旧バージョンからの変更点を一覧で確認できる
項番 エンティティ名 エンティティ_ID エンティティ概要 Ver.1.0.2での変更点 備考 1 書籍 BOOK 書籍を表現する 変更なし 変更なし 属性「オンラインショップ販売売 上」追加 新規追加 2 出版社 PUB_COMPANY 書籍に対応する出版社を表現 する 店舗別売上管理業務の追加に対応 3 販売 SALES 書籍の販売情報を保持する 4 店舗 STORE 書籍の販売を行う店舗を表現 する 店舗別売上管理業務の追加に対応エンティティ一覧の例
変更されたエンティティ
と属性を明記する
ビジネスプロセス
画面
C
C
R
R
R
R
R
R
U
R
R C
R
R
R
R
R C
R
R
受注
受注入力画面
受注修正画面
出荷入力画面
請求入力画面
出荷
請求
請
求
顧
客
商
品
イベント系エンティティ
リソース系
エンティティ
エンティティ
受
注
受
注
明
細
出
荷
CRUD図をわかりやすく表現するには
MD3001：CRUD図のCreate,Read,Update,Delete記述欄を固定する
¾
Create,Read,Update,Deleteの位置が縦に揃うため、Create,Read,Update,Deleteのないエンティティを発見しやすい
C
R
U
D
C
R
U
D
このように横一列に記
述する方法もある
このように
Create,Read,Update,
Deleteの記述欄を固定
すると見やすい
ビジネスプロセス 画面 C C R R R R R R U R R C R R R R R C R R C R U R U 顧客メンテナンス 顧客登録画面 顧客修正画面 商品メンテナンス 商品修正画面 請 求 顧 客 商 品 イベント系エンティティ エンティティリソース系 エンティティ 受 注 受 注 明 細 出 荷 受注 受注入力画面 受注修正画面 出荷入力画面 請求入力画面 出荷 請求
2.4 CRUD図の表現のコツ
CRUD図をわかりやすく表現するには
MD3002：CRUD図のエンティティをイベント系エンティティとリソース系エンティティに分離して記述する
¾
イベント系エンティティとリソース系エンティティが分離されていない場合、どのエンティティがイベント系エンティ
ティか明確にわからないため、業務のもれが発見しにくい
（注） イベント系エンティティ：受注、発注などの業務活動によって発生・増加する情報を管理するエンティティ リソース系エンティティ：顧客マスタ、商品マスタなど、イベント系エンティティから参照される、実際に存在するモノを管理するエンティティイベント系エンティティのうちCreateや
Updateがないエンティティが存在する場合
は業務がもれている可能性があるが、イベ
ント系エンティティとリソース系エンティティ
が分離されていない場合どのエンティティ
がイベント系エンティティか明確にわからな
いため、業務のもれが発見しにくい
CRUD図をわかりやすく表現するには
MD3003：CRUD図のビジネスプロセスを実際の業務の時系列順に並べる
¾
業務の流れに沿ってレビューをする際に説明がしやすくなる
ビジネスプロセス
受注
出荷
請求
ビジネスプロセスを実際の業務の時系列と同じように
上から下へ順番に並べることにより、レビューの際に
CRUD図の検証または確認がしやすくなる
ビジネスプロセス
画面
C
C
R
R
R
R
R
R
U
R
R C
R
R
R
R
R C
R
R
受注
受注入力画面
受注修正画面
出荷入力画面
請求入力画面
出荷
請求
請
求
顧
客
商
品
イベント系エンティティ
リソース系
エンティティ
エンティティ
受
注
受
注
明
細
出
荷
請
求
顧
客
商
品
イベント系エンティティ
リソース系
エンティティ
エンティティ
受
注
受
注
明
細
出
荷
2.4 CRUD図の表現のコツ
CRUD図をわかりやすく表現するには
MD3004：CRUD図のイベント系エンティティをエンティティを作成する順番に沿って並べる(1/2)
¾
【MD3003】と併せることでCreateが左上から右下に並ぶことが多くなるため、例外的な処理を見つけやすくなる
データモデル
受注
出荷
請求
エンティティを作成する順番
に左から右に配置する
受注コード
出荷コード
請求コード
受注コード(FK)
出荷コード(FK)
受注コード(FK)
ビジネスプロセス
画面
C
C
R
R
R
R
R
R
U
R
R C
R
R
R
R
R C
R
R
受注
受注入力画面
受注修正画面
出荷入力画面
請求入力画面
出荷
請求
請
求
顧
客
商
品
イベント系エンティティ
リソース系
エンティティ
エンティティ
受
注
受
注
明
細
出
荷
CRUD図をわかりやすく表現するには
MD3004： CRUD図のイベント系エンティティをエンティティを作成する順番に沿って並べる(2/2)
¾
【MD3003】と併せることでCreateが左上から右下に並ぶことが多くなるため、例外的な処理を見つけやすくなる
ビジネスプロセスは時系列順に上から下へ、エンティティ
は作成順に左から右へ配置されているため、基本的に
生成タイミング（C）が左上から右下に並ぶ
2.5 データのフロー等の表現のコツ
発注者がデータフロー図の構成要素を区別しやすくするには
MD4001：データフロー図にイラストを使用する
¾
イラスト入りの表現形式でデータフロー図を表現することで、構成要素同士の違いが明確になる
イラストなしのデータフロー図の例
イラスト入りのデータフロー図の例
凡例 ：データフロー（イラストを付加） ：プロセス ：データストア ：外部名 なお、イラストは外部名を示すイラストに変更する
データフロー図とは、システムにおける データの流れ（フロー）に着目して表現した 図である。使用する記号には4種類あり、 矢印がデータフロー、円がプロセス、二重 線がデータストア、四角が外部名を示す注文
顧客
出荷
出荷指示書倉庫
注文受付
注文情報
出荷指示書
出荷
注文受付
顧客
倉庫
注文情報
注文書
出荷情報
出荷情報
注文書 注文出荷完了
出荷完了
データの流れをわかりやすく表現するには
MD4002：処理で利用するデータの入出力を図を利用して記述する
¾
文章で表現するよりどの処理でどのようなデータを入力してどこに出力するのかがわかりやすい
入力
処理
出力
●ユーザ入力
●利用エンティティ
出荷情報
検索入力画面
出荷情報
検索結果画面
●画面出力
顧客
受注
受注明細
出荷
出荷情報
検索処理
IPO（入力-処理-出力を表で表したもの）の入力と出力の部分を図を利用してわかり
やすく表現した例
データの入出力をわかりやすく表現するのが目的なので、詳しい処理は記述しない
検索条件
各種情報
検索結果
<凡例>
：画面
：エンティ
ティ
：処理
2.5 データのフロー等の表現のコツ
状態の変化をわかりやすく表現するには
MD4003：処理の間を流れるデータとその状態を記述した図表を作成して説明する(1/2)
¾
各処理でデータの状態がどのように変化するのかがわかりやすい
1.申請／提出 3.管理確認① 2.未承認確認 5.人事管理 4.管理確認② term <0.申請> <4.再申請> <3.未承認> <3.未承認> <5.取下げ> <1.管理者承認済> <9.承認済> <9.承認済> <9.承認済> <2.人事代理承認済><凡例>
：処理名称 ：状態
状態の変化をわかりやすく表現するには
MD4003：処理の間を流れるデータとその状態を記述した図表を作成して説明する(2/2)
¾
各処理でデータの状態がどのように変化するのかがわかりやすい
No. 処理名称 処理概要 入力される状態 出力される状態 条件 1 申請／提出 各種申請書の申請、または勤怠 の提出を行う なし 0.申請 各種申請／勤怠提出を行った場合 2 未承認確認 管理者、または人事により未承認 となった各種申請または勤怠を修 正し、再申請または取下げを行う 3.未承認 4.再申請 5.取下げ 再申請／提出を行った場合 各種申請を取下げた場合 3 管理確認① 各種申請、または勤怠の確認お よび承認を行う 0.申請 4.再申請 1.管理者承認済 2.人事代理承認済 3.未承認 9.承認済 内容に不備がなく人事承認を行った場合 人事管理者による代理承認した場合 内容に不備がある場合 内容に不備がなく人事承認を必要としない場合 または、人事管理者が承認した場合 4 管理確認② 人事管理者により承認されている 各種申請または勤怠の確認を行 う 2.人事代理承認済 9.承認済 管理者が確認した場合 5 人事管理 管理者による承認済の各種申請 または勤怠の確認および承認を 行う 1.管理者承認済 3.未承認 9.承認済 内容に不備がある場合 内容に不備がなく全承認業務が終了する場合
第2部 記述確認では、設計書の記述や表現に注意すべき事項について、第1
部 表現 の2章に記した「設計書記述のポイント」と、設計書を記述する上で積
極的に確認すべき観点を一覧表としてまとめました。プロジェクトの進捗状況に
より適宜参考にしてください
第1章 設計方針のチェックリスト
設計方針のチェックリストは、以下の2点の内容を一覧表にまとめたものである
「第1部 表現」の2章に記した「設計書記述のポイント」の「表現のコツ一覧」
¾
プロジェクトにおいて採用することとなった「第1部 表現」の2章「設計書記述のポイント」に記した「表現
のコツ」が、設計書に適用されているかどうかを確認できるよう、チェックリストの形式に整理した
¾
「表現のコツ」に対応するコツIDをチェックリストの「コツID」欄に記述した
設計書を記述する上で積極的に確認すべき観点
¾
主に、 「第1部 表現」の2章「設計書記述のポイント」の検討過程において、"コツには至らないが、 重
要な観点である"と判断した事項を集約したものである。このため、各チェック項目内容にはばらつきが
あるためご留意いただきたい
¾
「表現のコツ」との判別のために、チェックリストの「コツID」欄には「－」を記述した
設計方針のチェックリストは、「第1部 レビュー」の1章「工程成果物の定義」の工程成果
物を基本とした分類により整理されており、各チェック項目に対する補足説明を補足事項
欄に記している
1.
工程成果物に関する事項
¾
各工程成果物に対し個別に確認すべき事項。工程成果物ごとに確認する
2.
工程成果物について共通的な事項
¾
各工程成果物に対して共通に確認すべき事項。各工程成果物に限らず共通的に確認する
設計書を記述する過程における備忘録として、またはレビュー実施前の確認リストとして、
プロジェクトにおいて適宜具体的なチェック方法に置き換えてご使用いただきたい
1 めてしまうと、同一のデータ項目の名称の不 一致や、型／桁／精度の不整合が発生しや すい。 整理・統一したデータ項目を使用してデータ モデルや画面を設計することで、データ項目 の不整合を防止する。 ― 2 共通の表現 のコツ データに関する制約条件をデータ辞書で管 理する 業務アプリケーションで発生するDBアクセス 時の制約条件（NULL可／不可、桁、精度の 制限など）をデータ辞書で管理しておくと、複 数業務アプリケーション間の矛盾を発見しや すくなる。 また、テスト工程でのテストデータ作成を効 率よく行える。 ― 3 共通の表現 のコツ モデリングツールを使用する データモデリングツールを使用することで、 以下のメリットがある。 ・表記法の統一 ・外部キーの型一致 ・ドメイン定義利用によるドメインの共有 ・リバース機能による物理DBとの整合 ― 4 ER図の表現 のコツ エンティティをタイプ分けして、色で表現す る レビューのポイントとなるタイプにピンクや赤 など、インパクトのある色を用いて、視覚的 に概観を掴みやすくする。 分類するタイプとしては、各種方法論にて多 様な定義が存在する。以下にタイプの例をあ げる。 ・イベント／リソース系エンティティ（あるいは リソース系エンティティを組織・場所・モノまで 詳細に分けたもの）といった業務に依存しな い分類 ・販売・出荷・支払といった業務依存の分類 MD1001 5 ER図の表現 のコツ ER図中のエンティティにインスタンスの作 成、および更新の時期を記述する 業務とエンティティのおおよその関係が把握 可能となる。 MD1002 6 ER図の表現 のコツ 業務単位にER図を作成する エンティティの関係が深いものどうしでグ ルーピングしているので、業務に関係がある エンティティに集中できる。 MD1003 7 ER図の表現 のコツ イベント系エンティティをデータの発生順で 記述する ER図上のエンティティを意味のある配置にす ることで、システム化業務フローに沿った データの発生順が理解しやすくなる。 MD1004
ID コツの分類 コツの説明 コツの補足 コツID プロジェクトにおける採用方針 適用確認欄 8 ER図の表現 のコツ 外部キーと継承元の属性の関連を、コメン トを利用してER図上に記述する 多くのER図の表記法には、外部キーと継承 元の属性を直接的に対応づける手段がな い。 コメントを利用して外部キーと継承元の属性 との関連を記述することで、ER図上で属性 の親子関係を明確にできる。 ― 9 エンティティ 一覧／定義 書の表現の コツ エンティティ一覧にデータの主管部署を記 述する データを作成／削除する部署を限定すること で、データへアクセスする機能の分散／重複 を防止できる。 設計時のデータ要件まとめ部署、および運 用時のデータ主管部署が明確になる。 MD2001 10 エンティティ 一覧／定義 書の表現の コツ エンティティ一覧に業務名、エンティティの 種別を記述する 一覧に記述した種別とER図の色分けやグ ルーピングと相違しないことを確認すると、エ ンティティの性質をより理解できる（MD1001 参照)。 データの移行、試験データ作成などの計画 策定に必要な情報となる。 MD2002 11 エンティティ 一覧／定義 書の表現の コツ エンティティ一覧にデータ件数や保存期間 などを記述する データの保存期間（削除のタイミング）が、 データ構造を決めるひとつの根拠となる。 データ件数の初期値、最大値、増加率を記 述し、データを格納するディスク容量の見積 もり、データの運用設計の入力情報にする。 MD2003 12 エンティティ 一覧／定義 書の表現の コツ エンティティおよび属性の抽出元を記述す る 発注者は、現行システムで利用している用 語でデータの意味を理解している。 新システムを開発する際、対象とする業務の 現行システムが存在する場合に、現行シス テムでの帳票や台帳、テーブルを記述する。 MD2004 13 エンティティ 一覧／定義 書の表現の コツ エンティティ一覧において旧システムの データモデルからの変更点を明記する データモデルの変更が軽微な場合に適用す る。 旧バージョンからの変更点を一覧で確認で きる。 MD2005 14 エンティティ 一覧／定義 書の表現の コツ 主キーが同じという理由だけで、エンティ ティを一つに纏めないようにする 主キーとなる属性が同じであっても、データ の発生・更新タイミングが異なる属性や、性 質が異なる属性が存在する。それらを別の エンティティに切り出すことで、業務で扱う データのまとまりとエンティティが近くなるた め、発注者に理解してもらいやすくなる。 また、1エンティティ内の属性数を少なく(適度 な数に)保てるため、性能面で問題が生じに くい。 ―
15 書の表現の コツ 性の詳細仕様(コード仕様)が明確になる。 また、エンティティ定義書の属性ごとにコード 仕様を記述する場合に比べ、修正もれが発 生しにくい。 ― 16 エンティティ 一覧／定義 書の表現の コツ 全文検索の対象項目を明記する 全文検索の有無により、物理構成が異なる のが一般的である。 エンティティ定義書の属性に全文検索対象 であるかを記述しておくと、物理構成への影 響を把握できる。 ― 17 CRUD図の 表現のコツ CRUD図のCreate,Read,Update,Delete記述 欄を固定する Create,Read,Update,Deleteの位置が縦に揃 うため、Create,Read,Update,Deleteのないエ ンティティを発見しやすい。 MD3001 18 CRUD図の 表現のコツ CRUD図のエンティティをイベント系エンティ ティとリソース系エンティティに分離して記 述する イベント系エンティティとリソース系エンティ ティが分離されていない場合、どのエンティ ティがイベント系エンティティか明確にわから ないため、業務のもれが発見しにくい。 MD3002 19 CRUD図の表現のコツ CRUD図のビジネスプロセスを実際の業務の時系列順に並べる 業務の流れに沿ってレビューをする際に説明がしやすくなる。 MD3003 20 CRUD図の 表現のコツ CRUD図のイベント系エンティティをエンティ ティを作成する順番に沿って並べる 【MD3003】と併せることでCreateが左上から 右下に並ぶことが多くなるため、例外的な処 理を見つけやすくなる。 MD3004 21 データのフ ロー等の表 現のコツ データフロー図にイラストを使用する イラスト入りの表現形式でデータフロー図を 表現することで、構成要素同士の違いが明 確になる。 MD4001 22 データのフ ロー等の表 現のコツ 処理で利用するデータの入出力を図を利 用して記述する 文章で表現するよりどの処理でどのような データを入力してどこに出力するのかがわ かりやすい。 MD4002 23 データのフ ロー等の表 現のコツ 処理の間を流れるデータとその状態を記 述した図表を作成して説明する 各処理でデータの状態がどのように変化す るのかがわかりやすい。 MD4003 24 その他の表 現のコツ ファイル一覧にデータ件数の特徴を記述す る ファイル一覧にデータ件数の初期値、最大 値、増加率、保存期間が記述してあると、そ のデータの特性がわかりやすくなる。 ― 25 その他の表現のコツ ファイル一覧に保持する世代を記述する 削除やバックアップの機能をどのように実装するかの判断基準となる。 ―
ID コツの分類 コツの説明 コツの補足 コツID プロジェクトにおける採用方針 適用確認欄 26 その他の表 現のコツ コード定義書に主管部署と更新サイクルを 記述する コードを管理する部署と、コードの追加・更新 を実施するサイクルを記述すると、コードを 追加・変更する機能をどのように実装するか の判断基準となる。 設計時のデータ要件まとめ部署、および運 用時のデータ主管部署が明確になる。 ―
