発注者ビューガイドライン (概説編) ver. 1 - IPA目次（1/2） 1. 発注者ビューガイドラインの狙いと使い方 5 i. はじめに 6 (1) 発注者ビューガイドラインとは

Copyright ©2008 IPA

発注者ビューガイドライン(概説編)ver. 1.0

発注者ビューガイドライン(概説編)ver. 1.0

２００８年７月

独立行政法人情報処理推進機構ソフトウェア・エンジニアリング・センター

Copyright ©2008 IPA2

概説編

使用条件

<ガイドラインをご使用になる前にお読みください>

発注者ビューガイドライン（以下、「本ガイドライン」といいます。）を利用することをもって、以下に記載する使用条件（以下、「本使用条件」といいます。）に同意したものとさせていただきます。

本ガイドラインの著作権は、独立行政法人情報処理推進機構が保有しています。

以下の利用可能な行為を除き、本ガイドラインの一部または全部を著作権法の定める範囲を超え、許可なく改変、公衆送信、販売、出版、翻訳、翻案等をすることは営利、非営利など目的の

いかんに関わらず禁じられています。

＜本ガイドラインの目的＞

本ガイドラインは、外部設計工程における、発注者にわかりやすい仕様の記述方法及び合意方法を世の中に広く普及することを目的としています。

＜利用可能な行為＞

本ガイドラインは、以下の著作権表示を明記した上で、

著作権表示： Copyright©2008 IPA

情報システム開発に携わる方が本目的のために

・本ガイドラインの全部または一部を無償で複製すること、

・本使用条件を配布先に遵守させることを条件に本ガイドラインの複製物を無償で再配布すること、

により利用することができます。

独立行政法人情報処理推進機構は、本ガイドラインが第三者の著作権、特許権、実用新案権等の知的財産権に抵触しないことを一切保証するものではなく、また、本ガイドラインの内容に

誤りがあった場合でも一切責任を負うものではありません。

独立行政法人情報処理推進機構は、上記の利用可能な行為を除き、第三者の著作権、特許権、実用新案権等の知的財産権に基づくいかなる権利も許諾するものではありません。

独立行政法人情報処理推進機構は、本ガイドラインのシステム開発への利用、開発したシステムの使用及びシステムの使用不能により生じるいかなる損害についても、なんら責任を負うも

のではありません。

本ガイドラインを海外へ持ち出し、または外国籍の人に提供する場合には、「外国為替及び外国貿易法」の規制及び米国輸出管理規則等外国の輸出関連法規を確認の上、必要な手続きを

行ってください。

本ガイドラインへのお問い合わせについては、独立行政法人情報処理推進機構ソフトウェア・エンジニアリング・センターまでご連絡下さい。

ＪａｖａおよびすべてのＪａｖａ関連の商標およびロゴは、米国およびその他の国における米国ＳｕｎＭｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．の商標または登録商標です。

その他、本書に記載されている会社名、製品名などは各社の商標または登録商標です。

なお、本資料では、™ または® の表記は省略しております。


概説編

目次（1/2）

1. 発注者ビューガイドラインの狙いと使い方 5

i. はじめに 6(1) 発注者ビューガイドラインとは 6

(2) 発注者ビューガイドラインの構成 7

ii. 発注者ビューガイドラインの想定読者と利用イメージ 8

iii. 発注者ビューガイドライン作成の背景 9(1) 情報システム開発における課題 9

(2) 課題へのアプローチ 10

(3) 発注者ビューの位置づけ 11

iv. 発注者ビューガイドラインの対象範囲 12(1) 対象工程 12

(2) 想定するシステムとガイドラインとの対応 13

v. 発注者ビューガイドラインの前提 14(1) 工程成果物 14

(2) 設計書 14

(3) レビューの考え方 15

vi. 発注者ビューガイドラインの構成 16(1) 工程成果物の定義 16

(2) 画面編における工程成果物の定義 17

(3) システム振舞い編における工程成果物の定義 18

(4) データモデル編における工程成果物の定義 19

(5) 各編の構成 20


概説編

目次（2/2）

2. 発注者ビューガイドラインのコツ一覧 21

i. はじめに 22(1) 本章の使い方 22

(2) 本章の読み方 22

ii. 発注者ビューガイドライン（画面編）のコツ 23(1) 「第1部表現」の読み方 23

(2) 「第1部表現」のコツ一覧 24

(3) 「第3部レビュー」の読み方 30

(4) 「第3部レビュー」のコツ一覧 31

iii. 発注者ビューガイドライン（システム振舞い編）のコツ 34(1) 「第1部表現」の読み方 34




iv. 発注者ビューガイドライン（データモデル編）のコツ 42(1) 「第1部表現」の読み方 42




3. 本ガイドラインについて 49


概説編

1. 発注者ビューガイドラインの狙いと使い方


概説編

i. はじめに

(1) 発注者ビューガイドラインとは

発注者ビューガイドラインは、「概説編」「画面編」「システム振舞い編」「データモデル編」「用語集」の5編により構成されます。

本ガイドラインは、「発注者ビューガイドライン（概説編）」です。

発注者ビューガイドラインは、発注者と開発者との認識の齟齬や、互いの意図とは異なる理解をしたことに気づかないまま開発が進んでしまう状態を防止することを目的として、発注者視点での設計書等ドキュメントの記述やレビューに関する「コツ」を集約・整理したものです。なお、「コツ」は、次の2つの観点に絞り、開発現場の設計事例から抽出しました。

誤った理解を防ぐ，あるいは見つけ出すためのポイント

誤った理解に誘導したり，誤りの発見を困難にするポイント

発注者ビューガイドラインは、以下に示す情報システム開発に携わる関係者を対象として書かれています。情報システム開発を請け負う側である、ＳＩベンダの従事者

情報システム開発を発注する側である、ユーザ企業の情報システム部門、および業務部門の各ユーザ


概説編

i. はじめに

(2) 発注者ビューガイドラインの構成

発注者ビューガイドラインは次の5編により構成されます。

① 発注者ビューガイドライン（概説編）発注者ビューガイドラインの概要の説明、及び、「発注者ビューガイドライン（画面編）」、「発注者ビューガイドライン（システム振舞い編）」、「発注者ビューガイドライン（データモデル編）」の各編で記載されているコツの参照ページを一覧で掲載しています。

② 発注者ビューガイドライン（画面編）外部設計書に含まれる、画面の工程成果物の表現及びレビューに関するコツをまとめたガイドラインです。

③ 発注者ビューガイドライン（システム振舞い編）外部設計書に含まれる、システム振舞いの工程成果物の表現及びレビューに関するコツをまとめたガイドラインです。

④ 発注者ビューガイドライン（データモデル編）外部設計書に含まれる、データモデルの工程成果物の表現及びレビューに関するコツをまとめたガイドラインです。

⑤ 発注者ビューガイドライン用語集「発注者ビューガイドライン（概説編）」、「発注者ビューガイドライン（画面編）」、「発注者ビューガイドライン（システム振舞い編）」、「発注者ビューガイドライン（データモデル編）」の各編を理解していただくために低限必要な、重要語句の意味を記述しています。


概説編

ii. 発注者ビューガイドラインの想定読者と利用イメージ

発注者ビューガイドラインは主に開発者の利用を想定していますが、ユーザ企業の当事者も想定読者としています。それぞれの利用イメージは次のとおりです。

①ＳＩベンダの場合（開発者側）：設計情報の記述時の留意点を確認して実践する発注者と設計書の確認を行う際の留意点を確認して実践する

