Transcript 「機能要件の合意形成ガイド」説明資料（PowerPoint形式）

Software
Engineering
Center
Information-technology Promotion Agency, Japan
機能要件に関する発注者と開発者の
合意形成を目指して
2011年 6月 3日
独立行政法人 情報処理推進機構(IPA)
ソフトウェア・エンジニアリング・センター(SEC)
Copyright© 2010,2011 Information-technology Promotion Agency, Japan. All rights reserved.
Software Engineering Center
SEC
使用条件
1.
2.
3.
4.
5.
6.
7.
Software Engineering
for Mo･No･Zu･Ku･Ri
本資料の著作権は、独立行政法人情報処理推進機構(IPA)が保有しています。
独立行政法人 情報処理推進機構は、「本資料の全部又は一部を複製、改変、公衆送信、又は翻
訳/翻案し、第三者に有償又は無償で再配布すること」を許諾します。なお、複製し再配布する場
合は、実際の契約書として使用する場合を除き、本使用条件を添付し、本使用条件に記載されて
いる条件を配布先に遵守させて下さい。改変又は翻訳/翻案し再配布する場合は、実際の契約書と
して使用する場合を除き、新しく使用条件を設定することが可能ですが、本使用条件を必ず含め
て下さい。
独立行政法人 情報処理推進機構は、本資料が第三者の著作権、特許権、実用新案権等の知的財
産権に抵触しないことを一切保証するものではなく、また、本資料の内容に誤りがあった場合で
も一切責任を負いかねます。
独立行政法人 情報処理推進機構は、本ページで記載された許諾内容を除き、独立行政法人 情
報処理推進機構又は第三者の著作権、特許権、実用新案権等の知的財産権に基づくいかなる権利
を許諾するものではありません。
独立行政法人 情報処理推進機構は、本資料の商取引への利用、システム開発への利用、開発さ
れたシステムの使用、及び当該システムの使用不能等により生じるいかなる損害についても、な
んら責任を負うものではありません。
本資料へのお問い合わせについては、独立行政法人 情報処理推進機構 ソフトウェア・エンジ
ニアリング・センターまでご連絡下さい。
二次利用時に著作権を表示する場合は、次のように表記してください。
 2011年に公開した場合
Copyright © 2011 IPA, 二次著作権者名
 2012年に公開した場合
Copyright © 2011,2012 IPA, 二次著作権者名
 2013年以降に公開した場合
Copyright © 2011-公開年 IPA, 二次著作権者名
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center
1
SEC
本日のメニュー
Software Engineering
for Mo･No･Zu･Ku･Ri
1. 「機能要件の合意形成ガイド」とその開発背景
2. 「機能要件の合意形成ガイド」内容の紹介
3. 「機能要件の合意形成ガイド」の適用例
4. まとめ～どのように使ったらよいか？～
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center
2
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
1.「機能要件の合意形成ガイド」とその開発背景
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center
3
「機能要件の合意形成ガイド」って何？
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 機能要件に着目し、上流工程で実現したい情報システム像を伝え、
発注者と開発者との不充分な合意形成が原因で発生する下流工程の
手戻りを防止するためのコツを集めたもの
実現したい情報システム像について
発注者と開発者が合意形成するた
めに、伝える側が漏れなく正確に情
報を提供するためのコツ
システム振舞い編
画面編
概説編および
６つの技術領域毎の編
の計７冊から構成
発注者と開発者との不充分な合意
形成が原因で下流工程で発生する
手戻りを防止するための先人の開
発者のコツ
データモデル
編
概要編
ZZ 9／ ZZ 9
納品書
(ZZ9)
Y Y Y Y /M M /D D 23:59
伝 票 番 号 XXXXXXXXXX お 届 け 先 コ ー ド XXXXXXXXXX
お届け先名
NNNNNNNNNNNNNN 御中
お届 け先住所 NNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNN
出荷元 コー ド
出荷部門
XXXXXXXXXX
NNNNNNNNNNNNNN
売上区分 X
発注区分 X
支払期限
YYYY 年 M M 月 D D 日
納品明細
No
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
品 番
商品名
XXXXXXXXXXXXXXXＮ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ
XXXXXXXXXXXXXXXＮ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ
XXXXXXXXXXXXXXXＮ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ
XXXXXXXXXXXXXXXＮ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ
XXXXXXXXXXXXXXXＮ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ
XXXXXXXXXXXXXXXＮ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ
XXXXXXXXXXXXXXXＮ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ
XXXXXXXXXXXXXXXＮ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ
XXXXXXXXXXXXXXXＮ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ
XXXXXXXXXXXXXXXＮ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ
XXXXXXXXXXXXXXXＮ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ
XXXXXXXXXXXXXXXＮ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ
XXXXXXXXXXXXXXXＮ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ
XXXXXXXXXXXXXXXＮ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ
XXXXXXXXXXXXXXXＮ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ
XXXXXXXXXXXXXXXＮ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ
XXXXXXXXXXXXXXXＮ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ
XXXXXXXXXXXXXXXＮ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ
XXXXXXXXXXXXXXXＮ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ
XXXXXXXXXXXXXXXＮ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ Ｎ
単 価 数量
\Z,ZZZ,ZZ ZZ
\Z,ZZZ,ZZ ZZ
\Z,ZZZ,ZZ ZZ
\Z,ZZZ,ZZ ZZ
\Z,ZZZ,ZZ ZZ
\Z,ZZZ,ZZ ZZ
\Z,ZZZ,ZZ ZZ
\Z,ZZZ,ZZ ZZ
\Z,ZZZ,ZZ ZZ
\Z,ZZZ,ZZ ZZ
\Z,ZZZ,ZZ ZZ
\Z,ZZZ,ZZ ZZ
\Z,ZZZ,ZZ ZZ
\Z,ZZZ,ZZ ZZ
\Z,ZZZ,ZZ ZZ
\Z,ZZZ,ZZ ZZ
\Z,ZZZ,ZZ ZZ
\Z,ZZZ,ZZ ZZ
\Z,ZZZ,ZZ ZZ
\Z,ZZZ,ZZ ZZ
9
帳票編
合 価
消費税
\Z,ZZZ,ZZZ,ZZ 額
\Z,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ \Z,ZZZ,ZZ
9
備 考
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
バッチ編
Copyright © 2010,2011 IPA, All Rights Reserved
外部インタフェース編
Software Engineering Center
4
「機能要件の合意形成ガイド」を作った背景
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 システム開発における手戻りとコストの関係
要件定義
運用テスト
システム仕様
システムテスト
10～100
修
正
ソフトウェア
仕様
ソフトウェア
テスト
5
コ
ス
プログラミング
ト
ソフトウェア システム
テスト
テスト
運用
テスト
発見工程別相対修正コスト
右の出典：B.W.Boehm “Soft. Eng.” IEEE Trans. com (Nov ‘76)
SEC-BOOKS『経営者が参画する要求品質の確保』（P26)より
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center
5
「機能要件の合意形成ガイド」を作った背景
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
事業
業務A
業務B
人による活動
人による活動
システム
システム
業務D
人による活動
業務C
事業・業務とシステム・ソフトウェアとの関係
人による活動
業務要件
業務E
人による活動
システム要件
システム
システム要件
非機能要件
人による活動
業務E
システム利用
機能要件
システム
ハードウェア ソフトウェア
アーキテクチャ設計
その他設備
(ネットワークなど)
ソフトウェア要件
出典：共通フレーム2007「ソフトウェアとシステム」に追記
Copyright © 2010,2011 IPA, All Rights Reserved
要
件
定
義
シ
ス
テ
ム
設
計
ソ
フ
ト
ウ
ェ
ア
設
計
業務要件のブレークダウン
Software Engineering Center
6
「機能要件の合意形成ガイド」を作った背景
発注者
顧客社外ユーザ
代理店
監督官庁
企業・個人ユーザ
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
システム開発に係る
ステークホルダー
開発者
開発グループ
顧客社内ユーザ
ソフトハウス
経営者
企画／
業務設計担当
システム
開発担当
開発ベンダ
オフショア先
運用・業務支援グループ
SECBOOKS 共通フレーム2007(第2版)P.6
「コミュニケーションチャネルの複雑さ」を参考
アウトソーサ
ヘルプ
デスク
コールセンタ
システム開発におけるステークホル
ダーの増加により、発注者間、発注
者と開発者間の認識の齟齬、意思
伝達の漏れが多く発生
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center
7
「機能要件の合意形成ガイド」を作った背景
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 システム開発において起こりうるギャップの例
発注者と開発者の認識の齟齬により要求と実現されるソフトとの間に
ギャップが生じる
これの解決支援が目的
①要件定義すべき内容が抜けてお
り、開発者に説明していない。
発注者
シ
ス
テ
ム
化
計
画
業
務
部
門
の
要
求
内
容
開発者
A
要
件
定
義
内
容
②発注者が開発者に説
明したが、何らかの
理由で漏れた。
B
外
部
設
計
内
容
C
ソ実
フ現
トさ
ウれ
ェる
ア
バグや障害
バグや障害
③発注者が開発者に
説明し、共通理解
が得られた。
バグや障害
この絵は、発注者が要件定義ま
でを行い、それ以降の工程を開
発者が行う場合の例
④開発者が何らかの理由により
誤認・拡大解釈し、実現範囲
に取り込んでしまった。
Copyright © 2010,2011 IPA, All Rights Reserved
参考文献：IPA/SEC
発注者ビューガイドラインの活用と拡張(p.4)
Software Engineering Center
8
SEC
「機能要件の合意形成ガイド」開発のあゆみ
２００６年度～２００７年度
２００８年度
２００９年度
2010年度
ＩＰＡ／ＳＥＣ
機能要件の合意形成技法ＷＧ
発注者ビュー検討会(注)
（情報システムにおける「仕様」について、お客様に
わかりやすい記述方法および合意方法を共同検
討することを目的に国内主要SI事業者（９社）が結
集した検討会）
発注者ﾋﾞｭｰｶﾞｲﾄﾞﾗｲﾝの作成／評価
Software Engineering
for Mo･No･Zu･Ku･Ri
課題整理・領域拡大
発注者ビュー
ガイドライン
成果物
｢発注者ビュー
ガイドライン
ver. 1.0｣
３技術領域
コツ数 187
IPAにて
７月より
公開
成果物
「発注者
ビューガイド
ラインの活用
と拡張」
改訂版
の作成
評価
成果物
機能要件の
合意形成ガイ
ド
６技術領域 ３月
コツ数 278
・Webサイトによる成果物の公開
・IPA/SEC，JUASとの連携
・書籍出版
書籍
「失敗しない｣
外部設計」
日経ＢＰ社
8月
注：発注者ビュー検討会＝実践的アプローチに基づく要求仕様の発注者ビュー検討会
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center
9
「機能要件の合意形成ガイド」普及のあゆみ

