X 0142：2010
（1）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
目 次
ページ
序文 ··································································································································· 1
1 適用範囲 ························································································································· 1
2 用語及び定義 ··················································································································· 1
3 IFPUG 4.1版未調整ファンクションポイントの概要 ································································ 9
3.1 ファンクションポイント法の目的及び利点 ·········································································· 9
3.2 計測事例の概要 ············································································································ 10
4 利用者要件記述 ··············································································································· 12
4.1 利用者要件記述の定義 ··································································································· 13
4.2 システムのライフサイクルを通した規模測定 ······································································ 13
4.3 ライフサイクル段階の比較······························································································ 15
4.4 計測上の留意点 ············································································································ 16
5 計測種別の決定 ··············································································································· 17
5.1 ファンクションポイント計測種別の定義 ············································································ 17
5.2 計測の種別の作業手順図 ································································································ 17
6 計測範囲及びアプリケーション境界の識別 ··········································································· 18
6.1 計測範囲及びアプリケーション境界の決定 ········································································· 18
6.2 計測範囲及びアプリケーション境界に関する規則及び手順 ···················································· 20
6.3 計測範囲及びアプリケーション境界を識別するための留意点 ················································· 21
7 データファンクションの計測 ····························································································· 21
7.1 ILF及びEIFの定義 ······································································································ 22
7.2 ILF及びEIFの計測規則 ································································································ 23
7.3 ILF及びEIFの計測手順 ································································································ 25
7.4 計測上の留意点 ············································································································ 26
7.5 ILF及びEIFの計測事例 ································································································ 27
7.6 ILFの識別事例 ············································································································· 30
7.6.1 ILF識別事例の概要 ···································································································· 30
7.6.2 事例1：人事情報システムのデータ ················································································ 30
7.6.3 事例2：人事情報システムのセキュリティ ······································································· 34
7.6.4 事例3：照会及び報告書出力のための監査データ ······························································ 40
7.6.5 事例4：未確定業務情報 ······························································································· 40
7.6.6 事例5：報告書書式定義 ······························································································· 42
7.6.7 事例6：代替索引 ········································································································ 44
7.6.8 事例7：共用データ ····································································································· 44
7.6.9 事例8：異なる利用者及び／又は異なるデータ視点 ··························································· 48
7.6.10 計測したILF，RET及びDETの概要············································································ 52
X 0142：2010 目次
（2）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ページ
7.6.11 ILFの複雑さ及び寄与 ································································································ 52
7.7 EIFの計測事例 ············································································································· 53
7.7.1 EIF計測事例の概要 ···································································································· 53
7.7.2 事例1：他システムからのデータの参照（出力処理） ························································ 54
7.7.3 事例2：他システムからのデータの参照（入力処理の一部として） ······································ 56
7.7.4 事例3：他システムへのデータの提供 ············································································· 58
7.7.5 事例4：ヘルプ機能システム ························································································· 58
7.7.6 事例5：データ変換 ····································································································· 61
7.7.7 事例6：トランザクション 入力ファイル ········································································· 62
7.7.8 事例7：異なる利用者及び／又は異なる利用者記述 ··························································· 64
7.7.9 事例8：同一データの複数目的での利用 ·········································································· 66
7.7.10 計測したEIF，RET及びDETの概要············································································ 67
7.7.11 EIFの複雑さ及び寄与 ································································································ 67
8 トランザクション ファンクションの計測 ············································································ 68
8.1 EI，EO及びEQの定義 ································································································· 68
8.2 EI，EO及びEQの計測規則 ··························································································· 72
8.3 EI，EO及びEQの計測手順 ··························································································· 76
8.4 EI，EO及びEQの計測上の留意点 ·················································································· 78
8.5 要素処理識別の事例 ······································································································ 79
8.5.1 要素処理識別のための識別事例の概要 ············································································ 79
8.5.2 事例1：社員及び扶養家族データの新規登録 ···································································· 79
8.5.3 事例2：小切手の印刷及び発行済みの印付け ···································································· 81
8.5.4 事例3：業務割当ての閲覧 ···························································································· 82
8.5.5 事例4：業務割当ての印刷及び選択基準の保存 ································································· 84
8.5.6 事例5：社員の個人データの面談情報 ············································································· 86
8.5.7 事例6：社員の個人データの運転免許情報 ······································································· 88
8.6 EI，EO及びEQの計測事例 ··························································································· 90
8.7 EIの計測事例 ·············································································································· 93
8.7.1 EI計測事例の概要 ······································································································ 93
8.7.2 事例1：制御情報 ········································································································ 94
8.7.3 事例2：画面情報入力 ·································································································· 97
8.7.4 事例3：複数のEI及び重複したEIをもつバッチ処理 ························································ 98
8.7.5 事例4：未確定業務情報の修正 ····················································································· 101
8.7.6 事例5：複数のFTRをもつEI ······················································································ 103
8.7.7 事例6：データ移行 ···································································································· 107
8.7.8 事例7：他システムからのデータ参照 ············································································ 109
8.7.9 事例8：画面情報出力を伴うEI（その1） ······································································ 110
8.7.10 事例9：画面情報出力を伴うEI（その2） ···································································· 111
8.7.11 EI，FTR及びDET計測の概要 ··················································································· 114
X 0142：2010
（3）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ページ
8.7.12 EIの複雑さ及び寄与 ································································································· 114
8.8 EOの計測事例 ············································································································ 115
8.8.1 EO計測事例の概要 ···································································································· 115
8.8.2 すべてのトランザクション ファンクション型に共通の規則 ··············································· 115
8.8.3 事例1：紙書類報告書の出力 ························································································ 116
8.8.4 事例2：オンライン報告 ······························································································ 118
8.8.5 事例3：他のシステムへの送信トランザクション ····························································· 120
8.8.6 事例4：エラーメッセージ又は確認メッセージ ································································ 122
8.8.7 事例5：通知メッセージ ······························································································ 123
8.8.8 事例6：アプリケーション境界の外部から，データなしに起動されるEO ····························· 125
8.8.9 事例7：EOの主機能 ·································································································· 127
8.8.10 事例8：EOトランザクション ファイル ······································································· 129
8.8.11 計測したEO，FTR及びDETの概要············································································ 131
8.8.12 EOの複雑さ及び寄与 ································································································ 131
8.9 EQの計測事例 ············································································································ 132
8.9.1 すべてのトランザクション ファンクション型に共通の規則 ··············································· 132
8.9.2 EQ計測事例の概要 ···································································································· 133
8.9.3 事例1：アプリケーションメニュー ··············································································· 133
8.9.4 事例2：検索データの一覧 ··························································································· 135
8.9.5 事例3：ドロップダウンリストボックス ········································································· 138
8.9.6 事例4：項目レベルのヘルプ（その1） ·········································································· 140
8.9.7 事例5：項目レベルのヘルプ（その2） ·········································································· 143
8.9.8 事例6：明示的には記述されていない照会 ······································································ 145
8.9.9 事例7：アプリケーション境界をまたぐデータなしに起動するEQ ······································ 147
8.9.10 事例8：他アプリケーションへのデータ送付 ·································································· 149
8.9.11 計測したEQ，FTR及びDETの概要············································································ 151
8.9.12 EQの複雑さ及び寄与 ································································································ 151
附属書JA（参考）JISと対応国際規格との対比表 ····································································· 153
X 0142：2010 目次
X 0142：2010 目次
（4）
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
まえがき
この規格は，工業標準化法に基づき，日本工業標準調査会の審議を経て，経済産業大臣が制定した日本
工業規格である。
この規格は，著作権法で保護対象となっている著作物である。
この規格の一部が，特許権，出願公開後の特許出願，実用新案権又は出願公開後の実用新案登録出願に
抵触する可能性があることに注意を喚起する。経済産業大臣及び日本工業標準調査会は，このような特許
権，出願公開後の特許出願，実用新案権及び出願公開後の実用新案登録出願にかかわる確認について，責
任はもたない。
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
日本工業規格
JIS
X 0142：2010
ソフトウェア技術−機能規模測定−
IFPUG機能規模測定手法
（IFPUG 4.1版未調整ファンクションポイント）
計測マニュアル
Software engineering-
IFPUG 4.1 Unadjusted functional size measurement method-
Counting practices manual
序文
この規格は，2003年に第1版として発行されたISO/IEC 20926を基に作成した日本工業規格であるが，
JISとしては不要であると判断して一部の記述を削除し，構成を変更し，更に箇条及び細分箇条に相当す
るところには箇条番号及び細分箇条番号を追加して作成した日本工業規格である。ただし，技術的内容に
ついては変更していない。
なお，この規格で点線の下線を施してある箇所は，対応国際規格を変更している事項である。変更の一
覧表にその説明を付けて，附属書JAに示す。
1
適用範囲
この規格は，IFPUG 4.1版機能規模測定手法について規定する。
この規格は，次のことを主な目的としている。
− 機能規模を計測するための明確で詳細な説明を提供する。
− IFPUG 4.1版未調整ファンクションポイントを計測する方法の一貫性を保証する。
− 一般的な方法論及び技法の提出物から機能規模を計測するための指針を与える。
注記 この規格の対応国際規格及びその対応の程度を表す記号を，次に示す。
ISO/IEC 20926:2003，Software engineering−IFPUG 4.1 Unadjusted functional size measurement
method−Counting practices manual（MOD）
なお，対応の程度を表す記号“MOD”は，ISO/IEC Guide 21-1に基づき，“修正している”
ことを示す。
2
用語及び定義
この規格で用いる主な用語及び定義は，次による。
2
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
2.1
IFPUG（The International Function Point Users Group）
ファンクションポイント法，その他のソフトウェア計測技術の普及及び支援を目的とする会員制非営利
組織。
2.2
アプリケーション（application）
事業目標の達成を支援するための，相互に強く関係する自動化された手続及びデータの集合。アプリケ
ーションは，一つ以上のコンポーネント，モジュール又はサブシステムからなる。システム，アプリケー
ションシステム又は情報システムの同義語として使用される場合もある。
2.3
アプリケーション境界（application boundary）
測定対象ソフトウェアと利用者との間の境界。
2.4
アプリケーション ファンクションポイント（application function point count）
アプリケーションが利用者に提供している測定時点の機能の測定量。ベースライン ファンクションポイ
ント又は導入ファンクションポイントとも呼ばれる。
2.5
維持管理された（maintained）
要素処理によってデータが追加，更新又は削除されている状態。
2.6
一般システム特性，GSC（general system characteristics，GSC）
アプリケーションの全体的複雑さを評価するための14種類の評価項目。
2.7
運用性GSC（operational ease GSC）
起動，バックアップ，回復などのシステムの運用面をどの程度留意しているかの度合い。14種類の一般
システム特性の一つ。
2.8
影響度，DI（Degree of Influence，DI）
14種類の一般システム特性の各々に対して，その影響の度合いを示す0から5までの数値。調整要因
（VAF）は，DIを使用して計算する。
2.9
影響度合計，TDI（Total Degree of Influence，TDI）
14種類の一般システム特性の度合いの合計。
2.10
エンドユーザ効率GSC（end-user efficiency GSC）
測定対象アプリケーションの利用者に対する，人的要因への配慮及び使いやすさへの配慮の度合い。14
種類の一般システム特性の一つ。
2.11
オンライン更新GSC（online update GSC）
内部論理ファイルがオンラインで更新される度合い。14種類の一般システム特性の一つ。
3
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
2.12
オンラインデータ入力GSC（online data entry GSC）
対話型のトランザクションを通してデータが入力される度合い。14種類の一般システム特性の一つ。
2.13
開発（development）
新規情報システムの要求分析，設計，コード作成，結合，テスト，導入及び受入れ。
2.14
開発プロジェクト ファンクションポイント，DFP（Development project Function Point count，DFP）
プロジェクト完了時に納入されるソフトウェアの初回導入時点に利用者に提供される機能の測定量。
2.15
外部インタフェースファイル，EIF（External Interface File，EIF）
計測対象アプリケーションによって参照される，論理的に関連のあるデータ又は制御情報の利用者視点
のグループ。ただし，維持管理は，他のアプリケーション境界の内部で行われる。EIFは，計測対象のア
プリケーション境界の内部にある一つ以上の要素処理によって参照されるデータを保持することを主目的
とする。このことは，あるアプリケーションで計測されるEIFは，他のアプリケーションにおいてILF（2.53
参照）でなければならないことを意味している。
2.16
外部キー（foreign key）
ILF又はEIF中のデータであり，利用者要件によって他のILF又はEIFと関係付けるためのデータ。
2.17
外部出力，EO（External Output，EO）
計測対象のアプリケーション境界の外部にデータ又は制御情報を出力する要素処理。EOは，データ又
は制御情報の取り出しの有無にかかわらず，処理ロジックによって情報を利用者に提供することを主目的
とする。EOは，処理ロジックに少なくとも一つの“数式又は演算の実行”又は導出データの生成を含ま
なければならない。EOは，一つ以上のILFの維持管理及び／又はシステムの振る舞いの変更を行っても
よい。
2.18
外部照会，EQ（External Inquiry，EQ）
計測対象のアプリケーション境界の外部にデータ又は制御情報を送り出す要素処理。EQは，ILF又は
EIFからデータ又は制御情報を取り出すことによって利用者に情報提供することを主目的とする。EQは，
処理ロジックに“数式又は演算の実行”を含まない。さらに，導出データを生成しない。処理中にILFを
維持管理せず，システムの振る舞いの変更も行わない。
2.19
外部入力，EI（External Input，EI）
計測対象のアプリケーション境界の外部から入力されるデータ又は制御情報を処理する要素処理。EIは，
一つ以上のILFの維持管理及び／又はシステムの振る舞いの変更を主目的とする。
2.20
関係（relationship）
二つの実体間の結び付き。関係は属性をもたず，ファンクションポイント計測時にはRET（2.75を参照）
として計測しない。
4
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
2.21
関連ファイル数，FTR（File Type Referenced，FTR）
FTRは，次のいずれか又は両方である。
− トランザクション ファンクションで参照又は維持管理されるILFの数
− トランザクション ファンクションで参照されるEIFの数
注記 FTRは，本来“数”ではなく，この規格で扱う概念的なファイルの総称をいうが，日本では慣
例的に“関連ファイル数”と呼びなら（慣）わしてきたため，この規格でも“関連ファイル数”
という訳を採用した。
2.22
機能（function）
アプリケーションの特徴又は能力であり，利用者が認識するもの。
2.23
機能改良（enhancement）
既存のアプリケーションの修正。
2.24
機能改良プロジェクト ファンクションポイント，EFP（Enhancement project Function Point count，EFP）
プロジェクト完了時点で納入された利用者機能の追加，変更及び／又は削除という，既存アプリケーシ
ョンへの修正を計測するファンクションポイント。
2.25
機能性（functionality）
2.22と同義。
2.26
寄与（contribution）
未調整ファンクションポイントにおける次のファンクション型の合計値。
− ILF（内部論理ファイル）
− EIF（外部インタフェースファイル）
− EI（外部入力）
− EO（外部出力）
− EQ（外部照会）
2.27
計測の目的（purpose of the count）
ファンクションポイントを測定する理由。
注記 ISO/IEC 20926:2009の定義を使用した。
2.28
計測範囲（counting scope）
特定のファンクションポイント計測に含める機能。
2.29
欠陥（defect）
異常動作又は不正結果の原因となるアプリケーションの問題。要求された機能の欠如も欠陥とみなす。
5
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
2.30
高負荷構成GSC（heavily used configuration GSC）
計算機資源の制約がアプリケーション開発に影響を与える度合い。14種類の一般システム特性の一つ。
2.31
再利用可能性GSC（reusability GSC）
アプリケーションそのもの及び／又はアプリケーション内のコードを他のアプリケーションで利用でき
るように特別に設計，開発及び保守された度合い。14種類の一般システム特性の一つ。
2.32
システム（system）
“アプリケーション（2.2）”を参照。
2.33
実体，実体型（entity，entity type）
利用者に関連する基本的な事物。この基本的な事物に関する事実の集合が保持される。属性を含む実体
間の関連も実体である。
2.34
実体副型（entity subtype）
実体型を分割したもの。実体副型は，親実体型のすべての属性及び関連を継承し，独自の属性及び／又
は関連をもつことができる。
2.35
処理ロジック（processing logic）
妥当性確認，アルゴリズム，計算，ファイルの参照・維持管理など，要素処理の実行に関する利用者要
件。
2.36
制御情報（control information）
計測対象アプリケーションの要素処理に影響を及ぼすデータ。対象となるデータ，処理時期及び／又は
処理方法を指定する。
2.37
生産性（productivity）
単位作業工数当たりの作業成果物の割合。
2.38
性能GSC（performance GSC）
応答，処理能力などに対する配慮がアプリケーション開発に及ぼす影響の度合い。14種類の一般システ
ム特性の一つ。
2.39
製品計測（product measures）
開発ソフトウェアアプリケーションについての情報獲得。
2.40
属性実体型（attribute entity type）
他の実体についての一つ以上の属性を記述する実体型。
6
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
2.41
測定（measurement）
基準に照らして相対的な値を割り当てること。通常，改善プロセスでは，測定によって得られた測定量
を組み合わせて測定法（metrics）という。
2.42
測定する（動詞）（measure，verb）
基準との比較によって確認又は評価する行為。
2.43
測定量（名詞）（measure，noun）
基準に照らして相対的な値を割り当てられた数。例えば，体積，高さ，ファンクションポイント，工数
など。
2.44
調整済みファンクションポイント，AFP（Adjusted Function Point count，AFP）
未調整ファンクションポイントに調整要因（VAF）を乗じた値に基づいて得られる総ファンクションポ
イント。調整済みファンクションポイントは，開発プロジェクト ファンクションポイント，機能改良プロ
ジェクト ファンクションポイント及びアプリケーション ファンクションポイントごとに定められている
計算式を使用して求める。一般には，調整済みファンクションポイントをファンクションポイントという。
注記 未調整ファンクションポイントが，JIS X 0135-1の機能規模に対応する。
2.45
調整要因，VAF（Value Adjusted Factor，VAF）
アプリケーションの利用者に提供される一般的な機能を示す要因。VAFは，アプリケーションに関する
14種類の一般システム特性の評価に基づいて計算される。
2.46
データ項目数，DET（Data Element Type，DET）
利用者視点に基づき，重複も繰返しもない，論理的データの最小単位。
注記 DETは，本来“数”ではなく，この規格で扱う概念的なデータの最小単位をいうが，日本では
慣例的に“データ項目数”と呼びなら（慣）わしてきたため，この規格でも“データ項目数”
という訳を採用した。
2.47
データ属性（data attribute）
実体の特性。データ属性は，一般にデータ項目数と同じである。
2.48
データ通信GSC（data communications GSC）
アプリケーションが処理装置と直接通信する度合い。14種類の一般システム特性の一つ。
2.49
データファンクション（data functions）
アプリケーション境界の内部又は外部のデータに対する利用者要件を満たす機能。データファンクショ
ンには，ILF及びEIFがある。
2.50
導入容易性GSC（installation ease GSC）
7
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
システム更改前後の環境の違いによって要求される変換及び／又は導入への配慮がアプリケーション開
発に与える影響の度合い。14種類の一般システム特性の一つ。インストール容易性ともいう。
2.51
トランザクション量GSC（transaction rate GSC）
単位時間当たりの業務トランザクションの頻度がアプリケーション開発に影響を与える度合い。14種類
の一般システム特性の一つ。
2.52
トランザクション ファンクション（transactional function）
データを処理するためにアプリケーションが利用者に提供する機能。トランザクション ファンクション
には，EI，EO及びEQがある。
2.53
内部論理ファイル，ILF（Internal Logical File，ILF）
計測対象のアプリケーション境界の内部で維持管理される，論理的に関連のあるデータ又は制御情報の
利用者視点のグループ。ILFは，計測対象のアプリケーション境界の内部にある一つ以上の要素処理によ
って維持管理されるデータを保持することを主目的とする。
2.54
任意サブグループ（optional subgroup）
2種類あるRETのサブグループの一つ。データインスタンスを追加又は生成する要素処理では，任意サ
ブグループは使用しなくてもよい。
2.55
導出データ（derived data）
ILF及び／又はEIFから情報を取り出すこと又は取り出したデータを検証すること以外の処理を必要と
するデータ。
2.56
必す（須）サブグループ（mandatory subgroup）
2種類あるRETのサブグループの一つ。データインスタンスを生成する要素処理では，必す（須）サブ
グループを一つ以上使用しなければならない。
2.57
ファイル（file）
データファンクションに関して，論理的に結び付いたデータ又は制御情報のグループ。データ又は制御
情報のグループを物理的に実装したものではない。
2.58
ファンクション型（function type）
アプリケーションが利用者に提供し，ファンクションポイント法で識別される次の5種類の基本的情報
処理サービス。
− ILF（内部論理ファイル）
− EIF（外部インタフェースファイル）
− EI（外部入力）
− EO（外部出力）
− EQ（外部照会）
8
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
2.59
ファンクションの複雑さ（functional complexity）
低，中又は高に判定されるファンクション型の複雑さ。データファンクションでは，RET及びDETに
基づいて決定される。トランザクション ファンクションでは，FTR及びDETに基づいて決定される。
2.60
ファンクションポイント，FP（Function Point，FP）
アプリケーションの機能規模を表す測定量の単位。
2.61
ファンクションポイント数（function point count）
特定のアプリケーション又はプロジェクトのFP測定結果（量）。
2.62
ファンクションポイント法，FP法（Function Point analysis）
利用者の視点から，ソフトウェア開発及び保守を測定するための標準的な一手法。
2.63
複雑な処理GSC（complex processing GSC）
処理ロジックがアプリケーションの開発に与える影響の度合い。14種類の一般システム特性の一つ。
2.64
複数サイトGSC（multiple site GSC）
複数の事業所及び複数の利用者組織でアプリケーションを使用することに対してどの程度配慮して開発
されるかの度合い。14種類の一般システム特性の一つ。
2.65
分散データ処理GSC（distributed data processing GSC）
アプリケーションの要素間でのデータ交換の度合い。14種類の一般システム特性の一つ。
2.66
変換機能（conversion functionality）
開発プロジェクトの場合は，データを変換するために与えられた機能及び／又は変換報告書のような利
用者が指定した変換要求を満たすために与えられる機能。機能改良プロジェクトの場合は，利用者の要求
する変換機能を実現するために納入された機能。
2.67
変更容易性GSC（facilitate change GSC）
処理ロジック及び／又はデータ構造を容易に修正できることを考慮してアプリケーションが開発されて
いる度合い。14種類の一般システム特性の一つ。
2.68
保守（maintenance）
仕様に従ってアプリケーションを利用可能な状態に維持する活動。一般的に，機能（すなわち，ファン
クションポイント）の変更を伴わない。保守には，修復，軽微な機能改良，変換，利用者支援及び予防保
守を含む。具体的な活動には，欠陥除去，ハードウェア又はソフトウェアの機能変更を伴わないアップグ
レード，最適化又は予防保守及び利用者支援を含む。
注記 IFPUGでは，“保守”と同じ意味で“支援（support）”を使用する場合がある。
9
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
2.69
未調整ファンクションポイント，UFP（Unadjusted Function Point count，UFP）
プロジェクト又はアプリケーションが利用者に提供する機能の測定量。データファンクション及びトラ
ンザクション ファンクションがこの測定量に寄与する。
2.70
要素処理（elementary process）
利用者にとって意味のある業務活動の最小単位。
2.71
予防保守（preventive maintenance）
発生する可能性のある欠陥又は故障を予防するためのハードウェア又はソフトウェアの変更。例えば，
保守性向上若しくは欠陥予防のためのプログラム又はデータの再構成。
2.72
利用者（user）
次のいずれか又は両方。
− 利用者機能要件を規定する人
− ソフトウェアとやり取りをする人若しくはもの又は相互に影響し合う人若しくはもの
2.73
利用者視点（user identifiable）
利用者及びソフトウェア開発者の両者で合意し，理解したプロセス及び／又はデータのグループに対す
る定義された要求。
注記 日本では，“User identifiable”を“利用者視点”と呼びなら（慣）わしてきたため，“利用者視
点”とした。このため，“User View”は，“利用者要件記述”とした。
2.74
利用者要件記述（user view）
利用者の言葉による利用者業務の公式な記述。開発者は，それを実現するために，利用者情報を情報技
術の言葉に変換する。
2.75
レコード種類数，RET（Record Element Type，RET）
ILF内又はEIF内にあるデータ要素の利用者視点に基づくサブグループ。
注記 RETそのものは，本来“数”でなく，単位をいうが，日本では慣例的に“レコード種類数”と
呼びなら（慣）わしてきたため，この規格では“レコード種類数”という訳を採用した。
3
IFPUG 4.1版未調整ファンクションポイントの概要
ここでは，機能規模計測手順の概要を提供する。概要には，機能規模計測の目的を規定しており，機能
規模計測の概要及び事例を提供する。
3.1
ファンクションポイント法の目的及び利点
ファンクションポイント法は，ソフトウェア開発を利用者の視点から計測する標準的な手法である。
IFPUG 4.1版未調整ファンクションポイントは，すべてのソフトウェアの計測に適用することができる。
3.1.1
ファンクションポイント法の目的
ファンクションポイント法は，主として論理設計に基づいて，利用者に提供される機能を定量化するこ
10
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
とによってソフトウェアを測定する。したがって，ファンクションポイント法の目的は，次のとおりにな
る。
− 利用者が要求し受け取る機能を測定する。
− 実装技術とは独立して，ソフトウェア開発及び維持管理を測定する。
上記の目的を満たすことに加え，ファンクションポイントを計測する手順は，次の特徴をもつ。
− 測定作業の負担を最小限にするためには十分簡易である。
− 多様なプロジェクト及び組織間で一貫した測定が実施できる。
3.1.2
ファンクションポイント法の利点
ファンクションポイント法は，次のことに適用できる。
− 購入したパッケージソフトウェアのすべての機能をファンクションポイント法を用いて計測すること
によって，そのパッケージソフトウェアの規模を決定する。
− 特に，利用者要件に合致する機能をファンクションポイント法を使用して計測することによって，利
用者組織に与えるパッケージソフトウェアの利点を利用者が決定することを支援する。
− 品質及び生産性の分析を支援するためにソフトウェア製品の規模を計測する。
− ソフトウェアの開発及び維持管理に必要とされる費用及び資源を見積もる。
− ソフトウェアを比較するための正規化の要素として用いる。
3.2
計測事例の概要
ここでは，ファンクションポイント計測の作業手順及び計測対象となっている構成要素について，概要
事例を示す。
3.2.1
概要図
人事情報システムの計測事例に関係する構成要素を，図1に示す。以降では，この図に基づいて説明す
る。
図1−人事情報システム概略図
利用者
利用者
社員情報の検索及び表示
（EQ）
社員報告書
（EO）
新入社員情報(EI)
人事情報システム
社員情報（ILF）
アプリケーション
境 界
為替システム
為替レート（EIF）
利用者
11
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
3.2.2
作業手順
3.2.2.1 ファンクションポイント種別の決定
ファンクションポイント計測の最初の作業は，ファンクションポイント計測の種別を決定することであ
る。
ファンクションポイントは，開発プロジェクト又はアプリケーションのいずれかに対応している。ファ
ンクションポイントには，次の3種類がある。
− 開発プロジェクト ファンクションポイント
− 機能改良プロジェクト ファンクションポイント
− アプリケーション ファンクションポイント
図1で示した人事情報システムの事例は，プロジェクト ファンクションポイントのものであり，これは
また，アプリケーション ファンクションポイントにつながっていく。
ファンクションポイント種別の詳細な定義は，箇条5に示す。
3.2.2.2 計測範囲及びアプリケーション境界の明確化
計測範囲は，ファンクションポイントに含まれる機能を定義する。
アプリケーション境界（図1の点線部）は，測定対象ソフトウェアと利用者との境界を示す。
図1は，測定対象の人事情報システムと為替システムとのアプリケーション境界を示している。この図
は，また，人事情報システムと利用者とのアプリケーション境界も示している。
計測範囲及びアプリケーション境界については，箇条6に示す。
3.2.2.3 未調整ファンクションポイントの決定
未調整ファンクションポイントは，プロジェクト又はシステムが利用者に提供する特定の計測可能な機
能を反映したものである。
システムの特定の利用者機能は，その機能が“どのように”実現されるかではなく，システムによって
“何が”実現されるかの観点で評価され，利用者が要求し定義した要素だけが計測される。
未調整ファンクションポイントには，データ及びトランザクションの二つのファンクション種別がある。
これらは，更に図2に示すように分類される。
未調整ファンクションポイントは単位呼称であり，未調整ファンクションポイントは，JIS X 0135-1で
定義されている機能規模である。
図2−未調整ファンクションポイント種別
内部論理ファイル
（ILF）
外部インタフェース
ファイル（EIF）
データ
ファンクション
未調整
ファンクションポイント
外部入力（EI）
外部出力（EO）
外部照会（EQ）
トランザクション
ファンクション
12
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
3.2.2.4 データファンクションの計測
データファンクションは，アプリケーション境界の内部データ要件及び外部データ要件を満たすために
利用者に提供される機能を表す。データファンクションは，ILF又はEIFである。
− ILFとは，計測対象のアプリケーション境界の内部で維持管理される，論理的に関連のあるデータ又
は制御情報の利用者視点のグループのことをいう。ILFは，計測対象のアプリケーション境界の内部
にある一つ以上の要素処理によって維持管理されるデータを保持することを主目的とする。
図1における人事情報システムのILFは，当該アプリケーションの中で維持管理される社員データ
のグループである。
− EIFとは，計測対象のアプリケーションによって参照される，論理的に関連のあるデータ又は制御情
報の利用者視点のグループのことをいう。ただし，維持管理は，他のアプリケーション境界の内部で
行われる。EIFは，計測対象のアプリケーション境界の内部にある一つ以上の要素処理によって参照
されるデータを保持することを主目的とする。このことは，あるアプリケーションで計測されるEIF
は，他のアプリケーションにおいてILFでなければならないことを意味している。
図1で示す人事情報システムの例は，為替システムによって維持管理され，人事情報システムによ
って参照される為替レートを示している。
データファンクションの詳細を，箇条7に示す。
3.2.2.5 トランザクション ファンクションの計測
トランザクション ファンクションは，データ処理のために利用者に提供される機能を表す。トランザク
ション ファンクションはEI，EO又はEQのいずれかである。
− EIとは，計測対象のアプリケーション境界の外部から入力されるデータ又は制御情報を処理する要素
処理のことをいう。EIは，一つ以上のILFの維持管理及び／又はシステムの振る舞いの変更を主目的
とする。
図1で示す人事情報システムの例は，人事情報システムに社員情報を入力する処理を示している。
− EOとは，計測対象のアプリケーション境界の外部にデータ又は制御情報を出力する要素処理のこと
をいう。EOは，データ又は制御情報の取り出しの有無にかかわらず，処理ロジックによって情報を
利用者に提供することを主目的とする。EOは，処理ロジックに少なくとも一つの“数式又は演算の
実行”又は導出データの生成を含まなければならない。EOは，一つ以上のILFの維持管理及び／又
はシステムの振る舞いの変更を行ってもよい。
図1で示す人事情報システムの例は，人事情報システムに登録されているすべての社員を記載する
報告書を作成する処理を示している。
− EQとは，計測対象のアプリケーション境界の外部にデータ又は制御情報を送り出す要素処理のこと
をいう。EQは，ILF又はEIFからデータ又は制御情報を取り出すことによって利用者に情報提供する
ことを主目的とする。EQは，処理ロジックに“数式又は演算の実行”を含まない。さらに，導出デ
ータを生成しない。処理中にILFを維持管理せず，システムの振る舞いの変更も行わない。
図1で示す人事情報システムの例は，社員情報を問い合わせて（入力要求），画面上に社員情報が表
示されたとき（出力検索），それを見る処理を示している。
トランザクション ファンクションの詳細を，箇条8に示す。
4
利用者要件記述
ここでは，プロジェクト又はシステムに対する利用者機能要件を定義するときの利用者の役割について
13
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
の概念を示す。
4.1
利用者要件記述の定義
利用者要件記述とは，利用者の言葉による利用者業務の公式な記述のことをいう。開発者は，これを実
現するために，利用者情報を情報技術の言語に変換する。
ファンクションポイント計測は，利用者及び開発者の両者に共通の言語で表した情報を利用して達成さ
れる。
利用者要件記述とは，次のことをいう。
− 業務機能の記述である。
− 利用者に承認されている。
− ファンクションポイントを計測するために利用できる。
− 物理的な様式は多様である（例えば，トランザクションのカタログ，提案書，要件書，外部仕様書，
詳細仕様書，利用者マニュアルなど）。
4.2
システムのライフサイクルを通した規模測定
プロジェクトの初期段階では，利用者機能要件は急速に拡大する。システムに組み入れる機能の選択に
ついては，利用者と開発者との間で合意されなければならない。プロジェクトの機能に関するこうした決
定は，次のものから影響を受ける。
− 組織のニーズ
− プロジェクトに関連した（業務及び技術に関する）リスク
− プロジェクトに割当てできる組織内での資源（例えば，予算，要員）
− 組織内で利用可能な技術
− コメント及び提案を通しての利用者又は開発者の影響
プロジェクトの開始時には，実現可能性の検討を行う。実現可能性の検討の結果として得られるものは，
抽象度の高い仕様書であり，通常は，非常に簡潔に記述される。例えば，次のようなものをいう。
− 組織は，新税法に対応するシステムを必要とする。
− 組織は，より効率的な在庫管理を実施するためのシステムを必要とする。
− 組織は，より効率的に人事情報を取り扱うシステムを必要とする。
実現可能性の検討の後，利用者は時間の経過とともに要件を詳細化する。ある時点で利用者は，ソフト
ウェア開発者と協議して詳細な要件を作成する。一方，ソフトウェア開発者は，実現可能性の検討結果を
もとに，早期に開発要件及び実現要件の検討に着手することができる。利用者と開発者とが議論すること
によって，要件が改善される。開発プロセスは組織によって異なっている。この規格では，目的を示すた
めに，要件書を次の三つに分けて説明する。
− 初期利用者要件書
− 初期技術要件書
− 最終機能要件書
他の開発手法と同様に，最終機能要件書の段階で，ファンクションポイントを最も正確に計測すること
ができる。
4.2.1
初期利用者要件書の段階
この段階では，利用者とソフトウェア開発者との間の打合せの前に利用者要件を示す。この段階は，次
の特性を一つ以上もっていてもよい。
− 不完全性
14
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
例1 初期利用者要件書は，関連する完全性に対して必要な機能を欠いてもよい。
− ユーティリティ機能の欠如
例2 必す（須）の妥当性確認の報告機能又は照会機能を欠いてもよい。
− 実現不可能又は利用困難
例3 利用者は，1時間のCPU処理を必要とするオンライン照会を要求してもよい。
− 一般性の過多
例4 要求には項目数を含まなくてもよい。
− 二人以上の利用者がプロジェクトに責任を負っている場合，機能要求の不統一
例5 要件が同じでない場合，利用者によって特定のプロジェクトの要求事項が異なってもよい。
− アプリケーション境界を考慮せずに規定された要件
例6 現在及び／又は将来のアプリケーション境界が考慮されていなくてもよい。
− 機能規模分析の概念又は定義に矛盾する表現
例7 初期利用者要件書は，システムの物理的又は運用的な事項に言及してもよい。
a) 事例
人事情報システムでは，利用者は，次のように要件を表現する。
“社員に関する作業を行っている間はいつでも，社員氏名を入力することによってその社員の情報が見
ることができるようにして欲しい。”
この要件は，照会画面の開発及び社員に関するひとまとまりのデータの開発を意味している（事例を単
純にするために，詳細には示さないが，社員に関するひとまとまりのデータは，社員の追加，更新及び削
除といった別の社員対応機能で内部的に維持管理される。）。
初期利用者要件書における機能の例には，次のものがある。
EQ 特定の社員に対する照会
ILF 社員に関するひとまとまりのデータ
4.2.2
初期技術要件書の段階
この段階では，実現可能性の検討から生成される，ソフトウェア開発者の視点からの要件を示す。既存
のアプリケーションがある場合，その中に要件を組み入れることはソフトウェア開発者の仕事の一つであ
る。初期技術要件書は，実現には必要とするが，ファンクションポイント計測には使用しない要素を含ん
でもよい（例えば，一時ファイル，索引など）。初期技術要件書は，次の特性を一つ以上もっている。
− 技術依存
例1 物理ファイルは，データベース環境によって変化する。
− 利用者の機能要求の誤識別
例2 ソフトウェア開発者は，利用者が要求していない機能を追加してもよい。
− 利用者にとってなじみのない用語
例3 ソフトウェア開発者は，論理的なデータではなく，物理的ファイルに言及してもよい。
− 技術的制約を過度に重視して，機能が決定されてもよい。
例4 開発者は，その組織で現在利用可能な計算機の処理能力に注目して，要求範囲を制限する傾
向がある。
− 組織の中の他のアプリケーションの技術的な構造に従って，アプリケーション境界が決定される。
例5 クライアントとサーバとでは技術要件が異なってもよいが，ファンクションポイントを計測
するときは，同一のアプリケーション境界に含まれる。
15
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
a) 事例
初期利用者要件書の段階と同一の事例を用いると，開発者は，次のように示している。
“社員照会の要求は理解する。特定の社員の情報を高速で取り出すためには索引を必要とする。”
初期技術要件書で機能は，次のように識別されることがある。
EQ 特定の社員に対する照会
ILF 社員に関するひとまとまりのデータ
ILF 1) 社員ファイルに関する索引
注1) この規格では，索引ファイルは計測対象ではない。この事例では，ソフトウェア開発者が犯
しやすい計測誤りを示すために索引ファイルを誤ってILFと識別している。
4.2.3
最終機能要件書の段階
この段階では，最終機能要件書は，利用者とソフトウェア開発者との共同作業の結果から得られる。共
同作業は，システムの矛盾のない完全な機能要件書を作成するために必要になる。この段階では，開発段
階を開始する前の，機能要件書の最終版であり，次の特性をもつ。
− 利用者及びソフトウェア開発者の両者が理解できる用語で書かれている。
− 他の利用者の要件も含めて，すべての利用者要件を統合した記述を提供している。
− ファンクションポイントを正確に計測するために十分な程度に完全で，矛盾がない。
− すべてのプロセス及びすべてのデータが利用者によって承認されている。
− 実現可能性及び使用性がソフトウェア開発者によって承認されている。
a) 事例
初期利用者要件書の段階と同一の事例を用いると，次のようになる。
利用者 “社員に関する作業を行っている間はいつでも，社員氏名を入力することによってその社員
の情報を見ることができるようにして欲しい。”
開発者 “社員照会の要求は理解する。しかし，同じ氏名をもつ社員がいるかもしれない。氏名を入
力するだけでは社員を特定することはできない。したがって，社員を選択するための社員一
覧画面（社員氏名，事業所及び保険者番号）を提案する。特定の社員の情報を高速で取り出
すためには索引を必要とする。”
利用者 “この場合，社員一覧画面が必要なことについては了解した。また，その機能は，社員選択
以外の目的にも利用できるかもしれない。”
利用者と開発者との議論の結果は，次のとおりになる。
− 機能要件書に社員一覧画面を追加し，ファンクションポイント計測を行う。
− 社員索引は，技術的な解決策であるため，ファンクションポイント計測から除く。
この例の最終機能要件書に含まれる機能は，次のとおりになる。
EQ 特定の社員に対する照会
EQ 社員一覧画面
ILF 社員に関するひとまとまりのデータ
最終機能要件書は，開発段階を開始する前の，要件の最終版である。この時点で，文書化した要件書が，
完全で，正式で，承認されていることに合意していることが望ましい。計測範囲に追加の変更がないとす
れば，ファンクションポイントは，開発の完了時のファンクションポイントと一致する。
4.3
ライフサイクル段階の比較
ファンクションポイントを計測する前に，アプリケーションのライフサイクル段階を決め，見積もろう
16
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
としているのか又は測定しようとしているのかを決める。いろいろな前提を記述する。
ファンクションポイント分析を完了するため，見積りには，未知の機能及び／又はそれらの複雑さにつ
いて前提を設けてもよい。
ファンクションポイント分析を完了するため，測定には，すべての機能及びそれらの複雑さの識別を包
含する。
初期の段階では，初期利用者要件だけがファンクションポイント分析のために入手できる唯一の文書で
ある。このような不利な点があるが，この計測値は，初期見積りを行うために有効である。様々なライフ
サイクル段階における，見積りのためのファンクションポイント法の用途を，表1に示す。
表1−ファンクションポイント法の用途
ライフサイクル段階
規模の見積りは可能か。
規模の測定は可能か。
提案：利用者がニーズ及び意図を表現する。
可能
不可能
要件：開発者及び利用者がレビューを行い，利用者
ニーズ及び意図の表現について合意する。
可能
可能
設計：開発者は，ファンクションポイント分析では
利用されない要素の実現を含めてもよい。
可能
可能
構築
可能
可能
出荷
可能
可能
修正保守
可能
可能
注記 特定のライフサイクルを意味しているわけではない。開発者と利用者とが対話する手法を使用する場合，
アプリケーションのライフサイクルにおけるある時点での見積りを期待できる。十分注意し，新規であ
れ，改良であれ，合意された利用者ニーズ及び意図を測定する。
4.4
計測上の留意点
次の留意点は，アプリケーションに対する利用者要件記述の識別に役立ち，ファンクションポイント法
の適用に役立つ。
− 利用者の観点からデータを論理的にみるとき，一つの物理的ファイルが一つの論理的ファイルに対応
すると想定しない。
− リレーショナルDBMSのテーブル又は順編成ファイルのような，ある種のデータ蓄積技術は，ILF又
はEIFと密接に関連しているが，このことが常に物理対論理の1対1の対応関係に等しいと想定しな
い。
− すべての物理的ファイルは，ILF又はEIFの一部として計測又は包含されなければならないと想定し
ない。
− トランザクション ファンクションを識別するときには，利用者が現在利用している他の紙書式も調べ
てみる。
− 複数の物理的入力，トランザクション ファイル又は画面で発生するトランザクションで，処理ロジッ
クが同じトランザクションは，通常は，一つのトランザクション ファンクション（EI，EO，EQ）に
相当する。
− 論理的にみる場合，一つの物理レポート，画面又はバッチ出力ファイルは，複数のEO及び／又はEQ
に対応できることを念頭に置く。
− 処理ロジックが同じ場合，二つ以上の物理レポート，画面又はバッチ出力ファイルは，一つのEO又
はEQに対応できることを念頭に置く。
− 一組のデータの再ソート又は再整列がその処理ロジックを独自なものとはしないことを念頭に置く。
17
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
5
計測種別の決定
ファンクションポイント計測の最初の作業は，ファンクションポイント計測の種別を決定することにあ
る。
5.1
ファンクションポイント計測種別の定義
ファンクションポイント計測には，プロジェクト又はアプリケーションのいずれかが関係する。それら
には，次の三つがある。
− 開発プロジェクト ファンクションポイント
− 機能改良プロジェクト ファンクションポイント
− アプリケーション ファンクションポイント
5.1.1〜5.1.3で，ファンクションポイント計測の各種別を定義する。
5.1.1
開発プロジェクト ファンクションポイント
開発プロジェクト ファンクションポイントは，開発プロジェクトが完了したときに納入されたソフトウ
ェアの最初の導入時に，利用者に提供される機能の計測値である。
5.1.2
機能改良プロジェクト ファンクションポイント
機能改良プロジェクト ファンクションポイントは，既存のアプリケーションに対する，開発プロジェク
トが完了したときに納入された利用者機能に追加，修正又は削除を行う改良の計測値である。
機能改良プロジェクトによる変更機能を導入するときに，アプリケーションのファンクションポイント
は，機能の変更を反映するために更新されなければならない。
5.1.3
アプリケーション ファンクションポイント
アプリケーション ファンクションポイント及びプロジェクト ファンクションポイントは，導入された
アプリケーションと関連が付いている。その値は，ベースライン ファンクションポイント又は導入ファン
クションポイントとしても参照されている。この値は，アプリケーションが利用者に提供する最新の機能
の計測値を示す。この値は，開発プロジェクトにおけるファンクションポイントが決まったときに初期値
とされる。機能改良プロジェクトが完了してアプリケーションの機能が変更される都度，この計測値は更
新される。
5.2
計測の種別の作業手順図
ファンクションポイント計測の種別及びそれらの関係を，図3に示す（プロジェクトAが最初に完了し，
続いてプロジェクトBの順になる。）。
18
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図3−計測種別
5.2.1
見積り値及び最終計測値
開発の初期段階でのファンクションポイント計測が納入する機能の見積りであることを自覚することが
重要になる。加えて，範囲が明らかになり，機能が開発されるにつれて，当初の仕様書には示されていな
い追加機能が明確になることはごく当たり前のことである。この現象を，要求の自然増（scope creep，scope
gallop）などということがある。
開発の完了時にアプリケーション ファンクションポイントを更新することが最も重要になる。開発中に
機能を変更する場合，開発の完了時でのファンクションポイント計測は，利用者に納入した全機能を正確
に反映していることが望ましい。
6
計測範囲及びアプリケーション境界の識別
ここでは，計測の目的，計測範囲及びアプリケーション境界を定義する。アプリケーション境界の決定
及び計測範囲の明確化のための規則，作業手順及び留意点を示す。
6.1
計測範囲及びアプリケーション境界の決定
ここでは，計測範囲及びアプリケーション境界を定義し，計測の目的がそれらに与える影響について説
明する。
6.1.1
計測の目的の定義
ファンクションポイント計測は，業務課題への解決策を提供することを目的とする。
計測は，次のことを目的とする。
− ファンクションポイント計測の種別及び開発中の業務課題への解決策を得るために必要とされる計測
範囲を決定する。
− 計測対象のソフトウェアと関連するソフトウェアとの間の境界決定に影響を与える。
例えば，人事情報システムの人事情報モジュールをパッケージソフトウェアに置き換える場合，利
用者は境界を再設定してもよいし，人事情報モジュールを関係のないアプリケーションと考えてもよ
い。
見積り値
プロジェクトAとしての
開発プロジェクト
ファンクションポイント
最終計測値
プロジェクトAとしての
開発プロジェクト
ファンクションポイント
見積り値
プロジェクトBとしての
機能改良プロジェクト
ファンクションポイント
最終計測値
プロジェクトBとしての
機能改良プロジェクト
ファンクションポイント
アプリケーション
ファンクションポ
イント
プロジェク
トの完了
初期値設定
プロジェク
トの完了
更新
19
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
計測の目的の例を次に示す。
− アプリケーションの最初のリリース版の開発工数を決めるために，見積り工程の入力として，ファン
クションポイントを提供する。
− アプリケーションの導入された基本部分のファンクションポイントを提供する。
− 二つの異なった供給者のパッケージソフトウェアによって納入される機能の比較を可能とするための
ファンクションポイントを提供する。
6.1.2
計測範囲の定義
計測範囲は，特定のファンクションポイントに含まれる機能を次のように決定する。
− 計測範囲は，計測対象のソフトウェアを決定する。
− 計測範囲は，ファンクションポイントの計測の目的によって決定される。
− 計測範囲は，計測目的に関係のある解を提供するために，ファンクションポイントにどの機能が含ま
れるかを識別する。
− 計測範囲は，二つ以上のアプリケーションを含む可能性がある。
計測種別ごとの計測範囲を次に示す。
− 機能改良プロジェクト ファンクションポイント
追加，変更又は削除されるすべての機能を含む。影響を受けるアプリケーション境界は，機能改良
の前後で，変わらない。アプリケーションの機能は，追加，変更又は削除される機能の影響を反映す
る。
− 開発プロジェクト ファンクションポイント
プロジェクト活動で影響を受ける（構築される又はカスタマイズされる）全機能を含む。
− アプリケーション ファンクションポイント
利用目的（例えば，ソフトウェアの解決策としてパッケージソフトウェアを提供する。）によって異
なり，次のような例がある。
− 利用者によって利用される機能だけ
− 納入される全機能
この二つの計測のアプリケーション境界は同じであり，計測範囲とは独立している。
6.1.3
アプリケーション境界の定義
アプリケーション境界は，測定対象ソフトウェアと利用者との間の境界を示す。
− アプリケーション境界は，アプリケーションの外部を定義する。
− アプリケーション境界は，アプリケーションの内部と外部である利用者との間の概念的な境界をいう。
− アプリケーション境界は，トランザクション（EI，EO及びEQ）によって処理されるデータをアプリ
ケーションの内部又は外部に移動させる“細胞膜”として作用する。
− アプリケーション境界は，アプリケーション（ILF）によって維持管理される論理データを含む。
− アプリケーション境界は，このアプリケーションによって参照されるが維持管理されない論理データ
を識別する助けとなる。
− アプリケーション境界は，アプリケーションに関する利用者の業務上の視点に依存し，技術的な観点
及び／又は実装上の観点に依存しない。
例えば，図4は，人事情報システムと外部のアプリケーション（為替システム及び固定資産管理システ
ム）との間の境界を示している。さらに，利用者と人事情報システムとの間の境界も示している。
20
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図4−アプリケーション境界
6.2
計測範囲及びアプリケーション境界に関する規則及び手順
ここでは，計測範囲及びアプリケーション境界を決めるときに適用する規則及び手順について示す。
アプリケーション境界の位置は，ファンクションポイント計測の結果に影響を与える重要な事項である。
アプリケーション境界は，計測範囲に含まれるアプリケーションに入力するデータを識別するために役立
つ。
6.2.1
アプリケーション境界に関する規則
アプリケーション境界には，次の規則を適用しなければならない。
− アプリケーション境界は，利用者の視点に基づいて決め，利用者が理解及び表現できるものに焦点を
当てる。
− 関連したアプリケーション間の境界は，技術的な観点ではなく利用者側から見た別々の機能領域に基
づく。
− アプリケーション又は機能改良対象のアプリケーションに対して設定された最初のアプリケーション
境界は，計測範囲の影響を受けない。
注記1 計測範囲の中に二つ以上のアプリケーションを含んでもよい。その場合には，複数のアプリ
ケーション境界を設定する。
注記2 要求分析の初期段階のようにアプリケーション境界が明確に定義できない場合，可能な限り，
アプリケーション境界を設定することが望ましい。
6.2.2
計測範囲及びアプリケーション境界に関する作業手順
利用者
人事情報システム
（計測対象プロジェクト）
為替システム
固定資産
管理システム
21
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
手順
作業内容
1
計測の目的を決定する。
2
計測範囲を識別する。
3
アプリケーション境界を識別する。
4
次の項目を文書化する。
− 計測の目的
− 計測範囲
− アプリケーション境界
− 上記に関連するすべての前提
6.3
計測範囲及びアプリケーション境界を識別するための留意点
6.3.1
計測範囲
計測範囲の識別に役立つ留意点を次に示す。
− 計測範囲の決定のため，ファンクションポイント計測目的をレビューする。
− 導入されたベースライン ファンクションポイント計測の範囲（すなわち，保守チームによって維持管
理されている機能）を識別する場合，現在提供され，利用者に利用されている全機能を含める。
6.3.2
アプリケーション境界
アプリケーション境界の識別に役立つ留意点を次に示す。
− システムの外部仕様書を使用するか，又はシステムフロー図を手に入れるかして，アプリケーション
の内部及び外部を明示するためシステムの周りに境界線を引く。
− データのグループがどのように維持管理されているかを調査する。
− ある種別の分析対象（例えば，実体又は要素処理）の所有者を機能領域に割り付けることによって機
能領域を明確にする。
− 工数，費用，欠陥などの関連した測定データを調査する。ファンクションポイント及び他の測定デー
タの境界は同じであることが望ましい。
6.3.3
留意点
開発中のソフトウェアと他のアプリケーションとの間のアプリケーション境界の設定は，主観的になっ
てもよい。一つのアプリケーションがいつ終了して，次のアプリケーションがいつ開始するかを正確に説
明することは，困難な場合が多い。技術的観点又は物理的観点ではなく，業務上の観点からアプリケーシ
ョン境界を設定する。アプリケーション境界を出入りするすべてのデータは，潜在的に計測範囲に含まれ
るので，アプリケーション境界は，注意して設定することが重要になる。
7
データファンクションの計測
データファンクションは，アプリケーション境界の内部又は外部のデータに対する要件を満たすために
利用者に提供される機能を表す。データファンクションには，内部論理ファイル（ILF）及び外部インタフ
ェースファイル（EIF）の二つがある。
ここでのファイルという用語は，従来のデータ処理で用いられる意味とは異なる。データファンクショ
ンにおけるファイルとは，論理的に関連するひとまとまりのデータのグループであり，物理的に実装され
たグループのひとまとまりではない。
ここでは，ILF及びEIFの定義を含み，これらのファンクション型に関連する計測の作業手順及び規則
について記述する。
22
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
7.1
ILF及びEIFの定義
ここでは，ILF及びEIFを定義する。これらの定義で使用する用語も定義する。必要に応じて事例を示
している。
7.1.1
ILF（内部論理ファイル）
計測対象のアプリケーション境界の内部で維持管理される，論理的に関連のあるデータ又は制御情報の
利用者視点のグループ。ILFは，計測対象のアプリケーション境界の内部にある一つ以上の要素処理によ
って維持管理されるデータを保持することを主目的とする。
7.1.2
EIF（外部インタフェースファイル）
計測対象アプリケーションによって参照される，論理的に関連のあるデータ又は制御情報の利用者視点
のグループ。ただし，維持管理は他のアプリケーション境界の内部で行われる。EIFは，計測対象のアプ
リケーション境界の内部にある一つ以上の要素処理によって参照されるデータを保持することを主目的と
する。このことは，あるアプリケーションで計測されるEIFは，他のアプリケーションにおいてILFでな
ければならないことを意味している。
7.1.3
ILFとEIFとの違い
ILFとEIFとの基本的な違いは，EIFが計測対象のアプリケーションによって維持管理されないことに対
し，ILFが維持管理されることにある。
7.1.4
ILF及びEIFの定義で使用している用語の定義
ここでは，ILF及びEIFの定義で使用する用語の定義を行う。
7.1.4.1 制御情報
計測対象アプリケーションの要素処理に影響を及ぼすデータ。対象となるデータ，処理時期及び／又は
処理方法を指定する。
例 給与課の担当者は，事業所ごとに社員にいつ給与の支払をするかという支払計画を立てるために
支払サイクルを決める。支払のサイクル，又は支払計画は，給与支払の要素処理をいつ起動する
かに影響を与えるタイミング情報を含んでいる。
7.1.4.2 利用者視点
利用者及びソフトウェア開発者の両者で合意し，理解したプロセス及び／又はデータのグループに対す
る定義された要件。
例 利用者及び開発者は，人事情報システムによって社員情報を維持管理し，記憶することに合意す
る。
7.1.4.3 維持管理された
要素処理によってデータが追加，更新又は削除されている状態。
例 追加，変更，削除，増加，修正，更新，割当て，作成などがあるが，これに限定しない。
7.1.4.4 要素処理
利用者にとって意味のある業務活動の最小単位。
例1 利用者がシステムに新しい社員を追加する機能を要求する場合の例を示す。利用者が定義する
社員の個人データには，給与情報及び扶養家族情報を含む。利用者の観点からすると，業務活
動の最小単位は，新入社員を追加することである。給与情報又は扶養家族情報のような情報の
一部の追加は，要素処理とみなせる業務活動ではない。
要素処理は，自己完結していなければならない。さらに，計測対象のシステムの業務を矛盾のない状態
にするものでなければならない。
23
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
例2 社員の追加という利用者要件は，給与情報及び扶養家族情報の設定を含む。社員情報のすべて
を追加しないうちは，社員情報は生成されない。情報の一部だけの追加では，社員を追加する
という業務は，矛盾のない状態になっていない。社員の給与情報及び扶養家族情報の両方を追
加すると，この一連の業務は完了し，業務は矛盾のない状態となる。
7.2
ILF及びEIFの計測規則
ここでは，ILF及びEIFを計測するときに適用する規則を定義する。
7.2.1
計測手順の概要
ここでは，ILF及びEIFの計測手順に関連する規則を要約する。
注記 計測手順の詳細は，7.3で示す。
ILF及びEIFの計測手順では，次の二つの作業を実施しなければならない。
手順
作業内容
1
ILF及びEIFを識別する。
2
ILF又はEIFの複雑さ及び未調整ファンクションポイントに対する寄与を決定する。
それぞれの作業のために，ILF計測規則及びEIF計測規則を使用する。計測規則には，次の二つの種類
がある。
a) 識別規則
b) 複雑さ及び寄与の規則
次の順番で規則を説明する。
1) ILF識別規則
2) EIF識別規則
3) 複雑さ及び寄与の規則，これには次の種別がある。
− DET
− RET
7.2.2
ILF識別規則
ILFの識別は，ILFの定義を満たすデータ又は制御情報のグループを探し出すことにある。
情報をILFとして計測するためには，次の識別規則のすべてが適用できなければならない。
− データ又は制御情報のグループは，論理的で利用者視点によるものである。
− データのグループは，計測対象のアプリケーション境界の内部で，要素処理によって維持管理される。
7.2.3
EIF識別規則
EIFの識別は，EIFの定義を満たすデータ又は制御情報のグループを探し出すことにある。
情報をEIFとして計測するためには，次の識別規則のすべてが適用できなければならない。
− データ又は制御情報のグループは，論理的で利用者視点によるものである。
− データのグループは，計測対象アプリケーションの外部にあって参照される。
− データのグループは，計測対象アプリケーションによって維持管理されない。
− EIFとして識別したデータのグループは，他のアプリケーションのILFとして維持管理される。
7.2.4
複雑さ及び寄与の定義及び規則
ILF，EIF及びそれらの相対的なファンクションの複雑さの数によって，未調整ファンクションポイント
に対するデータファンクションの寄与が決まる。
ILF又はEIFに関連したDET及びRETの数に基づいて，識別したそれぞれのILF又はEIFのファンク
ションの複雑さを割り当てる。
24
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ここでは，DET及びRETを定義し，それぞれの計測規則を規定している。
7.2.4.1 DETの定義
利用者視点に基づき，重複も繰返しもない，論理的データの最小単位。
7.2.4.2 DET計測規則
DETの計測には，次の規則を適用する。
− 要素処理の実行によって，ILF若しくはEIFを維持管理しているか，又はILF若しくはEIFから参照
される，一意で繰返しのない利用者視点のデータ項目を1DETとして計測する。
例1 複数の項目に保存される口座番号は，1DETと計測する。
例2 監査のために維持管理される10項目のグループについての処理の前後で，処理前のグループ
（全10項目）で1DET，処理後のグループ（全10項目）で1DET，合計2DETと計測する。
例3 顧客注文に対して消費税を計算して，ILFで維持管理するような，要素処理での計算結果は，
顧客注文ILFで1DETと計測する。
例4 利用者の要求がある場合に，請求書作成ファイルに保存される商品の単価又は時刻刻印のよ
うなデータ項目は，DETとして計測する。
例5 社員レコードのキー及び扶養家族レコードの外部キーとして，ILF又はEIFで社員番号が2
度現れる場合は，DETとして一度だけ計測する。
例6 ILF又はEIFにおいて，12か月の月次予算額は，1DETと計測する。これに加えて，適用可
能な月を識別するためのデータ項目を1DETと計測する。
− 二つのアプリケーションが，同一のILF又はEIFを維持管理及び／又は参照し，かつ，各々が異なっ
たDETを維持管理又は参照するとき，各々のアプリケーションが使用するDETだけを計測する。
例7 アプリケーションAは，住所を郵便番号，都道府県名及び市区町村名として識別し使用する。
アプリケーションBは，住所を別々の構成要素とみなさずに，データのひとかたまりとして
みなす。このとき，アプリケーションAでは3DETと計測し，アプリケーションBでは1DET
と計測する。
例8 アプリケーションXは，郵便番号，都道府県名，市区町村名，保険者番号，社員氏名及び指
定郵便配送先を含むILFを維持管理及び／又は参照する。アプリケーションZは，都道府県
名，市区町村名及び社員氏名を維持管理及び／又は参照する。アプリケーションXでは6DET
と計測し，アプリケーションZでは3DETと計測する。
− 他のILF又はEIFとの関係を定めるために利用者が要求したデータ項目は，1DETとして計測する。
例9 人事情報システムでは，社員情報はILFで維持管理される。社員情報の一部には社員の担当
業務名称を含む。この業務名称は，社員と社内の業務とを結び付けるために必要とされる項
目であり，DETとして計測する。この種別のデータ項目は，外部キーとして参照される。
例10 オブジェクト指向（OO）アプリケーションでは，利用者は，別々のILFとして識別される複
数のオブジェクトクラスの間の関係を必要とする。事業所名は，事業所情報EIFのDETであ
る。社員情報を処理するときに，事業所名は必要になる。したがって，社員情報ILFでも事
業所名をDETとして計測する。
7.2.4.3 RETの定義
ILF内又はEIF内にあるデータ要素の利用者視点に基づくサブグループ。
このサブグループには，次の二つがある。
− 任意サブグループ
25
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 必す（須）サブグループ
任意サブグループは，データインスタンスを追加又は生成する要素処理では，使用しなくてもよい。
必す（須）サブグループは，データインスタンスを生成する要素処理では，少なくとも一つは使用しな
ければならない。
例 人事情報システムでは，共通情報を入力することによって社員情報を追加する。共通情報に加え
て，社員情報には正社員又は非正社員を区別する情報がある。
利用者は，社員が正社員であるか，非正社員であるかを決める。どちらの社員にも扶養家族情
報がある。この例では，次に示すように三つのサブグループ又はRETがある。
− 正社員［必す（須）］：共通情報を含む。
− 非正社員［必す（須）］：共通情報を含む。
− 扶養家族（任意）
7.2.4.4 RET計測規則
RETの計測では，次の規則のいずれかを適用する。
− ILF又はEIFの必す（須）サブグループ又は任意サブグループのそれぞれをRETとして計測する。
− サブグループがない場合は，ILF又はEIFを1RETと計測する。
7.3
ILF及びEIFの計測手順
ここでは，ILF及びEIFの計測手順を詳細に記述する。
7.3.1
識別及び計測手順
次の手順に従って，ILF及びEIFを識別する。
手順
作業内容
適用規則
1
ILFの識別
ILF識別規則
2
EIFの識別
EIF識別規則
3
複雑さ及び寄与の決定
複雑さ及び寄与の計測手順
7.3.2
複雑さ及び寄与の計測手順
次の手順に従って，未調整ファンクションポイントに対するILFの複雑さ及び寄与並びにEIFの複雑さ
及び寄与を計算する。
26
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
手順
作業内容
1
複雑さ及び寄与の定義及び規則を使用して，RET及びDETを識別し，計測する。
2
次の複雑さ表に従って，機能の複雑さを判定する。
1〜19 DET
20〜50 DET
51 DET以上
1 RET
低
低
中
2〜5 RET
低
中
高
6 RET以上
中
高
高
3
ILF又はEIFをそれぞれの変換表を使用して，未調整ファンクションポイントに変換する。
ILF変換表：次の表に従って，ILFを未調整ファンクションポイントに変換する。
複雑さ判定
未調整ファンクションポイント
低
7
中
10
高
15
EIF変換表：次の表に従って，EIFを未調整ファンクションポイントに変換する。
複雑さ判定
未調整ファンクションポイント
低
5
中
7
高
10
例 複雑さの判定が高のEIFの未調整ファンクションポイントは，10に変換する。
4
未調整ファンクションポイントに対するILF及びEIFのそれぞれの寄与を計算する。
例 高と判定されたILFの複雑さが一つ，中と判定されたEIFの複雑さが二つ及び高と判定さ
れたEIFの複雑さが一つあるときの計測例を次に示す。
ファンクション型
ファンクションの複雑さ 複雑さの合計
ファンクション型の合計
ILF
0 低 × 7
＝ 0
0 中 × 10 ＝ 0
1 高 × 15 ＝ 15
15
EIF
0 低 × 5
＝ 0
2 中 × 7
＝ 14
1 高 × 10 ＝ 10
24
この簡単な例では，複雑さが低又は中と判定されたILFはないので，ILFの寄与の合計値は15となる。
EIFの複雑さは，複雑さ低がなく，複雑さ中が二つで14，複雑さ高が一つで10となり，合計値は24とな
る。
ILF及びEIFの寄与は，すべてのファンクション型について集計する表に加える。すべてのファンクシ
ョン型についての最終合計値が，未調整ファンクションポイントとなる。
7.4
計測上の留意点
次の計測上の留意点は，ILF及びEIFの識別規則を適用するときに参考にしてもよい。
注意 計測上の留意点は，計測規則ではないので，規則として使用しないことが望ましい。
27
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
a) データは，特定の利用者の要件を満たす論理的なグループかどうか。
− アプリケーションは，同じILF又はEIFを複数の処理で使用することができる。しかし，そのILF
又はEIFは1回だけ計測する。
− 同じアプリケーションで一つの論理ファイルをILF及びEIFの二つの論理ファイルとして計測する
ことはできない。データのグループがILF及びEIFの両方の規則を満たす場合には，ILFとして計
測する。
− データのグループをILF又はEIFとして計測しないときは，そのデータ項目はそのデータのグルー
プを含むILF又はEIFのDETとして計測する。
− 利用者の観点からデータを論理的に見るとき，一つの物理的ファイル，テーブル又はオブジェクト
クラスが一つの論理的ファイルに相当すると想定しない。
− リレーショナルDBMSのテーブル又は順編成ファイル若しくはオブジェクトクラスのように，ある
種のデータ蓄積技術は，ILF又はEIFと密接に関連しているが，このことが常に物理対論理の1対1
の対応関係に等しいと想定しない。
− すべての物理的ファイルは，ILF又はEIFの一部として計測又は包含されなければならないと想定
しない。
b) データは，アプリケーション境界の内部又は外部のどちらで維持管理されているか。
− 業務の手順書を調べる。
− 業務処理の機能分解で，利用者と他のアプリケーションとの間のインタフェースを明確にする。
− 手掛かりを得るために手順図を調べる。
− あるアプリケーションのファンクションポイントを計測するとき，二つ以上のアプリケーションに
よって維持管理されるILFは，それぞれのアプリケーションのILFとして計測する。ただし，それ
ぞれの計測対象アプリケーションで使用するDETだけを計測対象アプリケーションのILF及び／又
はEIFの計測に使用することが望ましい。
c) ILFのデータ項目がアプリケーションの要素処理で維持管理されているか。
− アプリケーションは，同じILF又はEIFを複数の処理で使用することができる。しかし，そのILF
又はEIFは，1回だけ計測する。
− 一つの要素処理は，複数のILFを維持管理することができる。
− 手掛かりを得るために手順図を調べる。
− アプリケーションのファンクションポイントを計測するとき，二つ以上のアプリケーションによっ
て維持管理されるILFは，それぞれのアプリケーションのILFとして計測する。
7.5
ILF及びEIFの計測事例
ここでは，関連するセキュリティシステム及び郵便発送システムを伴って，人事情報システムを事例と
して，データファンクションの識別及び計測手順を示す。
注記 この細分箇条の事例には，次の二つの目的がある。
1) ファンクションポイントの計測規則を，与えられた利用者要件に対してどう適用するかを示す。
2) 計測手順の使用に習熟する。
計測者は，次の点に注意しなければならない。
− 計測対象のプロジェクト又はアプリケーションの利用者要件を分析する。
− 利用者要件に基づいて計測する。
7.5.1
計測事例の構成
28
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ここでは，事例の記述方法について説明する。
7.5.1.1 記述の構成の概略
事例における説明の順序は，次のとおりである。
事例ごとには，次のように説明する。
a) ILF又はEIFを識別する。
b) ファンクションの複雑さに寄与するRET及びDETを識別し，計測する。
すべての事例を集約して，次のように説明する。
c) ILF又はEIFとして計測するかどうかにかかわらず，識別された全項目を集約する。
d) 識別したすべてのILF又はEIFに対して，未調整ファンクションポイントに対する複雑さ及び寄与を
決定する。
7.5.1.2 各事例の計測
各事例は，次の構成要素からなる。
a) 計測及び／又は識別の基礎情報
b) 計測規則及び／又は識別規則を適用するための表
7.5.1.2.1 構成要素の図
各事例の構成要素及び情報の流れを，図5に示す。
29
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
計測及び／又は識別の基礎情報
利用者要件
1 Xxxxxxxxxxxx
2 Xxxxxxxxxxx
3 Xxxxxxxxxxx
識別表
ILF及びEIFの識別
識別規則
規則の該当・非該当
Xxxxxxxxxxxxxxxxxxxxxxxx
Xxxxxxxxxxxxxxxxxxxxxxxx
Xxxxxxxxxxxxxxxxxxxxxxxx
当てはまる。 又は 当てはまらない。 説 明 ――――
当てはまる。 又は 当てはまらない。 説 明 ――――
当てはまる。 又は 当てはまらない。 説 明 ――――
識別したEI，EO及びEQに対して，
FTR及びDETを計測する。
識別規則
規則の該当・非該当
Xxxxxxxxxxxxxxxx
Xxxxxxxxxxxxxxxx
Xxxxxxxxxxxxxxxx
説 明 ―――――
説 明 ―――――
説 明 ―――――
図5−構成要素及び情報の流れ
7.5.1.2.2 計測及び／又は識別の基礎情報
各事例は，最初に計測及び／又は識別の基礎情報を提示する。図5に示すように，計測及び／又は識別
は，次の情報に基づいて行う。
− 利用者要件
− データモデル及びプロセスモデル
− 画面，画面情報又は報告書
30
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
注記 図のすべての情報がすべての例に含まれているわけではない。事例の中には，利用者要件だけ
が計測の基本になるものがある。他の例では，データモデル又はプロセスモデル，画面，画面
情報及び報告書を含んでいるものもある。
7.5.1.2.3 識別表
ファンクションを識別するための分析は，そのファンクションの識別規則を列挙した表を使用して行う。
その規則は，計測及び／又は識別の基礎情報を作り上げる構成要素に適用する。分析内容は，表中の規則
の該当・非該当の欄で説明する。
注記 すべての規則が当てはまる場合は，事例をILF又はEIFとして計測する。
次に示す表は，識別した各ファンクションに対する複雑さの識別規則及びその説明を示している。
7.5.1.3 識別したILF及びEIFの概要
各事例に対してすべての規則を適用した後，計測したもの及び計測しなかったものを概要の項で一覧表
示する。
7.5.1.4 すべてのILF及びEIFに対する複雑さ及び寄与
説明の最後の項は，未調整ファンクションポイントに対する複雑さ及び寄与の計算を示す。
7.6
ILFの識別事例
ここでは，人事情報システムを事例として，データファンクションの識別手順及び計測手順を示す。
7.6.1
ILF識別事例の概要
ILFの事例一覧を，表2に示す。
表2−事例一覧
事例
概要
人事情報システムのデータ
結合したデータに対してILFの識別を行う事例
人事情報システムのセキュリティ
人事情報システムのセキュリティ要件に対してILFを識別する
事例
照会及び報告書出力のための監査データ
実装面の要件に対してILFを識別する事例
未確定業務情報
アプリケーション境界の内部で維持管理される中断業務情報に
対してILFを識別する事例
報告書書式定義
アプリケーション境界の内部で維持管理される利用者要件に基
づく報告書書式定義に対してILFを識別する事例
代替索引
報告書定義の事例で記述した利用者要件のほかに，物理実装要
件に焦点を当てた事例
共用データ
二つ以上のアプリケーションで維持管理されるデータに対して
ILFを識別する事例
異なる利用者及び／又は異なるデータ視点
二つのアプリケーションが同一ファイルの異なるDETを利用す
る事例
7.6.2
事例1：人事情報システムのデータ
7.6.2.1 利用者要件
利用者は，業務情報の入力，照会及び報告書出力ができることを要求している。
一緒に維持管理されなければならない業務情報には，次のものが含まれる。
− 業務番号
− 業務名称
− 業務給与等級
− 業務説明行番号
31
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 業務説明
業務説明は，1行当たり80文字の行を複数行使用して記述することが望ましい。
7.6.2.2 E-R図
データの正規化によって得られた二つの実体を次のE-R図（図6）に示す。実体は，業務及び業務説明
である。
業務
業務
説明
凡例：
必す(須)の１対多の関係
属性実体型
実体型
図6−人事情報システムの業務のE-R図
業務には，次を含む。
− 業務番号
− 業務名称
− 業務給与等級
業務説明には，次を含む。
− 業務番号
− 業務説明行番号
− 業務説明
7.6.2.3 データベース構造
人事情報システムのデータベース構造を，図7に示す。
32
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
社員
業務説明
業務割当て
業務
給与等級
図7−人事情報システムのデータベース構造
7.6.2.4 データベース表
人事情報システムのためのデータベース構造を，表3に示す。
表3−人事情報システムのデータベース表
社員表
業務割当て表
業務説明表
データ要素
社員氏名
姓
名
保険者番号
雇用種別
部課番号
管理職コード
時給
円換算時給
所属組合識別番号
事業所名外部キー
通貨地域外部キー
データ要素
日付
査定等級
給与
業務番号外部キー
保険者番号外部キー
データ要素
行番号
業務説明
業務番号外部キー
業務表
事業所表
給与等級表
データ要素
業務名
業務番号
給与等級
データ要素
国名
郵便番号
都道府県名
市区町村名
事業所住所
事業所名
保険者番号外部キー
データ要素
給与等級
給与等級説明
7.6.2.5 ILFの識別
E-R図は，次の二つの情報のグループを示している。
− 業務
33
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 業務説明
それぞれのグループがILFであるかを決定する。
まず，業務グループの分析を次の表に示す。
ILF識別規則
規則の該当・非該当
データ又は制御情報のグループは，論理的で利用者視
点によるものである。
当てはまらない。
業務情報の追加の利用者要件を表すために，業務は，
業務説明実体又は表を伴わなければならない。
データのグループは，計測対象のアプリケーション境
界の内部で要素処理によって維持管理される。
当てはまる。
その要素処理は，業務（利用者に対して，実体又は表
で表した業務及び業務説明の両者を含む。）を維持管
理する。
以上の分析によって，業務説明がない業務だけではILFにはならない。
次に，業務説明がILFであるかを決定する。
ILF識別規則
規則の該当・非該当
データ又は制御情報のグループは，論理的で利用者視
点によるものである。
当てはまらない。
業務情報の追加の利用者要件を表すために，業務説明
は，業務実体又は表を伴わなければならない。
データのグループは，計測対象アプリケーション境界
の内部で要素処理によって維持管理される。
当てはまる。
その要素処理は，業務（利用者に対して，実体又は表
で表した業務及び業務説明の両者を含む。）を維持管
理する。
以上の分析によって，業務がない業務説明だけではILFにはならない。
利用者の観点から，人事情報システムに業務情報を追加するために，業務及び業務説明は一緒に用いら
れる。実体又は表で表した業務及び業務説明は，一緒に維持管理しなければならないので，それらを結合
しなければならない。
利用者の観点から，業務情報という論理的なデータのグループが一つ存在する。
次に，業務情報がILFであるかを決定するためにILF識別規則を適用する。その分析を次の表に示す。
ILF識別規則
規則の該当・非該当
データ又は制御情報のグループは，論理的で利用者視
点によるものである。
当てはまる。
業務及び業務説明は，一緒になって業務情報を人事情
報システムに追加するために用いられる。
データのグループは，計測対象のアプリケーション境
界の内部で要素処理によって維持管理される。
当てはまる。
その処理は，業務情報を登録する処理である。
以上の分析によって，業務情報はILFと識別される。実体又は表で表した業務及び業務説明の情報を要
約して，一つのILFと識別する。
7.6.2.6 RET及びDETの計測
RET及びDETを計測する。
DETについて，業務情報ILFに関連する各情報項目を調べ，DET計測規則が適用できるかを決める。
業務には，次のものを含む。
− 業務番号
− 業務名
− 業務給与等級
業務説明には，次のものを含む。
− 業務番号
34
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 業務説明行番号
− 業務説明
注記 業務説明は，それ自身ではILFではないので，そのDETは，業務情報ILFの合計に含まれる。
業務情報ILFについてのDETの分析を次の表に示す。
ILFのDET計測規則
規則の該当・非該当
要素処理の実行によって，ILF若しくはEIFを維持管
理しているか，又はILF若しくはEIFから参照される，
一意で繰返しのない利用者視点のデータ項目を1DET
として計測する。
すべてのデータ項目は，利用者視点から見たものであ
る。しかし，業務番号は，1回だけ計測する。
二つのアプリケーションが，同一のILF又はEIFを維
持管理及び／又は参照し，かつ，各々が異なったDET
を維持管理又は参照するとき，各々のアプリケーショ
ンが使用するDETだけを計測する。
該当する種別のデータはない。
他のILF又はEIFとの関係を確立するために利用者が
要求したデータ項目は，1DETとして計測する。
該当する種別のデータはない。
以上の分析によって，一意的な項目を1DETとして計測する。その結果，合計で5DETとなる。
RETについて，RET計測規則に基づいて，サブグループを識別する。
RET計測規則
規則の該当・非該当
ILF又はEIFの必す（須）サブグループ又は任意サブ
グループのそれぞれを1RETとして計測する。
業務及び業務説明のグループは，それぞれ業務情報
ILFの必す（須）サブグループである。
サブグループがない場合は，ILF又はEIFを1RETと
して計測する。
利用者の観点から，二つのサブグループがある。
二つのサブグループがあるので，このILFは2RETとなる。
業務情報ILFのRET及びDETの合計を次の表に示す。
RET
DET
業務
業務説明
業務番号
業務名
業務給与等級
業務説明行番号
業務説明行
合計
2RET
合計
5DET
7.6.3
事例2：人事情報システムのセキュリティ
7.6.3.1 利用者要件
利用者は，次の理由で，人事情報システムに対してセキュリティ機能を要求している。
a) 人事情報システムの各画面への利用者アクセスを許可又は拒否する。
b) 各画面に対する利用者アクセス権を変更する。
c) 次のデータを用いた，画面セキュリティの追加又は変更に関して報告する。
− セキュリティ情報の追加又は変更を行う利用者の識別
− 追加又は変更された利用者セキュリティ情報及び画面セキュリティ情報
− 変更前後の利用者セキュリティ情報及び画面セキュリティ情報
− 追加又は変更を行った日付及び時刻
d) 各利用者が次のデータを使用して，維持管理できるようにするために，社員の事業所へのアクセス権
の割当て
− 利用者アクセス権
35
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 利用者の保険者番号
− アクセス権の種別
e) 事業所での利用者アクセス権の変更
f)
日々のセキュリティ活動の監視及び報告書出力のための監査データの取得。この要求は，利用者の画
面セキュリティ要件を満たすように設計を実施するときに決定する。
7.6.3.2 E-R図
人事情報システムのセキュリティに関するE-R図を，図8に示す。
社員
セキュリティ
扶養家族
画面
セキュリティ
画面
セキュリティ
監査
社員
正社員
非正社員
凡例:
必す(須)の1対多の関係
任意の1対多の関係
属性実体型
実体型
実体副型
図8−人事情報システムのセキュリティのE-R図
7.6.3.3 実体属性
人事情報システムのE-R図におけるセキュリティに関する実体属性を，表4に示す。
36
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表4−人事情報システムにおける実体属性
社員セキュリティ
画面セキュリティ
画面セキュリティ監査
データ項目
利用者ID
保険者番号
アクセス権種別
事業所
データ項目
利用者ID
保険者番号
画面ID
利用者アクセス権
データ項目
変更日時
変更実施者の利用者ID
変更前情報
変更前利用者ID
変更前利用者アクセス権
変更前画面ID
変更後情報
変更後利用者ID
変更後利用者アクセス権
変更後画面ID
7.6.3.4 データフロー図
この事例のデータフロー図を，図9に示す。
凡例:
利用者又はシステム
保存データ
プロセス
データの流れ
図9−データフロー図
報告書作成
利用者
画面セキュリティ追加
画面セキュリティ
追加
画面
セキュリティ
画面セキュリティ
変更
画面
セキュリティ
監査
社員セキュリティ
追加
社員セキュリティ
変更
社員
セキュリティ
セキュリティ変更
報告書作成
画面セキュリティ変更
社員セキュリティ追加
社員セキュリティ変更
利用者ID，
保険証番号，アクセス権種別
社員セキュリティ情報の変更
日時，利用者ID，
変更前情報，変更後情報
日時，利用者ID，
変更前情報，変更後情報
日時，
利用者ID，
変更前情報，
変更後情報
画面セキュリティ
情報の
変更
37
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
7.6.3.5 ILFの識別
利用者要件には，次の三つのデータのグループがある。
− 画面セキュリティ監査
− 画面セキュリティ
− 社員セキュリティ
各グループがILFであるかを決定するため，ILF規則を用いる。
最初に，画面セキュリティ監査を分析する。
ILF識別規則
規則適用の該当・非該当
データ又は制御情報のグループは，論理的で利用者視
点によるものである。
当てはまらない。
画面セキュリティ監査データの属性は，画面セキュリ
ティの更新の一部としてだけ維持管理される。
データのグループは，計測対象のアプリケーション境
界の内部で要素処理によって維持管理される。
当てはまる。
その処理は，画面アクセスセキュリティ情報にアクセ
スする画面を追加及び変更する処理である。
以上の分析によって，画面セキュリティ監査は，それだけではILFでないことを示す。
次に，画面セキュリティ監査と一緒に，画面セキュリティを分析する。
ILF識別規則
規則の該当・非該当
データ又は制御情報のグループは，論理的で利用者視
点によるものである。
当てはまる。
利用者は，どの人の人事情報システムの情報を参照又
は更新してもよいかを管理することを望んでいる。利
用者は，画面へのアクセスを許可するセキュリティの
追加，変更及び監視を行う必要がある。
データのグループは，計測対象のアプリケーション境
界の内部で要素処理によって維持管理される。
当てはまる。
その処理は，画面アクセスセキュリティ情報にアクセ
スする画面を追加及び変更する処理並びに画面セキ
ュリティ監査データを保存する処理である。
以上の分析によって，画面セキュリティは，画面セキュリティ監査データと一緒にILFであることを示
す。
次に，社員セキュリティを分析する。
ILF識別規則
規則の該当・非該当
データ又は制御情報のグループは，論理的で利用者視
点によるものである。
当てはまる。
利用者は，特定の事業所での社員情報を維持管理でき
る人を限定することを望んでいる。
データのグループは，計測対象のアプリケーション境
界の内部で要素処理によって維持管理される。
当てはまる。
利用者は，社員情報を維持管理できる人を限定するこ
とを望んでいる。その処理は，社員セキュリティ情報
を追加及び変更する処理である。
以上の分析によって，社員セキュリティは，ILFとなる。
分析から次の二つは，ILFとなる。
− 画面セキュリティ情報
− 社員セキュリティ情報
7.6.3.6 RET及びDETの計測
RET及びDETを計測する。
DETについては，セキュリティデータに関連する各項目を調べ，DET計測規則が適用できるかを決める。
a) 画面セキュリティ
38
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
1) 利用者ID
2) 保険者番号
3) 画面ID
4) 利用者アクセス権
b) 画面セキュリティ監査
1) 変更日時
2) 変更実施者の利用者ID
3) 変更前情報
− 変更前利用者ID
− 変更前利用者アクセス権
− 変更前画面ID
4) 変更後情報
− 変更後利用者ID
− 変更後利用者アクセス権
− 変更後画面ID
c) 社員セキュリティ
1) 利用者ID
2) 保険者番号
3) アクセス権種別
4) 事業所
画面セキュリティ情報に対するDET分析を次の表に示す。
ILFのDET計測規則
規則の該当・非該当
要素処理の実行によって，ILF若しくはEIFを維持管
理しているか，又はILF若しくはEIFから参照される，
一意で繰返しのない利用者視点のデータ項目を1DET
として計測する。
画面セキュリティ監査における変更前情報及び変更
後情報をそれぞれ1DETとし，合計2DETとなる。
二つのアプリケーションが，同一のILF又はEIFを維
持管理及び／又は参照し，かつ，各々が異なったDET
を維持管理又は参照するとき，各々のアプリケーショ
ンが使用するDETだけを計測する。
該当する種別のデータはない。
他のILF又はEIFとの関係を定めるために利用者が要
求したデータ項目は，1DETとして計測する。
該当する種別のデータはない。
次の項目は，それぞれ1DETと計測する。
− 利用者ID
− 保険者番号
− 画面ID
− 利用者アクセス権
− 変更日時
− 変更実施者の利用者ID
− 変更前情報（変更前利用者ID，変更前利用者アクセス権及び変更前画面ID）
− 変更後情報（変更後利用者ID，変更後利用者アクセス権及び変更後画面ID）
39
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
社員セキュリティ情報に対するDET分析を次の表に示す。
ILFのDET計測規則
規則の該当・非該当
要素処理の実行によって，ILF若しくはEIFを維持管
理しているか，又はILF若しくはEIFから参照される，
一意で繰返しのない利用者視点のデータ項目を1DET
として計測する。
すべての項目は，利用者視点から見たものである。
二つのアプリケーションが，同一のILF又はEIFを維
持管理及び／又は参照し，かつ，各々が異なったDET
を維持管理又は参照するとき，各々のアプリケーショ
ンが使用するDETだけを計測する。
該当する種別のデータはない。
他のILF又はEIFとの関係を定めるために利用者が要
求したデータ項目は，1DETとして計測する。
保険者番号は，社員ILFとの関係を維持管理するため
に要求される。
次の項目は，それぞれ1DETと計測する。
− 利用者ID
− 保険者番号
− アクセス権種別
− 事業所
RETについて，RET計測規則に基づいてサブグループを識別する。
画面セキュリティ
RET計測規則
規則の該当・非該当
ILF又はEIFの必す（須）サブグループ又は任意サブ
グループのそれぞれを1RETとして計測する。
画面セキュリティ及び画面セキュリティ監査のグル
ープは，それぞれ画面セキュリティILFの必す（須）
サブグループである。
サブグループがない場合は，ILF又はEIFを1RETと
して計測する。
サブグループが二つあるので，それぞれを1RETと計
測する。
二つのサブグループがあるので，画面セキュリティILFは，2RETとなる。
社員セキュリティ
RET計測規則
規則の該当・非該当
ILF又はEIFの必す（須） サブグループ又は任意サブ
グループのそれぞれを1RETとして計測する。
サブグループはない。
サブグループがない場合は，ILF又はEIFを1RETと
して計測する。
サブグループはない。
サブグループがないので，社員セキュリティILFは，1RETとなる。
セキュリティのRET及びDETの合計を次の表に示す。
RET
DET
画面セキュリティ
画面セキュリティ監査
利用者ID
保険者番号
画面ID
利用者アクセス権
変更日時
変更実施者の利用者ID
変更前情報
変更後情報
合計
2RET
合計
8DET
40
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
社員セキュリティ
利用者ID
保険者番号
アクセス権種別
事業所
合計
1RET
合計
4DET
7.6.4
事例3：照会及び報告書出力のための監査データ
7.6.4.1 利用者要件
次に示すセキュリティに関する利用者要件の分析から，監査データが必要であることが分かる。
a) 人事情報システムの各画面への利用者アクセスを許可又は拒否する。
b) 各画面に対する利用者アクセス権を変更する。
c) 次のデータを用いた，画面セキュリティの追加又は変更に関して報告する。
− セキュリティ情報の追加又は変更を行う利用者の識別
− 追加又は変更された社員セキュリティ情報及び画面セキュリティ情報
− 変更前後の利用者セキュリティ情報及び画面セキュリティ情報
− 追加又は変更を行った日付及び時刻
d) 日々のセキュリティ活動の監視及び報告書出力のための監査データの取得。この要求は，利用者の画
面セキュリティ要件を満たすように設計を実施するときに決定する。
7.6.4.2 データフロー図
図9を参照。このデータフロー図は，前の事例と共通である。
7.6.4.3 ILFの識別
7.6.3.2の人事情報システムのセキュリティ事例から，画面セキュリティという一つのデータのグループ
があることが分かる。
この画面セキュリティ監査データが別個のILFであるかを決定するためにILF識別規則を適用する。
画面セキュリティ監査データの分析を次の表に示す。
ILF識別規則
規則の該当・非該当
データ又は制御情報のグループは，論理的で利用者視
点によるものである。
当てはまらない。
セキュリティ情報の追加という利用者要件を満たす
ためには，画面セキュリティ監査データは，画面セキ
ュリティ実体又は表を含まなければならない。
データのグループは，計測対象のアプリケーション境
界の内部で要素処理によって維持管理される。
当てはまる。
画面へのセキュリティアクセス権が追加又は変更さ
れる場合，監査情報を維持管理する。
画面セキュリティ監査データは，画面セキュリティの一部であるので，そのままではILFとは計測しな
い。
7.6.5
事例4：未確定業務情報
7.6.5.1 利用者要件
利用者要件から，未確定業務情報ファイルが必要となる。
業務情報の追加及び変更は，オフライン処理で行うことに決められた。オフライン処理を実施するとき，
利用者は，エラートランザクションが発生したときに未確定業務情報ファイルを更新することで，業務フ
ァイルの更新に失敗した業務が分かるようにすることを要求している。
未確定業務情報ファイルは，トランザクションを修正するシステムのオンライン画面で編集することが
できる。未確定業務情報ファイルの業務情報の中には誤っているものがあり得るので，不完全な業務又は
41
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
中断した業務の内容を変更する場合，すべての業務及びすべての業務説明の情報を維持管理する。
注記 この事例では，未確定業務情報ファイルがILFであるかを調べる。
7.6.5.2 データフロー図
この事例のデータフロー図を，図10に示す。
図10−データフロー図
7.6.5.3 ILFの識別
未確定業務情報がILFであるかを決定する。分析の概要を次の表に示す。
ILF識別規則
規則の該当・非該当
データ又は制御情報のグループは，論理的で利用者視
点によるものである。
当てはまる。
誤った情報がある業務は，人事情報システムへ追加す
るために，修正されなければならない。
データのグループは，計測対象のアプリケーション境
界の内部で要素処理によって維持管理される。
当てはまる。
未確定業務情報ファイルは，人事情報システムの画面
を使用して，変更される。
以上の分析によって，未確定業務情報は，ILFとなる。
7.6.5.4 RET及びDETの計測
RET及びDETを計測する。
DETについては，業務情報は，どの項目も誤っている可能性があるので，業務及び業務説明に関連する
業務及び業務説明報告
（ハードコピー）
業務番号，業務名，支払区分，
説明，業務一覧
バッチでの
業務変更
未確定業務情報の
維持管理
業務番号，業務名，支払区分，
行番号，説明
業務番号，
業務名，支払区分，説明
修正済業務
保留業務
ID業務名，業務番号，支払区分
追加
業務情報
業務及び
業務説明
利用者
業務番号
業務名，
給与等級，説明
未確定
業務情報
業務の報告書作成
業務追加
トランザクション
未確定業務情報の追加，変更，削除
業務及び業務説明報告
（マイクロフィルム）
バッチでの
業務追加
業務照会
42
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
各項目を調べる。各項目について，DET計測規則が適用できるかを決める。
未確定業務の項目は，次のとおりである。
− トランザクション型
− 未確定業務番号
− 未確定業務名
− 未確定業務給与等級
未確定業務説明の項目は，次のとおりである。
− トランザクション型
− 未確定業務説明行番号
− 未確定業務説明行
− 未確定業務番号
ILFのDET計測規則
規則の該当・非該当
要素処理の実行によって，ILF若しくはEIFを維持管
理しているか，又はILF若しくはEIFから参照される，
一意で繰返しのない利用者視点のデータ項目を1DET
として計測する。
すべての項目は，利用者視点から見たものである。
未確定業務番号及びトランザクション型は，重複発生
するDETである。それぞれを，1DETと計測する。
二つのアプリケーションが，同一のILF又はEIFを維
持管理及び／又は参照し，かつ，各々が異なったDET
を維持管理又は参照するとき，各々のアプリケーショ
ンが使用するDETだけを計測する。
該当する種別のデータはない。
他のILF又はEIFとの関係を定めるために利用者が要
求したデータ項目は，1DETとして計測する。
該当する種別のデータはない。
各項目を一つのDETと計測する。
RETについて，RET計測規則に基づいてサブグループを識別する。
RET計測規則
規則の該当・非該当
ILF又はEIFの必す（須） サブグループ又は任意サブ
グループのそれぞれを1RETとして計測する。
未確定業務情報は，次の二つの必す（須）サブグルー
プからなる。
− 未確定業務
− 未確定業務説明
サブグループがない場合は，ILF又はEIFを1RETと
して計測する。
サブグループがあるので，この規則は適用しない。
二つのサブグループがあるので，ILFは2RETとなる。
未確定ILFに対するRET及びDETの合計を次の表に示す。
RET
DET
未確定業務
未確定業務説明
未確定業務番号
未確定業務名
未確定業務給与等級
未確定業務説明行番号
未確定業務説明
トランザクション型
合計
2RET
合計
6DET
7.6.6
事例5：報告書書式定義
7.6.6.1 利用者要件
利用者は，次のことの実現を必要としている。
a) 次の項目を含む報告書書式定義に入力する。
43
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 報告書の識別子
− 報告書名称
− 報告書で用いられる項目
− 報告書生成のための計算式
b) 必要ならば，定義を変更して，いつでも登録された報告書書式定義を再利用できる。
c) 報告書書式定義を使用して，報告書の閲覧及び印刷ができる。
d) 報告書名称又は報告書識別子によって，既存の報告書書式定義を照会できる。
7.6.6.2 ILFの識別
報告書識別子，報告書名称，報告書の項目及び計算式は，一つのグループとして維持管理されるので，
報告書書式定義のためのデータの論理的なグループ分けを利用者要件から作り出す。
報告書書式定義がILFであるかを決めるための分析を次の表に示す。
ILF識別規則
規則の該当・非該当
データ又は制御情報のグループは，論理的で利用者視
点によるものである。
当てはまる。
データは，人事情報システムにおいて情報の閲覧及び
情報の出力に用いられる。
データのグループは，計測対象のアプリケーション境
界の内部で要素処理によって維持管理される。
当てはまる。
その処理は，報告書書式定義の追加及び変更の処理で
ある。
以上の分析によって，報告書書式定義は，ILFとなる。
7.6.6.3 RET及びDETの計測
RET及びDETの数を計測する。
DETについては，報告書定義ILFに関連する各項目を調べ，DET計測規則を適用できるかを決める。
報告書定義ILFは，次のとおりである。
− 報告書名称
− 報告書識別子
− 項目
− 計算式
報告書書式定義ILFに対するDET分析を次の表に示す。
ILFのDET計測規則
規則の該当・非該当
要素処理の実行によって，ILF若しくはEIFを維持管
理しているか，又はILF若しくはEIFから参照される，
一意で繰返しのない利用者視点のデータ項目を1DET
として計測する。
すべての項目は，利用者視点から見たものである。項
目及び計算式は，重複発生するDETである。
二つのアプリケーションが，同一のILF又はEIFを維
持管理及び／又は参照し，かつ，各々が異なったDET
を維持管理又は参照するとき，各々のアプリケーショ
ンが使用するDETだけを計測する。
該当する種別のデータはない。
他のILF又はEIFとの関係を定めるために利用者が要
求したデータ項目は，1DETとして計測する。
該当する種別のデータはない。
44
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
RETについては，RET計測規則に基づいてサブグループを識別する。
RET計測規則
規則の該当・非該当
ILF又はEIFの必す（須） サブグループ又は任意サブ
グループのそれぞれを1RETとして計測する。
報告書書式定義は，サブグループをもたない。
サブグループがない場合は，ILF又はEIFを1RETと
して計測する。
サブグループがないので，報告書書式定義ILFを1RET
と計測する。
サブグループがないので，このILFは，1RETとなる。
報告書書式定義に対するRET及びDETの合計を次の表に示す。
RET
DET
報告書書式定義グループ
報告書名称
報告書識別子
項目
計算式
合計
1RET
合計
4DET
7.6.7
事例6：代替索引
7.6.7.1 利用者要件
利用者は，望ましい定義書式を見つけるために，報告書名称を検索キーとして，報告書書式定義を調べ
ることが必要になる。利用者要件を満たすため，報告書名称を検索キーとして代替索引を作成する。
7.6.7.2 ILFの識別
索引がILFであるかを決めるための分析の概要を次の表に示す。
ILF識別規則
規則の該当・非該当
データ又は制御情報グループは，論理的で利用者視点
によるものである。
当てはまらない。
利用者の観点からすると，代替索引は，報告書書式定
義ILFを参照するために生成した，報告書書式定義の
特定の属性を利用者に提供するものである。代替索引
は，照会リストを生成するために必要なものである
が，それ自身業務機能を構成するものではない。
データのグループは，計測対象のアプリケーション境
界の内部で要素処理によって維持管理される。
対象外
以上の分析によって，この代替索引は論理グループではない。したがって，ILFとして計測しない。
7.6.8
事例7：共用データ
7.6.8.1 利用者要件
人事情報システムの利用者は，新入社員の各情報を維持管理することを必要としている。
人事情報システムの利用者が維持管理しなければならない情報は，次のとおりである。
− 社員ID
− 社員氏名
− 社員住所
− 社員給与等級
− 社員業務名称
新入社員レコードを生成した結果，社員の年金受給資格予定日が自動的に計算され，他の社員情報とと
もに保存される。
セキュリティ管理者は，各新入社員へのセキュリティレベルの割当てを要求している。セキュリティ管
理部門は，新入社員を雇用したあと経歴を調査し，適切なセキュリティレベルを割り当てる。
セキュリティ管理者が維持管理しなければならない情報は，次のとおりである。
45
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 社員ID
− 社員セキュリティレベル
セキュリティ管理者は，次の情報の一覧表も必要としている。
− 社員ID
− 社員氏名
− 社員セキュリティレベル
7.6.8.2 データフロー図
この事例のデータフロー図を，図11に示す。
利用者
社員の
生成
社員ID
社員氏名
社員住所
給与等級
業務名称
年金受給資格日
Screen
社員
利用者
セキュリティレベル
割当
社員ID
社員氏名
社員住所
給与等級
業務名称
年金受給資格日
セキュリティレベル
社員情報の
印刷
社員ID
社員氏名
セキュリティレベル
社員ID
セキュリティ水準
人事情報システム
セキュリティシステム
図11−データフロー図
7.6.8.3 ILFの識別
社員情報が人事情報システムのILFであるかを決定する。分析の概要を次の表に示す。
ILF識別規則
規則の該当・非該当
データ又は制御情報グループは，論理的で利用者視点
によるものである。
当てはまる。
この情報は，認識されており，人事情報システムによ
って要求されている。
データのグループは，計測対象のアプリケーション境
界の内部で要素処理によって維持管理される。
当てはまる。
社員レコード生成は，人事情報システムのアプリケー
ション境界の内部の処理である。
以上の分析によって，社員情報が人事情報システムのILFであることを示す。
社員情報がセキュリティシステムのILFであるかを決定する。
分析の概要を次の表に示す。
割当て
46
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ILF識別規則
規則の該当・非該当
データ又は制御情報グループは，論理的で利用者視
点によるものである。
当てはまる。
この情報は，認識されており，セキュリティ管理者によ
って要求されている。
データのグループは，計測対象のアプリケーション
境界の内部で要素処理によって維持管理される。
当てはまる。
社員セキュリティレベルの割当て手順は，セキュリティ
システムのアプリケーション境界の内部の処理である。
以上の分析によって，社員情報がセキュリティシステムのILFであることを示す。
7.6.8.4 RET及びDETの計測（人事情報システム）
人事情報システムの社員情報ILFについて，DET及びRETの数を計測する。
DETについては，人事情報システムでの社員情報ILFに関連する各項目を調べ，DET識別規則を適用で
きるかを決定する。
社員情報ILFの項目は，次のとおりである。
− 社員ID
− 社員氏名
− 社員住所
− 社員給与等級
− 社員業務名称
− 年金受給資格日
− 社員セキュリティレベル
人事情報システムにおける社員情報ILFのDETであるかの分析を次の表に示す。
ILFのDET計測規則
規則の該当・非該当
要素処理の実行によって，ILF若しくはEIFを維持管
理しているか，又はILF若しくはEIFから参照される，
一意で繰返しのない利用者視点のデータ項目を1DET
として計測する。
次の項目は，人事情報システムの利用者が認識してい
る。
− 社員ID
− 社員氏名
− 社員住所
− 社員給与等級
− 社員業務名称
− 年金受給資格日
二つのアプリケーションが，同一のILF又はEIFを維
持管理及び／又は参照し，かつ，各々が異なったDET
を維持管理又は参照するとき，各々のアプリケーショ
ンが使用するDETだけを計測する。
該当する種別のデータが存在する。
社員セキュリティレベルを除くすべての項目が人事
情報システムで利用される。
他のILF又はEIFとの関係を定めるために利用者が要
求したデータ項目は，1DETとして計測する。
該当する種別のデータは存在しない。
RETについては，RET識別規則に基づいてサブグループを識別する。
RET計測規則
規則の該当・非該当
ILF又はEIFの必す（須）サブグループ又は任意サブ
グループのそれぞれを1RETとして計測する。
社員情報は，サブグループをもたない。
サブグループがない場合は，ILF又はEIFを1RETと
して計測する。
サブグループがないので，人事情報システムでの社員
情報ILFを1RETとして計測する。
サブグループがないので，人事情報システムでの社員情報ILFは，1RETとなる。
人事情報システムでの社員情報ILFに対するRET及びDETの合計を次の表に示す。
47
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
RET
DET
社員情報
社員ID
社員氏名
社員住所
社員給与等級
社員業務名称
年金受給資格日
合計
1RET
合計
6DET
7.6.8.5 RET及びDETの計測（セキュリティシステム）
セキュリティシステムの社員情報ILFについて，DET及びRETの数を計測する。
DETについては，セキュリティシステムでの社員情報ILFに関連する各項目を調べ，DET識別規則に当
てはまるかを決める。
社員情報ILFは，次のとおりである。
− 社員ID
− 社員氏名
− 社員住所
− 社員給与等級
− 社員業務名称
− 年金受給資格日
− 社員セキュリティレベル
セキュリティシステムにおける社員情報ILFのDETの分析を次の表に示す。
ILFのDET計測規則
規則の該当・非該当
要素処理の実行によって，ILF若しくはEIFを維持管
理しているか，又はILF若しくはEIFから参照される，
一意で繰返しのない利用者視点のデータ項目を1DET
として計測する。
次の項目は，セキュリティ管理者の利用者が認識して
いる。
− 社員ID
− 社員氏名
− 社員セキュリティレベル
二つのアプリケーションが，同一のILF又はEIFを維
持管理及び／又は参照し，かつ，各々が異なったDET
を維持管理又は参照するとき，各々のアプリケーショ
ンが使用するDETだけを計測する。
該当する種別のデータが存在する。
社員ID，社員氏名及び社員セキュリティレベルだけが
セキュリティシステムで利用される。
他のILF又はEIFとの関係を定めるために利用者が要
求したデータ項目は，1DETとして計測する。
該当する種別のデータは存在しない。
RETについては，RET識別規則に基づきサブグループを識別する。
RET計測規則
規則の該当・非該当
ILF又はEIFの必す（須）サブグループ又は任意サブ
グループのそれぞれを1RETとして計測する。
社員情報は，サブグループをもたない。
サブグループがない場合は，ILF又はEIFを1RETと
して計測する。
サブグループがないので，セキュリティシステムでは
社員情報ILFは1RETとして計測する。
サブグループがないので，セキュリティシステムでは社員情報ILFは，1RETとなる。
セキュリティシステムでの社員情報ILFに対するRET及びDETの合計を次の表に示す。
RET
DET
社員情報
社員ID
社員氏名
社員セキュリティレベル
合計
1RET
合計
3DET
48
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
7.6.9
事例8：異なる利用者及び／又は異なるデータ視点
7.6.9.1 利用者要件
人事情報システムの利用者によって維持管理されなければならない情報は，次のとおりである。
− 社員ID
− 社員氏名
− 社員住所
社員住所には，次の項目を含んでいる。
− 階
− 建物番号
− 番地
− 市区町村名
− 都道府県名
− 郵便番号
− 社員給与等級
− 社員業務名称
新入社員レコードを生成した結果，社員の年金受給資格予定日が自動的に計算され，他の社員情報とと
もに保存される。人事情報システムの利用者は，各社員への郵便ラベルの作成を必要としている。
郵便発送担当部門では，各社員について，認識した番号内で変更を反映するために建物番号を維持管理
する機能を必要としている。
郵便発送担当部門では，社内便発送に最も効率的な方法を決定するため，事業所ごとの社員数を算出す
る機能も必要としている。それは，建物ごと，階ごとの社員数の一覧表である。
郵便発送担当部門が維持管理又は参照しなければならない情報は，次のとおりである。
− 社員ID
− 階
− 建物番号
7.6.9.2 データフロー図
この事例のデータフロー図を，図12に示す。
49
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
利用者
社員の
生成
社員ID
社員氏名
社員住所
給与等級
業務名称
年金受給資格日
Screen
社員
利用者
建物番号の
維持管理
社員ID
社員氏名
社員住所
階
建物番号
番地
市区町村名
都道府県名
郵便番号
給与等級
業務名称
年金受給資格日
セキュリティレベル
社員数の
印刷
社員ID
階
建物番号
社員ID
階
建物番号
人事情報システム
郵便発送システム
図12−データフロー図
7.6.9.3 ILFの識別
社員情報が人事情報システムのILFであるかを決定する。分析の概要を次の表に示す。
ILF識別規則
規則の該当・非該当
データ又は制御情報グループは，論理的で利用者視点
によるものである。
当てはまる。
この情報は，認識されており，人事情報システムによ
って要求されている。
データのグループは，計測対象のアプリケーション境
界の内部で要素処理によって維持管理される。
当てはまる。
社員レコード生成は，人事情報システムのアプリケー
ション境界の内部の処理である。
以上の分析によって，社員情報が人事情報システムのILFであることを示す。
社員情報が郵便発送システムのILFであるかを決定する。分析の概要を次の表に示す。
ILF識別規則
規則の該当・非該当
データ又は制御情報グループは，論理的で利用者視点
によるものである。
当てはまる。
この情報は，認識されており，郵便発送システムによ
って要求されている。
データのグループは，計測対象のアプリケーション境
界の内部で要素処理によって維持管理される。
当てはまる。
建物番号の維持管理の手順は，郵便発送システムのア
プリケーション境界の内部の処理である。
以上の分析によって，社員情報が郵便発送システムのILFであることを示す。
7.6.9.4 RET及びDETの計測（人事情報システム）
人事情報システムの社員情報ILFについて，DET及びRETの数を計測する。
郵便発送システム
社員ID
階
建物番号
50
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
DETについては，人事情報システムでの社員情報ILFに関連する各項目を調べ，DET識別規則に適用で
きるかを決める。
社員情報ILFは，次のとおりである。
− 社員ID
− 社員氏名
− 社員住所
− 階
− 建物番号
− 番地
− 市区町村名
− 都道府県名
− 郵便番号
− 社員給与等級
− 社員業務名称
− 年金受給資格日
− 社員セキュリティレベル
人事情報システムにおける社員情報ILFのDETの分析を次の表に示す。
ILFのDET計測規則
規則の該当・非該当
要素処理の実行によって，ILF若しくはEIFを維持管
理しているか，又はILF若しくはEIFから参照される，
一意で繰返しのない利用者視点のデータ項目を1DET
として計測する。
次の項目は，認識されており，人事情報システムによ
って要求されている。
− 社員ID
− 社員氏名
− 社員住所
− 社員給与等級
− 社員業務名称
− 年金受給資格日
二つのアプリケーションが，同一のILF又はEIFを維
持管理及び／又は参照し，かつ，各々が異なったDET
を維持管理又は参照するとき，各々のアプリケーショ
ンが使用するDETだけを計測する。
該当する種別のデータが存在する。社員ID，社員氏名，
社員住所，社員給与等級，社員業務名称及び年金受給
資格日だけが人事情報システムで利用される。
他のILF又はEIFとの関係を定めるために利用者が要
求したデータ項目は，1DETとして計測する。
該当する種別のデータは存在しない。
RETについては，RET識別規則に基づいてサブグループを識別する。
RET計測規則
規則の該当・非該当
ILF又はEIFの必す（須）サブグループ又は任意サブ
グループのそれぞれを1RETとして計測する。
社員情報は，サブグループをもたない。
サブグループがない場合は，ILF又はEIFを1RETと
して計測する。
サブグループがないので，人事情報システムでは社員
情報ILFを1RETとして計測する。
サブグループがないので，人事情報システムでは社員情報ILFは，1RETとなる。
人事情報システムでの社員情報ILFに対するRET及びDETの合計を次の表に示す。
51
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
RET
DET
社員情報
社員ID
社員氏名
社員住所
社員給与等級
社員業務名称
年金受給資格日
合計
1RET
合計
6DET
7.6.9.5 RET及びDETの計測（郵便発送システム）
郵便発送ステムの社員情報ILFについて，DET及びRETの数を計測する。
DETについては，郵便発送システムでの社員情報ILFに関連する各項目を調べ，DET識別規則を適用で
きるかを決める。
社員情報ILFは，次のとおりである。
− 社員ID
− 社員氏名
− 社員住所
− 階
− 建物番号
− 番地
− 市区町村名
− 都道府県名
− 郵便番号
− 社員給与等級
− 社員業務名称
− 年金受給資格日
− 社員セキュリティレベル
郵便発送システムにおける社員情報ILFのDETであるかの分析を次の表に示す。
ILFのDET計測規則
規則の該当・非該当
要素処理の実行によって，ILF若しくはEIFを維持管
理しているか，又はILF若しくはEIFから参照される，
一意で繰返しのない利用者視点のデータ項目を1DET
として計測する。
次の項目は，郵便発送システムの利用者が認識してい
る。
− 社員ID
− 階
− 建物番号
二つのアプリケーションが，同一のILF又はEIFを維
持管理及び／又は参照し，かつ，各々が異なったDET
を維持管理又は参照するとき，各々のアプリケーショ
ンが使用するDETだけを計測する。
該当する種別のデータが存在する。社員ID，階及び建
物番号だけが郵便発送システムで利用される。
他のILF又はEIFとの関係を定めるために利用者が要
求したデータ項目は，1DETとして計測する。
該当する種別のデータは存在しない。
RETについては，RET識別規則に基づいてサブグループを識別する。
RET計測規則
規則の該当・非該当
ILF又はEIFの必す（須）サブグループ又は任意サブ
グループのそれぞれを1RETとして計測する。
社員情報は，サブグループをもたない。
サブグループがない場合は，ILF又はEIFを1RETと
して計測する。
サブグループがないので，セキュリティシステムでは
社員情報ILFを1RETとして計測する。
52
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
サブグループがないので，郵便発送システムでの社員情報ILFは，1RETとなる。
郵便発送システムでの社員情報ILFに対するRET及びDETの合計を次の表に示す。
RET
DET
社員情報
社員ID
階
建物番号
合計
1RET
合計
3DET
7.6.10 計測したILF，RET及びDETの概要
ここでは，未調整ファンクションポイントの複雑さ及び寄与を計算する前に，計測したILF，RET及び
DETの概要を示す。
7.6.10.1 計測したILFの概要
人事情報システムのILF計測結果を次の表に示す。この表には，計測されなかったデータも含んでいる。
計測したILF
計測対象外
業務情報
監査データ
画面セキュリティ情報
代替索引
社員セキュリティ情報
未確定業務情報
報告書書式定義
社員情報（人事情報システム）
社員情報（セキュリティシステム）
社員情報（郵便発送システム）
7.6.10.2 RET及びDETの計測概要
人事情報システムのRET及びDETの計測結果を次の表に示す。
ILF
RET
DET
業務情報
2
5
未確定業務情報
2
6
報告書書式定義
1
4
社員情報
1
6
セキュリティシステムのRET及びDETの計測結果を次の表に示す。
ILF
DET
RET
画面セキュリティデータ情報
2
8
社員セキュリティデータ情報
1
4
社員情報
1
3
郵便発送システムのRET及びDETの計測結果を次の表に示す。
ILF
DET
RET
社員情報
1
3
7.6.11 ILFの複雑さ及び寄与
ここでは，未調整ファンクションポイントに対するILFの複雑さ及び寄与を決めるための最終ステップ
を示す。
最終ステップは，次のとおりである。
a) ILFの複雑さを判定する。
b) 複雑さを未調整ファンクションポイントへ変換する。
c) 未調整ファンクションポイントの合計に対するILFの寄与を計算する。
7.6.11.1 ILFの複雑さ判定
53
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ファンクションの複雑さは，低，中又は高に判定される。
次のILF複雑さ判定表をILFの複雑さ判定に用いる。
1〜19DET
20〜50DET
51DET以上
1RET
低
低
中
2〜5RET
低
中
高
6RET以上
中
高
高
次の表は，人事情報システムの各ILFについて，ファンクションの複雑さを示した表である。セキュリ
ティシステム及び郵便発送システムのデータファンクション型の複雑さの決定も同様の手順で行われる。
ILF
RET
DET
複雑さ
業務情報
2
5
低
未確定業務情報
2
6
低
報告書書式定義
1
4
低
社員情報
1
6
低
7.6.11.2 各ILFの未調整ファンクションポイントへの変換
次の表は，ILFのファンクションの複雑さを未調整ファンクションポイントへ変換する表である。
ファンクションの複雑さ判定
未調整ファンクションポイント
低
7
中
10
高
15
複雑さを次の表へ記入する。
7.6.11.3 ILFの寄与の小計
次の表は，人事情報システムについてILFのファンクションポイントを計測するものである。
ファンクション型
ファンクションの複雑さ 複雑さの合計
ファンクション型の合計
ILF
4 低 × 7
＝ 28
0 中 × 10 ＝
0
0 高 × 15 ＝
0
28
すべてのファンクション型を一覧表示した表にこのファンクションの合計値を記入する。すべてのファ
ンクション型についての最終の合計値が未調整ファンクションポイントとなる。
7.7
EIFの計測事例
ここでは，セキュリティシステム及び年金システムを伴って，人事情報システムを事例として，データ
ファンクションの計測手順を示す。
7.7.1
EIF計測事例の概要
EIFの事例一覧を，表5に示す。
表5−事例一覧
事例
概要
他システムからのデータの参照
（出力処理）
他のシステムで維持管理されるデータを参照するシステムに対してEIFを識
別する事例。このデータは，外部出力において利用される。
他システムからのデータの参照
（入力処理の一部として）
他のシステムからデータを参照する事例。この事例では，外部入力に対して
他のシステムで維持管理されるデータを参照するシステムに対するEIFを識
別する。
他システムへのデータの提供
他のシステムが計測対象のシステムからデータを取り出すときの計測方法
の事例
ヘルプ機能システム
別個のシステムによって提供されるヘルプ機能を，人事情報システムとして
計測する事例
54
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
データ変換
新しいシステムへデータ変換する場合の計測事例
トランザクション入力ファイル
人事情報システムに業務を追加するときに使用するトランザクション 入力
ファイルでのEIF識別規則を適用する事例
異なる利用者及び／又は異なる
利用者要件記述
複数のアプリケーションが同一のEIFを参照するが，要求記述が異なる事例
複数目的の利用
同一データを複数目的で利用する事例
7.7.2
事例1：他システムからのデータの参照（出力処理）
7.7.2.1 利用者要件
利用者は，人事情報システムで次の機能を要求している。
a) 社員情報の入力，照会及び報告書作成
b) 各建物に対して事業所情報を取得するため，固定資産管理システムと連動する。事業所情報には，事
業所名及び建物住所を含む。
7.7.2.2 EIFの識別
利用者要件から，二つの情報グループがある。
− 社員情報
− 事業所情報
社員情報がEIFであるかを決定するための分析の概要を次の表に示す。
EIF識別規則
規則の該当・非該当
データ又は制御情報グループは，論理的で利用者視点
によるものである。
当てはまる。
利用者は，社員情報に関する照会及び報告書作成がで
きることを要求している。
データのグループは，計測対象アプリケーションの外
部にあって参照されるものである。
当てはまらない。
計測対象の人事情報システムは，社員情報の作成を要
求している。
データのグループは，計測対象アプリケーションによ
って維持管理されない。
当てはまらない。
人事情報システムは，社員情報を追加，変更及び削除
する機能をもつ。
EIFとして識別したデータのグループは，他のアプリ
ケーションのILFとして維持管理される。
当てはまる。
しかし，ILFが計測対象の人事情報システムの内部で
維持管理されるため，この規則に適合しない。
以上の分析によって，社員情報は，人事情報システムの外部ではなく，システムの内部で維持管理され
る。したがって，EIFではない。
事業所情報がEIFであるかを決定するための分析の概要を次の表に示す。
EIF識別規則
規則の該当・非該当
データ又は制御情報グループは，論理的で利用者視点
によるものである。
当てはまる。
利用者は，社員情報報告書作成のために情報を取り出
すことができることを要求している。
データのグループは，計測対象アプリケーションの外
部にあって参照されるものである。
当てはまる。
このデータは，固定資産管理システムによって外部で
維持管理されている。
データのグループは，計測対象アプリケーションによ
って維持管理されない。
当てはまる。
55
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
EIFとして識別したデータのグループは，他のアプリ
ケーションのILFとして維持管理される。
現時点の情報だけでは，この規則に当てはまるかは明
確でない。利用者に確認したところ，利用者が，情報
を固定資産管理システムの画面から入力しているこ
とが分かる。
それゆえ，このデータのグループは，固定資産管理シ
ステムのILFであり，この規則に当てはまる。
事業所情報は，EIFのすべての要求に適合する。
7.7.2.3 RET及びDETの計測
DET及びRETを計測する。
DETについては，事業所情報EIFに関連する各データ項目を調べ，DET識別規則に当てはまるか決定す
る。
− 建物番号
− 建物名
− 建物住所
− 1行目
− 2行目
− 3行目
− 市区町村名
− 都道府県名
− 国名
DETであるかの分析の概要を次の表に示す。
EIFのDET計測規則
規則の該当・非該当
要素処理によって，ILF若しくはEIFを維持管理して
いるか，又はILF若しくはEIFから参照される，一意
で繰返しのない利用者視点のデータ項目を1DETとし
て計測する。
すべてのデータ項目は，利用者視点から見たものであ
る。建物住所は3行あるが，これは続き行であるので，
建物住所は1DETとして計測する。
二つのアプリケーションが，同一のILF又はEIFを維
持管理及び／又は参照し，かつ，各々が異なったDET
を維持管理又は参照するとき，各々のアプリケーショ
ンが使用するDETだけを計測する。
このデータは，固定資産管理システムで維持管理され
ている。
他のILF又はEIFとの関係を確立するために利用者が
要求したデータ項目は，1DETとして計測する。
該当する種別のデータは，存在しない。
各データ項目に対応して，1DETを計測する。
RETについては，RET計測規則に基づいてサブグループを識別する。
RET計測規則
規則の該当・非該当
ILF又はEIFの必す（須）サブグループ又は任意サブ
グループのそれぞれを1RETとして計測する。
事業所情報には，サブグループはない。
サブグループがない場合は，ILF又はEIFを1RETと
して計測する。
サブグループがないので，事業所情報EIFは1RETと
して計測する。
サブグループがないので，事業所情報EIFは，1RETとなる。
事業所情報EIFのRET及びDETの合計を次の表に示す。
56
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
RET
DET
事業所情報
建物番号
建物名
建物住所
1行目
2行目
3行目
市区町村名
都道府県名
国名
合計
1RET
合計
6DET
7.7.3
事例2：他システムからのデータの参照（入力処理の一部として）
7.7.3.1 利用者要件
利用者は，人事情報システムに次の機能を要求している。
− すべての非正社員には，円建てで支払わなければならない。
− 利用者が社員情報を追加及び変更する場合，人事情報システムは，為替システムを利用し，為替レー
トを取り出さなければならない。為替レートを取り出した後，人事情報システムは，社員の現地標準
時給を，次の式を使用して円建て時給に変換する。
7.7.3.2 データモデル
この事例のデータモデルを，図13に示す。
人事情報システム
扶養家族
為替レート
正社員
非正社員
社員
為替システム
凡例:
必す(須)の一対多の関係
任意の一対多の関係
属性実体型
実体型
実体副型
図13−データモデル図
標準時給
為替レート
= 円建て時給
57
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
為替情報には次を含む。
通貨
− 基本通貨に対する為替レート
− 国名
7.7.3.3 EIFの識別
利用者要件から，二つの情報グループがある。
− 為替情報
− 社員情報
為替情報がEIFであるかを決定するための分析の概要を次の表に示す。
EIF識別規則
規則の該当・非該当
データ又は制御情報のグループは，論理的で利用者視
点によるものである。
当てはまる。
利用者は，必要なすべての社員データを人事情報シス
テムが維持管理できるようにするため，現地通貨を
（日本円へ）換算することを要求している。
データのグループは，計測対象アプリケーションの外
部にあって参照されるものである。
当てはまる。
規則を適用する。
データのグループは，計測対象アプリケーションによ
って維持管理されない。
当てはまる。
規則を適用する。
EIFとして識別したデータのグループは，他のアプリ
ケーションのILFとして維持管理される。
現時点の情報だけでは，この規則が為替情報に当ては
まるかは明確ではない。利用者に確認したところ，情
報は電信サービス経由で利用され，為替システムで
ILFとして計測されていることが分かる。それゆえ，
この規則に当てはまる。
為替システムは，人事情報システムに為替レートを提供するので，通貨の為替データのグループは人事
情報システムのEIFである。社員情報は既に，ILFとして識別されている。
7.7.3.4 RET及びDETの計測
DET及びRETを計測する。
DETについては，為替情報EIFに関連するデータ項目を調べ，DET識別規則に当てはまるかを決定する。
DET計測の分析の概要を次の表に示す。
EIFのDET計測規則
規則の該当・非該当
要素処理によってILF又はEIFが維持管理又は参照さ
れる，一意で繰返しのない利用者視点の1データ項目
を1DETとして計測する。
すべてのデータ項目は，利用者視点から見たものであ
る。
二つのアプリケーションが，同一のILF又はEIFを維
持管理及び／又は参照し，かつ，各々が異なったDET
を維持管理又は参照するとき，各々のアプリケーショ
ンが使用するDETだけを計測する。
このデータは，為替システムによって維持管理され
る。
他のILF又はEIFとの関係を定めるために利用者が要
求したデータ項目は，1DETとして計測する。
該当する種別のデータは，存在しない。
各データ項目に対して，1DETを計測する。
RETについては，RET識別規則に基づいてサブグループを識別する。
RET計測規則
規則の該当・非該当
ILF又はEIFの必す（須）サブグループ又は任意サブ
グループのそれぞれを1RETとして計測する。
為替情報は，一つの実体に含まれる。それゆえ，サブ
グループはない。
サブグループがない場合は，ILF又はEIFを1RETと
して計測する。
サブグループがないので，為替情報を一つのRETとし
て計測する。
58
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
サブグループはないので，為替情報EIFは，1RETとなる。
為替情報のRET及びDETを次の表に示す。
RET
DET
為替情報
為替レート
国名
合計
1RET
合計
2DET
7.7.4
事例3：他システムへのデータの提供
7.7.4.1 利用者要件
利用者は，為替システムに次の機能を要求している。
− 他の通貨から円への為替レートを維持管理する。
− 人事情報などの他のアプリケーションが，為替情報を取り出せるためのインタフェースを提供する。
7.7.4.2 EIFの識別
この事例では，為替情報が為替システムのEIFであるかを決める。この分析の概要を次の表に示す。
EIF識別規則
規則の該当・非該当
データ又は制御情報のグループは，論理的で利用者視
点によるものである。
当てはまる。
利用者は，必要なすべての社員データを人事情報シス
テムが維持管理できるようにするため，現地通貨の為
替レートが利用できることを要求している。
データのグループは，計測対象アプリケーションの外
部にあって参照されるものである。
当てはまらない。
為替システムは，計測される対象であり，為替レート
は，そのシステムで維持管理されている。
データのグループは，計測対象アプリケーションによ
って維持管理されない。
当てはまらない。
為替レートは，為替システム利用者によって維持管理
される。
EIFとして識別したデータのグループは，他のアプリ
ケーションのILFとして維持管理される。
現時点の情報だけでは，この規則が為替情報に当ては
まるかは明確ではない。利用者に確認したところ，情
報は電信サービス経由で利用され，為替システムで
ILFとして計測されていることが分かる。為替データ
は，計測対象の為替システムで維持管理されるので，
この規則は当てはまらない。
為替情報は，為替システムの外部ではない。したがって，為替システムのEIFとしては計測されない。
為替情報は，ILFに関する次の規則に基づき，為替システムのILFとなる。
− データは利用者視点に基づいた論理的なグループである。
− データは為替システム内で維持管理される。
− データは為替システムのILFである。
為替レートの参照がEIFとして計測される手順については，ここまでに説明された事例を参照する。
7.7.5
事例4：ヘルプ機能システム
7.7.5.1 利用者要件
利用者は，ヘルプ機能システムに次のことを要求する。
a) その画面で利用できる各事業機能を達成するための各画面の使用法を利用者のために説明するための
仕組み
b) 画面ヘルプの変更機能
c) 人事情報システムの各データ項目に対する定義，デフォルト値及び有効値の設定機能
d) （個別のデータ項目に対する）項目ヘルプの変更機能
59
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
e) 人事情報システムによる画面ヘルプ及び項目ヘルプを検索するための機能
7.7.5.2 データフロー図
この事例におけるデータフロー図を，図14に示す。
利用者
画面ヘルプ
項目ヘルプの変更
画面ヘルプの追加
画面ID, ヘルプ記述
画面ヘルプの変更
項目ヘルプの変更
項目ヘルプ情報の変更
項目ヘルプ
項目ヘルプの追加
項目ヘルプの追加
項目ID
ヘルプ記述
有効値
デフォルト値
画面ヘルプの変更
画面ヘルプの追加
画面ヘルプ情
報への変更
人事情報
システム
項目ID
ヘルプ記述
有効値
デフォルト値
図14−データフロー図
7.7.5.3 EIFの識別
人事情報システムに対する利用者要件から，二つのデータグループがある。
− 画面ヘルプ
− 項目ヘルプ
画面ヘルプが人事情報システムのEIFであるかを決定するための分析の概要を次の表に示す。
EIF識別規則
規則の該当・非該当
データ又は制御情報のグループは，論理的で利用者視
点によるものである。
当てはまる。
利用者は，一元管理された画面ヘルプの仕組みをカス
タマイズしたヘルプにすることを要求している。
データのグループは，計測対象アプリケーションの外
部にあって参照されるものである。
当てはまる。
人事情報システムの外部である。
データのグループは，計測対象アプリケーションによ
って維持管理されない。
当てはまる。
規則を適用する。
EIFとして識別したデータのグループは，他のアプリ
ケーションのILFとして維持管理される。
当てはまる。
画面ヘルプは，ヘルプシステムでILFとして計測され
ている。
画面ヘルプ情報が人事情報システムによって取り出されるので，画面ヘルプ情報は，人事情報システム
においてEIFとなる。画面ヘルプは，ヘルプシステムにおいて維持管理され，ヘルプシステムのILFとし
て計測される。
60
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
項目ヘルプがEIFであるかを決定するための分析の概要を次の表に示す。
EIF識別規則
規則の該当・非該当
データ又は制御情報のグループは，論理的で利用者視
点によるものである。
当てはまる。
利用者は，一元管理された画面ヘルプの仕組みをカス
タマイズしたヘルプにすることを要求している。
データのグループは，計測対象アプリケーションの外
部にあって参照されるものである。
当てはまる。
項目ヘルプは，ヘルプシステムで維持管理される。し
たがって，人事情報システムの外部である。
データのグループは，計測対象アプリケーションによ
って維持管理されない。
当てはまる。
EIFとして識別したデータのグループは，他のアプリ
ケーションのILFとして維持管理される。
当てはまる。
項目ヘルプ情報が人事情報システムによって取り出されるので，項目ヘルプ情報は，人事情報システム
においてEIFとなる。項目ヘルプ情報は，ヘルプシステムで維持管理され，ヘルプシステムのILFとして
計測される。
7.7.5.4 RET及びDETの計測
DET及びRETを計測する。
DETについては，画面ヘルプ及び項目ヘルプに関するデータ項目を調べ，DET計測規則を使用して，
DETを計測する。
画面ヘルプのデータ項目は，次のとおりである。
− 画面ID
− 業務機能の説明
画面ヘルプに対するDETの分析を次の表に示す。
EIFのDET計測規則
規則の該当・非該当
要素処理によってILF又はEIFを維持管理又は参照さ
れる，一意で繰返しのない利用者視点の1データ項目
を1DETとして計測する。
すべてのデータ項目は，利用者視点から見たものであ
る。
二つのアプリケーションが，同一のILF又はEIFを維
持管理及び／又は参照し，かつ，各々が異なったDET
を維持管理又は参照するとき，各々のアプリケーショ
ンが使用するDETだけを計測する。
このデータは，ヘルプシステムで維持管理される。
他のILF又はEIFとの関係を定めるために利用者が要
求したデータ項目は，1DETとして計測する。
この規則に当てはまるデータはない。
項目ヘルプのデータ項目は，次のとおりである。
− 画面ID
− 項目ID
− 項目の説明
− デフォルト値
− 有効値
項目ヘルプのDETの分析を次の表に示す。
EIFのDET計測規則
規則の該当・非該当
要素処理によってILF又はEIFを維持管理又は参照さ
れる，一意で繰返しのない利用者視点の1データ項目
を1DETとして計測する。
すべてのデータ項目は，利用者視点から見たものであ
る。
61
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
二つのアプリケーションが，同一のILF又はEIFを維
持管理及び／又は参照し，かつ，各々が異なったDET
を維持管理又は参照するとき，各々のアプリケーショ
ンが使用するDETだけを計測する。
このデータは，ヘルプシステムで維持管理される。
他のILF又はEIFとの関係を定めるために利用者が要
求したデータ項目は，1DETとして計測する。
この規則に当てはまるデータはない。
RETについては，RET計測規則に基づいてサブグループを識別する。
RET計測規則
規則の該当・非該当
ILF又はEIFの必す（須）サブグループ又は任意のサ
ブグループのそれぞれを1RETとして計測する。
画面ヘルプ又は項目ヘルプのどちらにもサブグルー
プはない。
サブグループがない場合は，ILF又はEIFを1RETと
して計測する。
サブグループがないので，各EIF（画面ヘルプ及び項
目ヘルプ）は，1RETとして計測する。
サブグループがないので，ヘルプ情報は，各EIFに対して1RETだけとなる。
画面ヘルプEIFに対してRET及びDETの合計を次の表に示す。
RET
DET
画面ヘルプ情報
画面ID
業務機能の説明
合計
1RET
合計
2DET
項目ヘルプEIFに対してRET及びDETの合計を次の表に示す。
RET
DET
項目ヘルプ情報
画面ID
項目ID
項目の説明
デフォルト値
有効値
合計
1RET
合計
5DET
7.7.6
事例5：データ変換
7.7.6.1 利用者要件
ある組織が新規に人事情報システムのパッケージを購入した場合，その組織は，社員ファイルを既存の
人事情報システムから新システムにデータ移行することを要求している。
旧システムは，社員の扶養家族情報を維持管理する機能をもっていない。そのため，既存の社員ファイ
ルを新システムに移行するときに，扶養家族情報は初期化される。
7.7.6.2 データモデル
新・旧システムのデータモデルを，図15に示す。
62
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
人事情報システム
新
人事情報システム
旧
正社員
派遣社員
社員
扶養家族
正社員
派遣社員
社員
凡例:
属性実体型
実体型
任意の一対多の関係
実体副型
図15−データモデル図
新人事情報システムに社員情報を追加するため，旧人事情報システムの社員ファイルを使用する。
7.7.6.3 EIFの識別
利用者要件から，旧社員情報ファイルがEIFであるかを決定する。分析の概要を次の表に示す。
EIF識別規則
規則の該当・非該当
データ又は制御情報のグループは，論理的で利用者
視点によるものである。
当てはまらない。
旧社員情報ファイルは，利用者の観点から論理的な
データのグループではない。
データのグループは，計測対象アプリケーションの
外部にあって参照されるものである。
当てはまらない。
旧社員情報ファイルは，システムの外部にあるが，
参照されない。しかし，更新用データとして使われ
る。
データのグループは，計測対象アプリケーションに
よって維持管理されない。
当てはまる。
旧社員情報ファイルは，人事情報システムで維持管
理される。
EIFとして識別したデータのグループは，他のアプリ
ケーションのILFとして維持管理される。
当てはまる。
旧社員情報ファイルは，旧人事情報システムのILF
として維持管理される。
社員情報のファイルは，新システムに移行される社員情報のトランザクション ファイルとなる。変換処
理は，新人事情報システムのアプリケーション境界の内部に入った後，社員情報を維持管理する。
旧社員情報ファイルは，新人事情報システムの利用者の観点から，論理的なデータのグループではない。
したがって，EIFではない。旧社員情報ファイルを外部入力として計測する方法を知るためには箇条8を
参照する。
7.7.7
事例6：トランザクション 入力ファイル
7.7.7.1 利用者要件
利用者は，次の機能を要求している。
任意の1対多の関係
63
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− オンラインによる業務情報の追加，更新，削除，照会及び報告書作成。
− バッチ方式での業務情報の追加及び更新。
7.7.7.2 レコードレイアウト
バッチ方式での業務情報の追加及び更新におけるレコードレイアウトを，図16に示す。
図16−レコードレイアウト
7.7.7.3 レコード内容
各レコード型の内容を，表6に示す。
表6−レコードレイアウト一覧
レコード
カラム位置
データ項目
01
1〜3
トランザクション ファンクション型
業務
4〜5
レコード型
6〜10
業務番号
11〜45
業務名
46〜47
給与等級
02
1〜3
トランザクション ファンクション型
業務説明
4〜5
レコード型
6〜10
業務ID
11〜12
業務内容説明行番号
13〜41
業務内容説明行
7.7.7.4 EIFの識別
利用者要件からトランザクション ファイルがEIFであるかを決定する。分析の概要を次の表に示す。
EIF識別規則
規則の該当・非該当
データ又は制御情報のグループは，論理的で利用者視
点によるものである。
当てはまる。
データは，業務ILFを維持管理するためにアプリケー
ション境界の内部に存在するトランザクションに分
類される。
64
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
データのグループは，計測対象アプリケーションの外
部にあって参照されるものである。
当てはまる。
トランザクション ファイルは，処理されるアプリケ
ーション境界の外部に存在する。
データのグループは，計測対象アプリケーションによ
って維持管理されない。
当てはまる。
このデータは，維持管理されない。
EIFとして識別したデータのグループは，他のアプリ
ケーションのILFとして維持管理される。
当てはまらない。
業務ILFを更新するためにアプリケーション境界の内
部に存在するトランザクションは，要素処理を構成す
る。トランザクションファイルを更新する要素処理は
存在しない。
この事例ではEIFは存在しない。トランザクション入力ファイルを外部入力として計測する方法を知る
ためには箇条8を参照する。
7.7.8
事例7：異なる利用者及び／又は異なる利用者記述
7.7.8.1 利用者要件
人事情報システムの利用者は，新入社員の情報を維持管理することを要求している。
人事情報システムによって維持管理されるデータは，次のとおりである。
− 社員ID
− 社員氏名
− 社員住所
− 社員給与等級
− 社員業務名称
新入社員レコードの作成に伴い，社員の年金受給資格日が自動計算され，他の社員情報とともに保存さ
れる。
年金システムの利用者は，年金受給資格予定日で社員一覧を作成することができることを要求している。
7.7.8.2 データフロー図
この事例のデータフロー図を，図17に示す。
利用者
社員の
生成
社員ID
社員氏名
社員住所
社員給与等級
業務名称
年金受給資格日
Screen
社員
利用者
社員ID
社員氏名
社員住所
社員給与等級
社員職位
年金受給資格日
セキュリティレベル
社員一覧の
印刷
社員氏名
年金受給資格日
人事情報システム
年金システム
図17−データフロー図
65
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
7.7.8.3 EIFの識別
ここまでに説明した人事情報システムの事例から，社員情報は，人事情報システムのEIFではないこと
が分かっている。
人事情報が年金システムのEIFであるかを決定するための分析の概要を，次の表に示す。
EIF識別規則
規則の該当・非該当
データ又は制御情報のグループは，論理的で利用者視
点によるものである。
当てはまる。
データ項目は，年金システムの利用者によって理解さ
れている。
データのグループは，計測対象アプリケーションの外
部にあって参照されるものである。
当てはまる。
すべてのデータは，年金アプリケーションの外部にあ
る。
データのグループは，計測対象アプリケーションによ
って維持管理されない。
当てはまる。
データは，年金アプリケーションでは維持管理されな
い。
EIFとして識別したデータのグループは，他のアプリ
ケーションのILFとして維持管理される。
当てはまる。
データは，人事情報システムによって維持管理され
る。
社員情報は，年金システムでのEIFとして，すべての要件に当てはまる。
7.7.8.4 RET及びDETの計測
DET及びRETを計測する。
DETについては，年金システムでの社員情報EIFに関連するデータ項目を調べ，DETを計測するために，
DET計測規則を使用する。
社員情報のデータ項目は，次のとおりである。
− 社員ID
− 社員氏名
− 社員住所
− 社員給与等級
− 社員業務名称
− 年金受給資格日
年金システムでの社員情報のDET分析を，次の表に示す。
EIFのDET計測規則
規則の該当・非該当
要素処理によってILF若しくはEIFを維持管理してい
るか，又はILF若しくはEIFから参照される，一意で
繰返しのない利用者視点のデータ項目を1DETとして
計測する。
年金システムの利用者は，社員氏名及び年金受給資格
日だけを認識する。
二つのアプリケーションが，同一のILF又はEIFを維
持管理及び／又は参照し，かつ，各々が異なったDET
を維持管理又は参照する場合，各々のアプリケーショ
ンが使用するDETだけを計測する。
年金システムは，社員氏名及び年金受給資格日だけを
使用する。
他のILF又はEIFとの関係を定めるために利用者が要
求したデータ項目を1DETとして計測する。
該当する種別のデータはない。
年金システムでの社員情報EIFのデータ項目は，次のとおりである。
− 社員氏名
− 年金受給資格日
RETについては，RET計測規則に基づいてサブグループを識別する。
66
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
RET計測規則
規則の該当・非該当
EIF又はEIFの必す（須）又は任意のサブグループを
それぞれ1RETとして計測する。
サブグループはない。
サブグループがない場合は，ILF又はEIFを1RETと
して計測する。
サブグループはないので，各EIFに対して1RETと計
測する。
サブグループがないので，社員情報は，1RETだけとなる。
年金システムでの社員情報EIFに対するRET及びDETの合計は，次の表のとおりになる。
RET
DET
社員情報
社員氏名
年金受給資格日
合計
1RET
合計
2DET
7.7.9
事例8：同一データの複数目的での利用
7.7.9.1 利用者要件
利用者は，人事情報システムに，全社員の一覧を作成する機能を要求している。
各社員について，次の情報を表示しなければならない。
− 社員ID
− 社員氏名
7.7.9.2 データフロー図
この事例のデータフロー図を，図18に示す。
利用者
社員の
生成
社員ID
社員氏名
社員住所
給与等級
業務名称
年金受給資格日
Screen
社員
社員ID
社員氏名
社員住所
給与等級
業務名称
年金受給資格日
セキュリティレベル
社員一覧の
印刷
社員ID
社員氏名
人事情報システム
図18−データフロー図
7.7.9.3 EIFの識別
社員一覧を作成するために使用される社員情報が，人事情報システムのEIFであるかを決定するために
分析の概要を次の表に示す。
67
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
EIF識別規則
規則の該当・非該当
データ又は制御情報のグループは，論理的で利用者視
点によるものである。
当てはまる。
すべてのデータは，利用者によって理解されている。
データのグループは，計測対象アプリケーションの外
部にあって参照されるものである。
当てはまらない。
データ及び社員一覧表の作成処理は，人事情報システ
ムの外部ではない。
データのグループは，計測対象アプリケーションによ
って維持管理されない。
当てはまらない。
データは，人事情報システムで維持管理される。
EIFとして識別したデータのグループは，他のアプリ
ケーションのILFとして維持管理される。
対象外。
社員情報を作成するために使用される社員一覧情報は，人事情報システムのEIFではない。
7.7.10 計測したEIF，RET及びDETの概要
ここでは，未調整ファンクションポイントに対する複雑さ及び寄与を計算する前に，計測されたEIF，
RET及びDETの概要を示す。
7.7.10.1 識別したEIFの概要
人事情報システムのEIFを次に示す。この表には，計測しないデータも含んでいる。
識別したEIF
計測対象外
事業所情報
為替情報
画面ヘルプ情報
項目ヘルプ情報
旧人事情報システム社員データ
トランザクション入力ファイル
社員一覧情報
年金システムのEIFを次の表に示す。この表には，計測しないデータも含んでいる。
識別したEIF
計測対象外
社員情報
7.7.10.2 RET及びDETの計測の概要
人事情報システムのRET及びDETの数を次の表に示す。
EIF
RET
DET
事業所情報
為替情報
画面ヘルプ情報
項目ヘルプ情報
1
1
1
1
6
2
2
5
年金システムのRET及びDETの数を次の表に示す。
EIF
RET
DET
社員情報
1
2
7.7.11 EIFの複雑さ及び寄与
ここでは，未調整ファンクションポイントに対するEIFの複雑さ及び寄与を決定するための最終手順を
示す。
最終手順は，次のとおりである。
a) EIFの複雑さを判定する。
b) 複雑さを未調整ファンクションポイントへ変換する。
c) 未調整ファンクションポイントへのEIFの寄与を計算する。
7.7.11.1 EIFの複雑さ判定
ファンクションの複雑さは，低，中又は高で判定される。次に示すRET及びDETの複雑さ判定表によ
って，EIFの複雑さを判定する。
68
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
1〜19DET
20〜50DET
51DET以上
1RET
低
低
中
2〜5RET
低
中
高
6RET以上
中
高
高
人事情報システム内での各EIFについて，ファンクションの複雑さを次の表に示す。
EIF
RET
DET
複雑さ
事業所情報
1
6
低
為替情報
1
2
低
画面ヘルプ情報
1
2
低
項目ヘルプ情報
1
5
低
7.7.11.2 各EIFのファンクションポイントへの変換
次の表を使用して，ファンクションの複雑さを未調整ファンクションポイントへ変換する。
ファンクションの複雑さ評価
未調整ファンクションポイント
低
5
中
7
高
10
この複雑さを次の表へ記入する。
7.7.11.3 EIF寄与の算出
人事情報システム内でのEIFファンクション型の寄与を次の表に示す。
ファンクション型
ファンクションの複雑さ 複雑さの合計
ファンクション型の合計
EIF
4 低 × 5
＝ 20
0 中 × 7
＝
0
0 高 × 10 ＝
0
20
すべてのファンクション型を集計する表にこの合計値を記入する。すべてのファンクション型の値の最
終合計が，未調整ファンクションポイントとなる。
8
トランザクション ファンクションの計測
トランザクション ファンクションは，データを処理するためにシステムが利用者に提供する機能を表す。
トランザクション ファンクションには，EI，EO及びEQがある。
ここでは，EI，EO及びEQの各トランザクション ファンクションを定義し，対応するファンクション
ポイント計測規則及び計測手順を示す。さらに，それぞれのファンクションの詳細な事例を示す。
8.1
EI，EO及びEQの定義
ここでは，EI，EO及びEQを定義する。これらの定義で使用する用語も定義し，適宜，事例を示す。
8.1.1
EI
計測対象のアプリケーション境界の外部から入力されるデータ又は制御情報を処理する要素処理。EIは，
一つ以上のILFの維持管理及び／又はシステムの振る舞いの変更を主目的とする。
8.1.2
EO
計測対象のアプリケーション境界の外部にデータ又は制御情報を出力する要素処理。EOは，データ又
は制御情報の取り出しの有無にかかわらず，処理ロジックによって加工した情報を利用者に提供すること
を主目的とする。EOは，処理ロジックに少なくとも一つの“数式又は演算の実行”又は導出データの生
成を含まなければならない。EOは，一つ以上のILFの維持管理及び／又はシステムの振る舞いの変更を
行ってもよい。
69
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
8.1.3
EQ
計測対象のアプリケーション境界の外部にデータ又は制御情報を送り出す要素処理。EQは，ILF又は
EIFからデータ又は制御情報を取り出すことによって利用者に情報提供することを主目的とする。EQは，
処理ロジックに“数式又は演算の実行”を含まない。さらに，導出データを生成しない。処理中にILFを
維持管理せず，システムの振る舞いの変更も行わない。
8.1.4
EI，EO及びEQの概要
トランザクション ファンクション型間の主な違いは，主目的の違いである。表7に各トランザクション
ファンクション型で実行できる機能を要約し，各々の主目的を示す。EIについての主目的に注意する。こ
れは，EO及びEQとの主要な違いである。EOとEQとの主な違いは，EOは，利用者への情報提供という
主目的を実行するとき，システムの振る舞いを変更する機能又は一つ以上のILFの維持管理を行う機能を
実行できることにある。両者のその他の違いについては，各トランザクション ファンクションが使用する
処理ロジックの様式を8.2〜8.9で示す。
表7−EI，EO及びEQの概要表
機能
トランザクション ファンクション型
EI
EO
EQ
システムの振る舞いの変更
主目的
副目的
不可
一つ以上のILFの維持管理
主目的
副目的
不可
利用者への情報提供
副目的
主目的
主目的
凡例：主目的 トランザクション ファンクション型が主目的とする機能
副目的 トランザクション ファンクション型の機能であるが，副次的な機能で，時々提供される機能
不可 トランザクション ファンクション型では使用しない機能
8.1.5
EI，EO及びEQの定義で使用している用語の定義
8.1.5.1 要素処理
利用者にとって意味のある業務活動の最小単位。
例1 システムに新しい社員を追加する利用者機能要件の例を示す。利用者が定義する社員の個人デ
ータには，給与情報及び扶養家族情報を含む。この場合，利用者の観点からの業務活動の最小
単位は，新入社員を追加することになる。給与情報，扶養家族情報などの情報の一部追加は，
要素処理とみなせる業務活動ではない。
要素処理は，自己完結しており，かつ，計測対象のシステムの業務を矛盾のない状態にするものでなけ
ればならない。
例2 社員の追加という利用者要件には，給与情報及び扶養家族情報の設定を含む。社員情報のすべ
てを追加しないうちは，社員情報は生成されない。情報の一部だけの追加では，社員を追加す
るという業務は矛盾のない状態になっていない。社員の給与情報及び扶養家族情報の両方を追
加すると，この一連の業務は完了し，業務は矛盾のない状態になる。
8.1.5.2 制御情報
計測対象アプリケーションの要素処理に影響を及ぼすデータ。対象となるデータ，処理時期及び／又は
処理方法を指定する。
例 給与課の担当者は，事業所ごとに社員にいつ給与の支払をするかという支払計画を立てるために
支払サイクルを決める。支払のサイクル，又は支払計画は，給与支払の要素処理をいつ起動する
かに影響を与えるタイミング情報を含んでいる。
70
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
8.1.5.3 維持管理された
要素処理によってデータが追加，更新又は削除されている状態。
例 追加，変更，削除，増加，修正，更新，割当て，作成などがあるが，これに限定しない。
8.1.5.4 利用者
次のいずれか又は両方。
− 利用者機能要件を規定する人
− ソフトウェアとやり取りをする人若しくはもの又は相互に影響し合う人若しくはもの
例 事例には，社員を追加するために人事情報システムを操作する人事部の担当者，及び社員の扶養
家族情報を受け取るために人事情報システムを操作する福利厚生システムの担当者を含む。
8.1.5.5 処理ロジック
妥当性確認，アルゴリズム，計算，ファイルの参照・維持管理など，要素処理の実行に関する利用者要
件。要件には，次の活動を含む。
a) 妥当性確認の実行
例 新入社員を組織に追加するとき，社員追加処理は，追加する情報の妥当性を確認する処理ロジ
ックをもっている。
b) 数式又は演算の実行
例 組織の全社員について報告する場合，処理には，正社員数，非正社員数及び合計社員数の計算
を含む。
c) 等値変換の実行
例 要素処理は，日本円から他の通貨に変換するために為替レートを参照する。この変換は，表か
ら数値を取り出すことで達成できるので，計算は必要でない。
d) データの複数の組を比較するために特定の基準を使用してデータを抽出及び選択する。
例 業務割当てによって社員一覧表を作成するために，要素処理は，選択のために業務番号を比較
し，その業務割当てを使用して適切な社員を選び出す。
e) どちらを適用するかを決めるために条件を分析する。
例 社員を追加するとき，かつ，支払が正社員，非正社員のどちらかとなるときに要素処理によっ
て実行される処理ロジック。
f)
一つ以上のILFの更新
例 社員を追加するとき，要素処理は，社員データを維持管理するために社員情報ILFを更新する。
g) 一つ以上のILF又はEIFの参照
例 社員を追加するとき，為替情報EIFを参照し，正確な日本円との為替レートを使用して社員の
時間単価を決める。
h) データ又は制御情報の取得
例 支払可能な給与等級の一覧を見るために，給与等級情報を取得する。
i)
追加データを生成するために，既存データを変換することによって導出データを生成する。
例 患者の登録番号（ここでは，NIHTA01とする。）を決定（導出）するために，次のデータをつ
なぎ合わせる。
− 患者の姓の上3文字（NIHONの場合，NIH）
− 患者の名の上2文字（TAROの場合，TA）
− 重複のない2けた（桁）の連番（01から始める。）
71
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
j)
システムの振る舞いの変更
例 給与支払日が，“毎月15日及び月の最終日”から“隔週の金曜日”に変更する場合，給与支払
の要素処理の振る舞いを変更する。
k) アプリケーション境界の外部への情報の準備及び提供
例 利用者に社員一覧を提供する。
l)
アプリケーション境界の内部へ入力されるデータ又は制御情報を受け取る能力がある。
例 顧客の注文をシステムに追加するため，利用者は幾つかのデータを入力する。
m) データの再構築又は再配列
例 利用者は，アルファベット順の社員一覧を要求する。
注記 データの再構築又は再配列は，トランザクション ファンクションの型の識別すること又は重
複がないことに影響を与えない。
8.1.6
EI，EO及びEQが使用する処理ロジックの概要
EI，EO及びEQがどの処理ロジックを実行するかの概要を，表8に示す。各トランザクション ファン
クション型に対して，それぞれトランザクション ファンクション型の主目的を達成するために，実行しな
ければならない処理ロジックがある。
表8−処理ロジックの概要表
処理ロジックの定型手順
トランザクション ファンクション型
EI
EO
EQ
1 妥当性確認の実行
可能
可能
可能
2 数式又は演算の実行
可能
必す（須）
（最低一つ）
不可
3 等値変換の実行
可能
可能
可能
4 データの複数の組を比較するための特定の基準を使用し
たデータの抽出及び選択
可能
可能
可能
5 どちらを適用するかを決めるための条件の分析
可能
可能
可能
6 一つ以上のILFの更新
必す（須）
（最低一つ）
必す（須）
（最低一つ）
不可
7 一つ以上のILF又はEIFの参照
可能
可能
必す（須）
8 データ又は制御情報の取得
可能
可能
必す（須）
9 既存データの変換による導出データの生成
可能
必す（須）
（最低一つ）
不可
10 システムの振る舞いの変更
必す（須）
（最低一つ）
必す（須）
（最低一つ）
不可
11 アプリケーション境界の外部への情報の提供
可能
必す（須）
必す（須）
12 アプリケーション境界の内部へ入力されるデータ又は
制御情報の受入れ能力
必す（須）
可能
可能
13 データの再構築又は再配列
可能
可能
可能
凡例：必す（須）
この処理ロジックを必ず実行しなければならない。
必す（須）（最低一つ） これらに属する処理ロジックのうち最低一つは実行しなければならない。
可能
この処理ロジックの定型手順を実行してもよいが，必す（須）ではない。
不可
この処理ロジックの定型手順を実行してはならない。
72
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
8.2
EI，EO及びEQの計測規則
ここでは，EI，EO及びEQを計測するときに適用する規則を定義する。
8.2.1
計測手順の概要
ここでは，EI，EO及びEQの計測手順に関連する規則の概要を示す。
注記 計測手順の詳細は，EI，EO及びEQの計測手順に示す。
EI，EO及びEQの計測手順には，次の手順を含む。
手順
作業内容
1
要素処理を識別する。
2
識別した要素処理の主目的を決定し， EI，EO又はEQに従って分類する。
3
要素処理がEI，EO又はEQの識別規則に当てはまるか妥当性を調べる。
4
EI，EO又はEQの複雑さを決める。
5
未調整ファンクションポイントに対するEI，EO又はEQの寄与を決める。
8.2.2〜8.2.4で，規則を説明する。
8.2.2
要素処理の識別規則
要素処理を識別するために，システムで発生している利用者の作業を洗い出す。
処理が要素処理として識別されるためには，次の識別規則はすべて適用されなければならない。
a) その処理は，利用者にとって意味のある業務活動の最小単位である。
b) その処理は，自己完結しており，システムの業務を矛盾のない状態にする。
8.2.3
トランザクション ファンクションの識別規則
各要素処理を分類するためには，その主目的記述のどれを適用するかを決定し，関連する識別規則を使
用してどのトランザクション ファンクション型であるかを識別する。
8.2.3.1 EIの主目的
要素処理は，ILFの維持管理又はシステムの振る舞いの変更を主目的とする。
8.2.3.2 EI識別規則
一つ以上のILFの維持管理又はシステムの振る舞いの変更を主目的とする各要素処理について，機能が
EIかを決定するために，次の規則を適用する。要素処理を他のEIと重複のないEIとして計測するために
は，次の識別規則をすべて適用する。
a) データ又は制御情報は，アプリケーション境界の外部から入力される。
b) アプリケーション境界の外部から入力されるデータがシステムの振る舞いを変更する制御情報でない
場合，少なくとも一つのILFを維持管理する。
c) 識別した処理に対して，次の三つのうちいずれか一つを適用する。
− 処理ロジックが，このアプリケーションの他のEIによって実行された処理ロジックと異なってい
る。
− 識別したデータ項目の組が，このアプリケーションの他のEIについて識別されたデータ要素と異な
っている。
− 参照するILF又はEIFが，このアプリケーションの他のEIについて識別された参照するILF又は
EIFと異なっている。
8.2.3.3 EO及びEQの主目的
EO及びEQは，利用者に情報を提供することを主目的とする。
8.2.3.4 EO及びEQ共通の識別規則
利用者に情報を提供することを主目的とする各要素処理について，その要素処理がEO又はEQに該当
73
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
するかを決定するために，次の規則を適用する。要素処理を他と重複のないEO又はEQとして計測する
ためには，次の識別規則をすべて適用する。
a) アプリケーション境界の外部へデータ又は制御情報を出力する機能である。
b) 識別した処理に対して，次の三つのうちいずれか一つを適用する。
− 処理ロジックが，このアプリケーションの他のEO又はEQによって実行された処理ロジックと異
なっている。
− 識別したデータ要素の組が，このアプリケーションの他のEO又はEQについて識別されたデータ
要素と異なっている。
− 参照するILF又はEIFが，このアプリケーションの他のEO又はEQについて識別された参照する
ILF又はEIFと異なっている。
8.2.3.5 EO独自の識別規則
EO及びEQ共通の識別規則に加えて，要素処理が重複のないEOとして計測されるためには，次の四つ
のうちいずれか一つを適用する。
− 要素処理の処理ロジックが，少なくとも一つの“数式又は演算の実行”を含む。
− 要素処理の処理ロジックが，導出データを生成する。
− 要素処理の処理ロジックが，少なくとも一つのILFを維持管理する。
− 要素処理の処理ロジックが，システムの振る舞いを変更する。
8.2.3.6 EQ独自の識別規則
EO及びEQ共通の識別規則に加えて，要素処理が重複のないEQとして計測されるためには，次の識別
規則をすべて適用する。
− 要素処理の処理ロジックは，データ又は制御情報をILF又はEIFから取得する。
− 要素処理の処理ロジックは，“数式又は演算の実行”を含まない。
− 要素処理の処理ロジックは，導出データを生成しない。
− 要素処理の処理ロジックは，ILFを維持管理しない。
− 要素処理の処理ロジックは，システムの振る舞いを変更しない。
8.2.4
複雑さ及び寄与の定義及び規則
EI，EO及びEQの数並びに相対的な機能の複雑さによって，未調整ファンクションポイントへのトラン
ザクション ファンクションの寄与の合計値が決まる。
関連ファイル数（FTR）及びデータ項目数（DET）を基にして，それぞれの識別されたEI，EO及びEQ
にファンクションの複雑さを割り当てる。
8.2.4.1 FTRの定義
FTRは，次のいずれか又は両方である。
− トランザクション ファンクションで参照又は維持管理されるILFの数
− トランザクション ファンクションで参照されるEIFの数
8.2.4.2 DETの定義
利用者視点に基づき，重複も繰返しもない，論理的データの最小単位。
8.2.4.3 EIの複雑さ及び寄与の決定の規則
ここでは，EIの複雑さ及び寄与を決定するために使用するFTR及びDETの規則を定義する。
8.2.4.4 EIのFTR規則
FTR計測時には，次の規則を適用する。
74
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 維持管理されるILFは，1FTRと計測する。
− EIの処理時に参照されるILF又はEIFは，1FTRと計測する。
− 一つのEIの処理時に維持管理され，かつ，参照されるILFは，1FTRとだけ計測する。
8.2.4.5 EIのDET規則
DET計測時には，次の規則を適用する。
a) 次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の外部から入力される又はアプリケーション境界の内部から出力される。
− EI処理を完了するために必要である。
例1 業務名及び給与支払等級は，業務を登録するときに利用者が入力する二つのDETである。
b) システムによって取得又は導出されるデータ項目，及びILFに格納されるデータ項目で，要素処理の
実行中にそのデータ項目がアプリケーション境界をまたがらない場合は，DETとしては計測しない。
例2 顧客注文をシステムに追加するとき，単価は，各注文商品ごとに自動的に取り込まれ，請求
書ファイルに保存される。利用者が顧客注文を追加するときにアプリケーション境界をまた
がらないので，単価はEIのDETとしては計測しない。
例3 日本円以外の通貨の国で働いている非正社員に対して，円建ての時給を設定するために，そ
の国の時給が利用者によって入力される。この設定に当たり，社員の個人データを追加する
ために提供される入力データのすべてを処理するときに，為替レートが為替システムから取
得され，円建ての時給が計算される。算出した円建ての時給は，社員の個人データ追加の結
果として社員情報ILFで維持管理される。この場合の円建ての時給はアプリケーション境界
をまたがらないが，内部的に計算する（すなわち，導出データである）ので，EIのDETと
しては計測しない。
c) 処理中のエラー発生の通知，処理の完了確認又は処理続行の確認のために，アプリケーション境界の
外部にシステム応答メッセージを出力する機能を1DETと計測する。
例4 利用者が，既に登録している社員を人事情報システムに登録しようとしたとき，システムは
エラーメッセージを表示し，誤っている項目を強調表示する。このような場合の，エラー状
況の表示，処理の完了又は処理続行の確認を行うすべてのシステム応答を要約して，1DET
と計測する。
d) 同一の論理的処理を起動する手法が複数ある場合でも，実施する活動を指定する機能を1DETと計測
する。
例5 OKボタンのクリック又はファンクションキーの押下によって，利用者が社員追加を起動で
きる場合，その処理を起動する活動を1DETと計測する。
8.2.4.6 EO及びEQの複雑さ及び寄与の決定の規則
ここでは，EO及びEQの複雑さ及び寄与の決定に使用するFTR及びDETの規則を定義する。
8.2.4.7 EO及びEQに共通のFTR規則
次の規則は，EO及びEQ両方のFTR計測時に適用する。
− 要素処理の実行時に参照される各ILF又は各EIFは，1FTRと計測する。
8.2.4.8 EO独自のFTR規則
EOのFTR計測時に，EO及びEQ共通規則に加えて，次の規則を適用する。
75
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− 要素処理の実行時に維持管理される各ILFは，1FTRと計測する。
− 要素処理の実行時に維持管理され，かつ，参照される各ILFは，1FTRとだけ計測する。
8.2.4.9 EO及びEQの共通のDET規則
次の規則は，EO及びEQの両方のDET計測時に適用する。
a) 次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の外部から入力される。
− 要素処理がデータをいつ，何を，どのように取得又は生成するかを特定するために必要である。
例1 （EO及びEQの場合） 社員一覧表を作成する場合，社員氏名は，どの社員を表に記入す
るかを指定するときに利用者が提供するデータ項目である。
b) 次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の内部から出力される。
例2 （EO及びEQの場合） テキストメッセージは，単語，文又は句（例えば，注釈的な意見
を示すために報告書に記載された1行又は1段落）であってもよいが，1DETと計測する。
例3 （EO及びEQの場合） 物理的に複数項目に保存された口座番号又は日付は，ひとまとま
りの情報として要求されている場合，1DETと計測する。
例4 （EO及びEQの場合） 円グラフが，図形の出力表現として分類名称及び数値相当量で表
される場合，分類の指定で1DET，数値で1DET，合計で2DETと計測する。
c) あるDETがアプリケーション境界の外部から入力され，外部にも出力される場合，その要素処理に対
して1DETとだけ計測する。
d) 処理中のエラー発生の通知，処理の完了確認又は処理続行の確認のために，アプリケーション境界の
外部にシステム応答メッセージを出力する機能を1DETと計測する。
例5 （EO及びEQの場合） 利用者が名簿に記入することを要求するが，情報を読み書きでき
ない場合，それを知らせるシステム応答を1DETと計測する。
e) 同一の論理的処理を起動する手段が複数ある場合でも，実施する活動を指定する機能を1DETと計測
する。
例6 （EO及びEQの場合） OKボタンのクリック又はファンクションキーの押下によって，利
用者が社員追加を起動できる場合，その処理を起動する活動を1DETと計測する。
f)
システムによって取得又は導出されるデータ項目，及びILFに格納されるデータ項目で，要素処理の
実行中にそのデータ項目がアプリケーション境界をまたがらない場合は，DETとしては計測しない。
例7 （EOの場合） 給与支払小切手を印刷するとき，小切手の印刷済みを示すために，社員情
報ILFの状態項目を更新する。この場合，状態項目は，アプリケーション境界をまたがらな
いので，DETとして計測しない。
g) 文字列はDETとしては計測しない。
例8 （EO及びEQの場合） 帳票のタイトル，画面名称又はパネルの名称，欄見出し，項目名
称などの文字列は，DETとして計測しない。
h) ページ変数又はシステムが生成する日時・時刻情報は，計測しない。
76
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
例9 （EO及びEQの場合） システムが生成する変数及び日時・時刻情報の例としては，次の
ものがある。
− ページ番号
− “211列中の37列〜54列”のような位置情報
− GUIアプリケーションの前ページ，次ページ及びページ指定のようなページコマンド
− 表示できる場合の表示日時
8.3
EI，EO及びEQの計測手順
ここでは，EI，EO及びEQを計測する手順を，図19に示す。
トランザクション ファンクション
型の識別
要素処理の識別 1
要素処理の主目的の識別及び分類
（EI，EO又はEQ） 2
利用者に情報を提供する機能
ILFの維持管理又はシステムの振
る舞いの変更の機能
次を実施しない。
− 数式又は演算の実行
− データの導出
− ILFの更新
− システムの振る舞いの変更
次を実施する。
− 数式又は演算の実行
− データの導出
− ILFの更新
− システムの振る舞いの変更
要素処理がEI識別規則に
当てはまるかの確認
3
要素処理がEQ識別規則に当て
はまるかの確認 3
要素処理がEO識別規則に当て
はまるかの確認 3
EIの複雑さの決定
4
EQの複雑さの決定 4 EOの複雑さの決定 4 EIの寄与の決定 5
EQの寄与の決定 5 EOの寄与の決定 5
図19−計測手順図
8.3.1及び8.3.2で，各作業内容の手順を説明する。
8.3.1
識別及び計測手順
次の手順で，EI，EO及びEQを識別する。
手順
作業内容
適用規則
1
要素処理の識別
要素処理の識別規則
2
要素処理の主目的の識別及びEI，EO又はEQとし
ての分類
トランザクション ファンクション型の識別規則
− EIの主目的
− EO及びEQの主目的
ILFの維持管理又はシステムの振る舞いの変更を主目的とする場合，要素処理に対して次を適用する。
77
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
3
要素処理がEI識別規則に当てはまるかの確認
トランザクション ファンクション型の識別規則
− EI識別規則
4
EIの複雑さの決定
複雑さ及び寄与の手順を参照
5
EIの寄与の決定
複雑さ及び寄与の手順を参照
主目的が，利用者への情報提供であり，かつ，“数式又は演算の実行”，データの導出又は“ILFの更新又はシステ
ムの振る舞いの変更”のいずれかがある場合，要素処理に対して次を適用する。
3
要素処理がEO識別規則に当てはまるかの確認
トランザクション ファンクション型の識別規則
− EO及びEQ共通の識別規則
− 追加のEO識別規則
4
EOの複雑さの決定
複雑さ及び寄与の手順を参照
5
EOの寄与の決定
複雑さ及び寄与の手順を参照
主目的が，利用者への情報提供であり，かつ，“数式又は演算の実行”，データの導出又は“ILFの更新又はシステ
ムの振る舞いの変更”のいずれもない場合，要素処理に対して次を適用する。
3
要素処理がEQ識別規則に当てはまるかの確認
トランザクション ファンクション型の識別規則
− EO及びEQ共通の識別規則
− 追加のEQ識別規則
4
EQの複雑さの決定
複雑さ及び寄与の手順を参照
5
EQの寄与の決定
複雑さ及び寄与の手順を参照
8.3.2
複雑さ及び寄与の計測手順
次の手順で，EI，EO及びEQの複雑さ及び未調整ファンクションポイントへの寄与を計算する。
手順
複雑さの手順
4
EIの場合：
EIの複雑さの定義及び規則を使用して，FTR及びDETの数を計測する。
次の複雑さ表に従って，EIの複雑さを評価する。
DET
FTR
1〜4
5〜15
16以上
0〜1
低
低
中
2
低
中
高
3以上
中
高
高
手順
複雑さの手順
4
EO及びEQの場合：
EO又はEQの複雑さの定義及び規則を使用して，FTR及びDETの数を計測する。
次の複雑さ表に従って，EO又はEQの複雑さを評価する。複雑さを評価するために，重複しないよう
に，FTR及びDETの累積値を使用することに留意する。
DET
FTR
1〜5
6〜19
20以上
0〜1
低
低
中
2〜3
低
中
高
4以上
中
高
高
手順
寄与の手順
5
EI及びEQの場合：
次の寄与表を使用して，EI又はEQの複雑さを未調整ファンクションポイントに変換する。
ファンクションの複雑さの評価
未調整ファンクションポイント
低
3
中
4
高
6
78
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
手順
寄与の手順
5
EOの場合：
次の寄与表を使用して，EOの複雑さを未調整ファンクションポイントに変換する。
ファンクションの複雑さの評価
未調整ファンクションポイント
低
4
中
5
高
7
8.4
EI，EO及びEQの計測上の留意点
次に記載する計測上の留意点は，EI，EO及びEQの識別規則を適用するときに利用してもよい。
注記 計測上の留意点は，計測規則ではない。
a) データをアプリケーション境界の外部から受け取るか。
− 業務フロー図を調べる。
− 処理の機能分解の過程で，利用者と他のアプリケーションとのインタフェースがどこで発生するか
を識別する。
b) 利用者の観点から，その処理は最小の作業単位か。
− 使用されている他の紙書類又は電子化帳票を調べる。
− 利用者がどのように情報をグループ化しているかを識別するために，ILFを精査する。
− 処理の機能分解の過程で，利用者と他のアプリケーションとのインタフェースがどこで発生するか
を識別する。
− 手作業ではどのようにしているかを調べる。
− 論理的に見た場合，一つの物理的な入力，トランザクション ファイル又は画面は，複数のEI，EO
又はEQに対応することができることに注意する。
− 処理ロジックが同一の場合，二つ以上の物理的な入力，トランザクション ファイル又は画面が，一
つのEI，EO又はEQに対応することができることに注意する。
c) 処理は自己完結しているか，そして，業務を矛盾のない状態にしているか。
− 利用者が情報を使用して，どのように業務を行うかを理解するために，他のEI，EO及びEQを精
査する。
− 手掛かりを得るために，手順図を調べる。
− 手作業ではどのようにしているかを調べる。
− 他の判断と矛盾がないかを確認する。
d) 処理ロジックは，他のEI，EO及びEQと異なっているか。
− 要求された処理ロジックに基づいて，バッチ処理での入出力を識別する。
− データの分類又は再配列が処理ロジックを特有なものにしないことに留意する。
e) データ項目は，他のEI，EO又はEQと異なっているか。
− データ項目が別のEI，EO又はEQのデータ項目の部分集合の場合は，利用者が二つの要素処理（す
なわち，一つは元のデータ要素に対する要素処理で，もう一つは部分集合に対する要素処理）を要
求していることを確認する。
f)
要素処理をEI，EO又はEQに分類する前に，その主目的を明らかにする。
g) 要素処理の識別は，利用者と開発担当者との間での利用者要件の合意又は解釈に基づいて行う。
h) 機能分割によって得られる各要素は，そのまま一つの要素処理に対応付けられるわけではない。
79
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
i)
要素処理の識別には，利用者要件の解釈が必要になる。
j)
ILF及び／又はEIFに複数のRETがあっても，参照したILF及び／又はEIFを1FTRと計測する。
8.4.1
EO及びEQの計測上の追加の留意点
a) 利用者の観点から，その処理は最小の作業単位か。
− EO又はEQは，アプリケーション境界の内部の処理によって起動することができる。
例1 すべての変更された社員の給与等級の報告書を，システムの内部時計に基づいて，8時間ご
とに予算部門に送る利用者要件がある。
状況A：報告書には，社員ファイルから取り出した社員氏名，保険者番号及び時給をすべて含む。
この処理は，利用者の観点から最小の業務単位であり，“数式又は演算の実行”を含まな
いし，処理の中にILFの維持管理を含まない。したがって，この処理は，1EQとなる。
状況B：報告書には，社員ファイルから取り出した社員氏名，保険者番号及び時給をすべて含む。
さらに，その報告書には，社員ファイルのデータから計算したその社員の給料の変更率
を含む。この処理は，利用者の観点から最小の業務単位であり，処理の中にILFの維持
管理を含まない。しかしながら，この処理には数式を含むので，この処理は1EOとなる。
− EOのための導出データは，出力の上に表示されなくてもよい。
例2 毎月，次の30日間で査定の必要があるすべての社員を一覧表示する報告書を作成する。対象
になる社員は，社員ファイル上のデータ項目に記載された最後に実施した査定日に基づいて，
現在の日付に30日を加えて，次の査定日を計算し抽出する。これは，1EOとしての計測で
あり，EQとしての計測ではない。
8.5
要素処理識別の事例
ここでは，幾つかの事例を使用して，要素処理を識別する手順を示す。
8.5.1
要素処理識別のための識別事例の概要
要素処理を識別するための事例を，表9に示す。
表9−事例一覧
事例
概要
社員及び扶養家族データの新規登録
複数の処理が一つの要素処理を構成することを示す事例
小切手の発行及び支払済みのマーク
要素処理の主目的の概念を示す事例
業務割当ての閲覧
報告書を作成するための選択条件の入力が要素処理でないことを示す
事例
業務割当ての印刷及び選択基準の保存
後で使用するために印刷条件を保存することが独立した要素処理であ
ることを明白に示す事例
社員の個人データ及び面談情報
複数の処理が一つの要素処理を構成することを示す二つ目の事例
社員の個人データ及び運転免許情報
複数の処理が一つの要素処理を構成することを示す三つ目の事例
8.5.2
事例1：社員及び扶養家族データの新規登録
8.5.2.1 利用者要件
利用者が新入社員を追加する場合，次のデータを入力しなければならない。
a) 社員の基本データ
b) 扶養家族の人数が一人以上の場合，扶養家族人数
社員情報を更新するときに，トランザクション ファイルが作成される。このトランザクション ファイ
ルは，定期的に福利厚生システムへ送られる。
80
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
8.5.2.2 扶養家族情報なしでの社員情報の追加
扶養家族がいる場合，関連する扶養家族情報なしで，社員情報を追加することが要素処理であるかを決
める。
次の表にその分析を示す。
要素処理の識別規則
規則の該当・非該当
その処理は，利用者にとって意味のある業務活動の最小
単位である。
当てはまらない。
社員に扶養家族がいる場合，社員を追加するための利用
者要件を示すためには扶養家族情報を含まれなければ
ならない。
その処理は，自己完結しており，計測するアプリケーシ
ョンが実行する業務を矛盾のない状態にするものであ
る。
当てはまらない。
社員に扶養家族がいる場合，社員情報だけを登録しても
業務は矛盾のない状態ではない。
関連する扶養家族情報なしで，社員情報を追加することは，要素処理の要求事項に適合しない。
8.5.2.3 扶養家族情報だけの追加
社員情報なしで，扶養家族情報だけを追加することが要素処理であるかを決める。
次の表にその分析を示す。
要素処理の識別規則
規則の該当・非該当
その処理は，利用者にとって意味のある業務活動の最小
単位である。
当てはまらない。
社員データの維持管理処理と独立して，この作業を実行
することはできないので，この登録作業は明らかに利用
者にとって意味がない。
その処理は，自己完結しており，計測するアプリケーシ
ョンが実行する業務を矛盾のない状態にするものであ
る。
対象外。
関連する社員情報なしで，扶養家族情報を追加することは，要素処理の要求事項に適合しない。
8.5.2.4 扶養家族情報を伴う社員情報の追加
扶養家族がいる社員の場合，関連する扶養家族情報を伴う社員情報の追加が要素処理であるかを決める。
次の表にその分析を示す。
要素処理の識別規則
規則の該当・非該当
その処理は，利用者にとって意味のある業務活動の最小
単位である。
当てはまる。
人事情報システムに社員を追加するために，社員情報及
び扶養家族情報の両方を使用する。
その処理は，自己完結しており，計測するアプリケーシ
ョンが実行する業務を矛盾のない状態にするものであ
る。
当てはまる。
この処理は，それ自体で意味がある。必要な情報はすべ
て，人事情報システムに追加されるので，業務は矛盾の
ない状態のままである。更新ファイルを作成し，福利厚
生システムへ送ることができる。
扶養家族情報を伴う社員情報の追加は，要素処理の要求事項に合致する。
8.5.2.5 トランザクション ファイルの福利厚生システムへの送付
トランザクション ファイルを福利厚生システムへ送る処理が，追加の要素処理であるかを決める。
次の表にその分析を示す。
要素処理の識別規則
規則の該当・非該当
その処理は，利用者にとって意味のある業務活動の最小
単位である。
当てはまる。
内部で起動されたこの処理は，異なる利用者要件を反映
している。この要件は，独立した処理として構築される。
81
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
その処理は，自己完結しており，計測するアプリケーシ
ョンが実行する業務を一貫した状態にするものである。
当てはまる。
この処理は，自己完結している。福利厚生システムの更
新に使用されるトランザクション ファイルに更新レコ
ードを作成した後，このシステムは矛盾のない状態にあ
る。
トランザクション ファイルを福利厚生システムへ送る処理は，要素処理の要求事項に合致する。
8.5.2.6 結論
社員情報に扶養家族を追加するための利用者要件を満たすためには，異なる実装が考えられる。例えば，
次のものがある。
− 扶養家族画面の表示のきっかけとなる社員情報画面上の“扶養家族人数”と呼ぶデータ入力項目
− 扶養家族画面を表示するボタン
− 扶養家族画面を表示する社員情報画面上のメニュー項目
− 社員情報画面上の扶養家族情報を入力することの実現性
実装に関係なく，扶養家族を含む社員の追加という一つの要素処理がまだ存在する。
8.5.3
事例2：小切手の印刷及び発行済みの印付け
8.5.3.1 利用者要件
小切手を印刷し，その結果として，勘定書の支払済みの印を付ける。小切手に印刷するすべてのデータ
は，既に小切手ファイルに保存されている。
この事例についてのデータフロー図を，図20に示す。
図20−小切手発行の概略図
8.5.3.2 支払済みの印付け
支払済みの印を付けることが，要素処理であるかを決める。
次の表にその分析を示す。
要素処理の識別規則
規則の該当・非該当
その処理は，利用者にとって意味のある業務活動の最小
単位である。
当てはまらない。
小切手を印刷するために，項目の印刷及び印付けの両方
が要求される。
その処理は，自己完結しており，計測するアプリケーシ
ョンが実行する業務を一貫した状態にするものである。
当てはまらない。
この処理は，それ自体では意味がない。両方の作業が要
求されている。
小切手印刷
小切手ILF
小切手番号
金額
受取人
支払済み区分
AB12345 小切手
支払地 東京都千代田区XXX
千代田銀行永田町支店
金額
￥1,000,000＊
上記の金額をこの小切手と引換えに
持参人へお支払ください。
受取人 山田 太郎
拒絶証書不要
振出日 平成 年 月 日
振出地 東京都
株式会社 東京商事
振出人 代表取締役 岡本 太郎
82
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
支払済みの印を付けることは，要素処理に対する要求事項に合致しない。
8.5.3.3 小切手の印刷及び支払済みの印付け
小切手の印刷及び支払済みの印付けが，要素処理であるかを決める。
次の表にその分析を示す。
要素処理の識別規則
規則の該当・非該当
その処理は，利用者にとって意味のある業務活動の最小
単位である。
当てはまる。
小切手を印刷するために，項目の印刷及び印付けの両方
が要求される。
その処理は，自己完結しており，計測するアプリケーシ
ョンが実行する業務を一貫した状態にするものである。
当てはまる。
この処理は，それ自体で意味がある。小切手の印刷及び
支払済みの印付けの両方が処理の達成に要求されてい
る。
小切手の印刷及び支払済みの印付けは，要素処理の要求事項に合致する。
利用者の要件は，小切手を印刷することである。支払済み区分に印を付けることは，小切手印刷処理の
一部になる。小切手の印刷及び印付けは共に，利用者にとって意味のある業務活動の最小単位である。処
理全体が自己完結しており，システムの業務を矛盾のない状態にする。
8.5.4
事例3：業務割当ての閲覧
8.5.4.1 利用者要件
ある期間の業務割当て一覧を閲覧する。利用者は，選択基準を入力することができる。一度報告書を作
成した後，選択基準を保存するという要求はない。
この事例に対するデータフロー図を，図21に示す。
83
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図21−データフロー図
8.5.4.2 印刷条件の入力
業務割当て一覧を閲覧せずに選択基準を入力することは，要素処理であるかを決める。
次の表にその分析を示す。
要素処理の識別規則
規則の該当・非該当
その処理は，利用者にとって意味のある業務活動の最小
単位である。
当てはまらない。
利用者にとって意味があるのは，選択基準の入力及び一
覧表の閲覧である。
その処理は，自己完結しており，計測するアプリケーシ
ョンが実行する業務を一貫した状態にするものである。
当てはまらない。
この処理は，一覧表を閲覧とは独立して実行できないの
で，自己完結しない。
業務割当て一覧表を閲覧せずに選択基準を入力することは，要素処理の要求事項に合致しない。
8.5.4.3 業務割当て一覧の閲覧
選択基準を入力せずに業務割当て一覧を閲覧することが要素処理であるかを決める。
次の表にその分析を示す。
業務割当て一覧の基準
―
社員番号
開始日付
終了日付
印刷
取消
業務割当てILF
社員番号
割当て日
割当て内容
業務割当て一覧
日付 社員番号 割当て内容
H5/4/1 0103 xxxxxxxxxx
H7/10/1 0109 yyyyyyyyyy
H12/4/1 0106 zzzzzzzzzz
保存
選択基準の保存
印刷基準ILF
利用者ID
社員番号
開始日付
終了日付
報告書ID
業務割当て一覧の
印刷
84
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
要素処理の識別規則
規則の該当・非該当
その処理は，利用者にとって意味のある業務活動の最小
単位である。
当てはまらない。
利用者にとって意味があるのは，選択基準の入力及び一
覧表の閲覧である。
その処理は，自己完結しており，計測するアプリケーシ
ョンが実行する業務を一貫した状態にするものである。
当てはまらない。
この処理は，選択基準を入力によって独立して実行でき
ないので，自己完結しない。
選択基準を入力せずに業務割当て一覧を閲覧することは，要素処理の要求事項に合致しない。
8.5.4.4 選択基準の入力及び業務割当て一覧の閲覧
選択基準の入力及び業務割当て一覧の閲覧が要素処理であるかを決める。
次の表にその分析を示す。
要素処理の識別規則
規則の該当・非該当
その処理は，利用者にとって意味のある業務活動の最小
単位である。
当てはまる。
利用者にとって意味があるのは，選択基準の入力及び一
覧表の閲覧である。
その処理は，自己完結しており，計測するアプリケーシ
ョンが実行する業務を一貫した状態にするものである。
当てはまる。
業務を矛盾のない状態に保つためには，選択基準の入力
及び業務割当て一覧の閲覧の両者が実行されなければ
ならないので，この処理は自己完結している。
選択基準の入力及び業務割当て一覧の閲覧は，要素処理の基準に合致する。
制御情報は，EO又はEQの入力側である。どんなデータを検索若しくは生成するか，及び／又はどのよ
うにしてデータを検索若しくは生成するかを指定する要件は，利用者にデータを提供する要素処理の一部
になるが，それ自身は要素処理ではない。
選択基準を入力することは，利用者にとって意味のある最小の業務単位ではない。この処理は，報告書
を作成することと独立して実行できないので，自己完結しない。選択基準の入力及び報告書の作成は，一
緒になって，利用者にとって意味のある最小の業務単位となり，自己完結し，業務を矛盾のない状態にす
る。
8.5.5
事例4：業務割当ての印刷及び選択基準の保存
8.5.5.1 利用者要件
ある期間の業務割当て一覧を印刷する。利用者は，選択基準を指定できる。後で使用するために，選択
基準を保存できるようにするという利用者要件がある。
この事例のデータフロー図を，図22に示す。
85
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図22−データフロー図
8.5.5.2 選択基準の保存
業務割当て一覧の印刷を伴わない選択基準の保存は，要素処理であるかを決める。
次の表にその分析を示す。
要素処理の識別規則
規則の該当・非該当
その処理は，利用者にとって意味のある業務活動の最小
単位である。
当てはまる。
選択基準の保存は，最小の業務単位であり，利用者にと
って意味がある。
その処理は，自己完結しており，計測するアプリケーシ
ョンが実行する業務を一貫した状態にするものである。
当てはまる。
選択基準を保存することは，業務割当て一覧を印刷する
こととは独立して実行できる。
業務割当て一覧の印刷を伴わない選択基準の保存は，要素処理の要求事項に合致する。
8.5.5.3 業務割当て一覧の印刷
業務割当て一覧の基準
―
社員番号
開始日付
終了日付
印刷
保存
取消
選択基準の保存
業務割当て一覧の印刷
環境基準ILF
利用者ID
社員番号
開始日付
終了日付
報告書ID
業務割当てILF
社員番号
割当て日
割当て内容
業務割当て一覧
日付 社員番号 割当て内容
H5/4/1 0103 xxxxxxxxxx
H7/10/1 0109 yyyyyyyyyy
H12/4/1 0106 zzzzzzzzzz
86
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
業務割当て一覧の印刷が，選択基準の保存の有無にかかわらず，要素処理であるかを決める。
次の表にその分析を示す。
要素処理の識別規則
規則の該当・非該当
その処理は，利用者にとって意味のある業務活動の最小
単位である。
当てはまる。
業務割当て一覧の印刷は，最小の業務単位であり，利用
者にとって意味がある。
その処理は，自己完結しており，計測するアプリケーシ
ョンが実行する業務を一貫した状態にするものである。
当てはまる。
業務割当て一覧の印刷は，業務割当て一覧の閲覧とは独
立して実行できる。
業務割当て一覧の印刷は，選択基準の保存とともに，要素処理の要求事項に合致する。
選択基準の入力は，利用者が明白に基準を保存できるので，確かに利用者にとって意味がある。報告書
の印刷又は選択基準の保存は，いずれも独立して実行できる。そして，どちらも業務を矛盾のない状態に
保つ。
選択基準の保存及び報告書の作成のどちらの処理も，自己完結しており，業務にとって意味があり，業
務を矛盾のない状態に保つ。要素処理の識別規則によって，二つの要素処理がある。
8.5.6
事例5：社員の個人データの面談情報
8.5.6.1 利用者要件
新入社員を追加するときに，社員の個人データ（すなわち，保険者番号，社員氏名，住所など）に加え
て，その社員への面談結果の詳細を追加しなければならない。面談情報は，面談者氏名，面談実施日及び
面談者所感を含む。
この事例のデータフロー図を，図23に示す。
87
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図23−データフロー図
8.5.6.2 社員の個人データ登録
社員の個人データだけを登録することが要素処理であるかを決める。
次の表にその分析を示す。
社員の新規登録
―
保険証番号
登録
取消
面談結果の詳細の追加
―
面談者氏名
面談実施日
面談者所感
追加
取消
社員情報の作成
面談結果の詳細の追加
面談情報ILF
保険証番号 面談者氏名
氏名 面談実施日
住所 面談者所感
…… ********************
氏名
住所
88
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
要素処理の識別規則
規則の該当・非該当
その処理は，利用者にとって意味のある業務活動の最小
単位である。
当てはまらない。
利用者にとって意味があるのは，社員の個人データの登
録及び面談結果の詳細の追加の両方である。
その処理は，自己完結しており，計測するアプリケーシ
ョンが実行する業務を一貫した状態にするものである。
当てはまらない。
この処理は，面談結果の詳細の追加と独立して実行でき
ないので，自己完結していない。
面談結果の詳細の追加をしないで，社員の個人データを登録することは，要素処理の要求事項に合致し
ない。
8.5.6.3 面談結果の詳細の追加
面談結果の詳細だけを追加することが要素処理であるかを決める。
次の表にその分析を示す。
要素処理の識別規則
規則の該当・非該当
その処理は，利用者にとって意味のある業務活動の最小
単位である。
当てはまらない。
利用者にとって意味があるのは，社員の個人データの登
録及び面談結果の詳細の追加の両方である。
その処理は，自己完結しており，計測するアプリケーシ
ョンが実行する業務を一貫した状態にするものである。
当てはまらない。
この処理は，社員の個人データの登録と独立して実行で
きないので，自己完結していない。
社員の個人データの登録をしないで，面談結果の詳細を追加することは，要素処理の要求事項に合致し
ない。
8.5.6.4 社員の個人データの登録及び面談結果の詳細の追加
面談結果の詳細の追加とともに，社員の個人データを登録することが要素処理であるかを決める。
次の表にその分析を示す。
要素処理の識別規則
規則の該当・非該当
その処理は，利用者にとって意味のある業務活動の最小
単位である。
当てはまる。
利用者にとって意味があるのは，社員の個人データの登
録及び面談結果の詳細の追加の両方である。
その処理は，自己完結しており，計測するアプリケーシ
ョンが実行する業務を一貫した状態にするものである。
当てはまる。
測定対象のアプリケーションの業務を矛盾のない状態
に保つので，この処理は自己完結している。
8.5.6.5 結論
二つの入力処理が，常に連続し，お互いに依存している［二つの処理が必す（須）である。］場合，一つ
の要素処理及びファンクションが存在する。
新入社員の情報は，社員の個人データ及び面談結果の詳細の両者が入力されるまで，登録できない。社
員の個人データの登録だけでは，利用者にとって意味のある最小の業務単位にならないし，アプリケーシ
ョンの業務を矛盾のない状態に保たない。
要素処理の識別規則によって，ただ一つの要素処理がある。
8.5.7
事例6：社員の個人データの運転免許情報
8.5.7.1 利用者要件
新入社員を追加する場合，保険者番号，社員氏名，住所及び運転免許の有無を社員の個人データとして
登録する。社員が運転免許をもっている場合，二番目の処理として，社員の運転免許証番号，免許の種類
及び有効期限の登録を完了しなければならない。
89
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
この事例のデータフロー図を，図24に示す。
図24−データフロー図
8.5.7.2 運転免許情報なしでの社員の個人データの登録
社員の個人データだけを登録することが，運転免許をもっていない社員にとって，要素処理であるかを
社員の新規登録
―
保険証番号
氏名
住所
登録
取消
運転免許証情報の追加
―
運転免許証
運転免許証番号
免許の種類
有効期限
追加
取消
社員情報ILF
保険証番号
氏名
住所
運転免許証
運転免許証番号
免許の種類
有効期限
運転免許の有無
有
無
運転
免許証
社員の新規登録
運転免許証情報の登録
90
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
決める。
次の表にその分析を示す。
要素処理の識別規則
規則の該当・非該当
その処理は，利用者にとって意味のある業務活動の最小
単位である。
当てはまる。
社員の個人データを追加することは，最小の処理単位で
あり，利用者にとって意味がある。
その処理は，自己完結しており，計測するアプリケーシ
ョンが実行する業務を一貫した状態にするものである。
当てはまる。
その処理は，アプリケーションの業務を矛盾のない状態
に保つので，自己完結している。
運転免許情報なしで社員の個人データを追加することは，運転免許をもっていない社員に対する要素処
理の要求事項に合致する。
8.5.7.3 運転免許情報の登録
社員の個人データなしで，運転免許情報を登録することが要素処理であるかを決める。
次の表にその分析を示す。
要素処理の識別規則
規則の該当・非該当
その処理は，利用者にとって意味のある業務活動の最小
単位である。
当てはまらない。
社員の個人データの追加の処理なしで，運転免許情報を
登録することはできないので，利用者にとって，これは
意味がない。
その処理は，自己完結しており，計測するアプリケーシ
ョンが実行する業務を一貫した状態にするものである。
当てはまらない。
その処理は，社員の個人データの登録とは独立して実行
できないので，自己完結していない。
社員の個人データの登録なしで，運転免許情報を登録することは，要素処理の要求事項に合致しない。
8.5.7.4 社員の個人データ及び運転免許情報の追加
社員の個人データを運転免許情報とともに登録することが要素処理であるかを決める。
次の表にその分析を示す。
要素処理の識別規則
規則の該当・非該当
その処理は，利用者にとって意味のある業務活動の最小
単位である。
当てはまる。
社員の個人データの追加及び運転免許情報の登録は，最
小の処理単位であり，利用者にとって意味がある。
その処理は，自己完結しており，計測するアプリケーシ
ョンが実行する業務を一貫した状態にするものである。
当てはまる。
社員の個人データの追加及び運転免許情報の登録は，計
測対象のアプリケーションの業務を矛盾のない状態に
保つので，その処理は，自己完結している。
8.5.7.5 結論
二つの入力処理が常に連続しお互いに依存しているが，二つ目の処理が任意である［しかし，適用され
る場合は，必す（須）である。］場合，一つの要素処理とする。
社員の追加には，一つの要素処理がある。社員が運転免許をもっていない場合は，運転免許情報の登録
の手順は不要になる。社員が運転免許をもっている場合は，要素処理を完了しアプリケーションの業務を
矛盾のない状態に保つために，2番目の画面入力を完了しなければならない。
8.6
EI，EO及びEQの計測事例
ここでは，人事情報システムを事例として，トランザクション ファンクションを計測するための手順を
示す。
注記 この細分箇条の事例には，次の二つの目的がある。
91
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
− ファンクションポイントの計測規則を，与えられた利用者の要件に対してどう適用するかを示
す。
− 計測手順の使用に習熟する。
計測者は，次の点に注意しなければならない。
− 計測対象のプロジェクト又はアプリケーションの利用者要件を分析する。
− 利用者要件に基づいて計測する。
8.6.1
計測事例の構成
ここでは，事例の記述方法について説明する。
8.6.1.1 記述の構成の概要
事例における説明の順序は，次のとおりである。
まず，事例ごとに，次の順に説明する。
a) EI，EO及びEQを識別する。
b) ファンクションの複雑さをもたらすFTR及びDETを計測する。
次に，すべての事例を集約して，次の順に説明する。
c) EI，EO又はEQとして識別した項目及び識別しなかった項目を集約する。
d) 識別したすべてのEI，EO又はEQに対して，未調整ファンクションポイントに対する複雑さ及び寄
与を決定する。
8.6.1.2 各事例の計測
各事例は，次の構成要素からなる。
− 計測及び／又は識別の基礎情報
− 計測規則及び／又は識別規則を適用するための表
8.6.1.3 構成要素の図
各事例の構成要素及び情報の流れを，図25に示す。
92
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
計測及び／又は識別の基礎情報
利用者要件
1 Xxxxxxxxxxxx
2 Xxxxxxxxxxx
3 Xxxxxxxxxxx
識別表
EI，EO及びEQの識別
識別規則
規則の該当・非該当
Xxxxxxxxxxxxxxxxxxxxxxxx
Xxxxxxxxxxxxxxxxxxxxxxxx
Xxxxxxxxxxxxxxxxxxxxxxxx
当てはまる。 又は 当てはまらない。 説 明 ――――
当てはまる。 又は 当てはまらない。 説 明 ――――
当てはまる。 又は 当てはまらない。 説 明 ――――
識別したEI，EO及びEQに対して，FTR及びDETを計測する。
識別規則
規則の該当・非該当
Xxxxxxxxxxxxxxxx
Xxxxxxxxxxxxxxxx
Xxxxxxxxxxxxxxxx
説 明 ―――――
説 明 ―――――
説 明 ―――――
図25−構成要素及び情報の流れ
8.6.1.3.1 計測及び／又は識別の基礎情報
各事例は，最初に計測及び／又は識別の基礎情報を提示する。図25に示すように，計測及び／又は識別
は，次の情報に基づいて行う。
− 利用者要件
− データモデル及びプロセスモデル
− 画面，画面情報又は報告書
注記 図のすべての情報がすべての例に含まれているわけではない。事例の中には，利用者要件だけ
93
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
が計測の基本になるものがある。他の例では，データモデル又はプロセスモデル，画面，画面
情報及び報告書を含んでいるものもある。
8.6.1.3.2 識別表
ファンクションを識別するための分析は，そのファンクションの識別規則を列挙した表を用いて使用し
て行う。その規則は，計測及び／又は識別の基礎情報を作り上げる構成要素に適用する。分析内容は，表
中の規則の該当・非該当の欄で説明する。
注記 すべての規則が当てはまる場合は，事例をEI，EO又はEQとして計測する。
次に示す表は，識別した各ファンクションに対する複雑さの識別規則及びその説明を示している。
8.6.1.4 識別したEI，EO及びEQの概要
各事例に対してすべての規則を適用した後，計測したもの及び計測しなかったものを概要の項で一覧表
示する。
8.6.1.5 すべてのEI，EO及びEQに対する複雑さ及び寄与の合計
説明の最後の項は，未調整ファンクションポイントに対する複雑さ及び寄与の計算を示す。
8.6.2
すべてのトランザクション ファンクションに共通の規則
すべての事例を分析する手順は，箇条8の初めで記述した手順に従う。手順は，要素処理，主目的及び
トランザクション ファンクション型をEI，EO又はEQへ分類するための規則を適用することに関係して
いる。次の表に適用されなければならない規則を一覧表示する。
要素処理の識別規則
規則の該当・非該当
その処理は，利用者にとって意味のある業務活動の最小単位である。
その処理は，自己完結しており，計測するアプリケーションが実行
する業務を矛盾のない状態にするものである。
トランザクション ファンクションが要素処理となるためには，二つの識別規則のいずれの質問に対して
も，“当てはまる”でなければならない。
表10−トランザクション ファンクション型の主目的
主目的
EI
ILFの維持管理又はシステムの振る舞いの変更
EO
利用者への情報の提供
“数式又は演算の実行”，導出データの提供又は“一つ以上のILFの更新又はシス
テムの振る舞いの変更”
EQ
利用者への情報の提供
一つ以上のILF又はEIFから取得したデータだけの提供
EI，EO及びEQのいずれであるかを決定するために，トランザクション ファンクション型の主目的に
最もよく適合する記述を使用する。これは，ファンクションに対する利用者要件を注意深く，かつ，正確
に解釈することで決定できる。
8.7
EIの計測事例
ここでは，人事情報システムを使用して，EIの計測手順を示す。
8.7.1
EI計測事例の概要
EIの計測事例一覧を，表11に示す。
94
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
表11−事例一覧
事例
概要
制御情報
帳票出力に使用する制御情報を示す事例
画面入力
画面を介してのオンラインでのトランザクションの追加を計測する方法
を示す事例
複数のEI及び重複したEIをもつバッ
チ処理
複数の型又は様式の決まったレコードの型をもつトランザクション ファ
イルを計測する方法を示す事例
未確定業務情報の修正
中断したトランザクションの修正
業務の追加又は変更を実施するバッチ処理の間に，あるファイルに中断し
た業務の修正を計測する方法を示す事例
複数のFTRをもったEI
複数のファイルを参照するEIを計測するために，データフロー図を使用
することを示す事例
データ移行
一つのデータのグループを，データ項目を追加した新しい形式に移行する
処理を計測する方法を示す事例
他のアプリケーションからのデータ
参照
7.7.2で検討したEIFをなぜEIとして計測しないのかを示す事例
画面出力を伴うEI その1
演算によって作成し表示されている項目をもつEIを示す事例画面表示さ
れた演算項目をもつEIを示す事例
画面出力を伴うEI その2
演算によって作成した項目及び内包したEQをもつEIを示す事例演算項目
及び埋め込まれたEQをもつEIを示す事例
8.7.2
事例1：制御情報
8.7.2.1 利用者要件
業務割当て報告書をいつ，どのように印刷するかを制御する利用者要件がある。その報告書を作成する
ための特定の利用者要件を次に一覧表示する。
a) 報告書処理についての次の状況の制御
− 並べ替えの順序
− 印刷装置のポート
− マイクロフィッシュ（印刷装置以外の出力装置）による複製作成の有無
− 印刷の有無
b) 業務割当て報告書制御情報の保存
c) 制御情報の変更の実施及び変更内容の保存
d) 業務割当て報告書に対する制御情報の追加又は変更を確認するメッセージ，及びその報告書が作成さ
れたことを確認するメッセージの送出
注記 この事例は，業務割当て報告書の制御情報を追加するための要件だけを示している。
8.7.2.2 画面例
図26に示す業務割当て報告書の画面は，割当てを報告するための制御をするためによく使用する。
95
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図26−業務割当て報告書入力画面
手順1 要素処理の識別
そのトランザクション ファンクションは，要素処理の
識別規則に適合するか。
当てはまる。
手順2 主目的の決定及び分類
そのトランザクション ファンクションは，EIの主目的
を満たすか。
当てはまる。
主目的は，ILFの維持管理である。
手順3 EI識別規則に対する妥当性確認
EI識別規則
規則の該当・非該当
データ又は制御情報は，アプリケーション境界の外部か
ら入力される。
当てはまる。
人事情報システム
社員 業務 割当て 事業所 ヘルプ
業務割当て報告書
並替えの順序
［3］業務ID
［2］社員番号
［1］社員氏名
1,2,3で順序を指定
印刷装置のポート
［ ］LPT1
［ ］LPT2
［ ］LPT3
実行
取消
前回の指定値
実行
前回の指定値
取消
印刷の実行
プルダウンメニューに戻る
前回の指定値を表示
□ マイクロフィッシュへのコピー
□ 印刷
96
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
アプリケーション境界の外部から入力されたデータが
システムの振る舞いを変更する制御情報でない場合，少
なくとも一つのILFを維持管理する。
当てはまる。
アプリケーション境界の内部に入るデータは，最終的に
は，制御データとして使用する。また，報告書制御ILF
に保存する業務データである。
識別した処理に対して，次の三つのうちいずれか一つを
適用する。
− 処理ロジックが，このアプリケーションの他のEI
によって実行された処理ロジックと異なっている。
− 識別したデータ項目の組が，このアプリケーション
の他のEIについて識別されたデータ要素と異なっ
ている。
− 参照するILF又はEIFが，このアプリケーションの
他のEIについて識別された参照するILF又はEIF
と異なっている。
当てはまる。
この機能を実行する他のEIは，識別していない。
対象外。
対象外。
結論：一つのEIがある。
手順4 複雑さの決定
FTR計測規則
規則の該当・非該当
維持管理される1ILFは，1FTRと計測する。
当てはまる。
報告書制御ILFは，維持管理される。
EIの処理時に参照されるILF又はEIFは，1FTRと計測
する。
当てはまる。
報告書制御ILFは，参照される。
一つのEIの処理時に維持管理され，かつ，参照される
ILFは，1FTRとだけ計測する。
当てはまる。
報告書制御ILFは，維持管理され，かつ，参照される。
1回だけ計測する。
結論：FTRの数は，1となる。
DET計測規則
規則の該当・非該当
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の外部から入力される又はア
プリケーション境界の内部から出力される。
− EI処理を完了するために必要である。
次の項目が当てはまる。並べ替えの順序，印刷装置のポ
ート及び報告書の出力形式
システムによって取得又は導出されるデータ項目，及び
ILFに格納されるデータ項目で，要素処理の実行中にそ
のデータ項目がアプリケーション境界をまたがらない
場合は，DETとしては計測しない。
対象外。
処理中のエラー発生の通知，処理の完了確認又は処理続
行の確認のために，アプリケーション境界の外部にシス
テム応答メッセージを出力する機能を1DETと計測す
る。
次の項目が当てはまる。
利用者へのメッセージ
同一の論理的処理を起動する手段が複数ある場合でも，
実施する活動を指定する機能を1DETと計測する。
次の項目が当てはまる。
実行ボタン
結論：DETの数は，5となる。
複雑さ
1FTR及び5DET
複雑さは，低である。
手順5 寄与の決定
寄与が1で，複雑さのEIが低
3FPになる。
97
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
8.7.3
事例2：画面情報入力
8.7.3.1 利用者要件
次の利用者要件がある。
− 業務情報のオンライン追加
− 入力のエラーをオンラインで修正できるように，エラーメッセージの生成，及び間違い項目の強調表
示（高輝度表示）
− 追加した業務情報の保存
8.7.3.2 画面情報例
図27に示す業務データの画面情報は，新しい業務を追加するために使用する。
図27−業務情報入力画面
手順1 要素処理の識別
そのトランザクション ファンクションは，要素処理の
識別規則に適合するか。
当てはまる。
手順2 主目的の決定及び分類
そのトランザクション ファンクションは，EIの主目的
を満たすか。
当てはまる。
主目的は，ILFの維持管理である。
手順3 EI識別規則に対する妥当性確認
次の表は，新しい業務を追加するという機能に対して，EI識別規則を使用した利用者要件の分析を示す。
EI識別規則
規則の該当・非該当
データ又は制御情報は，アプリケーション境界の外部か
ら入力される。
当てはまる。
業務データは，アプリケーション境界の外部から入る。
アプリケーション境界の外部から入力されたデータが
システムの振る舞いを変更する制御情報でない場合，少
なくとも一つのILFを維持管理する。
当てはまる。
業務ILFが維持管理される。
アクション：□ 7＝前画面 8＝次画面 9＝保存
内容
業務番号： RD15379305
業務名称： 顧客情報の維持管理
給与等級： JRNY05A
行番号 業務内容
01 月次関東地区上顧客リスト更新
98
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
識別した処理に対して，次の三つのうちいずれか一つを
適用する。
− 処理ロジックが，このアプリケーションの他のEI
によって実行された処理ロジックと異なっている。
− 識別したデータ項目の組が，このアプリケーション
の他のEIについて識別されたデータ要素と異なっ
ている。
− 参照するILF又はEIFが，このアプリケーションの
他のEIについて識別された参照するILF又はEIF
と異なっている。
当てはまる。
エラーログを生成するための要件は，重複しない。
対象外。
対象外。
結論：新しい業務を追加する機能は，1EIとなる。
手順4 複雑さの決定
FTR計測規則
規則の該当・非該当
維持管理される1ILFは，1FTRと計測する。
当てはまる。
業務ILFは，参照され，更新される。
EIの処理時に参照されるILF又はEIFは，1FTRと計測
する。
当てはまる。
業務ILFは，参照される。
一つのEIの処理時に維持管理され，かつ，参照される
ILFは，1FTRとだけ計測する。
当てはまる。
業務ILFは，維持管理され，参照されるが，1回だけ計
測する。
結論：FTRの数は，1となる。
DET計測規則
規則の該当・非該当
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の外部から入力される又はア
プリケーション境界の内部から出力される。
− EI処理を完了するために必要である。
次の項目が当てはまる。
業務番号，業務名称，給与等級，業務説明行の行番号（繰
返し）及び業務説明行（繰返し）
システムによって取得又は導出されるデータ項目，及び
ILFに格納されるデータ項目で，要素処理の実行中にそ
のデータ項目がアプリケーション境界をまたがらない
場合は，DETとしては計測しない。
対象外。
処理中のエラー発生の通知，処理の完了確認又は処理続
行の確認のために，アプリケーション境界の外部にシス
テム応答メッセージを出力する機能を1DETと計測す
る。
次の項目が当てはまる。
エラーのメッセージ
同一の論理的処理を起動する手段が複数ある場合でも，
実施する活動を指定する機能を1DETと計測する。
次の項目が当てはまる。
追加した業務情報の保存。
結論：DETの数は，7となる。
複雑さ
1FTR及び7DET
複雑さは，低である。
手順5 寄与の決定
寄与が1で，複雑さのEIが低
3FPになる。
8.7.4
事例3：複数のEI及び重複したEIをもつバッチ処理
8.7.4.1 利用者要件
次の利用者要件がある。
− 業務情報のバッチ処理での追加及び変更
99
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
注記 前の事例では，オンライン処理を見たが，この事例では，業務情報をバッチ処理で追加するこ
とに焦点を当てる。
8.7.4.2 実装要件
バッチ処理の中で，うまく更新されなかった業務情報は，未確定業務情報ファイルにエラー登録し，後
で個別に維持管理することが決まっている（この要件に関しては，8.7.5を参照。）。
8.7.4.3 レコードレイアウト
この事例でのレコードレイアウトを，図28に示す。
図28−レコードレイアウト
8.7.4.4 レコードのデータ項目
それぞれのレコード型のデータ項目を，表12に示す。
表12−レコードレイアウト表
レコード
カラム位置
データ項目
01
業務
1〜3
4〜5
6〜10
11〜45
46〜47
トランザクション ファンクション型
レコード型
業務番号
業務名称
業務の給与等級
02
業務説明
1〜3
4〜5
6〜10
11〜12
13〜41
トランザクション ファンクション型
レコード型
業務番号
業務説明行の行番号
業務説明
レコード型
01 新規の業務へのレコードの追加
02 新規の業務説明へのレコードの追加
100
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
手順1 要素処理の識別：業務を扱うトランザクション ファンクション型
そのトランザクション ファンクションは，要素処理の
識別規則に適合するか。
当てはまらない。
業務説明のない業務情報は，利用者にとって意味がな
い。
手順1 要素処理の識別：業務説明を扱うトランザクション ファンクション型
そのトランザクション ファンクションは，要素処理の
識別規則に適合するか。
当てはまらない。
業務のない業務説明は，存在できない。
手順1 要素処理の識別業務及び業務説明を扱うトランザクション ファンクション型
そのトランザクション ファンクションは，要素処理の
識別規則に適合するか。
当てはまる。
業務及び業務説明は，利用者にとって意味がある。
手順2 主目的の決定及び分類
そのトランザクション ファンクションは，EIの主目的
を満たすか。
当てはまる。
主目的は，ILFの維持管理である。
手順3 EI識別規則に対する妥当性確認：業務及び業務説明を合わせた確認
EI識別規則
規則の該当・非該当
データ又は制御情報は，アプリケーション境界の外部か
ら入力される。
当てはまる。
アプリケーション境界の外部から入力されたデータが，
システムの振る舞いを変更する制御情報でない場合，少
なくとも一つのILFを維持管理する。
次の項目が当てはまる。
業務ILF及び未確定業務ILF
識別した処理に対して，次の三つのうちいずれか一つを
適用する。
− 処理ロジックが，このアプリケーションの他のEI
によって実行された処理ロジックと異なっている。
− 識別したデータ項目の組が，このアプリケーション
の他のEIについて識別されたデータ要素と異なっ
ている。
− 参照するILF又はEIFが，このアプリケーションの
他のEIについて識別された参照するILF又はEIF
と異なっている。
当てはまる。
この機能はオンライン処理のものとは重複しない。どの
ように異なる妥当性確認規則を適用しても，登録失敗時
に中断した業務に関する要件がある。
対象外。
対象外。
結論：業務及び業務説明を扱うトランザクション ファンクションを合わせて，一つのEIがある。
手順4 複雑さの決定
FTR計測規則
規則の該当・非該当
維持管理される1ILFは，1FTRと計測する。
次の項目が当てはまる。
業務ILF及び未確定業務ILF
EIの処理時に参照されるILF又はEIFは，1FTRと計測
する。
次の項目が当てはまる。
業務ILF
一つのEIの処理時に維持管理され，かつ，参照される
ILFは，1FTRとだけ計測する。
当てはまる。
業務ILFは，維持管理され，参照される。1回だけ計測
する。
101
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
結論：FTRの数は，2となる。
DET計測規則
規則の該当・非該当
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の外部から入力される又はア
プリケーション境界の内部から出力される。
− EI処理を完了するために必要である。
次の項目が当てはまる。
業務番号，業務名称，給与等級，業務説明行の行番号（繰
返し）及び業務説明行（繰返し）
レコード型は，物理的な項目なので計測しない。
システムによって取得又は導出されるデータ項目，及び
ILFに格納されるデータ項目で，要素処理の実行中にそ
のデータ項目がアプリケーション境界をまたがらない
場合は，DETとしては計測しない。
対象外。
処理中のエラー発生の通知，処理の完了確認又は処理続
行の確認のために，アプリケーション境界の外部にシス
テム応答メッセージを出力する機能を1DETと計測す
る。
対象外。
エラー情報は，未確定業務情報ファイルに記録される。
同一の論理的処理を起動する手段が複数ある場合でも，
実施する活動を指定する機能を1DETと計測する。
次の項目が当てはまる。
トランザクション ファンクション型
結論：DETの数は，6となる。
複雑さ
2FTR及び6DET
複雑さは，中である。
手順5 寄与の決定
寄与が1で，複雑さのEIが中
4FPになる。
8.7.5
事例4：未確定業務情報の修正
8.7.5.1 利用者要件
バッチ処理の中で，更新が失敗したすべての業務情報は，未確定業務情報ファイルにエラー登録するこ
とが決まっている。更新が失敗したトランザクションを呼び出して編集する画面の利用者要件がある。
注記 この事例では，未確定業務情報を修正する要件だけに焦点を当てる。
8.7.5.2 データフロー図
この事例のデータフロー図を，図29に示す。
102
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図29−データフロー図
手順1 要素処理の識別
そのトランザクション ファンクションは，要素処理の
識別規則に適合するか。
当てはまる。
手順2 主目的の決定及び分類
そのトランザクション ファンクションは，EIの主目的
を満たすか。
当てはまる。
主目的は，ILFの維持管理である。
手順3 EI識別規則に対する妥当性確認
EI識別規則
規則の該当・非該当
データ又は制御情報は，アプリケーション境界の外部か
ら入力される。
当てはまる。
未確定業務情報を修正するデータは，アプリケーション
境界の外部から入る。
アプリケーション境界の外部から入力されたデータが，
システムの振る舞いを変更する制御情報でない場合，少
なくとも一つのILFを維持管理する。
当てはまる。
業務情報の未確定業務情報ILFが更新される。
利用者
業務及び業務説明
未確定業務情報
バッチでの業務
の追加
バッチでの業務
の変更
未確定業務情報の
維持管理
業務情報報告書
の印刷
業務情報の報
告書
業務及び業務説明の報告書（マイクロフィッシュ）
業務情報及び説明の報告書（紙書類）業務番号，業務名称，給与等級，説明，業務の合計数
修正した未確定ジョブ情報
未確定ジョブ情報の追加，変更，削除
業務トランザク
ションの変更
業務トランザク
ションの追加
ID，業務番号，業務名称，
給与等級
未確定ジョブ情報
業務情報の追加
業務番号，業務名称，給与等級，説明
業務名称，給与等級，説明
業務番号
業務番号，業務名称，給与等級，行番号，説明
103
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
識別した処理に対して，次の三つのうちいずれか一つを
適用する。
− 処理ロジックが，このアプリケーションの他のEI
によって実行された処理ロジックと異なっている。
− 識別したデータ項目の組が，このアプリケーション
の他のEIについて識別されたデータ要素と異なっ
ている。
− 参照するILF又はEIFが，このアプリケーションの
他のEIについて識別された参照するILF又はEIF
と異なっている。
当てはまる。
この機能を実行する他のEIは識別していない。
対象外。
対象外。
結論：一つのEIがある。
手順4 複雑さの決定
FTR計測規則
規則の該当・非該当
維持管理される1ILFは，1FTRと計測する。
次の項目が当てはまる。
未確定業務情報ILF
EIの処理時に参照されるILF又はEIFは，1FTRと計測
する。
次の項目が当てはまる。
未確定業務情報ILF
一つのEIの処理時に維持管理され，かつ，参照される
ILFは，1FTRとだけ計測する。
当てはまる。未確定業務情報ILFは，維持管理され，参
照される。1回だけ計測する。
結論：FTRの数は，1となる。
DET計測規則
規則の該当・非該当
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の外部から入力される又はア
プリケーション境界の内部から出力される。
− EI処理を完了するために必要である。
次の項目が当てはまる。
トランザクション ファンクション型，業務番号，業務
名称，給与等級，業務説明行の行番号（繰返し）及び業
務説明行（繰返し）
レコード型は，物理的な項目なので計測しない。他のデ
ータ項目は，利用者が認識できる。
システムによって取得又は導出されるデータ項目，及び
ILFに格納されるデータ項目で，要素処理の実行中にそ
のデータ項目がアプリケーション境界をまたがらない
場合は，DETとしては計測しない。
対象外。
処理中のエラー発生の通知，処理の完了確認又は処理続
行の確認のために，アプリケーション境界の外部にシス
テム応答メッセージを出力する機能を1DETと計測す
る。
利用者へのメッセージはない。
同一の論理的処理を起動する手段が複数ある場合でも，
実施する活動を指定する機能を1DETと計測する。
次の項目が当てはまる。
入力キー
結論：DETの数は，7となる。
注記 トランザクション型は，未確定業務情報ファイルに保存し，利用者が維持管理する。
複雑さ
1FTR及び7DET
複雑さは，低である。
手順5 寄与の決定
寄与が1で，複雑さが低
3FPになる。
8.7.6
事例5：複数のFTRをもつEI
8.7.6.1 利用者要件
業務割当てを追加する利用者要件がある。
注記 この事例では，業務割当てを追加するという要件だけに焦点を当てる。
104
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
8.7.6.2 画面例
業務割当てを追加するための画面の事例を，図30に示す。
図30−業務割当て設定画面
8.7.6.3 データフロー図
この事例のデータフロー図を，図31に示す。
人事情報システム
社員 業務 割当て 事業所 ヘルプ
業務割当てデータ
前の業務
次の業務
社 員 の 配 属
やまだ
たろう
345-67-8901
本社工場
UFPCA
業務番号
割当て日
給与
査定等級
RD15379305
03/27/2000
17.28
優秀
顧客情報の維持管理
前の業務
次の業務
社員の前の業務割当てがある場合，それを表示
社員の次の業務割当てがある場合，それを表示
105
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図31−データフロー図
業務割当て
利用者
利用者
業務割当て
業務割当て
の追加
業務割当て
の変更
業務割当て
の変更
業務割当て報告書
の印刷
保険証番号，業務番号，発効日，査定等級，給与
氏名
氏名
業務名称
業務名称
保険証番号
業務番号
発効日
査定等級
給与
保険証番号
業務番号（新旧）
発効日
査定等級
給与
発効日
査定等級
給与
保険証番号
業務番号
業務割当て情報
保険証番号
業務番号
発効日
査定等級
給与
氏名
業務名称
保険証番号，氏名
業務番号，業務名称
保険証番号
氏名
業務番号
業務名称
発効日
査定等級
給与
業務割当て報告書
保険証番号
氏名
業務番号
業務名称
従事社員合計
業務
社員
業務
業務割当ての
照会
社員
106
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
手順1 要素処理の識別
そのトランザクション ファンクションは，要素処理の
識別規則に適合するか。
当てはまる。
手順2 主目的の決定及び分類
そのトランザクション ファンクションは，EIの主目的
を満たすか。
当てはまる。
主目的は，ILFの維持管理である。
手順3 EI識別規則に対する妥当性確認
EI識別規則
規則の該当・非該当
データ又は制御情報は，アプリケーション境界の外部か
ら入力される。
当てはまる。
アプリケーション境界の外部から入力されたデータが，
システムの振る舞いを変更する制御情報でない場合，少
なくとも一つのILFを維持管理する。
当てはまる。
業務割当てILFが維持管理される。
識別した処理に対して，次の三つのうちいずれか一つを
適用する。
− 処理ロジックが，このアプリケーションの他のEI
によって実行された処理ロジックと異なっている。
− 識別したデータ項目の組が，このアプリケーション
の他のEIについて識別されたデータ要素と異なっ
ている。
− 参照するILF又はEIFが，このアプリケーションの
他のEIについて識別された参照するILF又はEIF
と異なっている。
当てはまる。
この機能を実行する他のEIは識別していない。
対象外。
対象外。
結論：一つのEIがある。
手順4 複雑さの決定
FTR計測規則
規則の該当・非該当
維持管理される1ILFは，1FTRと計測する。
次の項目が当てはまる。
業務割当てILF
EIの処理時に参照されるILF又はEIFは，1FTRと計測
する。
当てはまる。
業務割当てILFが，参照される。
社員ILFは，社員の存在の確認及び社員氏名を表示する
ために参照される。
業務ILFは，業務の存在の確認及び業務名称を表示する
ために参照される。
一つのEIの処理時に維持管理され，かつ，参照される
ILFは，1FTRとだけ計測する。
当てはまる。
業務割当てILFは，維持管理され，参照される。1回だ
け計測する。
結論：FTRの数は，3となる。
DET計測規則
規則の該当・非該当
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の外部から入力される又はア
プリケーション境界の内部から出力される。
− EI処理を完了するために必要である。
次の項目が当てはまる。
保険者番号，業務番号，発効日，
給与及び査定等級
システムによって取得又は導出されるデータ項目，及び
ILFに格納されるデータ項目で，要素処理の実行中にそ
のデータ項目がアプリケーション境界をまたがらない
場合は，DETとしては計測しない。
この型のデータ項目はない。
107
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
処理中のエラー発生の通知，処理の完了確認又は処理続
行の確認のために，アプリケーション境界の外部にシス
テム応答メッセージを出力する機能を1DETと計測す
る。
次の項目が当てはまる。
エラーメッセージ
同一の論理的処理を起動する手段が複数ある場合でも，
実施する活動を指定する機能を1DETと計測する。
当てはまる。
トランザクションを保存するために，コマンドキーを要
求する。
結論：DETの数は，7となる。
複雑さ
3FTR及び7DET
複雑さは，高である。
手順5 寄与の決定
寄与が1で，複雑さが高
6FPになる。
8.7.7
事例6：データ移行
8.7.7.1 利用者要件
利用者が新しい人事情報システムを購入したときに，既存の社員情報を新しいシステムに移行できる利
用者要件がある。
従来のシステムでは，利用者は社員の扶養家族情報を維持管理することができない。既存の社員情報を
新しいシステムに移行するときに，扶養家族情報は，初期化される。
8.7.7.2 データ図
新旧のシステムのデータ比較を，図32に示す。
図32−新旧システムのデータ比較図
手順1 要素処理の識別
そのトランザクション ファンクションは，要素処理の
要求事項に当てはまるか。
当てはまる。
手順2 主目的の決定及び分類
そのトランザクション ファンクションは，EIの主目的
に当てはまるか。
当てはまる。
主目的は，ILFを維持管理する。
手順3 EI識別規則に対する妥当性確認
従来の人事情報システム
新しい人事情報システム
社員
正社員
非正社員
社員
正社員
非正社員
扶養家族
108
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
EI識別規則
規則の該当・非該当
データ又は制御情報は，アプリケーション境界の外部か
ら入力される。
当てはまる。
従来の人事情報システムの社員情報ファイルからのデ
ータは，アプリケーション境界の外部から入力される。
アプリケーション境界の外部から入力されたデータが，
システムの振る舞いを変更する制御情報でない場合，少
なくとも一つのILFを維持管理する。
当てはまる。
社員情報ILFが維持管理される。
識別した処理に対して，次の三つのうちいずれか一つを
適用する。
− 処理ロジックが，このアプリケーションの他のEI
によって実行された処理ロジックと異なっている。
− 識別したデータ項目の組が，このアプリケーション
の他のEIについて識別されたデータ要素と異なっ
ている。
− 参照するILF又はEIFが，このアプリケーションの
他のEIについて識別された参照するILF又はEIF
と異なっている。
当てはまる。
この機能を実行する他のEIは識別していない。
対象外。
対象外。
結論：1EIがある。
手順4 複雑さの決定
FTR計測規則
規則の該当・非該当
維持管理される1ILFは，1FTRと計測する。
社員情報ILFが維持管理される。
EIの処理時に参照されるILF又はEIFは，1FTRと計測
する。
社員情報ILFが参照される。
一つのEIの処理時に維持管理され，かつ，参照される
ILFは，1FTRとだけ計測する。
社員情報ILFは，維持管理され，参照される。1回だけ
計測する。
結論：FTRの数は，1となる。
DET計測規則
規則の該当・非該当
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の外部から入力される又はア
プリケーション境界の内部から出力される。
− EI処理を完了するために必要である。
社員氏名，保険者番号，扶養家族数，種別コード，職位，
標準時給，労働組合番号，扶養家族保険者番号，扶養家
族氏名，扶養家族生年月日，事業所名
システムによって取得又は導出されるデータ項目，及び
ILFに格納されるデータ項目で，要素処理の実行中にそ
のデータ項目がアプリケーション境界をまたがらない
場合は，DETとしては計測しない。
この型のDETはない。
処理中のエラー発生の通知，処理の完了確認又は処理続
行の確認のために，アプリケーション境界の外部にシス
テム応答メッセージを出力する機能を1DETと計測す
る。
対象外。
同一の論理的処理を起動する手段が複数ある場合でも，
実施する活動を指定する機能を1DETと計測する。
対象外。
結論：DETの数は，11となる。
複雑さ
1FTR及び11DET
複雑さは，低である。
手順5 寄与の決定
寄与が1で，複雑さが低
3FPになる。
109
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
8.7.8
事例7：他システムからのデータ参照
8.7.8.1 利用者要件
人事情報システムに対する次の利用者要件がある。
− すべての非正社員には，円建てで支払わなければならない。
− 利用者が社員情報を追加及び変更する場合，人事情報システムは，為替システムを利用し，為替レー
トを取り出さなければならない。為替レートを取り出した後，人事情報システムは，社員の現地標準
時給を次の式を使用して円建て時給に変換する。
標準時給
為替レート
= 円建て時給
この事例のファイルの関係を，図33に示す。
凡例:
必す(須)の1対多の関係
任意の1対多の関係
属性実体型
実体型
実体副型
図33−ファイルの関係図
8.7.8.2 変換の情報
変換のための情報を，次に示す。
為替ファイル
− 為替基準に対する為替レート
− 国名
手順1 要素処理の識別
そのトランザクション ファンクションは，要素処理の
要求事項に当てはまるか。
当てはまらない。
データの参照は，社員の追加と連携したときにだけ，意
味がある。
為替システム
人事情報システム
為替レート
社員
正社員
非正社員
扶養家族
110
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
結論：変換情報の検索について，EIは識別できない。変換情報がEIFとして計測されるかもしれない理由
を知るためには，箇条6のEIFの計測例を参照する。
8.7.9
事例8：画面情報出力を伴うEI（その1）
8.7.9.1 利用者要件
利用者は，顧客への売上情報が保存できることを要求している。個々の商品の売上金額を表示しなけれ
ばならない。さらに，売上の合計値は，売上情報を保存する前に，確認のために表示しなければならない。
8.7.9.2 画面情報出力の事例
次の売上画面情報は，出力項目をどう計測するかを示すために単純化される。利用者は，顧客名及び売
上データを入力する。各商品及び個数を入力すると，システムは，図34のように売上合計などを計算して
表示する。
図34−出力例
手順1 要素処理の識別
そのトランザクション ファンクションは，要素処理の
要求事項に当てはまるか。
当てはまる。
手順2 目的の決定及び分類
そのトランザクション ファンクションは，EIの主目的
に当てはまるか。
当てはまる。
主目的は，ILFを維持管理する。
手順3 EI識別規則に対する妥当性確認
EI識別規則
規則の該当・非該当
データ又は制御情報は，アプリケーション境界の外部か
ら入力される。
当てはまる。
売上データがアプリケーション境界の外部から入力さ
れる。
アプリケーション境界の外部から入力されたデータが，
システムの振る舞いを変更する制御情報でない場合，少
なくとも一つのILFを維持管理する。
当てはまる。
売上情報ILFが維持管理される。
売上情報
顧客名：
作成日：
商 品 個数 単価 金額
¥ . ¥ .
¥ . ¥ .
¥ . ¥ .
¥ . ¥ .
¥ . ¥ .
¥ . ¥ .
税抜き合計：¥ .
消費税 ：¥ .
売上合計 ：¥ .
F1：保存
111
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
識別した処理に対して，次の三つのうちいずれか一つを
適用する。
− 処理ロジックが，このアプリケーションの他のEI
によって実行された処理ロジックと異なっている。
− 識別したデータ項目の組が，このアプリケーション
の他のEIについて識別されたデータ要素と異なっ
ている。
− 参照するILF又はEIFが，このアプリケーションの
他のEIについて識別された参照するILF又はEIF
と異なっている。
当てはまる。
この機能を実行する他のEIは識別していない。
対象外。
対象外。
結論：一つのEIがある。
手順4 複雑さの決定
FTR計測規則
規則の該当・非該当
維持管理される1ILFは，1FTRと計測する。
当てはまる。
売上情報ILFが，維持管理される。
EIの処理時に参照されるILF又はEIFは，1FTRと計測
する。
当てはまる。
商品ILFが，商品金額を表示するために参照される。
一つのEIの処理時に維持管理され，かつ，参照される
ILFは，1FTRとだけ計測する。
対象外。
売上情報ILFは，維持管理され，参照される。一回だけ
計測する。
結論：FTRの数は，2となる。
DET計測規則
規則の該当・非該当
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の外部から入力される又はア
プリケーション境界の内部から出力される。
− EI処理を完了するために必要である。
当てはまる。
次の入力DETを計測する。
顧客名，作成日，商品（繰返し）及び個数（繰返し）
次の出力DETを計測する。
単価（繰返し），金額（繰返し），税抜き合計，消費税
及び売上合計
システムによって取得又は導出されるデータ項目，及び
ILFに格納されるデータ項目で，要素処理の実行中にそ
のデータ項目がアプリケーション境界をまたがらない
場合は，DETとしては計測しない。
出力DETを計測する。これらは導出データであり，ア
プリケーション境界をまたがる。
処理中のエラー発生の通知，処理の完了確認又は処理続
行の確認のために，アプリケーション境界の外部にシス
テム応答メッセージを出力する機能を1DETと計測す
る。
当てはまる。
エラー発生時，利用者へのメッセージを返す。
同一の論理的処理を起動する手段が複数ある場合でも，
実施する活動を指定する機能を1DETと計測する。
当てはまる。
保存を指示するF1キーを押す。
結論：DETの数は，11となる。
複雑さ
2FTR及び11DET
複雑さは，中である。
手順5 寄与の決定
寄与が1で，複雑さが中
4FPになる。
8.7.10 事例9：画面情報出力を伴うEI（その2）
8.7.10.1 利用者要件
業務を社員に割り当てることができることを要求している。社員及び業務を選択するために，二つのド
ロップダウンリストを使用して，社員ファイル及び業務情報ファイルを参照する利用者要件がある。社員
112
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
一覧は，社員番号及び社員氏名を表示する必要がある。業務情報一覧は，業務番号及び業務説明を表示す
る必要がある。業務に割り当てられた社員の社員番号は，その記録を保存した後で表示する。
8.7.10.2 画面情報出力の事例
次の業務割当て画面情報は，出力項目をどう計測するかを示すために単純化される。利用者は，社員番
号及び社員氏名を示すドロップダウンリストから社員を選択する。選択作業において，人事情報システム
は，業務割当てのために社員番号を必要とする。利用者は，業務番号及び業務説明を示すドロップダウン
リストから，業務を選択する。人事情報システムは，業務割当てのために業務番号が必要である。業務割
当てを保存するときに，人事情報システムは，その業務に割り当てる社員の人数を計算して，利用者に画
面表示する。
図35−業務割当て表示画面
社員及び業務についての二つの質問は，二つの独立した要素処理（2EQ）であることは明白である。こ
こでは，その点について分析しない。
手順1 要素処理の識別
そのトランザクション ファンクションは，要素処理の
要求事項に当てはまるか。
当てはまる。
手順2 主目的の決定及び分類
そのトランザクション ファンクションは，EIの主目的
に当てはまるか。
当てはまる。
主目的は，ILFを維持管理する。
手順3 EI識別規則に対する妥当性確認
EI識別規則
規則の該当・非該当
データ又は制御情報は，アプリケーション境界の外部から
入力される。
当てはまる。
人事情報システム
社員 業務 割当て 事業所 ヘルプ
業務割当て
社員番号
業務番号
割当て日
1290
03/27/2000
1290 日本 太郎
0100
0100 購買
保存
この業務に割り当てた社員の合計
3
113
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
アプリケーション境界の外部から入力されたデータが，シ
ステムの振る舞いを変更する制御情報でない場合，少なく
とも一つのILFを維持管理する。
当てはまる。
業務割当てILFが維持管理される。
識別した処理に対して，次の三つのうちいずれか一つを適
用する。
− 処理ロジックが，このアプリケーションの他のEIに
よって実行された処理ロジックと異なっている。
− 識別したデータ項目の組が，このアプリケーションの
他のEIについて識別されたデータ要素と異なってい
る。
− 参照するILF又はEIFが，このアプリケーションの他
のEIについて識別された参照するILF又はEIFと異
なっている。
当てはまる。
この機能を実行する他のEIは識別していない。
対象外。
対象外。
結論：業務割当てをすることは，一つのEIとなる。
手順4 複雑さの決定
FTR計測規則
規則の該当・非該当
維持管理される1ILFは，1FTRと計測する。
当てはまる。
業務割当てILFが，維持管理される。
EIの処理時に参照されるILF又はEIFは，1FTRと計測
する。
当てはまる。
業務割当てILFが，参照される。
一つのEIの処理時に維持管理され，かつ，参照される
ILFは，1FTRとだけ計測する。
当てはまる。
業務割当てILFが，維持管理され，参照される。1回だ
け計測する。
結論：FTRの数は，1となる。
DET計測規則
規則の該当・非該当
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の外部から入力される又はア
プリケーション境界の内部から出力される。
− EI処理を完了するために必要である。
当てはまる。
次の入力DETを計測する。
社員番号，業務番号及び割当て日
次の出力DETを計測する。
業務に割り当てた社員
ドロップダウンリストの社員氏名及び業務名称は，独立
したEQの一部分であるので，DETとして数えない。
システムによって取得又は導出されるデータ項目，及び
ILFに格納されるデータ項目で，要素処理の実行中にそ
のデータ項目がアプリケーション境界をまたがらない
場合は，DETとしては計測しない。
出力DETを計測する。これらは導出データであり，ア
プリケーション境界をまたがる。
処理中のエラー発生の通知，処理の完了確認又は処理続
行の確認のために，アプリケーション境界の外部にシス
テム応答メッセージを出力する機能を1DETと計測す
る。
当てはまる。
エラー発生時の，利用者へのメッセージを返す。
同一の論理的処理を起動する手段が複数ある場合でも，
実施する活動を指定する機能を1DETと計測する。
当てはまる。
保存を指示する唯一の保存キーがある。
結論：DETの数は，6となる。
複雑さ
1FTR及び6DET
複雑さは，低である。
手順5 寄与の決定
寄与が1で，複雑さが低
3FPになる。
114
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
8.7.11 EI，FTR及びDET計測の概要
ここでは，未調整ファンクションポイントへの複雑さ及び寄与を計算する前に，計測されたEI，FTR及
びDETの概要を示す。
8.7.11.1 EI識別の概要
次の表は，人事情報システムについてEIとして識別したデータを示す。同時に，EIとして識別しなか
ったデータも示す。
EIとして識別したデータ
EIとして識別しなかったデータ
業務割当て報告書の制御情報
他のアプリケーションからのデータの参照
業務情報の追加（画面入力）
業務情報の追加（バッチ入力）
退避トランザクションの修正
社員への業務割当て
社員情報の移行
画面情報出力を伴うEI その1
画面情報出力を伴うEI その2
8.7.11.2 FTR及びDET計測の概要
FTR及びDETの計測結果を次の表に示す。
EI
FTR
DET
業務割当て報告書の制御情報
1
5
業務情報の追加（画面入力）
1
7
業務情報の追加（バッチ入力）
2
6
退避トランザクションの修正
1
7
社員への業務割当て
3
7
社員情報の移行
1
11
画面情報出力を伴うEI その1
2
11
画面情報出力を伴うEI その2
1
6
8.7.12 EIの複雑さ及び寄与
最後に，未調整ファンクションポイントに対するEIの複雑さ及び寄与を決定するための最終手順を示す。
最終手順は，次のとおりである。
a) EIの複雑さを評価する。
b) 未調整ファンクションポイントに対する複雑さを寄与に変換する。
c) 未調整ファンクションポイントの合計に対するEI全体の寄与を計算する。
8.7.12.1 EIの複雑さの評価
次の複雑さの表によって，EIの複雑さを評価する。
1〜4 DET
5〜15 DET
16 DET以上
0〜1 FTR
低
低
中
2 FTR
低
中
高
3 FTR以上
中
高
高
次の表は，各EIに対するファンクションの複雑さを示す。
EI
FTR
DET
ファンクションの複雑さ
業務割当て報告書の制御情報
1
5
低
業務情報の追加（画面入力）
1
7
低
業務情報の追加（バッチ入力）
2
6
中
退避トランザクションの修正
1
7
低
社員への業務割当て
3
7
高
115
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
社員情報の移行
1
11
低
画面情報出力を伴うEI その1
2
11
中
画面情報出力を伴うEI その2
1
6
低
8.7.12.2 EIの寄与への変換
次の表で，EIの複雑さを寄与に変換する。
ファンクションの複雑さの評価
未調整ファンクションポイント
低
3
中
4
高
6
複雑さは，次の細分箇条の表に記録する。
8.7.12.3 EIの寄与の合計の計算
次の表で，EIのファンクション型に対する寄与の合計を計算する。
ファンクション型
ファンクションの複雑さ
複雑さの合計
ファンクション型の合計
EI
5 低
× 3 ＝ 15
29
2 中
× 4 ＝ 8
1 高
× 6 ＝ 6
この合計は，すべてのファンクションを一覧にする表に記録される。すべてのファンクション型に対す
る最終合計が，未調整ファンクションポイントとなる。
8.8
EOの計測事例
ここでは，人事情報システムを例にして，EO計測手順を示す。
8.8.1
EO計測事例の概要
EOの計測事例を，表13に示す。
表13−事例一覧
事例
概要
紙書類報告書の出力
紙書類報告書の計測を示す事例
オンライン報告
オンライン報告の計測を示す事例
他のシステムへの送信トランザクション
あるアプリケーションで作成され，他のアプリケーションに送ら
れるトランザクションを示す事例
エラーメッセージ又は確認メッセージ
エラーメッセージ又は確認メッセージをEIと計測しない理由を示
す事例
通知メッセージ
通知メッセージを計測する方法を示す事例
アプリケーション境界の外部から，データなし
に起動されるEO
EOが，アプリケーション境界の外部から，データなしで起動され
る概念を示す事例
EOの主機能
EOがファイルを更新できることを示す事例
EOトランザクション ファイル
計算処理があることが，要素処理をEQではなくEOであると決定
することを示す事例
8.8.2
すべてのトランザクション ファンクション型に共通の規則
すべての事例を分析する手順は，箇条8の初めで記述した手順に従う。手順は，要素処理の識別，主目
的及びトランザクション ファンクション型のEI，EO及びEQへの分類という規則を適用することによる。
次の表に適用されなければならない規則を一覧表示する。
要求処理の識別規則
規則の該当・非該当
その処理は，利用者にとって意味のある業務活動の最小単位である。
その処理は，自己完結しており，計測するアプリケーションが実行する業務を
矛盾のない状態にするものである。
116
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
トランザクション ファンクション型が要素処理となるためには，二つの識別規則のいずれの質問に対し
ても，“当てはまる”でなければならない。
表14−トランザクション ファンクション型の主目的
主目的
EI
ILFの維持管理又はシステムの振る舞いの変更
EO
利用者への情報の提供
“数式又は演算の実行”，導出データの提供又は“一つ以上のILFの更新又はシステムの振る舞い
の変更”
EQ
利用者への情報の提供
一つ以上のILF又はEIFから取得したデータだけの提供
EI，EO及びEQのいずれであるかを決定するために，トランザクション ファンクション型の主目的に
最もよく適合する記述を使用する。これは，ファンクションに対する利用者要件を注意深く，かつ，正確
に解釈することで決定できる。
8.8.3
事例1：紙書類報告書の出力
8.8.3.1 利用者要件
社員の業務割当て一覧を出力する利用者要件がある。
この報告書は，次を検索することによって作成する。
− 業務割当てILFからの業務割当て情報
− 社員情報ILF及び業務情報ILFからの追加情報
報告書の作成方法を決定するために，報告書制御ILFを参照する。
8.8.3.2 報告書の例
次の業務の社員割当て一覧は，業務及びその業務に割り当てた社員の一覧を示す。
図36−報告書出力例
HRS006 人事情報システム ページ 1
業務の社員割当て一覧 3／27／2000
業務番号 業務名称 社員保険証番号 社員氏名
9901 xxxxxxxxxxxxxxxxx nnn-nn-nnnn aaaa aaaaaa
mmm-mm-mmmm bbb bbbbbbb
lll-ll-llll cccccc cccccc
9902 yyyyyyyyyyyyyyyyy ppp-pp-pppp ddddd ddddd
9903 zzzzzzzz qqq-qq-qqqq eeeeee eeeeeeee
117
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
手順1 要素処理の識別
そのトランザクション ファンクションは，要素処理の
要求事項に当てはまるか。
当てはまる。
手順2 主目的の決定及び分類
そのトランザクション ファンクションは，EOの主目的
に当てはまるか。
当てはまる。
報告書は，計算項目を含む。
手順3 EO識別規則に対する妥当性確認
EO識別規則
規則の該当・非該当
アプリケーション境界の外部へデータ又は制御情報を
出力する機能である。
当てはまる。
報告書データは，アプリケーション境界の外部へ出力さ
れる。
識別した処理に対して，次の三つのうちいずれか一つを
適用する。
− 処理ロジックが，このアプリケーションの他のEO
又は EQによって実行された処理ロジックと異な
っている。
− 識別したデータ要素の組が，このアプリケーション
の他のEO又はEQについて識別されたデータ要素
と異なっている。
− 参照するILF又はEIFが，このアプリケーションの
他のEO又はEQについて識別された参照するILF
又はEIFと異なっている。
当てはまる。
この機能を実行する他のEOは識別していない。
対象外。
対象外。
次の規則のうちいずれか一つが適用される。
− 要素処理の処理ロジックが，少なくとも一つの“数
式又は演算の実行”を含む。
− 要素処理の処理ロジックが，少なくとも一つのILF
を維持管理する。
− 要素処理の処理ロジックが，導出データを生成する。
− 要素処理の処理ロジックが，システムの振る舞いを
変更する。
当てはまる。
業務の合計値は，計算項目である。
対象外。
対象外。
対象外。
結論：業務の社員割当て一覧に対して，1EOとなる。
手順4 複雑さの決定
FTR計測規則
規則の該当・非該当
要素処理の実行時に参照される各ILF又は各EIFは，
1FTRと計測する。
当てはまる。
次のILFが，参照される。
社員，業務，業務割当て，報告書制御
要素処理の実行時に維持管理される各ILFは，1FTRと
計測する。
当てはまらない。
維持管理されるILFはない。
要素処理の実行時に維持管理され，参照される各ILFは，
1FTRとだけ計測する。
対象外。
結論：FTRの数は，4となる。
DET計測規則
規則の該当・非該当
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の外部から入力される。
− 要素処理がデータをいつ，何を，どのように取得又
は生成するかを特定するために必要である。
対象外。
118
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の内部から出力される。
業務合計，業務番号，業務名称，社員保険者番号及び社
員氏名を報告する。各項目は，1回だけ計測する。
あるDETがアプリケーション境界の外部から入力され，
外部にも出力される場合，その要素処理に対して1DET
とだけ計測する。
対象外。
処理中のエラー発生の通知，処理の完了確認又は処理続
行の確認のために，アプリケーション境界の外部にシス
テム応答メッセージを出力する機能を1DETと計測す
る。
対象外。
同一の論理的処理を起動する手法が複数ある場合でも，
実施する活動を指定する機能を1DETと計測する。
対象外。
システムによって取得又は導出されるデータ項目，及び
ILFに格納されるデータ項目で，要素処理の実行中にそ
のデータ項目がアプリケーション境界をまたがらない
場合は，DETとしては計測しない。
対象外。
文字列はDETとしては計測しない。
ページ変数又はシステムが生成するスタンプは，計測し
ない。
結論：DETの数は，5となる。
複雑さ
4FTR及び5DET
複雑さは，中である。
手順5 寄与の決定
寄与が1で，複雑さが中
5FPになる。
8.8.4
事例2：オンライン報告
8.8.4.1 利用者要件
現在の業務割当ての継続期間の降順による社員一覧の出力の利用者要件がある。
この一覧は，オンラインで表示する。また，導出データ（例えば，業務割当て継続期間など）を含む。
8.8.4.2 画面の例
次の割当て期間による社員一覧の画面は，割当て継続期間順に社員を表示する。
図37−社員一覧表示画面
割当て継続期間による社員一覧
1〜18行／1，316行 3／27／2000
保険証番号 社員氏名 業務番号 業務名称 割当て継続期間
nnn-nn-nnnn aaaaaaaaaaa 9901 xxxxxxxxxxxxx 99か月
ppp-pp-pppp dddddddddd 9902 yyyyyyyyyyyyyy 54か月
lll-ll-llll cccccccccccc 9901 xxxxxxxxxxx 36か月
mmm-mm-mmmm bbbbbbbbbbb 9901 xxxxxxxxxxxxx 11か月
割当て期間が24か月を超える社員 320名
割当て期間が12か月を超える社員 553名
F1＝ヘルプ F7＝スクロールアップ F8＝スクロールダウン F16＝終了
119
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
手順1 要素処理の識別
そのトランザクション ファンクションは，要素処理の
要求事項に当てはまるか。
当てはまる。
手順2 主目的の決定及び分類
そのトランザクション ファンクションは，EOの主目的
に当てはまるか。
当てはまる。
一覧は，計算項目を含む。
手順3 EO識別規則に対する妥当性確認
EO識別規則
規則の該当・非該当
アプリケーション境界の外部へデータ又は制御情報を
出力する機能である。
当てはまる。
社員データは，アプリケーション境界の外部へ出力され
る。
識別した処理に対して，次の三つのうちいずれか一つを
適用する。
− 処理ロジックが，このアプリケーションの他のEO
又はEQによって実行された処理ロジックと異なっ
ている。
− 識別したデータ項目の組が，このアプリケーション
の他のEO又はEQについて識別されたデータ要素
と異なっている。
− 参照するILF又はEIFが，このアプリケーションの
他のEO又はEQについて識別された参照するILF
又はEIFと異なっている。
当てはまる。
この機能を実行する他のEOがない。
対象外。
対象外。
識別した処理に対して，次の四つのうちいずれか一つを
適用する。
− 要素処理の処理ロジックが，少なくとも一つの数式
又は演算を含む。
− 要素処理の処理ロジックが，少なくとも一つのILF
を維持管理する。
− 要素処理の処理ロジックが，導出データを生成する。
− 要素処理の処理ロジックが，システムの振る舞いを
変更する。
当てはまる。
対象外。
当てはまる。
対象外。
結論：割当て継続期間による社員一覧は，1EOとなる。
手順4 複雑さの決定
FTR計測規則
規則の該当・非該当
要素処理の実行時に参照される各ILF又は各EIFは，
1FTRと計測する。
当てはまる。
次のILFが，参照される。
社員，業務，業務割当て
要素処理の実行時に維持管理される各ILFは，1FTRと
計測する。
当てはまらない。
維持管理されるILFはない。
要素処理の実行時に維持管理され，参照される各ILFは，
1FTRとだけ計測する。
対象外。
結論：FTRの数は，3となる。
DET計測規則
規則の該当・非該当
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の外部から入力される。
− 要素処理がデータをいつ，何を，どのように取得又
は生成するかを特定するために必要である。
対象外。
120
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の内部から出力される。
割当て継続期間が24か月を超える社員の合計人数及び
割当て継続期間が12か月を超える社員の合計人数，保
険者番号，社員氏名，業務番号，業務名称並びに割当て
継続期間は，繰り返し表示する。各項目は1回だけ計測
する。
あるDETがアプリケーション境界の外部から入力され，
外部にも出力される場合，その要素処理に対して1DET
とだけ計測する。
対象外。
処理中のエラー発生の通知，処理の完了確認又は処理続
行の確認のために，アプリケーション境界の外部にシス
テム応答メッセージを出力する機能は，1DETと計測す
る。
対象外。
同一の論理的処理を起動する手段が複数あっても，処理
を指定する機能を1DETと計測する。
対象外。
要素処理の実行中にシステムによって取得又は導出さ
れて，ILFに格納されるデータ項目は，そのデータ項目
がアプリケーション境界をまたがらない場合，DETとし
ては計測しない。
対象外。
文字列はDETとしては計測しない。
ページ変数又はシステムが生成するスタンプは計測し
ない。
結論：DETの数は，7となる。
複雑さ
3FTR及び7DET
複雑さは，中である。
手順5 寄与の決定
寄与が1で，複雑さが中
5FPになる。
8.8.5
事例3：他のシステムへの送信トランザクション
8.8.5.1 利用者要件
人事情報システムで，社員扶養家族データを追加する場合に，福祉手当の記録との一貫性を維持するた
めに，この追加情報を福利厚生システムにも送信する利用者要件がある。毎日，この情報を福利厚生シス
テムに送信する。
8.8.5.2 実装要件
扶養家族データを追加する場合，その情報を出力トランザクションファイル上で適切に書式を設定する。
要求を実現するとき，福祉手当の情報とともに，ヘッダ及びトレーラレコードを含むことを決めた。こ
れらのレコードは，福利厚生システムによって，ファイルを転送するときに技術的に誤りがなかったこと
を保証するために使用される。
8.8.5.3 レコードレイアウト例
次の社員扶養家族のレコードレイアウトは，扶養家族の追加及び変更に関する情報を含んでいる。
121
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図38−レコードレイアウト
8.8.5.4 項目説明
レコード内の各項目の説明を，表15に示す。
表15−レコードレイアウト表
レコード種別
カラム位置
データ項目
ヘッダ
1
レコード種別H
2〜13
ファイル名
14〜19
作成日
扶養家族
1
レコード種別D
2〜10
社員保険者番号
11〜19
扶養家族保険者番号
20〜39
扶養家族名
40〜45
扶養家族生年月日
トレーラ
1
レコード種別T
2〜10
レコードの合計数
手順1 要素処理の識別−ヘッダ
このトランザクション ファンクションは，要素処理の
要求事項に当てはまるか。
当てはまらない。
ヘッダは，利用者にとって意味のあるデータを含んでい
ない。
手順1 要素処理の識別−トレーラ
このトランザクション ファンクションは，要素処理の
要求事項に当てはまるか。
当てはまらない。
トレーラは，利用者にとって意味のあるデータを含んで
いない。
手順1 要素処理の識別−扶養家族
このトランザクション ファンクションは，要素処理の
要求事項に当てはまるか。
当てはまる。
トランザクション ファイルの扶養家族部分は，要素処
理の要求事項を満たしている。
122
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
手順2 主目的の決定及び分類−扶養家族
トランザクション ファンクションはEOの主目的に当
てはまるか。
不確かであり，EO識別規則に照らし合わせなければな
らない。
手順3 扶養家族部分のEO識別規則に対する妥当性確認
EO識別規則
規則の該当・非該当
アプリケーション境界の外部へデータ又は制御情報が
出力される。
当てはまる。
出力トランザクション ファイルは，福利厚生システム
に転送されたデータを含む。
識別した処理に対して，次のいずれか一つが当てはま
る。
− 処理ロジックが，このアプリケーションの他のEO
又はEQのものと異なっている。
− 識別したデータ項目の組が，このアプリケーション
の他のEO又はEQのものと異なっている。
− 参照するILF又はEIFが，このアプリケーションの
他のEO又はEQのものと異なっている。
当てはまる。
この機能を実行する他のEOがない。
対象外。
対象外。
識別した処理に対して，次のいずれか一つが当てはま
る。
− 要素処理の処理ロジックが，少なくとも一つの数式
又は演算を含む。
− 要素処理の処理ロジックが，少なくとも1個のILF
を維持管理する。
− 要素処理の処理ロジックが，導出データを生成する。
− 要素処理の処理ロジックが，システムの振る舞いを
変更する。
当てはまらない。
当てはまらない。
当てはまらない。
当てはまらない。
結論：この機能はEOとしてみなされない。EQとして識別するが，ここでは説明しない。
8.8.6
事例4：エラーメッセージ又は確認メッセージ
8.8.6.1 利用者要件
業務情報を維持管理するときのメッセージ出力についての利用者要件がある。具体的にいうと，利用者
は，誤りを変更若しくは確認したことを知らせるメッセージ，又は処理が正常に終了したことを知らせる
メッセージを要求している。
8.8.6.2 画面例
図39の業務画面の一番下に，確認メッセージを示す。
123
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
動作□ 7＝前画面 8＝次画面
内容
業務番号：
RD15379305
業務名称：
顧客情報の更新
給与等級：
JRNY05A
行番号
業務内容
01
5月次関東地区上顧客リスト更新
F1＝ヘルプ F7＝スクロールアップ F8＝スクロールダウン F12＝キャンセル
処理は，正常終了しました。
図39−業務確認画面
手順1 要素処理の識別 − ヘッダ
このトランザクション ファンクションは，要素処理の
要求事項に当てはまるか。
当てはまらない。
エラーメッセージの出力は，要素処理ではない。EIにつ
いてDETとして計測される。
これ以上の分析は必要ない。
8.8.7
事例5：通知メッセージ
8.8.7.1 利用者要件
社員の業務割当て継続期間が12か月に達したとき，自動的にメッセージを通知する利用者要件がある。
これは，勤務評定が完了していることが望ましいということを示している。
8.8.7.2 画面例
図40の勤務評定画面に通知メッセージを示す。
図40−考課通知画面
−
勤務評定
日付：XX/XX/XX
時間：hh.mm
社員番号：XX-XX-XXX
X X
割当て継続期間が12か月を超えた業務
業務：XXXX X X
早急に勤務評定を計画することが望ましい。
124
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
手順1 要素処理の識別
このトランザクション ファンクションは，要素処理の
要求事項に当てはまるか。
当てはまる。
手順2 主目的の決定及び分類
トランザクション ファンクションはEOの主目的に当
てはまるか。
当てはまる。
12か月の完了日を計算する。
手順3 EO識別規則適合の検証
EO識別規則
規則の該当・非該当
アプリケーション境界の外部へデータ又は制御情報が
出力される。
当てはまる。
通知データは，アプリケーション境界の外部へ出力され
る。
識別された処理に対して，次のいずれか一つが当てはま
る。
− 処理ロジックが，このアプリケーションの他のEO
又は EQのものと異なっている。
− 識別したデータ項目の組が，このアプリケーション
の他のEO又はEQのものと異なっている。
− 参照するILF又はEIFが，このアプリケーションの
他のEO又はEQのものと異なっている。
当てはまる。
この機能を実行する他のEOがない。
対象外。
対象外。
識別した処理に対して，次のいずれか一つが当てはま
る。
− 要素処理の処理ロジックが，少なくとも一つの数式
又は演算を含む。
− 要素処理の処理ロジックが，少なくとも一つのILF
を維持管理する。
− 要素処理の処理ロジックが，導出データを生成する。
− 要素処理の処理ロジックが，システムの振る舞いを
変更する。
当てはまる。
12か月の完了日を計算する。
対象外。
対象外。
対象外。
結論：通知メッセージは，一つのEOとなる。
手順4 複雑さの決定
FTR計測規則
規則の該当・非該当
要素処理の実行時に参照される各ILF又は各EIFは，
1FTRと計測する。
当てはまる。
次のILFが，参照される。
社員，業務及び業務割当て
要素処理の実行時に維持管理される各ILFは，1FTRと
計測する。
対象外。
要素処理の実行時に維持管理され，参照される各ILFは，
1FTRとだけ計測する。
対象外。
結論：FTRの数は，3となる。
DET計測規則
規則の該当・非該当
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の外部から入力される。
− 要素処理がデータをいつ，何を，どのように取得又
は生成するかを特定するために必要である。
対象外。
125
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の内部から出力される。
当てはまる。
社員保険者番号，社員氏名，業務番号及び業務名称。
あるDETがアプリケーション境界の外部から入力され，
外部にも出力される場合，その要素処理に対して1DET
とだけ計測する。
対象外。
処理中のエラー発生の通知，処理の完了確認又は処理続
行の確認のために，アプリケーション境界の外部にシス
テム応答メッセージを出力する機能は，1DETと計測す
る。
対象外。
同一の論理的処理を起動する手段が複数あっても，処理
を指定する機能を1DETと計測する。
対象外。
要素処理の実行中にシステムによって取得又は導出さ
れて，ILFに格納されるデータ項目は，そのデータ項目
がアプリケーション境界をまたがらない場合，DETとし
ては計測しない。
文字列は，DETとしては計測しない。
ページ変数又はシステムが生成するスタンプは計測し
ない。
結論：DETの数は，4となる。
複雑さ
3FTR及び4DET
複雑さは，低である。
手順5 寄与の決定
寄与が1で，複雑さが低
4FPになる。
8.8.8
事例6：アプリケーション境界の外部から，データなしに起動されるEO
8.8.8.1 利用者要件
毎日曜日の午後11時00分に自動的に週次社員情報印刷の実行の利用者要件がある。報告には，それぞ
れの社員の詳細及び合計社員数を含む。
8.8.8.2 データモデル
この事例のデータフロー図を，図41に示す。
図41−データフロー図
週次社員情報の印刷
週次社員情報
氏名 事業所
土井 洋一 東京
玉田 圭史 名古屋
中田 英二 鹿嶋
川口 義男 磐田
中村 俊一 横浜
小野 信介 広島
高原 直行 神戸
宮本 恒夫 大阪
中沢 裕二 横浜
稲本 純一 大阪
遠藤 康人 京都
合計社員数：11名
社員ILF
保険証番号
名前
事業所
126
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
手順1 要素処理の識別
このトランザクション ファンクションは，要素処理の
要求事項に当てはまるか。
当てはまる。
手順2 主目的の決定及び分類
トランザクション ファンクションはEOの主目的に当
てはまるか。
当てはまる。
報告は，計算項目を含む。
手順3 EO識別規則適合の検証
EO識別規則
規則の該当・非該当
アプリケーション境界の外部へデータ又は制御情報が
出力される。
当てはまる。
報告データは，アプリケーション境界の外部へ出力され
る。
識別した処理に対して，次のいずれか一つが当てはま
る。
− 処理ロジックが，このアプリケーションの他のEO
又はEQのものと異なっている。
− 識別したデータ項目の組が，このアプリケーション
の他のEO又はEQのものと異なっている。
− 参照するILF又はEIFが，このアプリケーションの
他のEO又はEQのものと異なっている。
当てはまる。
この機能を実行する他のEOがない。
対象外。
対象外。
識別した処理に対して，次のいずれか一つが当てはま
る。
− 要素処理の処理ロジックが，少なくとも一つの数式
又は演算を含む。
− 要素処理の処理ロジックが，少なくとも一つのILF
を維持管理する。
− 要素処理の処理ロジックが，導出データを生成する。
− 要素処理の処理ロジックが，システムの振る舞いを
変更する。
当てはまる。
社員の合計が計算されている。
対象外。
対象外。
対象外。
結論：週次の社員週報は，EOとなる。
手順4 複雑さの決定
FTR計測規則
規則の該当・非該当
要素処理の実行時に参照される各ILF又は各EIFは，
1FTRと計測する。
次の項目が当てはまる。
社員情報
要素処理の実行時に維持管理される各ILFは，1FTRと
計測する。
当てはまらない。
維持管理されるILFはない。
要素処理の実行時に維持管理され，参照される各ILFは，
1FTRとだけ計測する。
対象外。
結論：FTRの数は，1となる。
DET計測規則
規則の該当・非該当
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の外部から入力される。
− 要素処理がデータをいつ，何を，どのように取得又
は生成するかを特定するために必要である。
当てはまらない。
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の内部から出力される。
社員氏名，事業所及び合計社員数。
127
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
あるDETがアプリケーション境界の外部から入力され，
外部にも出力される場合，その要素処理に対して1DET
とだけ計測する。
対象外。
処理中のエラー発生の通知，処理の完了確認又は処理続
行の確認のために，アプリケーション境界の外部にシス
テム応答メッセージを出力する機能は，1DETと計測す
る。
対象外。
同一の論理的処理を起動する手段が複数あっても，処理
を指定する機能を1DETと計測する。
対象外。
要素処理の実行中にシステムによって取得又は導出さ
れて，ILFに格納されるデータ項目は，そのデータ項目
がアプリケーション境界をまたがらない場合，DETとし
ては計測しない。
対象外。
文字列は，DETとしては計測しない。
ページ変数又はシステムが生成するスタンプは計測し
ない。
結論：DETの数は，3となる。
複雑さ
1FTR及び3DET
複雑さは，低である。
手順5 寄与の決定
寄与が1で，複雑さが低
4FPになる。
8.8.9
事例7：EOの主機能
8.8.9.1 利用者要件
小切手を印刷し，その結果として，勘定書の支払済みフラグを立てる。小切手に印刷するすべてのデー
タは，既に小切手ファイルに保存されている。
この事例についてのデータフロー図を，図42に示す。
図42−データフロー図
手順1 要素処理の識別
このトランザクション ファンクションは，要素処理の
要求事項に当てはまるか。
当てはまる。
小切手ILF
小切手番号
支払額
受取人
支払済み区分
AB12345 小切手
支払地 東京都千代田区XXX
千代田銀行永田町支店
金額
￥1,000,000＊
上記の金額をこの小切手と引換えに
持参人へお支払ください。
受取人 山田 太郎
拒絶証書不要
振出日 平成 年 月 日
振出地 東京都
株式会社 東京商事
振出人 代表取締役 岡本 太郎
小切手の印刷
128
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
手順2 主目的の決定及び分類
トランザクション ファンクションはEOの主目的に当
てはまるか。
当てはまる。
主目的は，小切手を印刷することである。ILFの維持管
理は二次的である。
手順3 EO識別規則適合の検証
EO識別規則
規則の該当・非該当
アプリケーション境界の外部へデータ又は制御情報が
出力される。
当てはまる。
小切手情報は，アプリケーション境界の外部に出力され
る。
識別した処理に対して，次のいずれか一つが当てはま
る。
− 処理ロジックが，このアプリケーションの他のEO
又はEQのものと異なっている。
− 識別したデータ項目の組が，このアプリケーション
の他のEO又はEQのものと異なっている。
− 参照するILF又はEIFが，このアプリケーションの
他のEO又はEQのものと異なっている。
当てはまる。
この機能を実行する他のEOがない。
対象外。
対象外。
識別した処理に対して，次のいずれか一つが当てはま
る。
− 要素処理の処理ロジックが，少なくとも一つの数式
又は演算を含む。
− 要素処理の処理ロジックが，少なくとも一つのILF
を維持管理する。
− 要素処理の処理ロジックが，導出データを生成する。
− 要素処理の処理ロジックが，システムの振る舞いを
変更する。
対象外。
当てはまる。
小切手ILFを更新する。
対象外。
対象外。
結論：一つのEOがある。
手順4 複雑さの決定
FTR計測規則
規則の該当・非該当
要素処理の実行時に参照される各ILF又は各EIFは，
1FTRと計測する。
当てはまる。
小切手ILFを参照する。
要素処理の実行時に維持管理される各ILFは，1FTRと
計測する。
当てはまる。
小切手ILFを維持管理する。
要素処理の実行時に維持管理され，参照される各ILFは，
1FTRとだけ計測する。
当てはまる。
小切手ILFを参照し，維持管理する。1回だけ計測する。
結論：FTRの数は，1となる。
DET計測規則
規則の該当・非該当
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の外部から入力される。
− 要素処理がデータをいつ，何を，どのように取得又
は生成するかを特定するために必要である。
対象外。
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の内部から出力される。
小切手番号，支払額及び受取人。
アプリケーション境界を越えないので，支払区分は計測
されない。日付は，保存も印刷もされない。
129
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
あるDETがアプリケーション境界の外部から入力され，
外部にも出力される場合，その要素処理に対して1DET
とだけ計測する。
対象外。
処理中のエラー発生の通知，処理の完了確認又は処理続
行の確認のために，アプリケーション境界の外部にシス
テム応答メッセージを出力する機能は，1DETと計測す
る。
対象外。
同一の論理的処理を起動する手段が複数あっても，処理
を指定する機能を1DETと計測する。
対象外。
要素処理の実行中にシステムによって取得又は導出さ
れて，ILFに格納されるデータ項目は，そのデータ項目
がアプリケーション境界を越えない場合，DETとしては
計測しない。
対象外。
文字列は，DETとしては計測しない。
ページ変数又はシステムが生成するスタンプは計測し
ない。
結論：DETの数は，3となる。
複雑さ
1FTR及び3DET
複雑さは，低である。
手順5 寄与の決定
寄与が1で，複雑さが低
4FPになる。
8.8.10 事例8：EOトランザクション ファイル
8.8.10.1 利用者要件
月末に，トランザクション ファイルを作成し，アプリケーションBへ送付する。小切手番号及び支払
額は，その月に処理した小切手の枚数及び印刷した小切手の合計金額を記録したファイルに含まれる。
8.8.10.2 データモデル
この事例のデータフロー図を，図43に示す。
図43−データモデル図
手順1 要素処理の識別
このトランザクション ファンクションは，要素処理の
要求事項に当てはまるか。
当てはまる。
月次小切手ファイルの生
成
小切手ILF
小切手番号
支払い額
−
アプリケーションA
月次小切手ファイル
小切手番号
支払額
印刷済み小切手の枚数
全小切手の合計金額
アプリケーションB
130
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
手順2 主目的の決定及び分類
トランザクション ファンクションは，EOの主目的に当
てはまるか。
当てはまる。
主目的は，トランザクション ファイルを作成すること
である。それには計算項目を含む。
手順3 EO識別規則適合の検証
EO識別規則
規則の該当・非該当
アプリケーション境界の外部へデータ又は制御情報が
出力される。
当てはまる。
トランザクション データは，アプリケーションに存在
する。
識別した処理に対して，次のいずれか一つが当てはま
る。
− 処理ロジックが，このアプリケーションの他のEO
又はEQのものと異なっている。
− 識別したデータ項目の組が，このアプリケーション
の他のEO又はEQのものと異なっている。
− 参照するILF又はEIFが，このアプリケーションの
他のEO又はEQのものと異なっている。
当てはまる。
この機能を実行する他のEOがない。
対象外。
対象外。
識別した処理に対して，次のいずれか一つが当てはま
る。
− 要素処理の処理ロジックが，少なくとも一つの数式
又は演算を含む。
− 要素処理の処理ロジックが，少なくとも一つのILF
を維持管理する。
− 要素処理の処理ロジックが，導出データを生成する。
− 要素処理の処理ロジックが，システムの振る舞いを
変更する。
当てはまる。
小切手の枚数及び合計金額を計算する。
対象外。
対象外。
対象外。
結論：一つのEOがある。
手順4 複雑さの決定
FTR計測規則
規則の該当・非該当
要素処理の実行時に参照される各ILF又は各EIFは，
1FTRと計測する。
当てはまる。
小切手ILFを参照する。
要素処理の実行時に維持管理される各ILFは，1FTRと
計測する。
対象外。
要素処理の実行時に維持管理され，参照される各ILFは，
1FTRとだけ計測する。
対象外。
結論：FTRの数は，1となる。
DET計測規則
規則の該当・非該当
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の外部から入力される。
− 要素処理がデータをいつ，何を，どのように取得又
は生成するかを特定するために必要である。
対象外。
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の内部から出力される。
小切手番号，支払額，印刷済み小切手番号，及び全小切
手の合計金額
131
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
あるDETがアプリケーション境界の外部から入力され，
外部にも出力される場合，その要素処理に対して1DET
とだけ計測する。
対象外。
処理中のエラー発生の通知，処理の完了確認又は処理続
行の確認のために，アプリケーション境界の外部にシス
テム応答メッセージを出力する機能は，1DETと計測す
る。
対象外。
同一の論理的処理を起動する手段が複数あっても，処理
を指定する機能を1DETと計測する。
対象外。
要素処理の実行中にシステムによって取得又は導出さ
れて，ILFに格納されるデータ項目は，そのデータ項目
がアプリケーション境界をまたがらない場合，DETとし
ては計測しない。
文字列は，DETとしては計測しない。
ページ変数又はシステムが生成するスタンプは計測し
ない。
結論：DETの数は，4となる。
複雑さ
1FTR及び4DET
複雑さは，低である。
手順5 寄与の決定
寄与が1で，複雑さが低
4FPになる。
8.8.11 計測したEO，FTR及びDETの概要
ここでは，未調整ファンクションポイントへの複雑さ及び寄与を計算する前に，計測されたEO，FTR
及びDETの概要を示す。
8.8.11.1 計測したEOの概要
次の表は人事情報システムについてEOとして識別したデータを示す。同時に，EOとして識別しなかっ
たデータも示す。
EOとして識別したデータ
EOとして識別しなかったデータ
業務の社員割当て一覧
福祉手当への新規扶養家族の処理
割当て継続期間による社員一覧
エラーメッセージ及び確認メッセージの表示
勤務評定の通知
週次社員情報一覧
小切手の印刷
小切手トランザクション ファイルの生成
8.8.11.2 FTR及びDET計測の概要
次の表は，計測したFTR及びDETの数を表す。
外部出力
FTR
DET
業務の社員割当て一覧
4
5
割当て継続期間による社員一覧
3
7
勤務評定の通知
3
4
週次社員情報一覧
1
3
小切手の印刷
1
3
小切手トランザクション ファイルの生成
1
4
8.8.12 EOの複雑さ及び寄与
EOの事例の最後に，未調整ファンクションポイントに対するEOの複雑さ及び寄与を決定するための最
終手順を示す。
132
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
最終手順は，次に示すとおりである。
a) EOの複雑さを評価する。
b) 未調整ファンクションポイントに対する複雑さを寄与に変換する。
c) 未調整ファンクションポイントの合計に対するEI全体の寄与を計算する。
8.8.12.1 EOの複雑さの評価
次の複雑さ表によって，EOの複雑さを評価する。
1〜5 DET
6〜19 DET
20 DET以上
1 FTR
低
低
中
2〜3 FTR
低
中
高
4 FTR以上
中
高
高
次の表は，各EOに対するファンクションの複雑さを示す。
EO
FTR
DET
ファンクションの複雑さ
業務の社員割当て一覧
4
5
中
割当て継続期間による社員一覧
3
7
中
勤務評定の通知
3
4
低
週次社員情報一覧
1
3
低
小切手の印刷
1
3
低
小切手トランザクション ファイルの生成
1
4
低
8.8.12.2 EOの寄与への変換
次の表で，EOの複雑さを寄与に変換する。
ファンクションの複雑さの評価
未調整ファンクションポイント
低
4
中
5
高
7
複雑さは，次の表に示す。
8.8.12.3 EOの寄与の計算
次の表で，EOのファンクション型に対する寄与の合計を計算する。
ファンクション型
ファンクションの複雑さ
複雑さの合計
ファンクション型の合計
EO
4 低
× 4 ＝ 16
26
2 中
× 5 ＝ 10
0 高
× 7 ＝ 0
この合計は，すべてのファンクションを一覧にする表に記録される。すべてのファンクション型に対す
る最終合計が，未調整ファンクションポイントとなる。
8.9
EQの計測事例
ここでは，EQを計測するための手順を示すために，人事情報システムを使用する。
8.9.1
すべてのトランザクション ファンクション型に共通の規則
すべての事例を分析する手順は，箇条8の初めで記述した手順に従う。手順は，要素処理の識別，主目
的及びトランザクション ファンクション型のEI，EO及びEQへの分類という規則を適用することに関係
している。次の表に適用されなければならない規則を一覧表示する。
要求処理の識別規則
規則の該当・非該当
その処理は，利用者にとって意味のある業務活動の最小単位である。
その処理は，自己完結しており，計測するアプリケーションが実行する業務
を矛盾のない状態にするものである。
133
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
トランザクション ファンクション型が要素処理となるためには，二つの識別規則のいずれの質問に対し
ても，“当てはまる”でなければならない。
表16−トランザクション ファンクション型の主目的
主目的
EI
ILFの維持管理又はシステムの振る舞いの変更
EO
利用者への情報の提供
“数式又は演算の実行”，導出データの提供又は“一つ以上のILFの更新又はシステムの振る舞
いの変更”
EQ
利用者への情報の提供
一つ以上のILF又はEIFから取得したデータだけの提供
EI，EO及びEQのいずれであるかを決定するために，トランザクション ファンクション型の主目的に
最も適合する記述を使用する。これは，ファンクションに対する利用者要件を注意深く，かつ，正確に解
釈することで決定できる。
8.9.2
EQ計測事例の概要
EQの計測事例の一覧を，表17に示す。
表17−事例一覧
事例
概要
アプリケーションメニュー
選択式のメニュー又はボタンをEQとして計測しない理由を示す事例
検索データの一覧
一覧の計測方法を説明する事例
ドロップダウンリストボックス
ドロップダウンリストボックスの計測方法を示す事例
項目レベルのヘルプ：その1
最初に現れる項目レベルのヘルプの計測方法を示す事例
項目レベルのヘルプ：その2
項目レベルのヘルプの計測方法を示す二つ目の事例
明示的には記述されていない照会
データ検索が明確に記述されていないが，言外に記述されている場合のフ
ァンクションポイントについて説明する事例
アプリケーション境界をまたぐデータ
なしに起動されるEQ
時間によって内部的にデータ検索及び表示が起動される場合の計測方法
を示す事例
他アプリケーションに送られるトラン
ザクション
他アプリケーションにファイルでデータを送付する場合の計測方法を示
す事例
8.9.3
事例1：アプリケーションメニュー
8.9.3.1 利用者要件
人事情報システムには，選択式のメニュー及びボタンを必要とする。
8.9.3.2 EQの入力側
人事情報システムのメインメニューの社員ドロップダウンメニューを，図44に示す。これは入力要求で
ある。
134
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
人事情報システム
社員
業務
割当て 勤務地
報告者
セキュリティ
ヘルプ
新規
表示
編集
印刷
図44−人事情報システムのメインメニュー
社員ドロップダウンメニューで新規を選択すると，図45の社員情報設定画面を表示する。
図45−社員情報設定画面
人事情報システム
社員情報設定
OK
取消
OK
取消
アプリケーションメニュー画面に戻る
決定
姓
名
保険証番号
扶養家族数
事業所
通貨
給与種別
（）時給
（）月給
− −
社員 業務 割当て 勤務地 報告者 セキュリティ ヘルプ
135
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
手順1 要素処理の識別
このトランザクション ファンクションは，要素処理の要
求事項に当てはまるか。
当てはまらない。
メニューオプションの選択は，利用者にとって意味のあ
るデータを含んでいない。
結論：要素処理はない。
8.9.4
事例2：検索データの一覧
8.9.4.1 利用者要件
利用者の要件は，次のとおりである。
− 社員一覧の表示。
この事例では，人事情報システムで社員一覧を表示することに焦点をしぼる。
この事例のデータフロー図を，図46に示す。
社員及び扶養者
情報
利用者
社員照会
保険証番号
社員情報
保険証番号,氏名,社員種別
労働組合,扶養者保険証番号,扶養名
扶養者生年月日，勤務地
保険証番号,氏名，社員種別
給与種別
社員一覧
の照会
表示の要求
アクセス許可
アクセス許可
社員の
セキュリティ
社員情報
社員一覧
図46−データフロー図
8.9.4.2 計測手順
人事情報システムのドロップダウンメニューを，図47に示す。表示項目及び入力キーは，この事例の入
力側に作っている。
136
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図47−人事情報システムのメインメニュー
利用者が社員ドロップダウンメニューの“表示”を選択すると，図48の社員一覧画面を表示する。
図48−社員情報表示画面
手順1 要素処理の識別
このトランザクション ファンクションは，要素処理の要
求事項に当てはまるか。
当てはまる。
手順2 主目的の決定及び分類
トランザクション ファンクションはEQの主目的に当
てはまるか。
当てはまる。
主目的は，データを表示することである。検索されたデ
ータだけが含まれている。
人事情報システム
新規
表示
編集
印刷
業務
割当て
勤務地
ヘルプ
社員
報告者
セキュリティ
人事情報システム
扶養家族
遠藤
小野
土井
中田
中村
宮本
表示
社員 業務 割当て 勤務地 報告者 セキュリティ ヘルプ
社員一覧
姓 名 保険証番号 給与種別
取消
康人
信介
洋一
英二
俊一
恒夫
123-456-789
234-567-891
345-678-912
456-789-123
567-891-234
678-912-345
月給
時給
時給
月給
時給
月給
137
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
手順3 EQ識別規則適合の検証
EQ識別規則
規則の該当・非該当
アプリケーション境界の外部へデータ又は制御情報を出
力する機能である。
当てはまる。
社員情報は，アプリケーション境界をまたぐ。
識別した処理に対して，次の三つのうちいずれか一つを
適用する。
− 処理ロジックが，このアプリケーションの他のEO
又はEQによって実行された処理ロジックと異なっ
ている。
− 識別したデータ項目の組が，このアプリケーション
の他のEO又はEQについて識別されたデータ要素
と異なっている。
− 参照するILF又はEIFが，このアプリケーションの
他のEO又はEQについて識別された参照するILF
又はEIFと異なっている。
当てはまる。
この機能を実行する他のEQがない。
対象外。
対象外。
要素処理の処理ロジックは，データ又は制御情報をILF
又はEIFから取得する。
当てはまる。
社員データを検索する。
要素処理の処理ロジックは，ILFを維持管理しない。
当てはまる。
要素処理の処理ロジックは，“数式又は演算の実行”を含
まない。
当てはまる。
要素処理の処理ロジックは，導出データを生成しない。 当てはまる。
要素処理の処理ロジックは，システムの振る舞いを変更
しない。
当てはまる。
結論：一つのEQがある。
手順4 複雑さの決定
FTR計測規則
規則の該当・非該当
要素処理の実行時に参照されるILF又はEIFは，1FTR
と計測する。
当てはまる。
結論：FTRの数は，1となる。
DET計測規則
規則の該当・非該当
次のすべてを満たすデータ項目は，1DETとして計測す
る。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の外部から入力される。
− 要素処理がデータをいつ，何を，どのように取得又
は生成するかを特定するために必要である。
対象外。
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の内部から出力される。
当てはまる。
次が繰り返され，1回だけ計測する。姓名，保険者番号，
給与種別
あるDETがアプリケーション境界の外部から入力され，
外部にも出力される場合，その要素処理に対して1DET
とだけ計測する。
対象外。
処理中のエラー発生の通知，処理の完了確認又は処理続
行の確認のために，アプリケーション境界の外部にシス
テム応答メッセージを出力する機能を1DETと計測す
る。
対象外。
同一の論理的処理を起動する手段が複数ある場合でも，
実施する活動を指定する機能を1DETと計測する。
次の項目が当てはまる。
表示項目又は入力キー
138
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
システムによって取得又は導出されるILFに格納される
データ項目で，要素処理の実行中にそのデータ項目がア
プリケーション境界をまたがらない場合は，DETとして
は計測しない。
対象外。
文字列はDETとしては計測しない。
ページ変数又はシステムが生成するスタンプは計測しな
い。
結論：DETの数は，4となる。氏名は，姓名で1DETと考える。
複雑さ
1FTR及び4DET
複雑さは，低である。
手順5 寄与の決定
寄与が1で，複雑さが低
3FPになる。
8.9.5
事例3：ドロップダウンリストボックス
8.9.5.1 利用者要件
人事情報システムに追加した労働組合の一覧を閲覧する利用者要件がある。
8.9.5.2 計測手順
労働組合項目の付いた非正社員データ画面を，図49に示す。
図49−非正社員データ画面
下向き矢印を選択すると，図50のドロップダウンリストを表示する。
社員リスト
人事情報システム
社員データ
山田
太郎
345-67-8901
非正社員データ
時給
労働組合
扶養家族
社員 業務 割当て 勤務地 報告者 セキュリティ ヘルプ
139
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図50−非正社員データ入力画面
手順1 要素処理の識別
このトランザクション ファンクションは，要素処理の要
求事項に当てはまるか。
当てはまる。
手順2 主目的の決定及び分類
トランザクション ファンクションはEOの主目的に当
てはまるか。
当てはまる。
主目的は，情報の表示である。検索データだけが含まれ
ている。
手順3 EQ識別規則適合の検証
EQ識別規則
規則の該当・非該当
アプリケーション境界の外部へデータ又は制御情報が出
力される。
当てはまる。
労働組合一覧を表示する。
識別した処理に対して，次のいずれか一つが当てはまる。
− 処理ロジックが，このアプリケーションの他のEO
又はEQのものと異なっている。
− 識別したデータ項目の組が，このアプリケーション
の他のEO又はEQのものと異なっている。
− 参照するILF又はEIFが，このアプリケーションの
他のEO又はEQのものと異なっている。
当てはまる。
この機能を実行する他のEQがない。
対象外。
対象外。
要素処理の処理ロジックは，データ又は制御情報をILF
又はEIFから取得する。
当てはまる。
要素処理の処理ロジックは，ILFを維持管理しない。
当てはまる。
要素処理の処理ロジックは，“数式又は演算の実行”を含
まない。
当てはまる。
社員リスト
人事情報システム
社員データ
山田
太郎
345-67-8901
非正社員データ
時給
労働組合
扶養家族
社員 業務 割当て 勤務地 報告者 セキュリティ ヘルプ
UPFCA
L841
CPLG
140
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
要素処理の処理ロジックは，導出データを生成しない。 当てはまる。
要素処理の処理ロジックは，システムの振る舞いを変更
しない。
当てはまる。
結論：一つのEQがある。
手順4 複雑さの決定
FTR計測規則
規則の該当・非該当
要素処理の実行時に参照される1ILF又は1EIFは，1FTR
と計測する。
次の項目が当てはまる。
労働組合
結論：FTRの数は，1となる。
DET計測規則
規則の該当・非該当
次のすべてを満たすデータ項目は，1DETとして計測す
る。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の外部から入力される。
− 要素処理がデータをいつ，何を，どのように取得又
は生成するかを特定するために必要である。
対象外。
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の内部から出力される。
次の項目が当てはまる。
労働組合
あるDETがアプリケーション境界の外部から入力され，
外部にも出力される場合，その要素処理に対して1DET
とだけ計測する。
対象外。
処理中のエラー発生の通知，処理の完了確認又は処理続
行の確認のために，アプリケーション境界の外部にシス
テム応答メッセージを出力する機能を1DETと計測す
る。
対象外。
同一の論理的処理を起動する手段が複数ある場合でも，
実施する活動を指定する機能を1DETと計測する。
次の項目が当てはまる。
下向き矢印
システムによって取得又は導出されるILFに格納される
データ項目で，要素処理の実行中にそのデータ項目がア
プリケーション境界をまたがらない場合は，DETとして
は計測しない。
対象外。
文字列は，DETとしては計測しない。
ページ変数又はシステムが生成するスタンプは計測しな
い。
結論：DETの数は，2となる。
複雑さ
1FTR及び2DET
複雑さは，低である。
手順5 寄与の決定
寄与が1で，複雑さが低
3FPになる。
8.9.6
事例4：項目レベルのヘルプ（その1）
8.9.6.1 利用者要件
人事情報システムの構築中に，オンラインで利用できる項目レベルのヘルプに関する利用者要件が追加
された。ヘルプ機能は，別のアプリケーションによって提供される。ヘルプシステムは，人事情報システ
ム，為替システム，固定資産管理システム及び福利厚生システムに共通ヘルプ機能を提供する。
141
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
8.9.6.2 計測手順
社員データ画面を，図51に示す。
図51−社員データ入力画面
利用者がカーソルを時給項目上に置いてF1キーを押すと，図52のヘルプテキストを含むテキストボッ
クスを表示する。
社員リスト
人事情報システム
社員データ
山田
太郎
345-67-8901
非正社員データ
時給
労働組合
扶養家族
社員 業務 割当て 勤務地 報告者 セキュリティ ヘルプ
142
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
図52−ヘルプ表示
手順1 要素処理の識別
このトランザクション ファンクションは，要素処理の要
求事項に当てはまるか。
当てはまる。
手順2 主目的の決定及び分類
トランザクション ファンクションはEQの主目的に当
てはまるか。
当てはまる。
主目的は，情報の表示である。検索データだけが含まれ
ている。
手順3 EQ識別規則適合の検証
EQ識別規則
規則の該当・非該当
アプリケーション境界の外部へデータ又は制御情報が出
力される。
当てはまる。
ヘルプ情報は，アプリケーション境界をまたぐ。
識別した処理に対して，次のいずれか一つが当てはまる。
− 処理ロジックが，このアプリケーションの他のEO
又はEQのものと異なっている。
− 識別したデータ項目の組が，このアプリケーション
の他のEO又はEQのものと異なっている。
− 参照するILF又はEIFが，このアプリケーションの
他のEO又はEQのものと異なっている。
当てはまる。
この機能を実行する他のEQがない。
対象外。
対象外。
要素処理の処理ロジックは，データ又は制御情報をILF
又はEIFから取得する。
当てはまる。
要素処理の処理ロジックは，ILFを維持管理しない。
当てはまる。
要素処理の処理ロジックは，“数式又は演算の実行”を含
まない。
当てはまる。
要素処理の処理ロジックは，導出データを生成しない。 当てはまる。
人事情報システム
時給
労働組合
扶養家族
社員 業務 割当て 勤務地 報告者 セキュリティ ヘルプ
時給
勤務時間1時間に対して支払われる給与額
この情報は，非正社員に対して必す（須）項目である。
有効値：時給を表す任意の値
デフォルト値：なし
デフォルト値：デフォルト値はなし
143
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
要素処理の処理ロジックは，システムの振る舞いを変更
しない。
当てはまる。
結論：一つEQがある。
手順4 複雑さの決定
FTR計測規則
規則の該当・非該当
要素処理の実行時に参照される1ILF又は1EIFは，1FTR
と計測する。
次の項目が当てはまる。
ヘルプ機能
結論：FTRの数は，1となる。
DET計測規則
規則の該当・非該当
次のすべてを満たすデータ項目は，1DETとして計測す
る。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の外部から入力される。
− 要素処理がデータをいつ，何を，どのように取得又
は生成するかを特定するために必要である。
次の項目が当てはまる。
画面ID，項目ID
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の内部から出力される。
次の項目が当てはまる。
ヘルプ記述，デフォルト値，有効な値
あるDETがアプリケーション境界の外部から入力され，
外部にも出力される場合，その要素処理に対して1DET
とだけ計測する。
対象外。
処理中のエラー発生の通知，処理の完了確認又は処理続
行の確認のために，アプリケーション境界の外部にシス
テム応答メッセージを出力する機能を1DETと計測す
る。
対象外。
同一の論理的処理を起動する手段が複数ある場合でも，
実施する活動を指定する機能を1DETと計測する。
次の項目が当てはまる。
F1キー
システムによって取得又は導出されるILFに格納される
データ項目で，要素処理の実行中にそのデータ項目がア
プリケーション境界をまたがらない場合は，DETとして
は計測しない。
対象外。
文字列はDETとしては計測しない。
ページ変数又はシステムが生成するスタンプは計測しな
い。
結論：DETの数は，6となる。
複雑さ
1FTR及び6DET
複雑さは，低である。
手順5 寄与の決定
寄与が1で，複雑さが低
3FPになる。
8.9.7
事例5：項目レベルのヘルプ（その2）
8.9.7.1 利用者要件
人事情報システムの構築中に，オンラインで利用できる項目レベルのヘルプに関する利用者要件が追加
された。ヘルプ機能は，別のアプリケーションによって提供される。ヘルプシステムは，人事情報システ
ム，為替システム，固定資産管理システム及び福利厚生システムに共通ヘルプ機能を提供する。
8.9.7.2 計測手順
144
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
社員データ画面を，図53に示す。
図53−社員データ画面
利用者は，ヘルプが必要な項目の上にカーソルを置き，その項目に関するヘルプを閲覧するためにF1
キーを押す。
手順1 要素処理の識別
このトランザクション ファンクションは，要素処理の要
求事項に当てはまるか。
当てはまる。
手順2 主目的の決定及び分類
トランザクション ファンクションは，EQの主目的に当
てはまるか。
当てはまる。
主目的は，情報の表示である。検索データだけが含まれ
ている。
手順3 EQ識別規則適合の検証
EQ識別規則
規則の該当・非該当
アプリケーション境界の外部へデータ又は制御情報が出
力される。
当てはまる。
ヘルプ情報は，アプリケーション境界をまたぐ。
識別した処理に対して，次のいずれか一つが当てはまる。
− 処理ロジックが，このアプリケーションの他のEO
又はEQのものと異なっている。
− 識別したデータ項目の組が，このアプリケーション
の他のEO又はEQのものと異なっている。
− 参照するILF又はEIFが，このアプリケーションの
他のEO又はEQのものと異なっている。
当てはまらない。
この項目に対して，項目レベルのヘルプを表示するため
の処理ロジックは既に識別されている。
対象外。
対象外。
要素処理の処理ロジックは，データ又は制御情報をILF
又はEIFから取得する。
対象外。
社員リスト
人事情報システム
社員データ
山田
太郎
345-67-8901
非正社員データ
時給
労働組合
扶養家族
社員 業務 割当て 勤務地 報告者 セキュリティ ヘルプ
145
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
要素処理の処理ロジックは，ILFを維持管理しない。
対象外。
要素処理の処理ロジックは，“数式又は演算の実行”を含
まない。
対象外。
要素処理の処理ロジックは，導出データを生成しない。 対象外。
要素処理の処理ロジックは，システムの振る舞いを変更
しない。
対象外。
結論：これは要素処理であるが，このシステムの中では重複した機能であるので，計測しない。項目レベ
ルヘルプは既に計測されている。
8.9.8
事例6：明示的には記述されていない照会
8.9.8.1 利用者要件
業務割当てに関する情報閲覧の利用者要件がある。それは明確には記述されていないが，業務情報を変
更する前に業務情報を検索しなければならないことは暗黙の了解事項である。利用者にとって，そもそも，
既存の業務割当て情報を閲覧せずにこれを変更するのは効率的でない。これを，明示的に記述されていな
い照会という。
8.9.8.2 計測手順
社員氏名及び業務番号だけの業務割当て編集画面を，図54に示す。
図54−業務割当て編集画面
人事情報システム
社員 業務 割当て 勤務地 報告者 セキュリティ ヘルプ
社員割当て
業務割当て編集
山田
太郎
労働組合
OK
日付
給与
確定給与率
5月号−表紙の印刷
取消
リストア
削除
RD15379305
OK
取消
リストア
削除
変更決定
変更取消し
前回の指定値を表示
確認メッセージの後，業務割当てを削除
146
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
社員氏名及び業務番号を入力すると，図55の業務情報を表示する。
図55−業務割当て表示画面
手順1 要素処理の識別
このトランザクション ファンクションは，要素処理の要
求事項に当てはまるか。
当てはまる。
手順2 主目的の決定及び分類
トランザクション ファンクションは，EQの主目的に当
てはまるか。
当てはまる。
主目的は，情報の提供である。検索データだけが含まれ
ている。
手順3 EQ識別規則適合の検証
EQ識別規則
規則の該当・非該当
アプリケーション境界の外部へデータ又は制御情報が出
力される。
当てはまる。
業務情報を表示する。
人事情報システム
社員 業務 割当て 勤務地 報告者 セキュリティ ヘルプ
社員割当て
業務割当て編集
山田
太郎
労働組合
OK
日付
給与
確定給与率
5月号−表紙の印刷
取消
リストア
削除
RD15379305
OK
取消
リストア
削除
変更決定
変更取消し
前回の指定値を表示
確認メッセージの後，業務割当てを削除
25/072006
147
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
識別した処理に対して，次のいずれか一つが当てはまる。
− 処理ロジックが，このアプリケーションの他のEO
又はEQのものと異なっている。
− 識別したデータ項目の組が，このアプリケーション
の他のEO又はEQのものと異なっている。
− 参照するILF又はEIFが，このアプリケーションの
他のEO又はEQのものと異なっている。
当てはまらない。
同じ情報を示すEQが既に存在している。
対象外。
対象外。
要素処理の処理ロジックは，データ又は制御情報をILF
又はEIFから取得する。
対象外。
要素処理の処理ロジックは，ILFを維持管理しない。
対象外。
要素処理の処理ロジックは，“数式又は演算の実行”を含
まない。
対象外。
要素処理の処理ロジックは，導出データを生成しない。 対象外。
要素処理の処理ロジックは，システムの振る舞いを変更
しない。
対象外。
結論：これは要素処理であるが，このシステムの中では重複した機能であるので，計測しない。同一の表
示機能は既に計測されている。
8.9.9
事例7：アプリケーション境界をまたぐデータなしに起動するEQ
8.9.9.1 利用者要件
システムによる毎月の自動的な月次会員報告印刷の利用者要件がある。
この事例のデータフロー図を，図56に示す。
図56−データフロー図
手順1 要素処理の識別
このトランザクション ファンクションは，要素処理の要
求事項に当てはまるか。
当てはまる。
手順2 主目的の決定及び分類
トランザクション ファンクションは，EQの主目的に当
てはまるか。
当てはまる。
主目的は，情報の表示である。検索データだけが含まれ
る。
手順3 EQ識別規則適合の検証
月次会員報告の印刷
月次会員報告
氏名 市 国
Angel,A. Milwaukee USA
Boxer,B. Chicago USA
Smith,S. London UK
Temple,S. Detroit USA
Wayne,J. Atlanta USA
会員ILF
会員番号
名前
市
国
148
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
EQ識別規則
規則の該当・非該当
アプリケーション境界の外部へデータ又は制御情報が出
力される。
当てはまる。
月次会員データは，アプリケーション境界をまたぐ。
識別した処理に対して，次のいずれか一つが当てはまる。
− 処理ロジックが，このアプリケーションの他のEO
又はEQのものと異なっている。
− 識別したデータ項目の組が，このアプリケーション
の他のEO又はEQのものと異なっている。
− 参照するILF又はEIFが，このアプリケーションの
他のEO又はEQのものと異なっている。
当てはまる。
この機能を実行する他のEQがない。
対象外。
対象外。
要素処理の処理ロジックは，データ又は制御情報をILF
又はEIFから取得する。
当てはまる。
要素処理の処理ロジックは，ILFを維持管理しない。
当てはまる。
要素処理の処理ロジックは，“数式又は演算の実行”を含
まない。
当てはまる。
要素処理の処理ロジックは，導出データを生成しない。 当てはまる。
要素処理の処理ロジックは，システムの振る舞いを変更
しない。
当てはまる。
結論：1EQとなる。EQは，アプリケーション境界をまたぐことなしに起動できることに注意する。この
事例では，トランザクションはアプリケーション境界の内部にある時間イベントによって起動され
る。
手順4 複雑さの決定
FTR計測規則
規則の該当・非該当
要素処理の実行時に参照される1ILF又は1EIFは，1FTR
と計測する。
次の項目が当てはまる。
会員情報
結論：FTRの数は，1となる。
DETについて，
DET計測規則
規則の該当・非該当
次のすべてを満たすデータ項目は，1DETとして計測す
る。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の外部から入力される。
− 要素処理がデータをいつ，何を，どのように取得又
は生成するかを特定するために必要である。
対象外。
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の内部から出力される。
次の項目が当てはまる。
社員氏名，市区町村名，国名
あるDETがアプリケーション境界の外部から入力され，
外部にも出力される場合，その要素処理に対して1DET
とだけ計測する。
対象外。
処理中のエラー発生の通知，処理の完了確認又は処理続
行の確認のために，アプリケーション境界の外部にシス
テム応答メッセージを出力する機能を1DETと計測す
る。
対象外。
同一の論理的処理を起動する手段が複数ある場合でも，
実施する活動を指定する機能を1DETと計測する。
対象外。
149
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
システムによって取得又は導出されるILFに格納される
データ項目で，要素処理の実行中にそのデータ項目がア
プリケーション境界をまたがらない場合は，DETとして
は計測しない。
対象外。
文字列は，DETとしては計測しない。
ページ変数又はシステムが生成するスタンプは計測しな
い。
結論：DETの数は，3となる。
複雑さ
1FTR及び3DET
複雑さは，低である。
手順5 寄与の決定
寄与が1で，複雑さが低
3FPになる。
8.9.10 事例8：他アプリケーションへのデータ送付
8.9.10.1 利用者要件
1日の終わりに，その日に印刷した小切手番号及び各小切手の支払額を一覧にしたトランザクション フ
ァイルをアプリケーションBへ送付する。
この事例のデータフロー図を，図57に示す。
図57−データフロー図
手順1 要素処理の識別
このトランザクション ファンクションは，要素処理の要
求事項に当てはまるか。
当てはまる。
手順2 主目的の決定及び分類
トランザクション ファンクションは，EQの主目的に当
てはまるか。
当てはまる。
主目的は情報の表示である。検索データだけが含まれる。
手順3 EQ識別規則が当てはまるかの検証
EQ識別規則
規則の該当・非該当
アプリケーション境界の外部へデータ又は制御情報を出
力される。
当てはまる。
データは，トランザクション データファイルとして，ア
プリケーション境界をまたぐ。
月次小切手ファイル
の生成
小切手ILF
小切手番号
支払額
日次小切手ファイル
アプリケーションA
小切手番号
支払額
アプリケーションB
150
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
識別された処理に対して，次のいずれか一つが該当する。
− 処理ロジックがこのアプリケーションの他のEO又
はEQと異なっている。
− 識別されたデータ項目の組が，このアプリケーショ
ンの他のEO又はEQのデータの組と異なっている。
− 参照するILF又はEIFが，このアプリケーションの
他のEO又はEQと異なっている。
当てはまる。
他にこの機能を実行するEQがない。
対象外。
対象外。
要素処理の処理ロジックは，データ又は制御情報をILF
又はEIFから取得する。
当てはまる。
要素処理の処理ロジックは，ILFを維持管理しない。
当てはまる。
要素処理の処理ロジックは，“数式又は演算の実行”を含
まない。
当てはまる。
要素処理の処理ロジックは，導出データを生成しない。 当てはまる。
要素処理の処理ロジックは，システムの振る舞いを変更
しない。
当てはまる。
結論：一つのEQがある。
手順4 複雑さの決定
FTR計測規則
規則の該当・非該当
要素処理の実行時に参照される1ILF又は1EIFは，1FTR
と計測する。
次の項目が当てはまる。
小切手ILF。
結論：FTRの数は，1となる。
DET計測規則
規則の該当・非該当
次のすべてを満たすデータ項目は，1DETとして計測す
る。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の外部から入力される。
− 要素処理がデータをいつ，何を，どのように取得又
は生成するかを特定するために必要である。
対象外。
次のすべてを満たすデータ項目は，1DETと計測する。
− 利用者から認識可能である。
− 繰返しがない。
− アプリケーション境界の内部から出力される。
次の項目が当てはまる。
小切手番号，支払額
あるDETがアプリケーション境界の外部から入力され，
外部にも出力される場合，その要素処理に対して1DET
とだけ計測する。
対象外。
処理中のエラー発生の通知，処理の完了確認又は処理続
行の確認のために，アプリケーション境界の外部にシス
テム応答メッセージを出力する機能を1DETと計測す
る。
対象外。
同一の論理的処理を起動する手段が複数ある場合でも，
実施する活動を指定する機能を1DETと計測する。
対象外。
システムによって取得又は導出されるILFに格納される
データ項目で，要素処理の実行中にそのデータ項目がア
プリケーション境界をまたがらない場合は，DETとして
は計測しない。
対象外。
文字列は，DETとしては計測しない。
ページ変数又はシステムが生成するスタンプは計測しな
い。
151
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
結論：DETの数は，2となる。
複雑さ
1FTR及び2DET
複雑さは，低である。
手順5 寄与の決定
寄与が1で，複雑さが低
3FPになる。
8.9.11 計測したEQ，FTR及びDETの概要
ここでは，未調整ファンクションポイントへの複雑さ及び寄与を計算する前に，計測されたEQ，FTR
及びDETの概要を示す。
8.9.11.1 計測したEQの概要
次の表は人事情報システムについてEQとして識別したデータを示す。同時に，EQとして識別しなかっ
たデータも示す。
計測したEQ
計測しないEQ
検索データ
アプリケーションメニュー
ドロップダウンリストボックス
項目レベルヘルプの2度目の出現
項目レベルヘルプの第一出現
明示的に記述されていない照会（既に計測済み）
月次会員報告
小切手トランザクション ファイル
8.9.11.2 FTR及びDETの概要
次の表は，FTR及びDETの数を表す。
外部照会
FTR
DET
検索データ
1
4
ドロップダウン リストボックス
1
2
項目レベルヘルプの第一出現
1
6
月次会員報告
1
3
小切手トランザクション ファイル
1
2
8.9.12 EQの複雑さ及び寄与
EQの事例の最後に，未調整ファンクションポイントに対するEQの複雑さ及び寄与を決定するための最
終手順を示す。
最終手順は，次に示すとおりである。
a) EQの複雑さを評価する。
b) 未調整ファンクションポイントに対する複雑さを寄与に変換する。
c) 未調整ファンクションポイントの合計に対するEI全体の寄与を計算する。
8.9.12.1 EQの複雑さの評価
次の複雑さ表によって，EOの複雑さを評価する。
1〜5 DET
6〜19 DET
20 DET以上
1 FTR
低
低
中
2〜3 FTR
低
中
高
4 FTR以上
中
高
高
凡例： FTR＝関連ファイル数
DET＝データ項目数
EQの複雑さ：次の表は，各EQに対するファンクションの複雑さを示す。
EQ
FTR
DET
ファンクションの複雑さ
検索データのリスト
1
4
低
152
X 0142：2010
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
ドロップダウンリストボックス
1
2
低
項目レベルヘルプ
1
6
低
週次の会員情報
1
3
低
日ごとの小切手ファイル
1
2
低
8.9.12.2 EQの寄与への変換
次の表で，EOの複雑さを寄与に変換する。
ファンクションの複雑さの評価
未調整ファンクションポイント
低
3
中
4
高
6
複雑さは，次の表に示す。
8.9.12.3 EQの寄与の計算
次の表で，EQのファンクション型に対する寄与の合計を計算する。
機能要素
複雑さ
寄与
寄与の合計
EQ
5 低
× 3 ＝ 15
15
中
× 4 ＝
高
× 6 ＝
この合計は，すべてのファンクションを一覧にする表に記録される。すべてのファンクション型に対す
る最終合計が，未調整ファンクションポイントとなる。
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
附属書JA
（参考）
JISと対応国際規格との対比表
JIS X 0142:2010 ソフトウェア技術−機能規模測定−IFPUG機能規模測定手法
（IFPUG 4.1版未調整ファンクションポイント）計測マニュアル
ISO/IEC 20926:2003 Software engineering−IFPUG 4.1 Unadjusted functional size
measurement method−Counting practices manual
(I)JISの規定
(II)
国際規格
番号
(III)国際規格の規定
(IV)JISと国際規格との技術的差異の箇条
ごとの評価及びその内容
(V)JISと国際規格との技術的差異の
理由及び今後の対策
箇条番号
及び題名
内容
箇条番号
内容
箇条ごと
の評価
技術的差異の内容
1
適用範囲
1
Introduction
削除
一部を除き，全文削除
規格内容として必要ない。
2
用語及び定義
IFPUG
Glossary
変更
Glossaryを，JISの箇条2とし，
個々の用語は五十音順にし，不
要なものを削除した。
原則として，JIS本文中で参照してい
ないものは削除した。
3
IFPUG 4.1版未調整
ファンクションポ
イントの概要
2
Overview of Function Point
Analysis
削除
Contents，Procedure by Chapter
を削除
目次などであり，JISとしては不要。
4
利用者要件記述
3
User View
削除
Contentsを削除
目次などであり，JISとしては不要。
5
計測種別の決定
4
Determine Type of Count
削除
Contentsを削除
目次などであり，JISとしては不要。
6
計測範囲及びアプ
リケーション境界
の識別
5
Identify Counting Scope
and Application Boundary
削除
Contentsを削除
目次などであり，JISとしては不要。
7
データファンクシ
ョンの計測
6
Count Data Functions
削除
Contents，Procedure Diagram，
Diagram of the Organizationを
削除
目次などであり，JISとしては不要。
8
トランザクション
ファンクションの
計測
7
Count
Transactional
Functions
削除
Contents，Procedure Diagram，
Diagram of the Organizationを
削除
目次などであり，JISとしては不要。
−
−
8
Determine
Value
Adjustment
Factor
(Optional)
削除
全文削除
調整済みファンクションポイントに
ついての参考記述であり，JISには不
要。
4
6
X
0
1
4
2
：
2
0
1
0
2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。
(I)JISの規定
(II)
国際規格
番号
(III)国際規格の規定
(IV)JISと国際規格との技術的差異の箇条
ごとの評価及びその内容
(V)JISと国際規格との技術的差異の
理由及び今後の対策
箇条番号
及び題名
内容
箇条番号
内容
箇条ごと
の評価
技術的差異の内容
−
−
9
Calculate Adjusted
Function Point Count
削除
全文削除
調整済みファンクションポイントに
ついての参考記述であり，JISには不
要。
−
−
Appendix
A
Calculation Tables
削除
全文削除
本文中に記載しており，JISとして
は，再掲不要とした。
−
−
Appendix
B
The Change from CPM4.0
to 4.1
削除
全文削除
計測マニュアル4.0から4.1への変更
内容についての記述であり，JISには
不要。
JISと国際規格との対応の程度の全体評価：ISO/IEC 20926:2003：MOD
注記1 箇条ごとの評価欄の用語の意味は，次による。
− 削除……………… 国際規格の規定項目又は規定内容を削除している。
− 変更……………… 国際規格の規定内容を変更している。
注記2 JISと国際規格との対応の程度の全体評価欄の記号の意味は，次による。
− MOD…………… 国際規格を修正している。
4
6
X
0
1
4
2
：
2
0
1
0