②ユーザ企業（発注者側）の情報システム部門の場合設計（仕様）情報の記述時の留意点を確認して実践するシステム設計に関する業務部門との確認を行う際の留意点を確認して実践する

③ユーザ企業（発注者側）の業務部門の場合該当する業務について、開発側の留意事項を予め確認する

③ 業務部門

Ａ社開発標準

Ｂ社開発標準

Ｃ社開発標準

Ａ社設計書

既存の開発標準に基づいて記述した設計情報に対し、発注者ビューガイドラインに基づいて情報を整理または付加する発注者ビューガイドラインに基づいてレビューを実施する

発注者ビューガイドライン

Ｂ社設計書

Ｃ社設計書

• 発注者ビューガイドラインで扱う設計情報の要素は開発標準に異存しない共通な要素として捉えている

• 設計書の様式や記法は規定していないため、各社開発標準に沿った異なる様式の設計書にコツを比較的容易に反映できる

書く

確認する

コツ② 情報システム部門

① ＳＩベンダ

コツコツコツ

コツ

コツ

各社ごとの設計書様式であっても、発注者にとって理解しやすくなる既存の設計情報にコツを反映する

コツ確認する

確認する

書く

開発側留意事項の確認


概説編

iii. 発注者ビューガイドライン作成の背景

(1) 情報システム開発における課題

情報システム開発には多様な関係者が絡み合っており、誤解や仕様の抜け・誤りを防止し、開発を円滑に進めるために

はこれらの関係者間における十分な意思疎通が不可欠です。設計書には標準的な記述方法も使われますが、これらは

情報システム開発における開発者の視点が主体であるために、発注者との意思疎通は必ずしも円滑であるとはいえず、

プロジェクトごとに不足事項を適宜補完しているのが現状です。

特に、開発者の説明が発注者にうまく伝わらないと、さまざまなトラブルが発生するだけでなく、情報システム開発が

失敗してしまいます。

特に、開発者の説明が発注者にうまく伝わらないと・・・さまざまなトラブルが発生するだけでなく、情報システム開発が失敗してしまいます。

さまざまなトラブル

設計書説明のための多大な

労力

手戻りの発生

発注者の不満

解釈の相違

仕様の抜けや誤りの発覚

開発者発注者

？ご説明いたします


概説編


(2) 課題へのアプローチ

受発注者相互の合意を得るためには、目標とする情報システム像に対する認識を一致させることが必要です。しかし、

立場の違いによって、「見えるもの」「わかるもの」は異なり、開発者の書いた設計書がそのまま「発注者にとって見える

もの」であるわけではなく、受発注者間における認識の齟齬が起こりやすいのが現状です。

そこで、発注者にとってわかりやすい仕様の記述方法、合意方法を検討する「実践的アプローチに基づく要求仕様の

発注者ビュー検討会」を発足させ、活動を開始しました。この検討会では、開発者の視点で書いた設計書を、発注者に

とって「見えるもの」「わかるもの」とするために、情報システム開発の各現場で行われている設計書の記述やレビュー

の工夫点を集約・整理しました。

目標とする情報システム像

発注者の視点で見る開発者の視点で書く

専門用語や図が使われた設計書

発注者の視点で“見える”・“わかる”

もの

認識の一致

目標とする情報システム像


概説編


(3) 発注者ビューの位置づけ

実践的アプローチに基づく要求仕様の発注者ビュー検討会では、開発者の視点で書いた設計書を発注者にとって「見

えるもの」「わかるもの」にする記述やレビューの方法を「発注者ビュー」と位置づけ、以下のとおり定義しました。

発注者ビューの目的は次のとおりです。

発注者および開発者が「目標とする情報システム像」を共有すること。

発注者における「目標とするシステム像」との相違が後工程で発見されることを未然に防ぐために、発注者

および開発者がシステムの外部設計を理解し、業務要件との不整合を発見し、是正結果を確認することを

促進すること。

発注者ビューとは、外部設計工程における各種設計書に対する発注者の理解容易性に貢献する伝達手段である。

発注者ビューとは、外部設計工程における各種設計書に対する発注者の理解容易性に貢献する伝達手段である。


概説編

iv. 発注者ビューガイドラインの対象範囲

(1) 対象工程

発注者ビューガイドラインでは、受発注者の接点が大きい外部設計の工程に着目し、これを対象工程としました。SEC BOOKS 「経営者が参画する要求品質の確保」※1 では、「システム設計」のプロセスにおける、「画面・帳票等の検討」「設計（外部）」の工程に該当しています。

外部設計工程の設計要素には、業務の処理や流れなどのプロセスや、データ、インターフェース等の機能要件や運用、操作等に関する非機能要件が挙げられます。本ガイドラインでは、発注者との関わりが大きい設計要素として、以下の3つの項目に着目しました。

① 画面画面および操作に関する外部設計要素。

② システム振舞い業務アプリケーションシステムが利用者または他システムに提供する機能および、それらの間の相互作用に関する

外部設計要素

③ データモデル業務アプリケーションシステムで使用するデータに関する外部設計要素

※1 「経営者が参画する要求品質の確保～超上流から攻めるＩＴ化の勘どころ～」独立行政法人情報処理推進機構ソフトウェア・エンジニアリング・センター編

システム化の方向性

システム設計

外部設計

内部設計

【情報システム開発のプロセス】

システム化計画

要件定義

システム開発

テスト

【発注者ビューガイドライン】

画面画面

データモデルデータモデルシステム振舞いシステム振舞い


概説編

iv. 発注者ビューガイドラインの対象範囲

(2) 想定するシステムとガイドラインとの対応

発注者ビューガイドラインでは、Ｗebベースのアプリケーションシステムを想定し、「画面」「システム振舞い」「データモデ

ル」の3つの項目において設計書や関連する資料の表現や確認方法、レビューの方法を「コツ」として集約しました。

■システム形態Ｗｅｂベースのアプリケーションシステム

Webベースを中心とした

サーバアプリケーション

データベースデータベース

「データモデル」の技術検討

「システム振舞い」の技術検討

「画面」の技術検討


概説編

v. 発注者ビューガイドラインの前提

(1) 工程成果物

発注者ビューガイドラインでは、情報システムの開発工程において作成され、発注者と合意する際に用いられる成果物のことを「工程成果物」と称しています。

外部設計工程の「工程成果物」は、現時点では標準とされる工程成果物が存在しません。このため、発注者ビューガイドラインでは、「画面編」「システム振舞い編」「データモデル編」の各編が対象とする工程成果物をそれぞれ定義しました。また、各工程成果物の構成要素は必要と考えられる記述事項を集約しました。

(2) 設計書

要求仕様に基づき、設計したドキュメントは発注者に対し「設計書」として提示します。設計書は、受発注者間で合意

した方法や様式で作成されるため、設計書の作成単位や構成が、発注者ビューガイドラインで前提としている工程

成果物のそれと一致しないことがあります。

例えば、発注者ビューガイドライン（画面編）では、工程成果物として「画面レイアウト」、「入出力項目」、「アクション明細」を定義して

いますが、実際のプロジェクトでは、これらを合わせて 1つの「ユーザーインターフェース設計書」として作成する場合があります。

ユーザーインターフェース設計書ユーザーインターフェース設計書ユーザーインターフェース設計書ユーザーインターフェース設計書

発注者発注者

画面レイアウト画面レイアウト

入出力項目入出力項目

アクション明細アクション明細

確認

【工程成果物】【設計書】


概説編

v. 発注者ビューガイドラインの前提

(3) レビューの考え方

発注者ビューガイドラインでは、レビューによる合意形成の成熟度の観点から、以下の3つのレビューの時期を想定しました。