Web公開文書の利用実績
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
「機能要件の合意形成ガイド」
2010/4~2010/11のダウンロード単純合計：
約42,000件(約5,000件/月)
ユニークユーザは月700～800人
「発注者ビューガイドライン」2008/7～
2010/６末のダウンロード単純合計：
約132,000件（約5,000件/月）
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 10
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
2．「機能要件の合意形成ガイド」内容の紹介
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 11
「機能要件の合意形成ガイド」の目的

SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
要件定義・外部設計におけるお客様との認識の齟齬を防ぐ
目的とする情報システム
像
（外部設計として整備する事
項）
業務モデルの構築
発注者
発注者視点で、
見える・わかる
情報システムの実現
開発者
発注者視点で書き、
説明する
外部設計書
機能要件の合意形成ガイド
お客様との認識の齟齬を防ぐ
非機能ではなく、機能寄り（機能要件、動作仕様etc…)
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 12
SEC
機能要件の合意形成ガイドとは

Software Engineering
for Mo･No･Zu･Ku･Ri
278のコツを適用する技術領域・適用画面に分類・整理したもの
278 言い切る／聞き切る 44 図表に書く
シ振
ス舞
テい
ム編
・言い切る/聞き切る
60
画
面
編
84
35
バ
ッ
チ
編
23
帳
票
編
31
７
７ ・バッチ処理一覧
・バッチ処理フロー
・バッチ処理定義
・バッチ共通ルール
７
・言い切る/聞き切る
８ ・帳票レイアウト
・帳票項目説明
・帳票概要
・帳票編集定義
８
１ ・もれ／矛盾をチェックする
２
３
１
２ ・もれ／矛盾をチェックする
４
２
３
１１
２ ・もれ／矛盾をチェックする
１
１
１
５
発注者
22 一緒にレビューする
94 が事前に
17
意識する
２ ・全レベルでレビュー(要件との整合)
・全レベルでレビュー(設計書の正しさ)
・仕掛レベルのレビュー
・充実レベルのレビュー
・充実・完成レベルのレビュー
２
３
３
５
８
５
２４
２ ・設計書レビューの進め方
１ ・画面全体に渡る共通事項のレビュー
３ ・画面の一連の動きのレビュー
６ ・１つの画面のレビュー
２
１
１５
４
５
４
１３
１０ ・外部システム関連図
・外部インタフェース一覧
・外部インタフェース項目説明
・外部インタフェース処理説明
１０
・言い切る/聞き切る
６ ・画面一覧
５ ・画面遷移
４ ・画面レイアウト
３ ・画面遷移・ﾚｲｱｳﾄ共通ﾙｰﾙ
６ ・画面入出力項目一覧
８ ・工程成果物間の関連
４
３６
８ ・ＥＲ図
・エンティティ一覧
・ＣＲＵＤ図
８
・言い切る/聞き切る
７ ・システム化業務フロー
１１
４
５
２
２９
６ ・画面一覧
・画面遷移
・画面レイアウト
・画面入出力項目一覧
・画面アクション明細
・画面遷移・ﾚｲｱｳﾄ共通ﾙｰﾙ
・工程成果物間の関連
６
・言い切る/聞き切る
45
外イフ
部 ンェ
ター
ス
編
５ ・システム化業務一覧
・システム化業務フロー
・システム化業務説明
・システム振舞い共通ﾙｰﾙ
・工程成果物間の関連
５
・言い切る/聞き切る
デ
ー
タ
モ
デ
ル
編
101 もれ／矛盾をチェックする
２７
・エンティティ・属性を抽出する
・データモデルの概要を説明する
・データモデルの詳細を説明する
・データの変化を確認する
・業務とデータの関係を確認する
・他ｼｽﾃﾑとやりとりするﾃﾞｰﾀを確認する
・業務量を確認する
０
２
１
Copyright © 2010,2011 IPA, All Rights Reserved
０
９
９
４
４
２ ・一緒にレビューする
２
７ ・発注者
が事前に
意識する
７
１ ・一緒にレビューする
０
３
１
１１
３
２
３
１
２４
２ ・一緒にレビューする
０
８
５
４
１０
８ ・発注者
が事前に
意識する
８
０
８
８
Software Engineering Center 13
「機能要件の合意形成ガイド」コツとは

「○○の様な場面に△△のような行動を取る（記述する）と□□の
様な効果がでる」といったイメージ
事例から生まれたもの


Software Engineering
for Mo･No･Zu･Ku･Ri
発注者と開発者との認識の齟齬を防止する為のノウハウ


SEC
ガイド執筆メンバにおける認識の齟齬防止に効果があった事例を抽
象化したもの
目的、施策、メリットがはっきりしている

はっきり出来なかった中途半端なモノ⇒コラム
※ コツが主役である。
→「工程成果物」、「合意成熟度レベル」、「４つの作業」などは、
コツを分類する為に用意された仕切り版の様なもの。
これらを規定するガイドではない。
※ あらゆる場面に効果が出る訳ではない
→利用時には取捨選択必要（コツ間の矛盾も存在）
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 14
「機能要件の合意形成ガイド」技術領域
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 技術領域
エンタープライズ系業務システムを構築するにあたり、機能要件として
設計対象となる主要な要素。次の６つの技術領域からなる。
システム振舞い
画面
データモデル
これらの
１つひとつが
技術領域
ZZ9／ZZ9
納品書
(ZZ9)
YYYY/MM/DD 23:59
伝票番号 XXXXXXXXXX お届け先コード XXXXXXXXXX
お届け先名
NNNNNNNNNNNNNN 御中
お届け先住所 NNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNN
出荷元コード
出荷部門
XXXXXXXXXX
NNNNNNNNNNNNNN
売上区分 X
発注区分 X
支払期限
YYYY年MM月DD日
納品明細
No
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
単 価
品 番
商品名
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ
9
帳票
数量
ZZ
ZZ
ZZ
ZZ
ZZ
ZZ
ZZ
ZZ
ZZ
ZZ
ZZ
ZZ
ZZ
ZZ
ZZ
ZZ
ZZ
ZZ
ZZ
ZZ
合 価
\Z,ZZZ,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ
\Z,ZZZ,ZZZ,ZZ
消費税
額
\Z,ZZZ,ZZ
\Z,ZZZ,ZZ
\Z,ZZZ,ZZ
\Z,ZZZ,ZZ
\Z,ZZZ,ZZ
\Z,ZZZ,ZZ
\Z,ZZZ,ZZ
\Z,ZZZ,ZZ
\Z,ZZZ,ZZ
\Z,ZZZ,ZZ
\Z,ZZZ,ZZ
\Z,ZZZ,ZZ
\Z,ZZZ,ZZ
\Z,ZZZ,ZZ
\Z,ZZZ,ZZ
\Z,ZZZ,ZZ
\Z,ZZZ,ZZ
\Z,ZZZ,ZZ
\Z,ZZZ,ZZ
\Z,ZZZ,ZZ
9
備 考
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
ＮＮＮＮＮＮＮＮＮＮＮＮ
バッチ処理
外部インタフェース
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 15
「機能要件の合意形成ガイド」工程成果物
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 工程成果物とは？
各技術領域において、設計書の一部として書かれ、
合意形成のために必要な設計要素（名称は一般的なもの）
設計書
画面設計書
発注者
「工程成果物」
画面レイアウト
画面入出力項目
一覧
確認
画面アクション明細
※ コツに登場する設計要素のみ収録
開発で必要なもの全てを収録しているわけではない。
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 16
「機能要件の合意形成ガイド」工程成果物
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 システム振舞い編の紹介
要件定義プロセスで作成される業務フローや業務処理定義書を元に、
システム化する範囲を識別し、その範囲の設計を発注者と開発者が合意
するためのコツを、４つの「工程成果物」を中心に解説。
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 17
「機能要件の合意形成ガイド」工程成果物
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 画面編の紹介
要件定義、外部設計工程で作成される業務フローやシステム化業務フ
ローを元に、導き出されるユーザインターフェースの１つである「画
面」を設計するためのコツを、6つの「工程成果物」を中心に解説。
画面遷移
画面間の遷移関係を示した図。
画面から画面への遷移と画面
遷移を起こすキッカケとなるイベン
ト。
条件分岐がある場合は、その条
件と対応する分岐遷移
画面一覧
No
分類
1 入力フォー
ム
2 入力フォー
ム
3 入力フォー
ム
…
…
画面
画面名
…
ID
ペット登録画面 S-01 …
販売者登録画 S-02 …
面
ログイン画面
S-05 …
…
…
システムで使用する
画面の一覧
…
画面遷移・レイアウト
共通ルール
画面レイアウトと画面遷移
余白
ヘッダーエリア
ユー コンテンツエリア コンテ
ティリ
（main）
ンツエ
ティエリ
リア
ア
（sub2）
コンテ
ンツエ
リア
（sub1） フッターエリア
画面アクション明細
アクションの処 アクションの処理詳細
理概要
入 力 さ れ た 情 ①顧客情報の入力チェック
報をもとに顧客 ②検索処理
情 報 を 登 録 す 入力された情報をもとに顧客情報テー
る
ブルを検索する
③-1 合致するデータが存在しない場合
顧客情報を登録し、顧客登録画面を初
期表示する
③-2 合致するデータが存在した場合
エラーメッセージを表示する
画面遷移に
伴って起動
させる動作
項目・イベント発生オブジェクト名、
それらに対応する画面部品
（ボタン、入力出力項目など）
およびその配置
20%
60%
に関する共通ルールおよ
び諸々の画面（群）が準じ
る 典型的なレイアウトや
80ﾋﾟｸｾﾙ 遷移のポリシ
80ﾋﾟｸｾ
60ﾋﾟｸｾﾙ
20%
画面レイアウト
画面入出力項目一覧
表
識別
示
表示用のラベル 部品の種類 入力
ID
桁
数
1 ユーザ名
ラベル
× 18
2 新しいパスワード
テキストボックス
△ 18
3 再入力パスワード
テキストボックス
△ 18
4 名前（姓）
テキストボックス
△ 19
5 名前（名）
テキストボックス
△ 19
6 Ｅメールアドレステキストボックス
○ 39
7 電話
テキストボックス
○ 19
8 住所１
テキストボックス
○ 39
9 住所２
テキストボックス
○ 39
Copyright © 2010,2011 IPA, All Rights Reserved
入
力
桁
数
10
10
18
18
38
18
38
38
データ型
文字列
文字列
文字列
文字列
文字列
文字列
文字列
文字列
文字列
入力制約
初期表示
○ ユーザ名値
パスワード入力パターン ×
パスワード入力パターン ×
×
×
Eメール入力パターン
×
電話番号入力パターン ×
×
×
-
画面を介して入出力
する項目の外部仕様
Software Engineering Center 18
SEC
「機能要件の合意形成ガイド」工程成果物
Software Engineering
for Mo･No･Zu･Ku･Ri
 データモデル編の紹介