充実期完成期仕掛期

外部設計要件定義内部設計

合意の成熟度の観点から見て前期、合意形成を開始、レビュー対象となる工程成果物の量が大幅に増加するフェーズ

合意の成熟度の観点から見て中期、合意形成が大幅に成熟、工程成果物の量は小幅に増加、バグ発見と修正が主となるフェーズ

合意の成熟度の観点から見て後期、合意の成熟を達成、工程成果物の量や修正数は安定、承認が主となるフェーズ


概説編

vi. 発注者ビューガイドラインの構成

(1) 工程成果物の定義「発注者ビューガイドライン（画面編）」「発注者ビューガイドライン（システム振舞い編）」「発注者ビューガイドライン

（データモデル編）」の各編において、14種類の工程成果物を定義しました。

項番編工程成果物名説明

1 画面編画面一覧システムで使用する画面の一覧

2 画面編画面遷移システムにおける画面の遷移

3 画面編

画面編

画面編

画面レイアウト画面の部品とその配置

4 画面編画面遷移・レイアウト共通ルール共通的な画面レイアウトや画面遷移のポリシー

5 入出力明細画面の入出力の仕様

6 アクション明細画面遷移に伴って起動される動作

7 システム振舞い編システム化業務一覧システム化業務の一覧表

8 システム振舞い編システム化業務フロー業務全体を俯瞰する流れ図（業務フロー）において、システム化する部分を識

別したもの

9 システム振舞い編システム化業務説明書システム化業務の説明

10 システム振舞い編システム振舞い共通ルール項番7～9の工程成果物に共通に適用するルールであり、図表の記述および

構成要素の整理分類に関するもの

11 データモデル編 ER図利用するデータをモデル化して表現した図

12 データモデル編エンティティ一覧エンティティの一覧

13 データモデル編エンティティ定義書エンティティおよびエンティティごとの属性の一覧

14 データモデル編 CRUD図業務とエンティティの関係を表現した図


概説編

(2) 画面編における工程成果物の定義画面編では、以下の6種類の工程成果物を定義しました。


画面遷移・レイアウト共通ルール

画面一覧表示される画面と、その画面の順序関係。画面から画面への遷移を起こすキッカケとなるイベント。条件分岐がある場合は、その条件と対応する分岐遷移

画面レイアウトと画面遷移に関する共通なルールおよび諸々の画面（群）が準じる典型的なレイアウトや遷移のポリシｰ

システムで使用する画面の一覧

項目・イベント発生オブジェクト名、それらに対応する画面部品（ＩＮ・ＯＵＴの区別が必要）およびその配置

No 分類画面名画面ID

…

1 入力フォーム

ペット登録画面 S-01 …


販売者登録画面

S-02 …


ログイン画面 S-05 …

… … … … …

余白

ユーティリ

ティエリコンテンツエリア

フッターエリア

20% 60% 20%

ヘッダーエリアコンテンツエリア

（main）コンテンツエリア

（sub2）

80ﾋﾟｸ

80ﾋﾟｸ

60ﾋﾟｸ

画面遷移

画面レイアウトレイアウト図

使用する部品

識別ＩＤ表示範囲画面部品の説明① ユーザ名入力するテキストボ② パスワードを入力するテキス③ ログイン処理を起動するボタ

操作手順①ユーザ名をテキストボックスに入力する。②パスワードをテキストボックスに入力する。③「ログイン」ボタン押下する。

ログイン画面で使用する部品には、ユーザ名・パスワードの入力にテキストボックスとログインにボタンがある。

ラベル画面部品の種類Username: テキストボックスPassword: テキストボックスLogin ボタン

①

②③

フッタ01※この名称は共通ルールに従って記載されています。

ヘッダ01※この名称は共通ルールに従って記載されています。

アクション明細画面遷移に伴って起動させる動作

アクションの処理概要

アクションの処理詳細

①顧客情報の入力チェック②検索処理入力された情報をもとに顧客情報テーブルを検索する③-1 合致するデータが存在しない場合顧客情報を登録し、顧客登録画面を初期表示する③-2 合致するデータが存在した場合エラーメッセージを表示する

入力された情報をもとに顧客情報を登録する

入出力項目

画面に入出力する項目の入出力の外部仕様

識別ID

表示用のラベル部品の種類入力

表示桁数

入力桁数

データ型入力制約

1 ユーザ名ラベル × 18 - 文字列 - ○ ユーザ名値2 新しいパスワーテキストボック △ 18 10 文字列パスワード入力パターン × -3 再入力パスワーテキストボック △ 18 10 文字列パスワード入力パターン × -4 名前（姓）テキストボック △ 19 18 文字列 × -5 名前（名）テキストボック △ 19 18 文字列 - × -6 Ｅメールアドレステキストボック ○ 39 38 文字列 Eメール入力パターン × -7 電話テキストボック ○ 19 18 文字列電話番号入力パターン × -8 住所１テキストボック ○ 39 38 文字列 - × -9 住所２テキストボック ○ 39 38 文字列 - × -

初期表示

表記例は Java Pet Store* を題材としています。

* Java Pet Store Software :http://java.sun.com/blueprints/code/jps132/docs/index.html


概説編

(3) システム振舞い編における工程成果物の定義システム振舞い編では、以下の4種類の工程成果物と工程成果物間の関連を定義しました。


Webベースを中心とした

サーバアプリケーション

システム振舞い

＋

システム利用作業または機能の一覧表

他の工程成果物に共通に適用される図表の記述に関するルール、および工程成果物の構成要素の整理分類に関するルール

No. 業務中機能小機能1 発注書作成・・・2 発注書再利用・・・3 入力支援・・・4 発注書申請・・・5 承認者自動設・・・6 代理承認者設・・・

発注書作成

発注書申請

システム化業務一覧

業務全体を俯瞰する流れ図（業務

フロー）において、システム化する部分を識別したもの

販売部門出荷部門（倉庫）

仕入先

進捗登録

顧客登録物件仮押

顧客の登録

意思の確認

テナント契約

システム化業務フロー

システム利用作業と機能の内容

システム化業務説明書概要

事前条件

管理者権限を持ったユーザでログインしていること。

事後条件

入力データユーザ情報(画面) 出力データ

備考なし

5:ユーザ情報の変更を要求す

■利用者のアクション

1:ユーザ情報の一覧を要求す

3:変更するユーザを選択し、4:データベースからユーザの詳細情報を取得し、利用者へ返す。

6:データベースの該当するユーザ情報を変更する。

ユーザを情報を変更する。データベースのユーザ情報が変更されること。

ユーザ情報(テーブル)基本シナリオ

■システムのアクション

2:データベースからユーザ情報の一覧を取得し、利用者へ返す。

並行分岐

／同期合流

システム対象外の

帳票

条件分岐

／合流

システムによる

帳票

データの流れ作業

制御の流れシステムによる

バッチ処理

業務データシステム化業務

(システム利用作業)

記号記号の意味記号記号の意味

並行分岐

／同期合流

システム対象外の

帳票

条件分岐

／合流

システムによる

帳票

データの流れ作業

制御の流れシステムによる

バッチ処理

業務データシステム化業務

(システム利用作業)

記号記号の意味記号記号の意味

システム振舞い共通ルール


概説編

データモデルデータモデル

(4) データモデル編における工程成果物の定義データモデル編では、以下の4種類の工程成果物を定義しました。

データモデルを補足する説明資料やデータモデルを作成する上での規則などをその他資料として記述しています。


データ辞書

ユーザ企業内で利用するデータをモデル化して表現したもの。エンティティとリレーションを表現するシンボルを用いて作図する。

ユーザ企業内で利用するデータに関する規則

エンティティ名およびエンティティごとの属性の一覧

ER図

エンティティ定義書

データの小単位であるデータ項目を定義

エンティティ一覧

ドメイン定義書

データ項目定義書

コード定義書

エンティティの一覧

データ項目をカテゴリ分けするための基準

データの内部構造や値が決まっているデータ項目の仕様を定義

その他資料

CRUD図

エンティティ名商品

項番属性名型桁 PK 説明1 商品番号 X 10 P ・・・2 商品名 X 100 ・・・3 商品区分コードX 3 ・・・

・・・

エンティティ名商品

項番属性名型桁 PK 説明1 商品番号 X 10 P ・・・2 商品名 X 100 ・・・3 商品区分コードX 3 ・・・

・・・

項番エンティティ名説明1 顧客・・・2 商品・・・3 受注・・・

項番エンティティ名説明1 顧客・・・2 商品・・・3 受注・・・

機能とエンティティの関係を表現したもの。エンティティ

顧客

受注

受注明細

機能

顧客登録

受注登録

受注明細登録

顧客検索

C

R

R

R

C

R C

製品

R

エンティティ顧客

受注

受注明細

機能

顧客登録

受注登録

受注明細登録

顧客検索

C

R

R

R

C

R C

製品

R


概説編


(5) 各編の構成画面編、システム振舞い編

「第1部表現」、「第2部記述確認」、「第3部レビュー」の3部構成