開発対象システムのデータモデルを設計するためのコツを、
４つの「工程成果物」を中心に解説。
ER図
ユーザ企業内で利用す
るデータをモデル化して
表現したもの
CRUD図
業務とエンティティの
関係を表現したもの
エンティティ
顧
客
機
能
エンティティとリレーショ
ンを表現するシンボルを
用いて作図する。
顧客登録
C
顧客検索
R
受注登録
R
受注明細登録
R
製
品
受
注
受
注
明
細
C
R
R
C
その他資料
データモデル
エンティティ一覧
項番 エンティティ名
説明
1 顧客
・・・
2 商品
・・・
3 受注
・・・
エンティティの一
覧
エンティティ定義
エンティティ名商品
エンティティ名およ
項番 属性名 型 桁 PK 説明
1 商品番号 X 10 P ・・・
びエンティティごと
2 商品名
X 100
・・・
3 商品区分コード
X 3
・・・
の属性の一覧
・・・
Copyright © 2010,2011 IPA, All Rights Reserved
データ辞書
ユーザ企業内で利用する
データに関する規則集
データの最小単位で
データ項目定義 あるデータ項目を定義
ドメイン一覧／定義
データ項目をカテゴリ
分けするための基準
コード一覧／定義
データの内部構造や値
が決まっているデータ項
目の仕様を定義
ファイル一覧／定義
システム間でやりと
りされるデータファイ
ルの一覧／詳細
Software Engineering Center 19
SEC
「機能要件の合意形成ガイド」工程成果物
Software Engineering
for Mo･No･Zu･Ku･Ri
 外部インタフェース編の紹介
外部インタフェースについての「コツ」を、４つの「工程成果物」を中心
に解説。
外部インタフェースの対象領域
やりとりされる
データ
（名称、内容）
開発対象
業務システム
相手先
業務システム
データのやりとりの特性
データのやりとりの方向、手段／方法
データのやりとりのタイミング
外部インタフェース項目説明
No
1
PKEY 項目名
1 送信時刻
2
送信件数
ディテールヘッダ
No PKEY 項目名
1
1 受注番号
2
2 受注区分
3
顧客コード
4
受注金額合計
VARCHAR2
6
7
受注明細件数
支払区分
VARCHAR2
VARCHAR2
クレジット番号
クレジットユーザ名
届け先住所
届け先氏名
届け先電話番号
VARCHAR2
VARCHAR2
VARCHAR2
VARCHAR2
VARCHAR2
3
レコードフッタ
No PKEY 項目名
1
1 送信時刻
システム間のデータの送受
信関係を図示したもの
属性
VARCHAR2
VARCHAR2
VARCHAR2
NUMBER
受注日時
9
希望配送日
9
希望配送時間帯
ディテールボディ
No PKEY 項目名
1
1 注文番号
2
2 商品コード
3
3 商品単価
4
4 購入数量
5
ディテールフッタ
No PKEY 項目名
1
1 終了レコード
2
2 受注明細件数
システム
Ｂ
NUMBER
5
8
9
10
11
12
外部システム関連図
属性
VARCHAR2
VARCHAR2
VARCHAR2
桁数 必須 説明
12 ○ 送信処理を開始した時刻
（yyyymmdd/hhmmssの形式）
2 ○ 送信する受注件数（＝ディテールヘッダレコード数）
桁数 必須 説明
12 ○ 受注（あるいは取消）処理時に採番した番号
1 ○ 受注あるいは取消の区分、１：受注、０：取消
12 ○ 受注を受けた顧客の顧客コード
12 ○ 受注金額あるいは取消金額
（＝ディテールボディの単価×購入数量の合計）
15 ○ 受注あるいは取消が成立した日時
（yyyymmdd/hhmmssの形式）
2 ○ 後続するディテールボディーレコード数
1 ○ 支払方法区分
（D:送品時支払、C:クレジット支払、S:振込)
16
クレジット支払いの場合のクレジット番号
16
クレジット支払いの場合のクレジット所有者名
100
顧客情報で登録されている住所と異なる場合の送付先住
50
顧客情報で登録されている住所と異なる場合の送付先氏
8
顧客情報で登録されている住所と異なる場合の送付先電
話番号
8
配送希望日
1
配送時間帯区分(1：午前中、2:13-15、3:15-18、4:18-20)
属性
NUMBER
CHAR
NUMBER
NUMBER
桁数
属性
桁数
2
12
6
2
NUMBER
12
属性
VARCHAR2
必須 説明
○ 受注した注文明細毎の番号（1から昇順）
○ 受注した商品の商品コード
○ 受注時点での商品単価（受注時は必須）
○ 受注あるいは取り消した商品数
必須 説明
○ 受注明細件数
（ディテールヘッダの受注明細件数と同じ）
桁数 必須 説明
12 ○ 送信処理を開始した時刻
（yyyymmdd/hhmmssの形式）
外部インタフェースに含まれ
る項目に関する定義
システムＡ
外部インタフェース処理説明
通信先
通信先プラットフォーム
受注管理システム
UNIX(HP-UX11i)
エラー時の対応
送信/受信
送信
データ量
メッセージ長
可変
５００Byte(max)
エスケープの規定
エラー時のファイルを破棄し、ファイルを再生成後にリトライする。
外部インタフェース処理説明
・ レコード間では次の規則に従っていること。
① レコードヘッダレコードの送信件数、レコードフッタレコードの送信件数、ならびにディテールヘッダレコードの数は一致していること。
② ディテールヘッダレコードの受注明細件数、ディテールフッタレコードの受注明細件数、ならびに後続するディテールボディレコードの件数は一致していること。
③ ディテールヘッダレコードの受注金額合計と後続するディテールボディレコードの販売単価×購入数量の合計は一致していること。
④ レコードヘッダレコードの送信時刻とレコードフッタレコードの送信時刻は一致していること。
外部インタフェース一覧
・ 受信側で上記の規則に従っていないデータを受信した場合には、途中でデータが欠落したものとみなし、送信エラー扱いとすること。
No 外部インタフェースID
出力 入力
相手先システム情報
(To) (From) 自システム名
システム名
既／新
○
受注管理システム 販売管理システム 既存
外部データ名
1
7800001
受注情報
2
7800002
商品出荷状況情報
○
受注管理システム 販売管理システム 既存
3
7800003
商品情報
○
受注管理システム 販売管理システム 既存
4
7800004
新規顧客情報
○
5
7800005
顧客更新情報
○
6
7800006
受注処理ログ情報
7
7800007
信用照会問合せ情報
8
7800008
信用照会結果情報
9
10
11
6800001
6800002
6800009
出荷指示情報
配送結果情報
販売管理処理ログ情
報
・ 送信対象の受注情報がない場合は、レコードヘッダレコードとレコードフッタレコードだけを送信し、その際の送信件数は０とする。
受注管理システム 顧客管理システム 既存
受注管理システム 顧客管理システム 既存
○
受注管理システム 処理証跡管理シス 既存
テム
受注管理システム クレジット信用照会 既存
システム(外部）
○
受注管理システム クレジット信用照会 既存
システム(外部）
販売管理システム 集配信システム
既存
販売管理システム 集配信システム
既存
販売管理システム 処理証跡管理シス 既存
テム
○
○
○
○
・ 受信側は外部インタフェースレコードを受信したら、受信したレコードが上記に示す規則に従っているかを確認する。
規則に従った外部インタフェースレコードであった場合には、送信元に対して「受信成功」のメッセージを送信する。
規則に従っていない場合には「送信エラー」のメッセージを送信する。
外部インタフェースを一覧化
したもの
システム
Ｃ
外部システムとのデータのやりとりの
方式について、概要を記述したもの
システムＣ
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 20
「機能要件の合意形成ガイド」工程成果物
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 バッチ編の紹介
バッチ処理の外部設計とバッチ処理以外の設計要素との接点にあたる
コツを、４つの「工程成果物」を中心に解説。
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 21
SEC
「機能要件の合意形成ガイド」工程成果物
Software Engineering
for Mo･No･Zu･Ku･Ri
 帳票編の紹介
開発対象となる業務システムで帳票として扱われる出力成果物を設計
するためのコツを、５つの「工程成果物」を中心に解説。
帳票概要
サブシステム名
販売管理
帳票名
商品一覧リスト 帳票分類 一覧表
業務名
販売管理
帳票ＩＤ
RZAB-01
出力枚数 100P／回
機能名
商品管理
作成方法
バッチ出力
作成環境 サーバ
出力様式 CSV
用紙サイズ A４横
プリンタ種別
その他 出力タイミング 月次
保存期間 －
改ページ条件
なし
出力制御条件 なし
セキュリティ条件 なし
指定プリンタ なし
再出力 可
利用部門 ○○部門担当者（●●さん）
現行帳票名
概要
商品管理機能の商品情報一覧画面で表示されている商品リストの一覧を出力する
商品一覧は、商品コード、商品名、商品名（カタカナ）、単価、販売開始時期、当月販売可否、当月販売可能数を掲載する。
商品の出力順序は商品コード順である。
備考
帳票項目説明
No
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
フォント
種類
サイズ
項目名
【ヘッダ部】
ページ番号
伝票内通しページ番号
通番ページ番号
MSゴシック
MSゴシック
MSゴシック
出力日、出力時刻
消費税額
備考
【合計行】
合計金額
仮受消費税
編集様式
参照先エンティティ
出力編集
MSゴシック
MSゴシック
MSゴシック
MSゴシック
MSゴシック
MSゴシック
MSゴシック
MSゴシック
MSゴシック
MSゴシック
MSゴシック
MSゴシック
10
10
10
10
10
10
10
10
10
10
10
10
左詰
左詰
左詰
左詰
左詰
左詰
左詰
左詰
左詰
左詰
左詰
左詰
10
28
10
10
10
40
40
1
1
4
2
2
MSゴシック
MSゴシック
MSゴシック
MSゴシック
MSゴシック
MSゴシック
10
10
10
10
10
10
左詰
左詰
左詰
左詰
左詰
左詰
2
15
24
10
3
14
2
15
24
7
3
10
8 左詰
3
3
3
フォーマット
3 数字(ZZ9)
3 数字(ZZ9)
通番ページ編集ルールに従う
3 数字(ZZ9)
通番ページ編集ルールに従う
YYYY/MM/DD△H24:MI
出力時のシステム時刻を設定
14 (出力日と出力時刻の間は半角
（伝票単位に更新）
空白を空けること）
伝票単位に出力
10 文字列
28 文字列（日本語）
10 文字列
10 文字列
10 文字列（日本語）
40 文字列（日本語）
40 文字列（日本語）
1 文字列
1 文字列
4 数字
2 数字(Z9)
2 数字(Z9)
MSゴシック
【伝票ヘッダ】
出荷元コード
出荷元名
伝票番号
届け先コード
届け先名
届け先住所１
届け先住所２
売上区分
発注区分
支払期限（年）
支払期限（月）
支払期限(日）
【明細行】
NO
品番
商品名
単価
数量
合価
表示属性
文字詰 表示桁数 内部桁数
8 右詰
8 右詰
8 右詰
16
数字(Z9)
文字列
文字列（日本語）
数字（\Z,ZZZ,ZZ9）
数字(ZZ9)
数字(\Z,ZZZ,ZZZ,ZZ9)
出荷トランザクション
部門マスタ
出荷トランザクション
出荷トランザクション
出荷トランザクション
出荷トランザクション
出荷トランザクション
出荷トランザクション
出荷トランザクション
支払期限マスタ
帳票の用途、物理的な属性、動作環境、
運用要件などについてまとめたもの
参照カラム
部門コード
表示用部門名
出荷Ｎｏ
納品先コード
納品先名
納品先住所１
納品先住所２
売上区分
発注区分
支払期限
１から昇順にカウントアップ
出荷明細トランザクション 品番
商品マスタ
商品名
商品マスタ
単価
出荷明細トランザクション 数量
合価＝単価×数量
消費税額
＝(単位消費税額×数量）
MSゴシック
10 左詰
10
MSゴシック
10 左詰
24
24 文字列（日本語）
MSゴシック
MSゴシック
10 左詰
10 左詰
16
14
12 数字(\ZZZ,ZZZ,ZZZ,ZZ9)
10 数字(\Z,ZZZ,ZZZ,ZZ9)
7 数字（\Z,ZZZ,ZZ9）
商品マスタ
単位消費税額
帳票レイアウト
1
2
ZZ9／ZZ9
16px
納品書
4
10px
出荷元コード
出荷部門
8
伝票番号 XXXXXXXXXX お届け先コード XXXXXXXXXX
お届け先名 9 NNNNNNNNNNNNNN
御中
お届け先住所 NNNNNNNNNNNNNNNNNNNNN 10
NNNNNNNNNNNNNNNNNNNNN
売上区分 X
発注区分 X
支払期限
11
納品明細
17
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
3
(ZZ9)
YYYY/MM/DD 24:59
ヘッダ
部
5
XXXXXXXXXX
NNNNNNNNNNNNNN6
10px
12
13
YYYY年MM月DD日
14
No
帳票名
作成周期 出力様式
用紙
プリンタ種別
サイズ
帳票分類
改ページ 出力制約
条件
条件
1 RZAB-01
商品一覧リスト
月次
CSV
A4横
その他
一覧表
なし
なし
販売
商品管理
バッチ出力
2 RZAB-02
商品明細情報表
随時
汎用紙
A4横
モノクロレーザ
詳細表
なし
あり
販売
商品管理
オンライン出力
3 RZBA-01
送付先宛名シールリスト その他
専用紙
A4縦
モノクロレーザ
宛名リストなし
なし
販売
販売促進
オンライン出力
4 RZCB-02
得意先別受注明細表
PDF
A4横
その他
明細表
販売
売上管理
バッチ出力
5 RZCC-01
得意先別請求書（帳票） 月次
汎用紙
A4横
ページプリンタ
明細表
販売
請求管理
バッチ出力
6 RZCC-01
得意先別請求書（FAX） 月次
FAX
A4横
その他
明細表
販売
請求管理
オンライン出力
帳票ID
月次
業務
機能
作成方法
出荷明細トランザクション 備考
10px
7
No
合計金額＝Σ（合価）
仮受消費税＝Σ（消費税額）
帳票レイアウトに基づいて印字されるデータ
項目の属性情報を記載したもの
10px
帳票一覧
【利用頻度】月１回
【出力条件】そのまま印刷可能な状態とすること。
【帳票廃止可能性】電子化し再利用できるなら廃止可
15
16
10px
作成する帳票を一覧化したもの
見出し
項目１
項目２
項目３
項目４
□□□
□□□
□□□
□□□
□□□
□□□
□□□
□□□
□□□□
□□□□
□□□□
□□□□
□□□□
□□□□
□□□□
□□□□
□□□□□
□□□□□
□□□□□
□□□□□
□□□□□
□□□□□
□□□□□
□□□□□
□□□
□□□
□□□
□□□
□□□
□□□
□□□
□□□
伝票ヘッダ部
（２ページ目以降
は、
売上区分、発注区
分、支払期限は印
帳票編集定義
処理説明
サブシステム名
業務名
機能名
帳票分類
処理説明
全般
21
18
24
消費税 23
備 考
品 番
商品名 19 20 単 価 数量 22 合 価
\Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ ZZ \Z,ZZZ,ZZZ,Z 額
\Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ ZZ \Z,ZZZ,ZZZ,Z
\Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ ZZ \Z,ZZZ,ZZZ,Z
\Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ ZZ \Z,ZZZ,ZZZ,Z
\Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ ZZ \Z,ZZZ,ZZZ,Z
\Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ ZZ \Z,ZZZ,ZZZ,Z
\Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ ZZ \Z,ZZZ,ZZZ,Z
\Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ ZZ \Z,ZZZ,ZZZ,Z
\Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ ZZ \Z,ZZZ,ZZZ,Z
\Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ ZZ \Z,ZZZ,ZZZ,Z
\Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ ZZ \Z,ZZZ,ZZZ,Z
\Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ ZZ \Z,ZZZ,ZZZ,Z
\Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ ZZ \Z,ZZZ,ZZZ,Z
\Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ ZZ \Z,ZZZ,ZZZ,Z
\Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ ZZ \Z,ZZZ,ZZZ,Z
\Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ ZZ \Z,ZZZ,ZZZ,Z
\Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ ZZ \Z,ZZZ,ZZZ,Z
\Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ ZZ \Z,ZZZ,ZZZ,Z
\Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ ZZ \Z,ZZZ,ZZZ,Z
\Z,ZZZ,ZZ ＮＮＮＮＮＮＮＮＮＮＮＮ
XXXXXXXXXXXXXXXＮＮＮＮＮＮＮＮＮＮＮＮ \Z,ZZZ,ZZ ZZ \Z,ZZZ,ZZZ,Z
9
9
\Z,ZZZ,ZZZ,ZZZ,Z 25
合計金額
Z9 \Z,,ZZZ,ZZZ,Z 26
うち消費税
Z9
以上、確かに納品致しました。
●●県△△市□□町４－２１－２２
株式会社
◇◇◇◇◇◇◇◇
明細表
販売管理
販売管理
納品書出力
改ページ条件 あり
出力制御条件 あり
帳票名
帳票ＩＤ
出力様式 汎用紙
帳票作成方法
納品書
RZCD-01
用紙サイズ Ａ４横
バッチ出力
モノクロレーザ
なし
本帳票は、出荷に伴う納品書を作成するものである。
本帳票は、出荷トランザクションに格納されたデータと出荷明細トランザクションに格納されたデータをもとに納品書を作成する。
本帳票は、出荷トランザクションに格納された出荷元コード、伝票番号をキーとして１つの納品書を作成する。
出荷される商品の明細データは出荷明細トランザクションに格納されており、必要なデータは発注番号をキーとして抽出する。
改ページ条件 発注番号が変わる毎に改ページを行う。
同一の発注番号で納品書に印字される出荷明細（納品明細）が２０件を超える場合には、20件毎に改ページを行う。
同一の発注番号で改ページが発生する場合には伝票ヘッダ部、フッタ部の処理が異なるので注意のこと。
発注番号が変わる毎に合計行部の印字内容も変わるので注意のこと。
ヘッダ部
明細行部
（25行を超えた
ら改ページす
る）
伝票ヘッダ部
合計行部
（最終ペー
ジにのみ印
刷すること）
10px
帳票上で印字されるデータの出力位置、
大きさなどを示したもの
Copyright © 2010,2011 IPA, All Rights Reserved
ヘッダ部は改ページされる毎に作成する。
ページ番号
伝票番号が変わることに１にリセットする。改ページされたら１カウントアップする。
伝票内通しページ番号
同一の伝票番号における総ページ数を示す。
同一の伝票番号の明細行は２０件毎に改ページされるので、
出荷明細トランザクションにある同一の伝票番号を持つ明細行数の和から総ページ数を算出する。
通番ページ番号 本帳票の通しページである。１から改ページ毎に１カウントアップする。
出力日、出力時刻印刷処理の行われたシステム時刻を設定する。この時刻は伝票番号毎にリセットする。
伝票ヘッダ部は改ページされる毎に作成する。
同一の伝票番号の納品書が複数枚にわたる場合には、2ページ目以降は売上区分、発注区分、支払い期限は印字しない。
出荷元情報
出荷元コード
出荷部門
納品先情報
伝票番号
お届け先コード
お届け先名
お届け先住所１
お届け先住所２
出荷トランザクションの部門コードを設定する。
部門コードをキーとして部門マスタを参照し、このコードに合致する表示用部門名を設定する。
出荷トランザクションに格納されている出荷Ｎｏを設定する。
出荷トランザクションに格納されている納品先コードを設定する。
出荷トランザクションに格納されている納品先名を設定する。
出荷トランザクションに格納されている納品先住所１を設定する。
出荷トランザクションに格納されている納品先住所２を設定する。
出力項目のデータ転記／編集、改ページ、
ヘッダ／フッタの編集要件を示したもの
Software Engineering Center 22
「機能要件の合意形成ガイド」合意形成とは
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 合意形成の進め方(合意成熟度と4つの作業)
（次工程へ）
合意成熟度のレベル
完成
一緒に
レビューする
もれ／矛盾を
チェックする
図表に書く
言い切る／聞き切る
充実
もれ／矛盾を
チェックする
一緒に
レビューする
図表に書く
言い切る／聞き切る
仕掛
合意形成を図るための作業
（要件定義から）
外部設計の工程
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 23
「機能要件の合意形成ガイド」合意形成成熟度と作業
 合意成熟度レベル

SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
定義は細かく書いてあるが、
読者はなんとなく
分かっていれば十分
合意形成の進度に応じた分類
 ４つの作業

合意形成の為に行う作業の大まかな分類
レベル
合意成熟度
レベル
４つの作業
仕掛
充実
完成
各
レ
ベ
ル
の
ゴ
ー
ル
の
イ
メ
ー
ジ
もれ／矛盾をチェックする
作
業
の
種
類
図表に書く
一緒にレビューする
言い切る／聞き切る
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 24
「機能要件の合意形成ガイド」合意形成成熟度と作業
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 合意形成の進め方（合意成熟度のレベル）
レベル
仕掛
充実
完成
仕掛レベル
各
レ
ベ
ル
の
ゴ
ー
ル
の
イ
メ
ー
ジ
作
業
の
種
類
 発注者が「言い切っ
た」、開発者が「聞き
切った」と言えるレベ
ル
もれ／矛盾をチェックする
図表に書く
一緒にレビューする
 要件定義が完了して
いなければ、このレ
ベルで実施します。シ
ステム化の目的と範
囲が明確になってい
ます。
言い切る／聞き切る
概要編３１ページ～３３ページからの抜粋
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 25
「機能要件の合意形成ガイド」合意形成成熟度と作業
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 合意形成の進め方（合意成熟度のレベル）
レベル
仕掛
充実
完成
充実レベル
各
レ
ベ
ル
の
ゴ
ー
ル
の
イ
メ
ー
ジ
作
業
の
種
類
 言い切った／聞き
切った内容から「図
表に書いてレビュー」
を繰り返し、発注者と
開発者の合意内容が
充実していくレベル
もれ／矛盾をチェックする
図表に書く
一緒にレビューする
言い切る／聞き切る
概要編３１ページ～３６ページからの抜粋
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 26
「機能要件の合意形成ガイド」合意形成成熟度と作業
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 合意形成の進め方（合意成熟度のレベル）
レベル
仕掛
充実
完成
各
レ
ベ
ル
の
ゴ
ー
ル
の
イ
メ
ー
ジ
作
業
の
種
類
完成レベル
 合意内容が管理され、
発注者と開発者の双
方が「合意内容を確
認できた」と言えるレ
ベル
 外部設計工程の成果
物の最終承認直前ま
でのレベル
もれ／矛盾をチェックする
図表に書く
一緒にレビューする
言い切る／聞き切る
概要編３１ページ～３６ページからの抜粋
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 27
「機能要件の合意形成ガイド」合意形成成熟度と作業
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 合意形成の進め方（４つの作業）
レベル
仕掛
充実
各
レ
ベ
ル
の
ゴ
ー
ル
の
イ
メ
ー
ジ
完成
 要件定義の結果を伝えます。
• システム化の目的・範囲
• 運用時や保守拡張時の操
作や業務
言い切る／聞き切る
もれ／矛盾をチェックする
作
業
の
種
類
発注者は
図表に書く
一緒にレビューする
• 業務遂行において変えるこ
とのできない制約条件（業
務や組織構造、連携システ
ムなどにより生じる制約、
及び業務上の法令や規則
など）
正しく伝えるために、
発注者が言い切ること、開
発者が聞き切ることです。
概要編３１ページ～４１ページからの抜粋
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 28
「機能要件の合意形成ガイド」合意形成成熟度と作業
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 合意形成の進め方（４つの作業）
レベル
仕掛
充実
各
レ
ベ
ル
の
ゴ
ー
ル
の
イ
メ
ー
ジ
完成
開発者は
設計書の記述上の約
束事を共通ルールとし
て記述します。
発注者から聞き切った
情報を反映して書きま
す。
図表に書く
レビューで指摘された
欠陥を修正します。
もれ／矛盾をチェックする
作
業
の
種
類
一緒にレビューする
言い切る／聞き切る
概要編３１ページ～４１ページからの抜粋
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 29
「機能要件の合意形成ガイド」合意形成成熟度と作業
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 合意形成の進め方（４つの作業）
レベル
仕掛
充実
完成
各
レ
ベ
ル
の
ゴ
ー
ル
の
イ
メ
ー
ジ
共通ルール自体にも
れ／矛盾がないことを
チェックします。
もれ／矛盾をチェックする
作
業
の
種
類
開発者は
図表に書く
「工程成果物」が共通
ルールに沿っているこ
とをチェックします。
他の技術領域の「工
程成果物」を含め、整
合をチェックします。
一緒にレビューする
言い切る／聞き切る
概要編３１ページ～４１ページからの抜粋
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 30
「機能要件の合意形成ガイド」合意形成成熟度と作業
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 合意形成の進め方（４つの作業）
レベル
仕掛
充実
完成
各
レ
ベ
ル
の
ゴ
ー
ル
の
イ
メ
ー
ジ
発注者は開発者が想定
していない前提や運用が
ないかをレビューします。
一緒にレビューする
もれ／矛盾をチェックする
作
業
の
種
類
発注者の要件と開発者
の設計に齟齬がないこと
をレビューします。
図表に書く
システム化の目的と範囲
に照らし合わせて、「工程
成果物」が正しく書かれ
ていることをレビューしま
す。
言い切る／聞き切る
概要編３１ページ～４１ページからの抜粋
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 31
「機能要件の合意形成ガイド」合意形成成熟度と作業
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 合意形成の進め方(合意成熟度と4つの作業)再掲
（次工程へ）
合意成熟度のレベル
完成
一緒に
レビューする
もれ／矛盾を
チェックする
図表に書く
言い切る／聞き切る
充実
もれ／矛盾を
チェックする
一緒に
レビューする
図表に書く
言い切る／聞き切る
仕掛
合意形成を図るための作業
（要件定義から）
外部設計の工程
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 32
「機能要件の合意形成ガイド」目次構成

SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
若干差異はあるが、各技術領域編内部の構成はほぼ同じ
第１章
概要
編全体の概要
・前提条件、スコープ
・工程成果物の定義
第２章
合意形成に使う
主な図表の解説
各工程成果物の詳細説明（サンプル付き）
第３章
合意形成のコツ
コツの紹介
・「４つの作業」別に記述
・「発注者が事前に意識する」が含まれる
ものがある
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 33
「機能要件の合意形成ガイド」コツの読み方SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
コツの目的：
何を解決したいコツなのか
施策：目的達成のために、どうすれば
よいのかの概要
合意成熟度レベル：
どのタイミングで使えるか
工程成果物：
このコツに登場す
る工程成果物
具体例：
コツの具体例
メリット：
コツ適応による効果
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 34
「機能要件の合意形成ガイド」記述例
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 言い切る／聞き切るためのコツの例
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 35
「機能要件の合意形成ガイド」記述例
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 図表に書くためのコツの例
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 36
「機能要件の合意形成ガイド」記述例
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 もれ／矛盾をチェックするためコツの例
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 37
「機能要件の合意形成ガイド」記述例
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 一緒にレビューするためのコツの例
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 38
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
3．「機能要件の合意形成ガイド」の適用例
（開発者向け書き方／レビュー編）
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 39
SEC
事例１：わかりにくい設計書
Software Engineering
for Mo･No･Zu･Ku･Ri
 事例：わかりにくい画面遷移ドキュメント
 ユーザの役割（一般ユーザ、サプライヤ、管理者）毎に、異なる遷移を表
現しようと、以下の様な遷移図を持っていくと、お客様に「意味がわから
ない」といわれた。
《開始点》
ログイン画面
遷移と分岐が
ゴチャゴチャし
てて分からん
…
[一般ユーザの場合]
トップページ
[サプライヤの場合]
[管理者の場合]
管理者トップページ
サプライヤトップページ
メニュー画面
発注者側
（お客様）
[一般ユーザの場合]
《終了点》
商品一覧画面（ユーザ）
[サプライヤの場合]
[管理者の場合]
《終了点》
商品一覧画面（管理者）
《終了点》
商品一覧画面（サプライヤ）
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 40
SEC
事例１：わかりにくい設計書
Software Engineering
for Mo･No･Zu･Ku･Ri
 何故、そのようなことになってしまったのか？
 ユーザ役割毎に画面遷移順序が異なるにも拘わらず、１つの画面遷移
ドキュメントに収めてしまったから。
一般ユーザの遷移
《開始点》
ログイン画面
[一般ユーザの場合]
トップページ
サプライヤの遷移
望ましい書き方は
ユーザ役割別に
画面遷移を作成す
る
[サプライヤの場合]
[管理者の場合]
管理者トップページ
商品一覧(ユーザ編)画面遷移
サプライヤトップページ
《開始点》
《開始点》
ログイ ン 画面（共通）
トップページ
管理者トップページ
サ プライ ヤ トップページ
[メニュー選択]
メニュー画面（共通）
[メニュー選択]
メニュー画面（共通）
[業務種類選択]
《終了点》
商品一覧画面（管理者）
《終了点》
商品一覧画面（サプライヤ）
メニュー画面（共通）
[業務種類選択]
[業務種類選択]
《終了点》
商品一覧画面（ユ ーザ ）
商品一覧画面（ユーザ）
[ログイ ン ]
[サプライヤの場合]
[管理者の場合]
《終了点》
ログイ ン 画面（共通）
[ログイ ン ]
[メニュー選択]
[一般ユーザの場合]
《開始点》
ログイ ン 画面（共通）
[ログイ ン ]
メニュー画面
商品一覧(サプライヤ編)画面遷移
商品一覧(管理者編)画面遷移
《終了点》
商品一覧画面（管理者）
《終了点》
商品一覧画面（サ プライ ヤ ）
画面遷移の例
管理者の遷移
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 41
事例１：わかりにくい設計書
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 適用できるコツ（書き方のコツ）
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 42
事例１：わかりにくい設計書
Copyright © 2010,2011 IPA, All Rights Reserved
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
Software Engineering Center 43
事例２：出来上がった画面遷移をレビューする SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 事例：出来上がった画面遷移の過不足についてレビューしたい
 出来上がった画面遷移が過不足なく記述されていることを確認したい。
どうすればいい？
単に追いかけるだけ
じゃ芸がないよな…
受付状況確認画面
ログイン画面
注文結果確認画面
［受付状況確認］
［注文］
［ログイン］
［注文入力］
［書籍検索］
メニュー画面
「OK」
「閉じる」
注文入力画面
開発者側
［書籍登録］
書籍検索画面
［確認］
「OK」
「閉じる」
書籍登録画面
書籍登録確認画面
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 44
事例２：出来上がった画面遷移をレビューする SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 適用できるコツ（レビューのコツ）
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 45
SEC
事例３：発注者と一緒にレビューする
Software Engineering
for Mo･No･Zu･Ku･Ri
 事例：出来上がったデータモデルについてレビューしたい
 データモデルのレビューが表面的になりがち
 お客様に、データ構造の意味（出来ること／出来ないこと など）をしっ
かり伝えるにはどうすればよい？
たぶん、良いん
じゃないかな．．．
大丈夫かな…
買取引
発注者側
（お客様）
対象ER図の例
取引ID
顧客
商談ID ( F K)
楽器番号 ( F K)
希望価格
取引ステータス
取引発生日
取引グループ
顧客ID
グループID
顧客名
連絡先
顧客ID ( F K)
発生日
終了日
商品
楽器番号
売取引
取引ID
ステータス
開発者側
商談ID ( F K)
取引ステータス
希望価格
楽器番号 ( F K)
取引発生日
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 46
事例３：発注者と一緒にレビューする
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 適用できるコツ（レビューのコツ）
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 47
事例のまとめ（適用する上での注意事項） SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 取り上げたものは、「お客様との齟齬を防止するノウハウ」
 ガイドにおいてはこのノウハウをコツと呼ぶ
 「機能要件の合意形成ガイド」はこのようなコツが満載
 コツについてケーススタディからわかること
 どの局面にも通用するわけではない
 コツの適用可能/不可能はプロジェクト（システム）の特性により異なる。
（例えば、CRUD図は顧客納品物/レビューの対象ではない。）
 唯一の解ではない
 たとえば、画面遷移の過不足をチェックする方法はこれだけではない
 コツは“森”ではなく“木”に近い
 大局的な作業プロセスや、成果物構成などを規定するものではなく、
特定の場面において役立つノウハウ（記述の仕方、振る舞い）。
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 48
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
3．「機能要件の合意形成ガイド」の適用例
（発注者への要求確認編）
Copyright © 2010,2011 ＩＰＡ, All Rights Reserved
Software Engineering Center 49
事例１：例外業務システム処理の設計漏れ SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 事例：会計システムの振込処理における誤振込時の組戻し処理の漏れ
 会計システムの振込処理において、誤振込が発生した場合、財務部が金融機
関に連絡をした上で、振込データの戻しとこれに伴う会計処理（組み戻し処
理）を行うことになっているが、会計システムでは組み戻し処理が設計され
ていなかった。
 本番直前の運用テストの段階で財務部からの指摘で組み戻し処理が抜けてい
る事が判明。急遽追加することになった。
当社の支払処理は銀行振込の
場合、・・・・・・・・・
という手順となります。
ここはシステム化の対象です。
ヒアリング時
経理部門担当者
レビュー時
システム化業務フ
ロー
販売部門
業務フロー
万一、振込口座が
誤っていて誤振込
になった場合には、
銀行に連絡すると
ともに組戻し処理
を行います。
財務部門担当者
なるほど、
そういう処理の
流れになるん
ですね？
経理部門担当者
出荷部門
（倉庫）
仕入先
<<システム支援>>
顧客の登録
システム化される
振込処理の流れ
は次のようになり
ます。
テナント
契約
販売部門
出荷部門
（倉庫）
<<システム支援>>
仕入先
物件仮押
<<人の作業>>
意思の確認
<<システム>>
顧客登録
<<システム>>
進捗登録
<<システム支援>>
顧客の登録
テナント
契約
<<システム支援>>
物件仮押
<<人の作業>>
意思の確認
<<システム>>
顧客登録
<<システム>>
進捗登録
ふむふむ。
振込結果
はどうわか
るの？
経理部門担当者
開発担当者
Copyright © 2010,2011 IPA, All Rights Reserved
開発担当者
Software Engineering Center 50
事例１：例外業務システム処理の設計漏れ SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 何故、そのようなことになってしまったのか？
 レビュー時に業務フローとシステム化業務フローを比較・検証しなかっ
たから。
システム化業務フローを見ていただけでは例外業務である組み戻し処理
が抜けていることに気付かなかった。
レビュー時
ヒアリング
時
経理部門担当者
業務フロー
販売部門
出荷部門
（倉庫）
システム化業務フ
ロー
販売部門
経理部門担当者
出荷部門
（倉庫）
仕入先
<<システム支援>>
顧客の登録
仕入先
テナント
契約
<<システム支援>>
物件仮押
<<システム>>
顧客登録
<<システム支援>>
顧客の登録
テナント
契約
<<人の作業>>
意思の確認
<<システム支援>>
物件仮押
<<人の作業>>
意思の確認
<<システム>>
進捗登録
<<システム>>
顧客登録
<<システム>>
進捗登録
財務部門担当者
ヒアリングでは、業務フローを使って、
業務の流れとその中からシステム化
対象の業務を確認していた。
開発担当者
業務フローと
システム化業務フロー
の
比較・検証を行い、
システム化対象業務の
漏れがないかを確認し
ていなかった
Copyright © 2010,2011 IPA, All Rights Reserved
経理部門担当者
開発担当者
レビューでは、システム化業務フロー
を使って、システム化対象の業務の
流れとシステムとのやりとりに齟齬が
ないかを中心に確認していたため、
対象業務に漏れがないかの確認がで
きていなかった。
Software Engineering Center 51
事例１：例外業務システム処理の設計漏れ SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 適用できるコツ（言い切る／聞き切るコツ）
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 52
事例２：業務運用パターンの確認漏れ
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 事例：売上伝票入力の承認のやり方が不十分と開発途中で発覚
 発注者は開発者にシステム化対象業務の説明する際に、開発者に業務の流れを理
解してもらおうと思い、最もシンプルなフローで「営業部で手続き」等の曖昧な
表現で流れを説明した。その際、伝票入力者と承認者等の役割（ロール）の違い
は後で確認されると思い、説明しなかった。
 開発者は説明されたとおりに、入力処理と承認処理を同一画面で行うよう設計し
た。またワークフローもシンプルな構成のものを想定した。
 権限階層やワークフローの実態が明確になるにつれ、当初開発者が想定していた
規模よりも大きな規模の開発である事がわかり、予算の追加と工期の延長が必要
となってしまった。
システム化される発注処理は各部署
でデータ入力して、承認するという流
れとなっています。
ヒアリング
時
システム化業務フ
ロー
販売部門
伝票承認者
承認代行者
出荷部門
（倉庫）
仕入先
なるほどそうですか。
<<システム支援>>
顧客の登録
テナント
契約
<<システム支援>>
内部統制上、伝票入力者と
伝票承認者は別々にし、承認 営業部門担当者
者も代行をおけるようになって
いるが、その辺は販売担当の
伝票入力者 SEなら常識でわかってくれる
よね？
物件仮押
<<人の作業>>
意思の確認
Copyright © 2010,2011 IPA, All Rights Reserved
<<システム>>
顧客登録
<<システム>>
進捗登録
開発担当者
Software Engineering Center 53
事例２：業務運用パターンの確認漏れ
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 何故、そのようなことが起こってしまったのか？
 発注者が、各部署には入力権限、承認権限、代理承認権限のユーザーがい
るにも拘らず、役割（ロール）を正確に伝えなかった、また実際のワーク
フローもデータの内容により複雑な分岐となることを説明しなかったため
。
 開発者は入力処理と承認処理が分かれていることを確認しているにも拘わ
らず、入力処理と承認処理の利用者の相違、入力処理、承認処理それぞれ
の流れについて確認を怠っていたため。
ヒアリング／レビュー時
また入力処理から承認処理までの一
連の処理の流れを確認させていただ
けませんか？
システム化業務フ
ロー
販売部門
出荷部門
（倉庫）
仕入先
<<システム支援>>
顧客の登録
テナント
契約
<<システム支援>>
物件仮押
<<人の作業>>
営業部門担当者
意思の確認
入力処理と承認処理に分かれていま
すが、それぞれの処理を担当する役
割は異なるのでしょうか？
<<システム>>
顧客登録
承認処理はどういう場合でも同一で
すか？弊社の場合、受注金額で
承認できる職位が異なるんですが？
<<システム>>
進捗登録
開発担当者
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 54
事例２：業務運用パターンの確認漏れ
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 適用できるコツ（レビューのコツ）
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 55
事例３：要求した画面イメージと異なる
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 事例：発注者からの注文入力画面に関する不十分な要求
 注文入力画面は、同一画面上段に入力欄、下段に注文履歴欄を設け、注文
履歴を確認しながら注文入力を行うという要件であるが、発注者は開発者
に単に「注文履歴を確認しながら注文入力が行えるよう」という曖昧な要
件を伝えたのみで画面レイアウトの提示をしなかった。
 開発者は要件に沿うよう注文入力画面と注文履歴画面を分けて設計した。
 発注者はレビューの段階で注文入力画面がイメージと異なる事に気付き、
急遽仕様変更することになった。
１つの画面
で 発注者：
注文入力画面
発注者：
商品名：
注文番号：
注文
数：
合計
注文
注文番
号
商品名：
わかりました
注文番号：
注文
数：
注文入力画面
２つの画面で
本日の受注一覧：
商品名
発注
者
メニュー
ｷｬﾝｾﾙ
注文数
営業部門担当者
開発担当者
注文入
力
注文履
歴
注文番
号
合計
注文
本日の受注一覧：
商品名
発注
者
ｷｬﾝｾﾙ
注文数
注文入力画面と注文履歴画面
があり、注文履歴を見ながら注
文入力できるようにしてほしい
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 56
SEC
事例３：要求した画面イメージと異なる
Software Engineering
for Mo･No･Zu･Ku･Ri
 何故、そのようなことが起こってしまったのか？
 発注者が具体的な画面レイアウトの提示をしなかった、また開発者が発
注者に確認しなかったから。
 開発者と発注者の間で業務の流れに沿った注文入力画面と注文履歴画面
の流れ、利用シーンを確認しなかったから。
????
注文入力画面
注文入力終了
発注者：
商品名：
複数件数ある場合
注文番号：
ログイン画面
注文入力画
面
営業部門担当
者
開発担当者
こんな画面の遷移と
画面のイメージで
よかったでしょうか？
注文
数：
合計
注文
ｷｬﾝｾﾙ
確認終了
メニュー画面
注文検索画
面
注文一覧画
面
注文番
号
本日の受注一覧：
商品名
発注
者
注文数
更新終了
注文更新画
面
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 57
事例３：要求した画面イメージと異なる
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 適用できるコツ（言い切る／聞き切るコツ）
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 58
SEC
事例４：意図しない画面遷移
Software Engineering
for Mo･No･Zu･Ku･Ri
 事例：一括注文取消処理の画面遷移がおかしい
 注文一括取消処理は「発注履歴画面にて取消対象を複数選択後、注文取消画面に
遷移し、選択した個々の注文内容を確認しながら取消処理を選択数分連続して行
う」という要件を開発者に提示した。
 出来上がったシステムを確認したところ、
「発注履歴画面（2件選択）→注文取消画面（1件目）→注文取消画面（2件目）
→発注履歴画面」と遷移して欲しいところが、
「発注履歴画面（2件選択）→注文取消画面（1件目）
→発注履歴画面→注文取消画面（２件目）→発注履歴画面」というように
都度発注履歴画面に戻るようになっていた。
注文取消画面
（取消注文１）
注文履歴画面
注文取消画面
（取消注文１）
実行
注文履歴画面
取消の適否確認
削除したい注文
を選択（複数）
実行
発注者
実行
取消注文１に対する注文取消処理およ
び
注文取消画面（取消注文２）の表示
削除したい注文
を選択（複数）
取消注文１に対す
る
注文取消処理
注文取消画面
（取消注文２）
実行
開発者
Copyright © 2010,2011 IPA, All Rights Reserved
取消注文２に対す
る
注文取消処理
Software Engineering Center 59
SEC
事例４：意図しない画面遷移
Software Engineering
for Mo･No･Zu･Ku･Ri
 何故、そのようなことが起こってしまったのか？
 レビューでは発注履歴画面と注文取消画面の確認はしたが、画面遷移の
確認を怠ってしまったから。
レビュー時
ふむふむ。
その操作手順でＯＫです。
発注者
この画面の表示項目は・・・・・・で、操作手
順は・・・・・・・・・・・と
なります。これでＯＫですか？
注文履歴画面
画面レイアウト
注文取消画面
画面レイアウト
開発者
レビュー
対象外
注文取消画面
注文履歴画
面
注文取消画面
注文取消画面
画面遷移
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 60
事例４：意図しない画面遷移
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 適用できるコツ（レビューのコツ）
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 61
SEC
事例５：無駄な類似した帳票の開発
Software Engineering
for Mo･No･Zu･Ku･Ri
 事例：異なる現場部門から類似した内容の帳票開発要求
 大規模システム開発のため、発注者側は設計担当者を業務領域毎に分け、個々に帳
票レイアウト定義を実施。担当者毎に完成時期が異なり、工期も厳しかったため、
発注者側は帳票類の整理と合理化の手間を省き、帳票レイアウト完成の都度五月雨
式に開発者に提示。
 出来上がった帳票を俯瞰すると同じような帳票を幾つも作成してしまい、その無駄
を開発担当者から指摘された。
この帳票は
このレイアウト
でないと
使えません。
開発依頼
部門Ａ担当者
このレイアウト
で何年も業務を
してきたので今
更変更できませ
ん。
部門Ｂ担当者
この帳票は
うちの部門の
ノウハウの塊
です。変更は
無理です。
整
理
・
統
合
調
整
で
き
ず
出力項目もレイアウト
もかなり類似している
のに、それぞれ作る
必要があるのかな？
確認してみよう。
開発依頼
開発者
発注者調整
役
開発依頼
部門Ｃ担当者
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 62
SEC
事例５：無駄な類似した帳票の開発
Software Engineering
for Mo･No･Zu･Ku･Ri
 何故、そのようなことが起こってしまったのか？
 業務担当毎に設計した帳票類を一旦発注者側内部で整理、合理化した上で開
発者に開発すべき帳票を提示すべきだったが、厳しい工期で各業務担当部門
との調整をつけられず、
業務担当毎に必要な帳票の開発依頼をかけたため。
 帳票の利用目的、必要な理由の確認が不十分なまま開発依頼を行ったため。
この帳票は
うちの部門の
ノウハウの塊
です。変更は
無理です。
このレイアウトで何
年も業務をしてきた
ので今更変更できま
せん。
この帳票は
このレイアウト
でないと
使えません。
この帳票は半年に１回
だけ利用します。
部門Ａ担当者
この帳票の利用目的は
××なので、代替策があ
るなら考えます。
部門Ｂ担当者
部門Ｃ担当者
こうした調整を図り、帳票を最低限必要なものに絞りたかっ
た
Ａ部門の帳票１とＢ部門の帳
票２とＣ部門の帳票３はほとん
ど同じ内容ですが、どのような
使われ方をしていますか？
発注者調整役
３帳票で異なるのは
この部分だけで、
使われ方も３部門とも
同じようなのですが、
統一すると問題になるのは
どんなことですか？
Copyright © 2010,2011 IPA, All Rights Reserved
この項目と
この項目を演算
した結果あればよく、
多少の変更はでき
るかも。
Software Engineering Center 63
事例５：無駄な類似した帳票の開発
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 適用できるコツ（言い切る／聞き切るコツ）
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 64
事例６：現場業務に精通しない担当者からの帳票要求 SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 事例：現場業務に精通していない業務設計担当者からの帳票開発要求
 発注者側の業務設計担当者は現場の業務にあまり精通していなかったが、
開発者は業務設計担当者の提示する要件に基づいて帳票設計を実施した。
 展開時のユーザー向け説明会で、現場の利用者から帳票に承認印欄が不足
しているとの不備を指摘され、急遽設計変更を行うことになった。
折角作っていただいた
のに、この帳票には
承認印欄がないので、
業務では使えません。
現場担当者に
は未確認
この帳票の仕様は、・・・・・のよ
うになっています。
現場業務に
詳しくない
はいわかりました。
そのように開発します。
開発者
現場業務担当者
発注者側
業務設計担当者
開発
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 65
事例６：現場業務に精通しない発注者の帳票要求
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 何故、そのようなことが起こってしまったのか？
 現場の業務担当者に開発する帳票の仕様に関して意見を聴いていなかった
から。
帳票レビュー迄に現場の担当者の意見も聞いておけばこのような事態にな
らなかった。
この帳票のままでは
承認印欄がないので、
業務では使えません。
追加するようにお願いし
ます。
このような帳票の仕様で現場業務で
適用していただけますか？
何か問題はありませんか？
開発者
現場業務担当者
発注者側
業務設計担当者
帳票レビュー前に内部で確認しておくべきこと
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 66
事例６：現場業務に精通しない発注者の帳票要求
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 適用できるコツ（レビューのコツ）
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 67
SEC
適用事例のまとめ(1/3)
Software Engineering
for Mo･No･Zu･Ku･Ri
 発注者が開発者に曖昧な要件を提示すると、出来上がるシ
ステムは発注者が意図するものと異なるものとなる可能性
が高くなる。
 出来るだけ要件の曖昧さを排除し、開発者に正確に伝える事が肝
要
 言い切るコツの活用（特にコツID02T001）
発注者はシステムに求めるイメージ、業務上のルール、仕事のや
り方などを文書にとりまとめ、具体的に開発者に伝える。
 発注者は開発者に要件を正確に伝えた心算でいても、正確
に伝わっているとは限らない。
 要件が正しく伝わっている事を確認する事が肝要
 レビューのコツの活用
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 68
適用事例のまとめ(2/3)
Copyright © 2010,2011 IPA, All Rights Reserved
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
Software Engineering Center 69
適用事例のまとめ(3/3)
Copyright © 2010,2011 IPA, All Rights Reserved
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
Software Engineering Center 70
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
4．まとめ
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 71
SEC
どのように使ったらよいか？
Software Engineering
for Mo･No･Zu･Ku･Ri
 どのような場面で使うことを想定して作ったか？
・・・活用のヒントとして
1. 開発標準に沿った設計業務を補足するコツ集として

設計に関するドキュメントを介して、ＳＩベンダの開発担当者間、
あるいは開発担当者とユーザ企業情報システム部門・ユーザとの間の
スムーズな意思疎通をはかるために利用する。
2. 教育コンテンツの素材集として

ＳＩベンダやユーザ企業の情報システム部門を中心に、
各社の教育コンテンツの素材集として利用する。
3. レビューに臨む際の心得として

情報システム開発のステークホルダ間のコミュニケーションを
円滑にするために、レビューのコツを利用する。
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 72
SEC
どのように使ったらよいか？
Software Engineering
for Mo･No･Zu･Ku･Ri
 活用事例活用のヒントとして（旧発注者ビューガイドライン時の適用事例）
#
企業（順不同）
状況
１
㈱ＮＴＴデータ
開発手順に適用。具体的には、発注者ビューガイドラインをベースに成果物の記述項目と図の凡例を見直し。また、”コツ”
については社内の既存のチェックリストと統合。
２
富士通㈱
標準開発プロセスの設計書の記述要項、記述例、ワークシートの改善を実施済み。
３
日本電気㈱
社内向けの設計ガイドとして、開発プロセスに合わせてどの作業、どの設計ドキュメントで適用するかを他の設計ガイドと連
携させ独自にガイドとして再編集して利用。
４
㈱日立製作所
標準開発プロセスの設計書の記述要項、記述例、ワークシートの改善を実施済み。
５
㈱構造計画研究所
社内規定「機能設計書記述要領」の１つとして組み入れ、公開。
６
東芝ソリューション㈱
情報システム開発標準群の１つとして組み入れ、社内公開。また、コツの使用について優先度表を作成し、併せて公開。
７
日本ユニシス㈱
社内の（開発関連）知財として管理し展開（公開）するとともに、SE向け説明会等での（書籍も含めた知識の）活用、説明会
の実施など。）
８
ＴＩＳ㈱
社内向け設計ガイドに発注者ビューガイドラインの記述要素を取り込み。発注者ビューガイドライン自体も参考文書として社
内公開。
９
沖電気工業㈱
2008年度より、開発標準に適用。具体的には、発注者ビューガイドラインをそのまま採用せずに、システム設計書作成規定
の「参考資料」として組み入れております。
10
㈱インテック
ガイドラインと社内設計標準の関連付けを実施。
その対比表を基に適切な局面でガイドの該当箇所を参照し、活用するように社内に案内。
11
㈱東京証券取引所
社内の参考情報とするとともに、社内システム開発プロセスへの組込みを検討中。
12
清水建設㈱
2008年上期に特定アプリケーションの開発案件において、「画面編」を適用し、評価を実施。
「発注者ビューガイドラインの活用と拡張～機能要件の合意形成を目指して～」（ 2009年3月31日）からの抜粋・要約
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 73
SEC
どのように使ったらよいか？
Software Engineering
for Mo･No･Zu･Ku･Ri
 悩み・気づき・ヒント
‼ 設計書レビュー時に、
基本的なことの指摘
が多くありませんか？
‼ テスト結果の確認や
検収時に、手直し要
望が多くありません
か？
‼ カットオーバ後に、
すぐ手直しということが
多くありませんか？
そんな時には「機能要件の合意形成ガイド」を一度見てみよう。
⇒そこには発注者と開発者間の合意をより良くするためのヒントがあります。
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 74
SEC
おわりに
Software Engineering
for Mo･No･Zu･Ku･Ri
ダウンロードはこちらから･･･
http://sec.ipa.go.jp/reports/20100331.html
Џо•сЏ€—ќђ„ђi‹@Ќ\ЃFѓ\ѓtѓgѓEѓFѓAѓGѓ“ѓWѓjѓAѓЉѓ“ѓOhp.mht
7冊構成
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 75
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
以上です。
ご清聴ありがとうございました。
Copyright © 2010,2011 IPA, All Rights Reserved
Software Engineering Center 76