設計書や補足資料の記述に関するコツを集約 (第1部表現）

設計書の記述を確認する上で留意すべき事項を一覧化（第2部記述確認）

発注者と開発者とのレビューに関するコツを集約（第3部レビュー）

特に、お客様に対する要件の確認から始まり、外部設計書が完成するまでの間に段階がある点に着目し、それぞれの段階で留意すべき

事項について言及。

データモデル編

画面編、システム振舞い編と同様の3部に「第4部レビュー時の確認」を加えた4部構成

発注者と開発者とのレビュー時に確認すべき事項を一覧化（第4部レビュー時の確認）

データモデル編では、発注者と開発者の間で記述内容を確認するアプローチ方法が他ガイドラインとは異なり、既存資料を用いたり、補足

資料を積極的に作成するなど、発注者とコミュニケーションを促進することを想定。


概説編

2. 発注者ビューガイドラインのコツ一覧


概説編

i. はじめに

(1) 本章の使い方

本章では、「発注者ビューガイドライン（画面編）」、「発注者ビューガイドライン（システム振舞い編）」、「発注者ビューガイドライン（データモデル編）」の「第1部表現」「第3部レビュー」のコツ読み方と、コツの一覧を掲載します。コツごとに、記述元のガイドラインの該当ページ番号を示しています。コツの詳しい内容を参照したい場合に参考にしてください。

(2) 本章の読み方

『「第1部表現」の読み方』及び、『「第3部レビュー」の読み方』について「発注者ビューガイドライン（画面編）」、「発注者ビューガイドライン（システム振舞い編）」、「発注者ビューガイドライン（データモデル編）」に掲載されているコツの読み方を示します

『「第1部表現」のコツ一覧』および、『「第3部レビュー」のコツ一覧』について「コツの分類」

コツの分類を表します

「ID」

コツのIDです

「コツの説明」

コツを説明する文章です

「ページ番号」

コツが記述されているガイドラインの該当ページ番号です


概説編

ii. 発注者ビューガイドライン（画面編）のコツ

(1) 「第1部表現」の読み方「発注者ビューガイドライン（画面編）」の「第1部表現」のコツの読み方は次のとおりです。

目次に対応するタイトルを記述しています。この例は「第1章画面一覧 1.4 設計書記述のポイント 1.4.1書き方のコツ」の節に記述されている、設計書の書き方のコツを記したページの１部です。

誤った理解を防ぐ、あるいは認識のずれを見つけ出すためのポイントをコツとして紹介しています。コツにはそれぞれ番号をつけています。

コツの具体的な記述例です。この例では、システム全体で必要とする画面の全体図の記述例を示しています。

具体的な記述例の勘所は吹き出しで補足説明しています。この例では、システム全体で必要とする画面の全体図を作成する際のポイントを示しています。

このページで書かれている設計書の種類を表します。「第１部表現」では６種類の設計書についてコツを書いています。


概説編


項番コツの分類ＩＤコツの説明ページ番号

1FD1001

FD1002

FD1003

FD1004

FD1005

FD1006

FD1007

FD1008

9 画面遷移

書き方のコツ

FD2001 一覧性があると、全体像を把握するのに役立ち、開発者が説明しやすく、かつユーザにも理解されやすい。

画面編第1部 – 42

2

画面編第1部 - 14

システム全体で必要とする画面の全体図が作成されている。システム全体としての画面の抜け漏れや重複を確認でき、作業の優先度も確認できる。システムの全体像に関する合意を得やすくする。

画面一覧に記述する分類には、あらかじめ定義された分類を使用する。また、未定義の分類については、新たな分類として定義した上で使用することにより、未定義の分類の使用による混乱を避けることができる。

適切な量（機能別、分類別等）に分類され、理解しやすい順序で記述されていると、画面の重複と抜け漏れの排除が容易になる。

あらかじめ管理方法を定めた項目番号を記述することによって、画面の重複や抜け漏れの確認が容易になり、画面一覧の完成度を向上させる。

画面一覧に記述する各画面の仕様の概要に加えて、当該仕様が導かれた要件及びその理由を補足資料として作成しておくと、仕様漏れの防止に有効である。

3画面編第1部 – 17


画面の利用者や利用目的等の画面の特徴を捉えた説明を画面一覧の補足資料として記述する。これにより、レビュー時の確認内容がより具体的になり、画面仕様の品質が妥当なレベルへ到達することを促進する。また、発注者が仕様を理解しやすくなる。

画面一覧

書き方のコツ

あらかじめ定義された機能または分類に抜け漏れがある場合、画面一覧の画面の抜け漏れは、さらに増加する可能性がある。これを防止するために、設計が進み、機能や画面の分類が定義された段階で、機能や分類に抜け漏れがないことを確認する。

7 画面編第1部 – 26

画面一覧

確認のコツ画面一覧に付与したシーケンシャル番号を利用することで、画面の特定や、画面の全体量の把握ができ、レビューを効率的に行うことができる。

8 画面編第1部 – 28



6 画面編第1部 – 23

(2) 「第1部表現」のコツ一覧「発注者ビューガイドライン（画面編）」の「第1部表現」のコツは次のとおりです。


概説編


10FD2002

FD2003

FD2004

画面遷移

書き方のコツ

FD2005

FD2006

FD3001

FD3002

17 FD3003 画面部品の説明や見た目で、入出力が発生するか否かを明確に伝えると、入出力事項の意

識付けができた状態で入出力項目の説明を受けることができる。


18 FD3004 画面レイアウトに、構成要素の配置やボタン押下時の簡単な動作だけを記述している。この

ことにより、本来画面レイアウトで明らかにすべき仕様が確認できず、不完全な仕様となるリ

スクがある。


19 FD3005 画面レイアウトの定義に必要な入力情報が明確になっており、画面レイアウトの仕様の妥当

性を、検証するための根拠の候補が整う（本質的な議論ができるようになる）。根拠の候補と

は、同じフェーズの工程成果物（データモデル等）との整合性だけでなく、抽象度の異なる工

程成果物（要件定義書）との整合性を保持することを裏付けるための議論の材料のこと。


画面レイアウト

確認のコツ

11


画面名が、業務的に意味のある識別名になっていないと、画面遷移上で実際の画面が想起しにくく確認しずらい。

画面遷移の遷移線が錯綜していると、処理の流れが煩雑となり、ユーザを混乱させる。

画面遷移が上から下、左から右に遷移するように配置する。

実装寄りのイベントや条件分岐の条件になっていると、画面遷移図上で実際の業務的な処理が想起できず、読み手を混乱させる。

12画面編第1部 – 44


画面レイアウトと画面遷移上の遷移が過不足なく記述されていることを確認する。

全体を軽くレビューする際に、表現（見た目）がわかりやすく、見ただけで画面部品の状態や種類などを把握しやすい表記にすると、説明の手間が省け、画面部品の状態や種類の違いを明確に認識することができる。（特に、入出力項目や可変長の表を対象とする）

操作手順に加えて、操作に対応するシステムのリアクションを記述する。

これにより、発注者とシステムの境界が明確になり、発注者が使う場面を想定して、操作手

順をより詳細まで確認しやすくなる。

15 画面編第1部 – 61


書き方のコツ

16 画面編第1部 – 67

13画面編第1部 – 45

14 画面遷移

確認のコツ




概説編


20


確認のコツ

FD3006 あるまとまった情報項目群（複数の同類のものが集まっている様子）があれば、それらを対

象とした機能概要を記述する。

（”「顧客情報」を登録・変更する”など、「」内があるまとまった情報項目群であるとし、”『氏名』

を登録・変更する”など、『』内があるまとまった情報項目群の中にある単項目であるとした場

合。）


21 FD4001 共通ルールの整備にあたり、準拠すべき社内の基準、公的な基準を示すことにより、共通

ルールの適用基準が明確になる。


22 FD4002 画面レイアウト共通ルールに「画面遷移パターンの定義」や「エラー表示方法」を記載するこ

とによって、各画面ごとのアクション明細での記述を省け、確認ポイントが絞られる。


23 FD4003 表示をさかのぼるボタンの押下など、共通的なアクションの場合、画面毎に記述していくと記

述量も増え、確認ポイントが増える。「共通のアクション明細」を作るなどの工夫が必要。


24 FD4004 共通ルールの記述が少ないと、個々の画面や機能でばらばらなつくりとなってしまう。あとか

ら共通化するのは困難を伴う。


25 FD4005 画面の見出し、データ入出力領域、エラーメッセージ等の表示領域を標準化する。画面編第1部 – 111

26 FD4006 画面共通のエリアのアクションを示す設計書が別途必要となる。（ナビゲーションなど）共通

ルールの記述だけで不充分な点は、該当事項に特化した画面設計書や設計書サンプルな

ど、具体例を示さないと発注者の理解が困難な場合がある。


27 FD4007 複数の画面で表示される一組の入出力項目がある場合、そのレイアウトを共通ルールとし

てパターン化する。


28 画面遷移・レイア

ウト共通ルール

確認のコツ

FD4008 数値化できるルール、特に制限を示す項目は可能なかぎり数値化しておくことにより判断の

曖昧さを排除することができる。


画面遷移・レイア


書き方のコツ



概説編


29 FD4009 画面を使う人がヘッダー領域から何を読み取れるようにするか、を明確にすることで、ルー

ルの記述の意図を顧客に伝えやすくする。


30 FD4010 共通ルールによる各エリアの配色やレイアウト例を施した状態の見た目の全体表示イメー

ジを用意して、各エリアの配色やエリア同士の配色の組合せに問題がないかを確認できる

ようにする。


31 FD4011 色の表現を“赤”といった記述をしている場合、厳密に（“#FF0000”）というように示してあって

も、色の認識は共有しにくい。実際に色やフォントを表示して見せる必要がある。色の例を

示さないと、顧客との認識の相違を生じさせることになり得る。


32 FD4012 使用できるカラーの範囲、基本的な配色が指定されている。色彩の使われ方に一定の法則

があると、例えば「赤色系表示箇所は注意や重要事項」など、画面操作方法の習熟に効果

的であるほか、個別画面の仕様への理解もスムーズになる。


34

画面遷移・レイア


確認のコツ

FD4014 共通的な項目が複数画面にある場合、共通的な表示用方法（ラベル名やフォント、色、な

ど）にすべき範囲を明確にしているか。


35 FD5001 入力制約や出力仕様がパターン化されて記述されていると、余計な説明が不要となる。さら

に仕様のばらつきを抑えることができる。


36 FD5002 画面の入出力項目について、それぞれ取得方法が明確であり、発注者が入力するデータと

それ以外から取得するデータとの区別が明確である。このことにより、必要な機能及びその

内容が明確になり、要件の抜け漏れを防止しやすい。また、入出力項目の取得方法が明確

であるため、画面の操作性の議論や開発範囲を明確化しやすい。


37 FD5003 ラベル名の命名規則、画面部品の種類の適用ルール（コンボボックスとラジオボタンのどち

らを用いるかの定義等）が定義されており、その定義チェックが容易にできる工夫がされて

いると、余計な説明が不要となる。さらに仕様のばらつきを抑えることができる。


入出力項目

書き方のコツ

33 FD4013 フォント名を共通ルールで示すだけでは、開発者にはわかりやすいが、発注者にはどのよう

なフォントで表示されるのかわからなくなってしまうので、フォント表示の具体例を示せるよう

にしておくべきである。




概説編


38 入出力項目

書き方のコツ

FD5004 アクション明細や画面遷移が発生する入出力項目に対して記載があると、アクション明細や

画面遷移と連動して仕様を把握し易い。


39 FD5005 文章のみの資料となっていると、誤解を招く可能性が高い。視覚的に伝えると直感的に伝わ

る。


40 FD5006 ある軸で分類した業務の流れや権限等ごとに仕様が違う場合は、個別に記述されていると、

仕様の抜け漏れがない。


41 FD6001 あるまとまった情報項目群があれば、それらを対象としたアクションの概要を記述する。画面編第1部 – 172

42 FD6002 アクションの処理概要と処理詳細を分けることにより、何の処理をするのか理解しやすい。画面編第1部 – 173

43 FD6003 条件による場合わけが多い場合やアクションの処理が複雑な場合は「アクションの詳細」欄

に大量に記述が必要になってしまい、確認ポイントがぼやける。


44 FD6004 場合わけが発生する場合は階層的に示し、どこで処理が分岐しているのかを明確に示すと、

場合わけの全体像が想起されるため、過不足や問題点の気づきを促すことが出来る。


45 FD6005 あいまいな表現(処理単位，タイミング等)があり処理内容が不明だと、混乱する。設計意図

を正しく伝えられずに誤解を招く。


46 FD6006 実装よりの表現(手続き的な詳細の仕様)となっていると、実際の業務仕様を想起できない。

理解できない。


47 FD6007 条件による場合分けが多い場合でも全て記載することで、機能の曖昧な部分を残さず確認

できる。


48 FD6008 画面遷移のイベントと名称を統一することで、遷移にまつわるアクションの抜け漏れをチェッ

クしやすい。


アクション明細

確認のコツ

アクション明細

書き方のコツ

入出力項目

確認のコツ



概説編


49 FD7001 例えばどのような値を入力するのか、具体例を示し、画面レイアウトと入出力項目の間で同

期が取れていることを確認することで、制約条件の抜け漏れを防げる。


50 FD7002 画面レイアウトとアクション明細の間で記載する定義内容が明確に切り分けられていない場

合、重複などにより、確認ポイント（発注者に確認してもらう主要な内容）がぼやける。


51 FD7003 適切な量（機能別、分類別等）に分類され、理解しやすい順序で記述されていると、画面仕

様の重複や抜け漏れの確認や、画面仕様の理解が容易になる。これにより、発注者が画面

仕様を理解しやすくなり、レビューにおいてより本質的な確認を行うことができる。また、機

能別、分類別等の区別もなく、ランダムに画面一覧が記述されていると、画面の抜け漏れや

重複の確認が困難となる。


52 FD7004 業務の流れや権限等ごと仕様が違う場合は、個別に記述されていると、仕様の抜け漏れが

ない。


53 工程成果物間の

関連確認のコツ

FD7005 画面遷移で予期している動作とアクション明細で定義されたアクションの処理内容が異なる、

もしくは、アクション明細で定義された内容が曖昧で適切なアクションを表現しているか不明

だと、論点や説明が曖昧になる。誤解を招く。


工程成果物間の

関連書き方のコツ



概説編


(3) 「第3部レビュー」の読み方「発注者ビューガイドライン（画面編）」の「第3部レビュー」のコツの読み方は次のとおりです。

目次に対応するタイトルを記述しています。

コツの具体的な記述例です。この例は、「画面遷移とアクション明細が対応づいていることが資料を使って確認できるように説明する」という確認方法の具体例を示しています。

具体的な記述例の補足説明

このページのコツと関連する、工程成果物を示します。工程成果物は、「第１部表現」と対応しています。

レビュー（設計書の記述内容を発注者と開発者が確認すること）のポイントをコツとして紹介


概説編



1FR0001

FR0002

FR0003

FR0004

FR0005

FR0006

FR0007

FR0008

9 FR0009 想定される例外条件を網羅的に洗い出す。画面編

第3部 – 19

2

画面編

第3部 – 11

画面仕様全体のレビューの順番をあらかじめ決める。

他の画面あるいは工程成果物への影響度に留意して説明順序を決定する。

画面遷移、画面レイアウト、入出力項目の資料をレビューの際に同時に参照できるよう別々の冊子（レビュー用の準備資料）として用意する。

設計書で使用されている用語が、発注者の用語と合致しているか、混乱を招く使われ方をし

ていないか確認していただく。

説明する時は、画面遷移と細かい桁数・入力規則などの画面詳細に分けて行う。

3画面編

第3部 – 13

画面編

第3部 – 12

複数の情報項目が組み合わされて一つの情報項目を表すルールがある場合、その組み合

わせに名称（情報項目群）をつけて組み合わせの名称で説明を行う。

継続検討している箇所については発注者と開発者の間で情報を共有する。7 画面編

第3部 – 17

発注者の理解度を確認しながらレビューを進める。8 画面編

第3部 – 18

画面レビューの進

め方のコツ

4画面編

第3部 – 14

5画面編

第3部 – 15

6 画面編

第3部 – 16

(4) 「第3部レビュー」のコツ一覧「発注者ビューガイドライン（画面編）」の「第3部レビュー」のコツは次のとおりです。


概説編


10 FR1001 発注者が実際に操作できるプログラム等を使って画面レイアウトの仕様の確認をする場合は、レビュー前に確認項目をまとめておく。

画面編

第3部 – 22

11 FR1002 画面共通の情報と、個別の画面の情報は分離して説明する。画面編

第3部 – 23

12 FR1003 レビューの際に、共通ルールに従った具体例を提示して説明する。画面編

第3部 – 24

13 FR1004 画面一覧を活用して発注者との間に必要な機能などの認識の齟齬がないか早期に確認する。

画面編

第3部 – 25

14

画面全体にわたる共通事項をレビューするコツ

FR1005 レビューの際にエラー表示を具体的に説明し、表示の妥当性判断に役立てる。画面編

第3部 – 26

15 FR2001 業務の流れ、画面遷移のレビューを実施してから画面レイアウトのレビューを実施する。画面編

第3部 – 28

16 FR2002 画面遷移とアクション明細が抜け漏れなく記述されていることを確認できるように、対応付けて説明する。

画面編

第3部 – 29

17 FR2003 業務の流れに沿って画面遷移および画面レイアウトのレビューを実施する。画面編

第3部 – 30

18 FR2004 画面レイアウトのレビューの際、画面遷移の該当箇所を示す。画面編

第3部 – 31

19

画面の一覧の動

きをレビューする

コツ

FR2005 画面レイアウトと共に画面遷移が見られるように予め用意しておき、遷移の発生する画面部品を説明するときは、遷移後の画面を説明し、画面遷移上の位置を示す。

画面編

第3部 – 32

20 1つの画面をレビューするコツ

FR3001 特に重要であったり、複雑であったりする画面レイアウトは、全てのパターンについて漏れな

く説明する。

画面編

第3部 – 35



概説編


21 FR3002 条件に応じて画面レイアウトが変化する場合基準となる画面レイアウトだけを説明するので

はなく、権限や条件に対応する画面を一つずつ説明する。

画面編

第3部 – 37

22 FR3003 画面レイアウトにて、見た目が似たような画面部品が存在する場合、それぞれの違いを明

確にして説明する。

画面編

第3部 – 38

23 FR3004 配色を確認するときは、実際に表示してみせる。画面編

第3部 – 39

24 FR3005 画面レイアウトを用いて入出力項目をレビューする。画面編

第3部 – 40

25 FR3006 入出力項目の桁数と画面レイアウトの表示範囲が異なる場合、明示的に説明する。画面編

第3部 – 41

26 FR3007 画面レイアウトの入出力項目は、入力・出力定義の説明を行う。画面編

第3部 – 42

27 FR3008 画面レイアウトの説明後、入力が必要な箇所やボタン押下時の動作を説明しておくと、後々の入出力項目やアクション明細のレビューの際に発注者の理解が得やすい。

画面編

第3部 – 43

28 FR3009 画面レイアウト上で入出力項目とアクション明細を合わせることで、条件分岐の認識が発注者と一致していることを確認する。

画面編

第3部 – 44

29 FR3010 仕様の検証に必要十分な情報が記述されているか確認する。画面編

第3部 – 45

1つの画面をレビューするコツ



概説編

iii. 発注者ビューガイドライン（システム振舞い編）のコツ

(1) 「第1部表現」の読み方「発注者ビューガイドライン（システム振舞い編）」の「第1部表現」のコツの読み方は次のとおりです。

【コツの分類】コツの分類を記述しています

【コツの目的】コツを適用する目的を記述しています

【コツの説明】コツの内容を記述しています。また、コツにはそれぞれ番号を付加しています

【コツの適用例】コツを具体的に適用した記述例です

【コツの補足】コツの補足を吹き出しで記述しています

【工程成果物】コツの対象となる工程成果物を記述しています

【コツの補足】コツの補足を記述しています


概説編


1 SD1001

SD1002

SD1003

SD1004

SD1005

SD1006

SD1007

SD2001

9 SD2002 システム化業務フローの詳細を隠蔽して大きな流れを記述する。システム振舞い編第1部 – 35

10


書き方のコツ

SD2003 システム化業務フローを部門等の役割に基づき対応する区画に記述する。システム振舞い編第1部 – 36

2

システム振舞い編第1部 – 14

システム化業務一覧の中のシステム化業務を、階層構造に分けて記述する。

機能分類（オンライン、バッチ等）の列を追加する。

システム化業務一覧で、システム利用作業に対応する利用者を記述する。

業務と機能の関係を表す場合、関連する機能は、処理の順序に従って整列さ

せておく。

システム化業務一覧について、業務一覧と業務フローを使い、系統立てて記述

する。

3システム振舞い編第1部 – 16


システム化業務一覧に関連する業務を確認し、備考欄等を使い補足する。

システム化業務一覧に事前条件や事後条件などの情報を備考欄等を使い、記

述する。

システム化業務一覧

書き方のコツ

7 システム振舞い編第1部 – 20

システム化業務フローは、業務フローの1業務に対応させる形で記述する。8 システム振舞い編第1部 – 34




(2) 「第1部表現」のコツ一覧「発注者ビューガイドライン（システム振舞い編）」の「第1部表現」のコツは次のとおりです。



概説編


11 SD2004 システム化業務フローで、システムを表す区画を記述する。システム振舞い編第1部 – 37

12 SD2005 システム化する部分をシステム化業務を表す図記号を用いて記述する。システム振舞い編第1部 – 38

13 SD2006 処理の流れ、データの流れを表す矢線は、それぞれ異なる線の種類を用いる。システム振舞い編第1部 – 39

14 SD2007 フローが交差しないように記述する。システム振舞い編第1部 – 40

15 SD2008 1枚のシステム化業務フローに記述する業務は10個前後にする。システム振舞い編第1部 – 41

16 SD2009 開発対象と開発対象外を区別して表す。システム振舞い編第1部 – 42

17 SD2010 処理の頻度・タイミングを明示する。システム振舞い編第1部 – 43

18 SD2011 バッチを表すシステム化業務フローは、起動条件、終了条件、処理時間等を記

述する。


19 SD2012 バッチに関しては、時間軸を明示する。システム振舞い編第1部 – 44

20 SD2013 システム化業務フローに説明文も併せて記述する。システム振舞い編第1部 – 45

21 SD2014 処理内容を誤解なく伝える必要のあるシステム化業務は文章などで表す。システム振舞い編第1部 – 46

22 システム化業務フロー

確認のコツ

SD2015 システム化業務フローで、使用される画面や帳票の対応関係を確認する。システム振舞い編第1部 – 48


書き方のコツ



概説編


23 SD3001 システム化業務のシナリオを、利用者とシステムに分けて記述する。システム振舞い編第1部 – 58

24 SD3002 事前条件と事後条件を記述する。システム振舞い編第1部 – 59

25 SD3003 基本・代替・例外の3シナリオを考える。システム振舞い編第1部 – 60

26 SD3004 基本・代替・例外の3シナリオを併記する。システム振舞い編第1部 – 61

27

システム化業務説明書

書き方のコツ

SD3005 箇条書きの番号に、連番ではなく枝番を使用する。システム振舞い編第1部 – 62

28 SD4001 事前にシステム化業務（機能）分類を定義しておく。システム振舞い編第1部 – 80

29 SD4002 システム化業務フローなどで記述する記号は、ルールとして定義しておく。システム振舞い編第1部 – 81

30 SD4003 事前に分類されたメッセージを定義しておく。システム振舞い編第1部 – 82

31

システム振舞い共通ルー

ル

書き方のコツ

SD4004 システム化業務フローを書く時は、事前に区画と時間軸の配置をルールとして

定義しておく。


32 システム振舞い共通ルー

ル

確認のコツ

工程成果物間の関連

書き方のコツ

SD4005 名称が一元管理されている事を確認する。システム振舞い編第1部 – 85

33 SD5001 工程成果物間でシステム化業務の記述単位をそろえる。システム振舞い編第1部 – 92

34 SD5002 共通ルールの重要な日付／期日の定義の中に、システム化業務フローの情報

も併せて記述する。




概説編


35 工程成果物間の関連

確認のコツ

SD5003 システム化業務説明書とシステム化業務一覧の対応関係を確認する。システム振舞い編第1部 – 95



概説編


(3) 「第3部レビュー」の読み方「発注者ビューガイドライン（システム振舞い編）」の「第3部レビュー」のコツの読み方は次のとおりです。

【コツの分類】合意成熟度のフェーズに基づくコツの分類を記述しています






【合意成熟度のフェーズと工程成果物】コツの対象となるフェーズと工程成果物を記述しています


概説編


1 SR0001

SR0002

SR0003

SR0004

SR0005

SR0006

SR0007

SR0008

9

合意の成熟度のフェーズ

の仕掛期でレビューする

コツ

SR0009 画面レイアウトをもとに、該当するシステム化業務があるかを確認する。システム振舞い編第3部 – 24

10 SR0010 システム化業務一覧に対して、要件定義書に定義された業務一覧と突合せを

行なう。


11


の仕掛期から充実期でレ

ビューするコツ SR0011 境界を確認する。システム振舞い編第3部 – 27

2


業務を実現するための機能を確認する。

業務上のタイミングを確認する。

分岐の境界条件を確認する。

システム全体を鳥瞰できる図を補足して要件定義書を確認する。

システム全体を鳥瞰できる図においては、利用者から確認を始める。

3


要件定義書の利用者の定義を確認する。

合意の成熟度のすべての

フェーズで段階的にレ

ビューする共通のコツ

システム化業務一覧とシステム化業務フローで、システム利用作業の利用者

の観点があっているかを確認する。


他システムとのインターフェースとなるシステム化業務が抽出できているかを確

認する。

8






(4) 「第3部レビュー」のコツ一覧「発注者ビューガイドライン（システム振舞い編）」の「第3部レビュー」のコツは次のとおりです。



概説編


12 SR0012 業務フローのシステム化対象範囲を確認する。システム振舞い編第3部 – 28

13SR0013 現行システムの課題が、抽出したシステム化業務で解決されているかを確認

する。


14


の仕掛期から充実期でレ

ビューするコツ

SR0014 利用者とその役割別のシナリオのバリエーションを確認する。システム振舞い編第3部 – 30

15 SR0015 発注者の操作に関係する情報を中心に、システム化業務フローを説明する。システム振舞い編第3部 – 32

16 SR0016 業務データの種類と状態を確認する。システム振舞い編第3部 – 33

17 SR0017 並行処理における各分岐の事前条件、事後条件に矛盾がないことを確認する。システム振舞い編第3部 – 34

18 SR0018 画面一覧を用いて、利用するシステム化業務を確認する。システム振舞い編第3部 – 35

19 SR0019 画面をもとに、実現すべきシステム化業務の内容を確認する。システム振舞い編第3部 – 36

20 SR0020 画面をもとに、エラー処理を確認する。システム振舞い編第3部 – 37

21 SR0021 事前条件、事後条件、例外シナリオを確認する。システム振舞い編第3部 – 38

22 SR0022 日付／期日とシステム化業務を確認する。システム振舞い編第3部 – 39

23


の充実期でレビューする

コツ

SR0023 原因と結果の対応表を用いて、シナリオの種類を確認する。システム振舞い編第3部 – 40



概説編

iv. 発注者ビューガイドライン（データモデル編）のコツ

(1) 「第1部表現」の読み方「発注者ビューガイドライン（データモデル編）」の「第1部表現」のコツの読み方は次のとおりです。

【コツの分類】コツを適用する工程成果物を記述しています







概説編


1MD1001

MD1002

MD1003

MD1004

MD2001

MD2002

MD2003

MD2004

9

エンティティ一覧

／定義書の表現

のコツ

MD2005 エンティティ一覧において旧システムのデ－タモデルからの変更点を明記するデータモデル編第1部 – 20

2

データモデル編第1部 – 11

エンティティをタイプ分けして、色で表現する

ER図中のエンティティにインスタンスの作成、および更新の時期を記述する

業務単位にER図を作成する

イベント系エンティティをデ－タの発生順で記述する

エンティティ一覧にデ－タの主管部署を記述する

3データモデル編第1部 – 13


エンティティ一覧に業務名、エンティティの種別を記述する

ER図の表現のコ

ツ

エンティティ一覧にデ－タ件数や保存期間などを記述する7 データモデル編第1部 – 18

エンティティおよび属性の抽出元を記述する8 データモデル編第1部 – 19



6 データモデル編第1部 – 17

(2) 「第1部表現」のコツ一覧「発注者ビューガイドライン（データモデル編）」の「第1部表現」のコツは次のとおりです。



概説編


10 MD3001 CRUD図のCreate,Read,Update,Delete記述欄を固定するデータモデル編第1部 – 21

11 MD3002 CRUD図のエンティティをイベント系エンティティとリソ－ス系エンティティに分離して記述

する


12 MD3003 CRUD図のビジネスプロセスを実際の業務の時系列順に並べるデータモデル編第1部 – 23

13

CRUD図の表現の

コツ

MD3004 CRUD図のイベント系エンティティをエンティティを作成する順番に沿って並べるデータモデル編第1部 – 24

14 MD4001 デ－タフロ－図にイラストを使用するデータモデル編第1部 – 26

15 MD4002 処理で利用するデ－タの入出力を図を利用して記述するデータモデル編第1部 – 27

16

デ－タのフロ－等

の表現のコツ

MD4003 処理の間を流れるデ－タとその状態を記述した図表を作成して説明するデータモデル編第1部 – 28



概説編

(3) 「第3部レビュー」の読み方「発注者ビューガイドライン（データモデル編）」の「第3部レビュー」のコツの読み方は次のとおりです。

【合意成熟度のフェーズ】コツの対象となるフェーズを記述しています




【コツの分類】レビュー活動の分類を記述しています





概説編


1 MR1001

MR1002

MR1003

MR1004

MR2001

MR2002デ－タモデルの概

要を説明するコツ

MR2003

MR3001

9 MR3002 デ－タモデルに、実デ－タを当てはめて補足するデータモデル編第3部 – 22

10 MR3003 画面レイアウトとER図を対応づけて確認するデータモデル編第3部 – 23

11

デ－タモデルの詳

細を説明するコツ

MR3004 ER図上のエンティティをレビュ－対象の業務で囲むデータモデル編第3部 – 24

2

データモデル編第3部 - 14

業務の中で利用する“モノ”に着目して、デ－タや情報を抽出・分類する

業務用語辞書を元にしてデ－タ辞書を作成する

デ－タ項目の型／桁／精度はドメイン定義書で確認する

デ－タ項目の情報はコ－ド定義書に記述して確認する

デ－タモデルの概要を業務や大きな機能レベルでまとめてエンティティの候補を確認す

る



扱うエンティティをグル－ピングした資料を作成して確認する

エンティティ・属性

を抽出するコツ

システムが扱う情報を俯瞰できる資料を作成し、システムが扱う情報の範囲を確認する7

実デ－タを例に使って、工程成果物の読み方を説明する






(4) 「第3部レビュー」のコツ一覧「発注者ビューガイドライン（データモデル編）」の「第3部レビュー」のコツは次のとおりです。



概説編


12 MR3005 画面でデ－タを作成・変更するか／しないかでエンティティを区別するデータモデル編第3部 – 25

13 MR3006 発注者への確認事項をＥＲ図にコメントとして直接記述し、議論のポイントを明らかにするデータモデル編第3部 – 26

14 MR3007 新規要件への対応箇所をレビュ－ポイントとしてER図上で明らかにしておくデータモデル編第3部 – 27

15 MR3008 新規要件に伴うER図の変更は、変更前/後を比較して効果を説明するデータモデル編第3部 – 28

16 MR3009 旧システムと新システムのデ－タベ－ス移行の方針について業務内容の観点で図示し

て説明する


17 MR3010 業務とエンティティのまとまりとの対応を示し、デ－タモデルの読み方を説明するデータモデル編第3部 – 30

18 MR3011 他の設計ドキュメントでエンティティ名を記述する場合、区別できる表現にするデータモデル編第3部 – 31

19 MR3012 エンティティが多く複雑で、一枚で俯瞰できない場合は概略のER図をつくるデータモデル編第3部 – 32

20 MR4001 実デ－タ例を使用しながら、処理とデ－タ生成の流れを記述した資料を用意し、機能を確

認する


21 MR4002 積層棒で状態遷移を作成して、確認するデータモデル編第3部 – 34

22 MR4003 状態遷移図でエンティティの取り得る状態を図示するデータモデル編第3部 - 35

デ－タの変化を確

認するコツ

デ－タモデルの詳

細を説明するコツ



概説編


23 MR5001 設計書の処理単位に、処理概要、設計内容とともにC,R,U,Dもあわせて記述するデータモデル編第3部 – 36

24 MR5002 エンティティの作成、参照、更新と削除タイミングを確認ポイントに絞って表で説明するデータモデル編第3部 – 37

25

業務とデ－タの関

係を確認するコツ

MR5003 エンティティの構造に対応する表構造を示し、発注者に表の構造と値を確認するデータモデル編第3部 – 38

26 MR6001 システム間で連携するデ－タを図や表で確認するデータモデル編第3部 – 39

27 MR6002 ファイルとエンティティの構造の対応関係をファイル-DB関連図で表すデータモデル編第3部 – 41

28 MR6003 エンティティ定義書とファイル定義書を並べ、項目毎の登録状況を色分けして表現するデータモデル編第3部 – 42

29 MR7001 デ－タの利用箇所と出力量を一覧で記載して確認するデータモデル編第3部 – 43

30 MR7002 ER図で使用されている属性名称を用いずに、エンティティの件数を確認するデータモデル編第3部 – 44

31 MR7003 デ－タベ－ス容量の見積の際に大レコ－ドを算出した根拠を記述するデータモデル編第3部 - 45

業務量を確認する

コツ

他システムとやり

とりするデ－タを

確認するコツ



概説編

3. 本ガイドラインについて


概説編


実践的アプローチに基づく要求仕様の発注者ビュー検討会について

実践的アプローチに基づく要求仕様の発注者ビュー検討会は、情報システムにおける「仕様」について、「お客様にわかりやすい記述方法および合意方法」を共同検討することを目的として、株式会社ＮＴＴデータ、富士通株式会社、日本電気株式会社、株式会社日立製作所、株式会社構造計画研究所、東芝ソリューション株式会社の6社により、2006年4月12日に発足しました。その後、2007年8月1日より、日本ユニシス株式会社、沖電気工業株式会社、TIS株式会社の3社が加わり、合計9社による検討活動となりました。

本ガイドラインを読まれたみなさんへ

発注者ビューガイドラインは、システム開発に関わる方々がお互いの理解の齟齬を減らし、円滑に意思疎通を図るための知見を提供したい、という思いをこめて執筆しました。このガイドラインを大いにご利用いただくことで、発注者も開発者も目標とするシステム像を共有し、かつ、発注者の思い描くシステムが実現されることを願っております。


概説編


謝辞

株式会社東京証券取引所様、ＡＧＳ株式会社様、三菱電機インフォメーションシステム

ズ株式会社様には、ガイドラインの記載内容について多数のご意見をいただきましたこ

とに感謝いたします。


概説編

参考文献

[1]独立行政法人情報処理推進機構ソフトウェア・エンジニアリング・センター編

経営者が参画する要求品質の確保第２版～超上流から攻めるIT化の勘どころ～, 株式会社オーム社, 2006

Documents

発注者ビューガイドライン (概説編) ver. 1 - IPA目次（1/2） 1. 発注者ビューガイドラインの狙いと使い方 5 i. はじめに 6 (1) 発注者ビューガイドラインとは