>サイトトップへ >このカテゴリの一覧へ

X 0142

:2010

(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

  計測した ILFRET 及び DET の概要

52


X 0142

:2010  目次

(2)

ページ

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

  計測した EIFRET 及び DET の概要

67

7.7.11

  EIF の複雑さ及び寄与

67

8

  トランザクション  ファンクションの計測

68

8.1

  EIEO 及び EQ の定義

68

8.2

  EIEO 及び EQ の計測規則

72

8.3

  EIEO 及び EQ の計測手順

76

8.4

  EIEO 及び 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

  EIEO 及び 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

  EIFTR 及び DET 計測の概要

114


X 0142

:2010

(3)

ページ

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

  事例 7EO の主機能

127

8.8.10

  事例 8EO トランザクション  ファイル

129

8.8.11

  計測した EOFTR 及び 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

  計測した EQFTR 及び DET の概要

151

8.9.12

  EQ の複雑さ及び寄与

151

附属書 JA(参考)JIS と対応国際規格との対比表

153

X 0142

:2010  目次


X 0142

:2010  目次

(4)

まえがき

この規格は,工業標準化法に基づき,日本工業標準調査会の審議を経て,経済産業大臣が制定した日本

工業規格である。

この規格は,著作権法で保護対象となっている著作物である。

この規格の一部が,特許権,出願公開後の特許出願,実用新案権又は出願公開後の実用新案登録出願に

抵触する可能性があることに注意を喚起する。経済産業大臣及び日本工業標準調査会は,このような特許

権,出願公開後の特許出願,実用新案権及び出願公開後の実用新案登録出願にかかわる確認について,責

任はもたない。


日本工業規格

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

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

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

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

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

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

システム更改前後の環境の違いによって要求される変換及び/又は導入への配慮がアプリケーション開

発に与える影響の度合い。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

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

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

とによってソフトウェアを測定する。したがって,ファンクションポイント法の目的は,次のとおりにな

る。

−  利用者が要求し受け取る機能を測定する。

−  実装技術とは独立して,ソフトウェア開発及び維持管理を測定する。

上記の目的を満たすことに加え,ファンクションポイントを計測する手順は,次の特徴をもつ。

−  測定作業の負担を最小限にするためには十分簡易である。

−  多様なプロジェクト及び組織間で一貫した測定が実施できる。

3.1.2

ファンクションポイント法の利点

ファンクションポイント法は,次のことに適用できる。

−  購入したパッケージソフトウェアのすべての機能をファンクションポイント法を用いて計測すること

によって,そのパッケージソフトウェアの規模を決定する。

−  特に,利用者要件に合致する機能をファンクションポイント法を使用して計測することによって,利

用者組織に与えるパッケージソフトウェアの利点を利用者が決定することを支援する。

−  品質及び生産性の分析を支援するためにソフトウェア製品の規模を計測する。

−  ソフトウェアの開発及び維持管理に必要とされる費用及び資源を見積もる。

−  ソフトウェアを比較するための正規化の要素として用いる。

3.2

計測事例の概要

ここでは,ファンクションポイント計測の作業手順及び計測対象となっている構成要素について,概要

事例を示す。

3.2.1

概要図

人事情報システムの計測事例に関係する構成要素を,

図 に示す。以降では,この図に基づいて説明す

る。

図 1−人事情報システム概略図

利用者

利用者

社員情報の検索及び表示

(EQ)

社員報告書

(EO)

新入社員情報(EI)

人事情報システム

社員情報(ILF)

アプリケーション

境  界

為替システム

為替レート(EIF)

利用者


11

X 0142

:2010

3.2.2

作業手順

3.2.2.1

  ファンクションポイント種別の決定

ファンクションポイント計測の最初の作業は,ファンクションポイント計測の種別を決定することであ

る。

ファンクションポイントは,開発プロジェクト又はアプリケーションのいずれかに対応している。ファ

ンクションポイントには,次の 3 種類がある。

−  開発プロジェクト  ファンクションポイント

−  機能改良プロジェクト  ファンクションポイント

−  アプリケーション  ファンクションポイント

図 で示した人事情報システムの事例は,プロジェクト  ファンクションポイントのものであり,これは

また,アプリケーション  ファンクションポイントにつながっていく。

ファンクションポイント種別の詳細な定義は,箇条 に示す。

3.2.2.2

  計測範囲及びアプリケーション境界の明確化

計測範囲は,ファンクションポイントに含まれる機能を定義する。

アプリケーション境界(

図 の点線部)は,測定対象ソフトウェアと利用者との境界を示す。

図 は,測定対象の人事情報システムと為替システムとのアプリケーション境界を示している。この図

は,また,人事情報システムと利用者とのアプリケーション境界も示している。

計測範囲及びアプリケーション境界については,箇条 に示す。

3.2.2.3

  未調整ファンクションポイントの決定

未調整ファンクションポイントは,プロジェクト又はシステムが利用者に提供する特定の計測可能な機

能を反映したものである。

システムの特定の利用者機能は,その機能が“どのように”実現されるかではなく,システムによって

“何が”実現されるかの観点で評価され,利用者が要求し定義した要素だけが計測される。

未調整ファンクションポイントには,

データ及びトランザクションの二つのファンクション種別がある。

これらは,更に

図 に示すように分類される。

未調整ファンクションポイントは単位呼称であり,未調整ファンクションポイントは,JIS X 0135-1 

定義されている機能規模である。

図 2−未調整ファンクションポイント種別

内部論理ファイル 
(ILF)

外部インタフェース 
ファイル(EIF)

データ 
ファンクション

未調整 
ファンクションポイント

外部入力(EI)

外部出力(EO)

外部照会(EQ)

トランザクション 
ファンクション


12

X 0142

:2010

3.2.2.4

  データファンクションの計測

データファンクションは,アプリケーション境界の内部データ要件及び外部データ要件を満たすために

利用者に提供される機能を表す。データファンクションは,ILF 又は EIF である。

− ILF とは,計測対象のアプリケーション境界の内部で維持管理される,論理的に関連のあるデータ又

は制御情報の利用者視点のグループのことをいう。ILF は,計測対象のアプリケーション境界の内部

にある一つ以上の要素処理によって維持管理されるデータを保持することを主目的とする。

図 における人事情報システムの ILF は,当該アプリケーションの中で維持管理される社員データ

のグループである。

− EIF とは,計測対象のアプリケーションによって参照される,論理的に関連のあるデータ又は制御情

報の利用者視点のグループのことをいう。ただし,維持管理は,他のアプリケーション境界の内部で

行われる。EIF は,計測対象のアプリケーション境界の内部にある一つ以上の要素処理によって参照

されるデータを保持することを主目的とする。このことは,あるアプリケーションで計測される EIF

は,他のアプリケーションにおいて ILF でなければならないことを意味している。

図 で示す人事情報システムの例は,為替システムによって維持管理され,人事情報システムによ

って参照される為替レートを示している。

データファンクションの詳細を,箇条 に示す。

3.2.2.5

  トランザクション  ファンクションの計測

トランザクション  ファンクションは,データ処理のために利用者に提供される機能を表す。トランザク

ション  ファンクションは EI,EO 又は EQ のいずれかである。

− EI とは,計測対象のアプリケーション境界の外部から入力されるデータ又は制御情報を処理する要素

処理のことをいう。EI は,一つ以上の ILF の維持管理及び/又はシステムの振る舞いの変更を主目的

とする。

図 で示す人事情報システムの例は,人事情報システムに社員情報を入力する処理を示している。

− EO とは,計測対象のアプリケーション境界の外部にデータ又は制御情報を出力する要素処理のこと

をいう。EO は,データ又は制御情報の取り出しの有無にかかわらず,処理ロジックによって情報を

利用者に提供することを主目的とする。EO は,処理ロジックに少なくとも一つの“数式又は演算の

実行”又は導出データの生成を含まなければならない。EO は,一つ以上の ILF の維持管理及び/又

はシステムの振る舞いの変更を行ってもよい。

図 で示す人事情報システムの例は,人事情報システムに登録されているすべての社員を記載する

報告書を作成する処理を示している。

− EQ とは,計測対象のアプリケーション境界の外部にデータ又は制御情報を送り出す要素処理のこと

をいう。EQ は,ILF 又は EIF からデータ又は制御情報を取り出すことによって利用者に情報提供する

ことを主目的とする。EQ は,処理ロジックに“数式又は演算の実行”を含まない。さらに,導出デ

ータを生成しない。処理中に ILF を維持管理せず,システムの振る舞いの変更も行わない。

図 で示す人事情報システムの例は,社員情報を問い合わせて(入力要求),画面上に社員情報が表

示されたとき(出力検索)

,それを見る処理を示している。

トランザクション  ファンクションの詳細を,箇条 に示す。

4

利用者要件記述

ここでは,プロジェクト又はシステムに対する利用者機能要件を定義するときの利用者の役割について


13

X 0142

:2010

の概念を示す。

4.1

利用者要件記述の定義

利用者要件記述とは,利用者の言葉による利用者業務の公式な記述のことをいう。開発者は,これを実

現するために,利用者情報を情報技術の言語に変換する。

ファンクションポイント計測は,利用者及び開発者の両者に共通の言語で表した情報を利用して達成さ

れる。

利用者要件記述とは,次のことをいう。

−  業務機能の記述である。

−  利用者に承認されている。

−  ファンクションポイントを計測するために利用できる。

−  物理的な様式は多様である(例えば,トランザクションのカタログ,提案書,要件書,外部仕様書,

詳細仕様書,利用者マニュアルなど)

4.2

システムのライフサイクルを通した規模測定

プロジェクトの初期段階では,利用者機能要件は急速に拡大する。システムに組み入れる機能の選択に

ついては,利用者と開発者との間で合意されなければならない。プロジェクトの機能に関するこうした決

定は,次のものから影響を受ける。

−  組織のニーズ

−  プロジェクトに関連した(業務及び技術に関する)リスク

−  プロジェクトに割当てできる組織内での資源(例えば,予算,要員)

−  組織内で利用可能な技術

−  コメント及び提案を通しての利用者又は開発者の影響

プロジェクトの開始時には,

実現可能性の検討を行う。

実現可能性の検討の結果として得られるものは,

抽象度の高い仕様書であり,通常は,非常に簡潔に記述される。例えば,次のようなものをいう。

−  組織は,新税法に対応するシステムを必要とする。

−  組織は,より効率的な在庫管理を実施するためのシステムを必要とする。

−  組織は,より効率的に人事情報を取り扱うシステムを必要とする。

実現可能性の検討の後,利用者は時間の経過とともに要件を詳細化する。ある時点で利用者は,ソフト

ウェア開発者と協議して詳細な要件を作成する。一方,ソフトウェア開発者は,実現可能性の検討結果を

もとに,早期に開発要件及び実現要件の検討に着手することができる。利用者と開発者とが議論すること

によって,要件が改善される。開発プロセスは組織によって異なっている。この規格では,目的を示すた

めに,要件書を次の三つに分けて説明する。

−  初期利用者要件書

−  初期技術要件書

−  最終機能要件書

他の開発手法と同様に,最終機能要件書の段階で,ファンクションポイントを最も正確に計測すること

ができる。

4.2.1

初期利用者要件書の段階

この段階では,利用者とソフトウェア開発者との間の打合せの前に利用者要件を示す。この段階は,次

の特性を一つ以上もっていてもよい。

−  不完全性


14

X 0142

:2010

例 1  初期利用者要件書は,関連する完全性に対して必要な機能を欠いてもよい。

−  ユーティリティ機能の欠如

例 2  必す(須)の妥当性確認の報告機能又は照会機能を欠いてもよい。

−  実現不可能又は利用困難

例 3  利用者は,1 時間の CPU 処理を必要とするオンライン照会を要求してもよい。

−  一般性の過多

例 4  要求には項目数を含まなくてもよい。

−  二人以上の利用者がプロジェクトに責任を負っている場合,機能要求の不統一

例 5  要件が同じでない場合,利用者によって特定のプロジェクトの要求事項が異なってもよい。

−  アプリケーション境界を考慮せずに規定された要件

例 6  現在及び/又は将来のアプリケーション境界が考慮されていなくてもよい。

−  機能規模分析の概念又は定義に矛盾する表現

例 7  初期利用者要件書は,システムの物理的又は運用的な事項に言及してもよい。

a)

事例

人事情報システムでは,利用者は,次のように要件を表現する。

“社員に関する作業を行っている間はいつでも,社員氏名を入力することによってその社員の情報が見

ることができるようにして欲しい。

この要件は,照会画面の開発及び社員に関するひとまとまりのデータの開発を意味している(事例を単

純にするために,詳細には示さないが,社員に関するひとまとまりのデータは,社員の追加,更新及び削

除といった別の社員対応機能で内部的に維持管理される。

初期利用者要件書における機能の例には,次のものがある。

  EQ  特定の社員に対する照会

  ILF  社員に関するひとまとまりのデータ

4.2.2

初期技術要件書の段階

この段階では,実現可能性の検討から生成される,ソフトウェア開発者の視点からの要件を示す。既存

のアプリケーションがある場合,その中に要件を組み入れることはソフトウェア開発者の仕事の一つであ

る。初期技術要件書は,実現には必要とするが,ファンクションポイント計測には使用しない要素を含ん

でもよい(例えば,一時ファイル,索引など)

。初期技術要件書は,次の特性を一つ以上もっている。

−  技術依存

例 1  物理ファイルは,データベース環境によって変化する。

−  利用者の機能要求の誤識別

例 2  ソフトウェア開発者は,利用者が要求していない機能を追加してもよい。

−  利用者にとってなじみのない用語

例 3  ソフトウェア開発者は,論理的なデータではなく,物理的ファイルに言及してもよい。

−  技術的制約を過度に重視して,機能が決定されてもよい。

例 4  開発者は,その組織で現在利用可能な計算機の処理能力に注目して,要求範囲を制限する傾

向がある。

−  組織の中の他のアプリケーションの技術的な構造に従って,アプリケーション境界が決定される。

例 5  クライアントとサーバとでは技術要件が異なってもよいが,ファンクションポイントを計測

するときは,同一のアプリケーション境界に含まれる。


15

X 0142

:2010

a)

事例

初期利用者要件書の段階と同一の事例を用いると,開発者は,次のように示している。

“社員照会の要求は理解する。特定の社員の情報を高速で取り出すためには索引を必要とする。

初期技術要件書で機能は,次のように識別されることがある。

  EQ  特定の社員に対する照会

  ILF  社員に関するひとまとまりのデータ

  ILF

1)

  社員ファイルに関する索引

1)

  この規格では,索引ファイルは計測対象ではない。この事例では,ソフトウェア開発者が犯

しやすい計測誤りを示すために索引ファイルを誤って ILF と識別している。

4.2.3

最終機能要件書の段階

この段階では,最終機能要件書は,利用者とソフトウェア開発者との共同作業の結果から得られる。共

同作業は,システムの矛盾のない完全な機能要件書を作成するために必要になる。この段階では,開発段

階を開始する前の,機能要件書の最終版であり,次の特性をもつ。

−  利用者及びソフトウェア開発者の両者が理解できる用語で書かれている。

−  他の利用者の要件も含めて,すべての利用者要件を統合した記述を提供している。

−  ファンクションポイントを正確に計測するために十分な程度に完全で,矛盾がない。

−  すべてのプロセス及びすべてのデータが利用者によって承認されている。

−  実現可能性及び使用性がソフトウェア開発者によって承認されている。

a)

事例

初期利用者要件書の段階と同一の事例を用いると,次のようになる。

利用者  “社員に関する作業を行っている間はいつでも,社員氏名を入力することによってその社員

の情報を見ることができるようにして欲しい。

開発者  “社員照会の要求は理解する。しかし,同じ氏名をもつ社員がいるかもしれない。氏名を入

力するだけでは社員を特定することはできない。したがって,社員を選択するための社員一

覧画面(社員氏名,事業所及び保険者番号)を提案する。特定の社員の情報を高速で取り出

すためには索引を必要とする。

利用者  “この場合,社員一覧画面が必要なことについては了解した。また,その機能は,社員選択

以外の目的にも利用できるかもしれない。

利用者と開発者との議論の結果は,次のとおりになる。

−  機能要件書に社員一覧画面を追加し,ファンクションポイント計測を行う。

−  社員索引は,技術的な解決策であるため,ファンクションポイント計測から除く。

この例の最終機能要件書に含まれる機能は,次のとおりになる。

  EQ  特定の社員に対する照会

  EQ  社員一覧画面

  ILF  社員に関するひとまとまりのデータ

最終機能要件書は,開発段階を開始する前の,要件の最終版である。この時点で,文書化した要件書が,

完全で,正式で,承認されていることに合意していることが望ましい。計測範囲に追加の変更がないとす

れば,ファンクションポイントは,開発の完了時のファンクションポイントと一致する。

4.3

ライフサイクル段階の比較

ファンクションポイントを計測する前に,アプリケーションのライフサイクル段階を決め,見積もろう


16

X 0142

:2010

としているのか又は測定しようとしているのかを決める。いろいろな前提を記述する。

ファンクションポイント分析を完了するため,見積りには,未知の機能及び/又はそれらの複雑さにつ

いて前提を設けてもよい。

ファンクションポイント分析を完了するため,測定には,すべての機能及びそれらの複雑さの識別を包

含する。

初期の段階では,初期利用者要件だけがファンクションポイント分析のために入手できる唯一の文書で

ある。このような不利な点があるが,この計測値は,初期見積りを行うために有効である。様々なライフ

サイクル段階における,見積りのためのファンクションポイント法の用途を,

表 に示す。

表 1−ファンクションポイント法の用途

ライフサイクル段階

規模の見積りは可能か。

規模の測定は可能か。

提案:利用者がニーズ及び意図を表現する。

可能

不可能

要件:開発者及び利用者がレビューを行い,利用者
ニーズ及び意図の表現について合意する。

可能

可能

設計:開発者は,ファンクションポイント分析では
利用されない要素の実現を含めてもよい。

可能

可能

構築

可能

可能

出荷

可能

可能

修正保守

可能

可能

注記  特定のライフサイクルを意味しているわけではない。開発者と利用者とが対話する手法を使用する場合,

アプリケーションのライフサイクルにおけるある時点での見積りを期待できる。十分注意し,新規であ
れ,改良であれ,合意された利用者ニーズ及び意図を測定する。

4.4

計測上の留意点

次の留意点は,アプリケーションに対する利用者要件記述の識別に役立ち,ファンクションポイント法

の適用に役立つ。

−  利用者の観点からデータを論理的にみるとき,一つの物理的ファイルが一つの論理的ファイルに対応

すると想定しない。

−  リレーショナル DBMS のテーブル又は順編成ファイルのような,ある種のデータ蓄積技術は,ILF 又

は EIF と密接に関連しているが,このことが常に物理対論理の 1 対 1 の対応関係に等しいと想定しな

い。

−  すべての物理的ファイルは,ILF 又は EIF の一部として計測又は包含されなければならないと想定し

ない。

−  トランザクション  ファンクションを識別するときには,利用者が現在利用している他の紙書式も調べ

てみる。

−  複数の物理的入力,トランザクション  ファイル又は画面で発生するトランザクションで,処理ロジッ

クが同じトランザクションは,通常は,一つのトランザクション  ファンクション(EI,EO,EQ)に

相当する。

−  論理的にみる場合,一つの物理レポート,画面又はバッチ出力ファイルは,複数の EO 及び/又は EQ

に対応できることを念頭に置く。

−  処理ロジックが同じ場合,二つ以上の物理レポート,画面又はバッチ出力ファイルは,一つの EO 又

は EQ に対応できることを念頭に置く。

−  一組のデータの再ソート又は再整列がその処理ロジックを独自なものとはしないことを念頭に置く。


17

X 0142

:2010

5

計測種別の決定

ファンクションポイント計測の最初の作業は,ファンクションポイント計測の種別を決定することにあ

る。

5.1

ファンクションポイント計測種別の定義

ファンクションポイント計測には,プロジェクト又はアプリケーションのいずれかが関係する。それら

には,次の三つがある。

−  開発プロジェクト  ファンクションポイント

−  機能改良プロジェクト  ファンクションポイント

−  アプリケーション  ファンクションポイント

5.1.1

5.1.3 で,ファンクションポイント計測の各種別を定義する。

5.1.1

開発プロジェクト  ファンクションポイント

開発プロジェクト  ファンクションポイントは,

開発プロジェクトが完了したときに納入されたソフトウ

ェアの最初の導入時に,利用者に提供される機能の計測値である。

5.1.2

機能改良プロジェクト  ファンクションポイント

機能改良プロジェクト  ファンクションポイントは,既存のアプリケーションに対する,開発プロジェク

トが完了したときに納入された利用者機能に追加,修正又は削除を行う改良の計測値である。

機能改良プロジェクトによる変更機能を導入するときに,アプリケーションのファンクションポイント

は,機能の変更を反映するために更新されなければならない。

5.1.3

アプリケーション  ファンクションポイント

アプリケーション  ファンクションポイント及びプロジェクト  ファンクションポイントは,導入された

アプリケーションと関連が付いている。その値は,ベースライン  ファンクションポイント又は導入ファン

クションポイントとしても参照されている。この値は,アプリケーションが利用者に提供する最新の機能

の計測値を示す。この値は,開発プロジェクトにおけるファンクションポイントが決まったときに初期値

とされる。機能改良プロジェクトが完了してアプリケーションの機能が変更される都度,この計測値は更

新される。

5.2

計測の種別の作業手順図

ファンクションポイント計測の種別及びそれらの関係を,

図 に示す(プロジェクト A が最初に完了し,

続いてプロジェクト B の順になる。


18

X 0142

:2010

 

図 3−計測種別

5.2.1

見積り値及び最終計測値

開発の初期段階でのファンクションポイント計測が納入する機能の見積りであることを自覚することが

重要になる。加えて,範囲が明らかになり,機能が開発されるにつれて,当初の仕様書には示されていな

い追加機能が明確になることはごく当たり前のことである。この現象を,要求の自然増(scope creep,scope

gallop)などということがある。

開発の完了時にアプリケーション  ファンクションポイントを更新することが最も重要になる。

開発中に

機能を変更する場合,開発の完了時でのファンクションポイント計測は,利用者に納入した全機能を正確

に反映していることが望ましい。

6

計測範囲及びアプリケーション境界の識別

ここでは,計測の目的,計測範囲及びアプリケーション境界を定義する。アプリケーション境界の決定

及び計測範囲の明確化のための規則,作業手順及び留意点を示す。

6.1

計測範囲及びアプリケーション境界の決定

ここでは,計測範囲及びアプリケーション境界を定義し,計測の目的がそれらに与える影響について説

明する。

6.1.1

計測の目的の定義

ファンクションポイント計測は,業務課題への解決策を提供することを目的とする。

計測は,次のことを目的とする。

−  ファンクションポイント計測の種別及び開発中の業務課題への解決策を得るために必要とされる計測

範囲を決定する。

−  計測対象のソフトウェアと関連するソフトウェアとの間の境界決定に影響を与える。

例えば,人事情報システムの人事情報モジュールをパッケージソフトウェアに置き換える場合,利

用者は境界を再設定してもよいし,人事情報モジュールを関係のないアプリケーションと考えてもよ

い。

見積り値

プロジェクト A としての

開発プロジェクト

ファンクションポイント

最終計測値

プロジェクト A としての

開発プロジェクト

ファンクションポイント

見積り値

プロジェクト B としての

機能改良プロジェクト

ファンクションポイント

最終計測値

プロジェクト B としての

機能改良プロジェクト

ファンクションポイント

ア プ リ ケ ー シ ョ ン
フ ァ ン ク シ ョ ン ポ
イント

プロジェク

トの完了

初期値設定

プロジェク

トの完了

更新


19

X 0142

:2010

計測の目的の例を次に示す。

−  アプリケーションの最初のリリース版の開発工数を決めるために,見積り工程の入力として,ファン

クションポイントを提供する。

−  アプリケーションの導入された基本部分のファンクションポイントを提供する。

−  二つの異なった供給者のパッケージソフトウェアによって納入される機能の比較を可能とするための

ファンクションポイントを提供する。

6.1.2

計測範囲の定義

計測範囲は,特定のファンクションポイントに含まれる機能を次のように決定する。

−  計測範囲は,計測対象のソフトウェアを決定する。

−  計測範囲は,ファンクションポイントの計測の目的によって決定される。

−  計測範囲は,計測目的に関係のある解を提供するために,ファンクションポイントにどの機能が含ま

れるかを識別する。

−  計測範囲は,二つ以上のアプリケーションを含む可能性がある。

計測種別ごとの計測範囲を次に示す。

−  機能改良プロジェクト  ファンクションポイント

追加,変更又は削除されるすべての機能を含む。影響を受けるアプリケーション境界は,機能改良

の前後で,変わらない。アプリケーションの機能は,追加,変更又は削除される機能の影響を反映す

る。

−  開発プロジェクト  ファンクションポイント

プロジェクト活動で影響を受ける(構築される又はカスタマイズされる)全機能を含む。

−  アプリケーション  ファンクションポイント

利用目的(例えば,ソフトウェアの解決策としてパッケージソフトウェアを提供する。

)によって異

なり,次のような例がある。

−  利用者によって利用される機能だけ

−  納入される全機能

この二つの計測のアプリケーション境界は同じであり,計測範囲とは独立している。

6.1.3

アプリケーション境界の定義

アプリケーション境界は,測定対象ソフトウェアと利用者との間の境界を示す。

−  アプリケーション境界は,アプリケーションの外部を定義する。

−  アプリケーション境界は,

アプリケーションの内部と外部である利用者との間の概念的な境界をいう。

−  アプリケーション境界は,トランザクション(EI,EO 及び EQ)によって処理されるデータをアプリ

ケーションの内部又は外部に移動させる“細胞膜”として作用する。

−  アプリケーション境界は,アプリケーション(ILF)によって維持管理される論理データを含む。

−  アプリケーション境界は,このアプリケーションによって参照されるが維持管理されない論理データ

を識別する助けとなる。

−  アプリケーション境界は,アプリケーションに関する利用者の業務上の視点に依存し,技術的な観点

及び/又は実装上の観点に依存しない。

例えば,

図 は,人事情報システムと外部のアプリケーション(為替システム及び固定資産管理システ

ム)との間の境界を示している。さらに,利用者と人事情報システムとの間の境界も示している。


20

X 0142

:2010

図 4−アプリケーション境界

6.2

計測範囲及びアプリケーション境界に関する規則及び手順

ここでは,計測範囲及びアプリケーション境界を決めるときに適用する規則及び手順について示す。

アプリケーション境界の位置は,

ファンクションポイント計測の結果に影響を与える重要な事項である。

アプリケーション境界は,計測範囲に含まれるアプリケーションに入力するデータを識別するために役立

つ。

6.2.1

アプリケーション境界に関する規則

アプリケーション境界には,次の規則を適用しなければならない。

−  アプリケーション境界は,利用者の視点に基づいて決め,利用者が理解及び表現できるものに焦点を

当てる。

−  関連したアプリケーション間の境界は,技術的な観点ではなく利用者側から見た別々の機能領域に基

づく。

−  アプリケーション又は機能改良対象のアプリケーションに対して設定された最初のアプリケーション

境界は,計測範囲の影響を受けない。

注記 1  計測範囲の中に二つ以上のアプリケーションを含んでもよい。その場合には,複数のアプリ

ケーション境界を設定する。

注記 2  要求分析の初期段階のようにアプリケーション境界が明確に定義できない場合,可能な限り,

アプリケーション境界を設定することが望ましい。

6.2.2

計測範囲及びアプリケーション境界に関する作業手順

利用者

人事情報システム

(計測対象プロジェクト)

為替システム

固定資産

管理システム


21

X 0142

:2010

手順

作業内容

1

計測の目的を決定する。

2

計測範囲を識別する。

3

アプリケーション境界を識別する。

4

次の項目を文書化する。 
−  計測の目的

−  計測範囲 
−  アプリケーション境界 
−  上記に関連するすべての前提

6.3

計測範囲及びアプリケーション境界を識別するための留意点

6.3.1

計測範囲

計測範囲の識別に役立つ留意点を次に示す。

−  計測範囲の決定のため,ファンクションポイント計測目的をレビューする。

−  導入されたベースライン  ファンクションポイント計測の範囲(すなわち,保守チームによって維持管

理されている機能)を識別する場合,現在提供され,利用者に利用されている全機能を含める。

6.3.2

アプリケーション境界

アプリケーション境界の識別に役立つ留意点を次に示す。

−  システムの外部仕様書を使用するか,又はシステムフロー図を手に入れるかして,アプリケーション

の内部及び外部を明示するためシステムの周りに境界線を引く。

−  データのグループがどのように維持管理されているかを調査する。

−  ある種別の分析対象(例えば,実体又は要素処理)の所有者を機能領域に割り付けることによって機

能領域を明確にする。

−  工数,費用,欠陥などの関連した測定データを調査する。ファンクションポイント及び他の測定デー

タの境界は同じであることが望ましい。

6.3.3

留意点

開発中のソフトウェアと他のアプリケーションとの間のアプリケーション境界の設定は,主観的になっ

てもよい。一つのアプリケーションがいつ終了して,次のアプリケーションがいつ開始するかを正確に説

明することは,困難な場合が多い。技術的観点又は物理的観点ではなく,業務上の観点からアプリケーシ

ョン境界を設定する。アプリケーション境界を出入りするすべてのデータは,潜在的に計測範囲に含まれ

るので,アプリケーション境界は,注意して設定することが重要になる。

7

データファンクションの計測

データファンクションは,アプリケーション境界の内部又は外部のデータに対する要件を満たすために

利用者に提供される機能を表す。データファンクションには,内部論理ファイル(ILF)及び外部インタフ

ェースファイル(EIF)の二つがある。

ここでのファイルという用語は,従来のデータ処理で用いられる意味とは異なる。データファンクショ

ンにおけるファイルとは,論理的に関連するひとまとまりのデータのグループであり,物理的に実装され

たグループのひとまとまりではない。

ここでは,ILF 及び EIF の定義を含み,これらのファンクション型に関連する計測の作業手順及び規則

について記述する。


22

X 0142

:2010

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

例 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

ここでは,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

−  必す(須)サブグループ

任意サブグループは,データインスタンスを追加又は生成する要素処理では,使用しなくてもよい。

必す(須)サブグループは,データインスタンスを生成する要素処理では,少なくとも一つは使用しな

ければならない。

例  人事情報システムでは,共通情報を入力することによって社員情報を追加する。共通情報に加え

て,社員情報には正社員又は非正社員を区別する情報がある。

利用者は,社員が正社員であるか,非正社員であるかを決める。どちらの社員にも扶養家族情

報がある。この例では,次に示すように三つのサブグループ又は 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

手順

        作業内容

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 の複雑さが一つあるときの計測例を次に示す。

ファンクション型

ファンクションの複雑さ  複雑さの合計

ファンクション型の合計

0

  低  × 7  =

0

0

  中  × 10  =

0

ILF

1

  高  × 15  =  15

15

0

  低  × 5  =

0

2

  中  × 7  =  14

EIF

1

  高  × 10  =  10

24

この簡単な例では,複雑さが低又は中と判定された ILF はないので,ILF の寄与の合計値は 15 となる。

EIF の複雑さは,複雑さ低がなく,複雑さ中が二つで 14,複雑さ高が一つで 10 となり,合計値は 24 とな

る。

ILF 及び EIF の寄与は,すべてのファンクション型について集計する表に加える。すべてのファンクシ

ョン型についての最終合計値が,未調整ファンクションポイントとなる。

7.4

計測上の留意点

次の計測上の留意点は,ILF 及び EIF の識別規則を適用するときに参考にしてもよい。

注意  計測上の留意点は,計測規則ではないので,規則として使用しないことが望ましい。


27

X 0142

:2010

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

ここでは,事例の記述方法について説明する。

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

  構成要素の図

各事例の構成要素及び情報の流れを,

図 に示す。


29

X 0142

:2010

計測及び/又は識別の基礎情報

利用者要件

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

  計測及び/又は識別の基礎情報

各事例は,最初に計測及び/又は識別の基礎情報を提示する。

図 に示すように,計測及び/又は識別

は,次の情報に基づいて行う。

−  利用者要件

−  データモデル及びプロセスモデル

−  画面,画面情報又は報告書


30

X 0142

:2010

注記  図のすべての情報がすべての例に含まれているわけではない。事例の中には,利用者要件だけ

が計測の基本になるものがある。他の例では,データモデル又はプロセスモデル,画面,画面

情報及び報告書を含んでいるものもある。

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−事例一覧

事例

概要

人事情報システムのデータ

結合したデータに対して ILF の識別を行う事例

人事情報システムのセキュリティ

人事情報システムのセキュリティ要件に対して ILF を識別する
事例

照会及び報告書出力のための監査データ

実装面の要件に対して ILF を識別する事例

未確定業務情報

アプリケーション境界の内部で維持管理される中断業務情報に

対して ILF を識別する事例

報告書書式定義

アプリケーション境界の内部で維持管理される利用者要件に基

づく報告書書式定義に対して ILF を識別する事例

代替索引

報告書定義の事例で記述した利用者要件のほかに,物理実装要
件に焦点を当てた事例

共用データ

二つ以上のアプリケーションで維持管理されるデータに対して
ILF を識別する事例

異なる利用者及び/又は異なるデータ視点

二つのアプリケーションが同一ファイルの異なる DET を利用す
る事例

7.6.2

事例 1:人事情報システムのデータ

7.6.2.1

  利用者要件

利用者は,業務情報の入力,照会及び報告書出力ができることを要求している。

一緒に維持管理されなければならない業務情報には,次のものが含まれる。

−  業務番号

−  業務名称

−  業務給与等級

−  業務説明行番号


31

X 0142

:2010

−  業務説明

業務説明は,1 行当たり 80 文字の行を複数行使用して記述することが望ましい。

7.6.2.2

  E-R 

データの正規化によって得られた二つの実体を次の E-R 図(

図 6)に示す。実体は,業務及び業務説明

である。

業務

業務
説明

凡例:

必す(須)の1対多の関係

属性実体型

実体型

図 6−人事情報システムの業務の E-R 

業務には,次を含む。

−  業務番号

−  業務名称

−  業務給与等級

業務説明には,次を含む。

−  業務番号

−  業務説明行番号

−  業務説明

7.6.2.3

  データベース構造

人事情報システムのデータベース構造を,

図 に示す。


32

X 0142

:2010

社員

業務説明

業務割当て

業務

給与等級

図 7−人事情報システムのデータベース構造

7.6.2.4

  データベース表

人事情報システムのためのデータベース構造を,

表 に示す。

表 3−人事情報システムのデータベース表

社員表

業務割当て表

業務説明表

データ要素

社員氏名 

名 
保険者番号 
雇用種別

部課番号 
管理職コード 
時給

円換算時給 
所属組合識別番号 
事業所名外部キー

通貨地域外部キー

データ要素

日付 
査定等級

給与 
業務番号外部キー 
保険者番号外部キー

データ要素

行番号 
業務説明

業務番号外部キー

業務表

事業所表

給与等級表

データ要素

業務名 
業務番号

給与等級

データ要素

国名 
郵便番号

都道府県名 
市区町村名 
事業所住所

事業所名 
保険者番号外部キー

データ要素

給与等級 
給与等級説明

7.6.2.5

  ILF の識別

E-R 図は,次の二つの情報のグループを示している。

−  業務


33

X 0142

:2010

−  業務説明

それぞれのグループが 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

−  業務説明行番号

−  業務説明

注記  業務説明は,それ自身では 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

−  利用者の保険者番号

−  アクセス権の種別

e)

事業所での利用者アクセス権の変更

f)

日々のセキュリティ活動の監視及び報告書出力のための監査データの取得。この要求は,利用者の画

面セキュリティ要件を満たすように設計を実施するときに決定する。

7.6.3.2

  E-R 

人事情報システムのセキュリティに関する E-R 図を,

図 に示す。

社 員

セ キ ュ リ テ ィ

扶 養 家 族

画 面

セ キ ュ リ テ ィ

画 面

セ キ ュ リ テ ィ

監 査

社 員

正 社 員

非 正 社 員

凡例:

必す(須)の 1 対 多の関係

任意の 1 対多の 関係

属 性実体型

実 体型

実 体副型

図 8−人事情報システムのセキュリティの E-R 

7.6.3.3

  実体属性

人事情報システムの E-R 図におけるセキュリティに関する実体属性を,

表 に示す。


36

X 0142

:2010

表 4−人事情報システムにおける実体属性

社員セキュリティ

画面セキュリティ

画面セキュリティ監査

データ項目 
  利用者 ID

  保険者番号 
  アクセス権種別 
  事業所

データ項目 
  利用者 ID

  保険者番号 
  画面 ID 
  利用者アクセス権

データ項目 
  変更日時

  変更実施者の利用者 ID 
  変更前情報 
    変更前利用者 ID

    変更前利用者アクセス権 
    変更前画面 ID 
  変更後情報

    変更後利用者 ID 
    変更後利用者アクセス権 
    変更後画面 ID

7.6.3.4

  データフロー図

この事例のデータフロー図を,

図 に示す。

 

凡例:

利用者又はシステム

保存データ

プロセス

データの流れ

図 9−データフロー図

報告書作成

利用者

画面セキュリティ追加

利用者 ID,保険証番号 
アクセス権, 
画面 ID

画面セキュリティ 
追加

画面 
セキュリティ

画面セキュリティ 
変更

画面 
セキュリティ
監査

社員セキュリティ 
追加

社員セキュリティ 
変更

社員 
セキュリティ

セキュリティ変更
報告書作成

画面セキュリティ変更

社員セキュリティ追加

社員セキュリティ変更

利用者 ID, 
保険証番号,アクセス権種別

社員セキュリティ情報の変更

日時,利用者 ID, 
変更前情報,変更後情報

日時,利用者 ID, 
変更前情報,変更後情報

日時, 
利用者 ID, 
変更前情報, 
変更後情報

画面セキュリティ 
情報の

変更


37

X 0142

:2010

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

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

社員セキュリティ情報に対する 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

社員セキュリティ

利用者 ID 
保険者番号

アクセス権種別   
事業所

合計 1RET

合計 4DET

7.6.4

事例 3:照会及び報告書出力のための監査データ

7.6.4.1

  利用者要件

次に示すセキュリティに関する利用者要件の分析から,監査データが必要であることが分かる。

a)

人事情報システムの各画面への利用者アクセスを許可又は拒否する。

b)

各画面に対する利用者アクセス権を変更する。

c)

次のデータを用いた,画面セキュリティの追加又は変更に関して報告する。

−  セキュリティ情報の追加又は変更を行う利用者の識別

−  追加又は変更された社員セキュリティ情報及び画面セキュリティ情報

−  変更前後の利用者セキュリティ情報及び画面セキュリティ情報

−  追加又は変更を行った日付及び時刻

d)

日々のセキュリティ活動の監視及び報告書出力のための監査データの取得。この要求は,利用者の画

面セキュリティ要件を満たすように設計を実施するときに決定する。

7.6.4.2

  データフロー図

図 を参照。このデータフロー図は,前の事例と共通である。

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

中断した業務の内容を変更する場合,すべての業務及びすべての業務説明の情報を維持管理する。

注記  この事例では,未確定業務情報ファイルが 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

各項目を調べる。各項目について,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

−  報告書の識別子

−  報告書名称

−  報告書で用いられる項目

−  報告書生成のための計算式

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

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

−  社員 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

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

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

7.6.9

事例 8:異なる利用者及び/又は異なるデータ視点

7.6.9.1

  利用者要件

人事情報システムの利用者によって維持管理されなければならない情報は,次のとおりである。

−  社員 ID

−  社員氏名

−  社員住所

社員住所には,次の項目を含んでいる。

−  階

−  建物番号

−  番地

−  市区町村名

−  都道府県名

−  郵便番号

−  社員給与等級

−  社員業務名称

新入社員レコードを生成した結果,社員の年金受給資格予定日が自動的に計算され,他の社員情報とと

もに保存される。人事情報システムの利用者は,各社員への郵便ラベルの作成を必要としている。

郵便発送担当部門では,各社員について,認識した番号内で変更を反映するために建物番号を維持管理

する機能を必要としている。

郵便発送担当部門では,社内便発送に最も効率的な方法を決定するため,事業所ごとの社員数を算出す

る機能も必要としている。それは,建物ごと,階ごとの社員数の一覧表である。

郵便発送担当部門が維持管理又は参照しなければならない情報は,次のとおりである。

−  社員 ID

−  階

−  建物番号

7.6.9.2

  データフロー図

この事例のデータフロー図を,

図 12 に示す。


49

X 0142

:2010

利用者

社員の 
生成

社員 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

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

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

サブグループがないので,郵便発送システムでの社員情報 ILF は,1RET となる。

郵便発送システムでの社員情報 ILF に対する RET 及び DET の合計を次の表に示す。

RET DET

社員情報

社員 ID 
階 
建物番号

合計 1RET

合計 3DET

7.6.10

  計測した ILFRET 及び 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

ファンクションの複雑さは,低,中又は高に判定される。

次の 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−事例一覧

事例

概要

他システムからのデータの参照
(出力処理)

他のシステムで維持管理されるデータを参照するシステムに対して EIF を識
別する事例。このデータは,外部出力において利用される。

他システムからのデータの参照
(入力処理の一部として)

他のシステムからデータを参照する事例。この事例では,外部入力に対して
他のシステムで維持管理されるデータを参照するシステムに対する EIF を識
別する。

他システムへのデータの提供

他のシステムが計測対象のシステムからデータを取り出すときの計測方法
の事例

ヘルプ機能システム

別個のシステムによって提供されるヘルプ機能を,人事情報システムとして
計測する事例


54

X 0142

:2010

データ変換

新しいシステムへデータ変換する場合の計測事例

トランザクション入力ファイル

人事情報システムに業務を追加するときに使用するトランザクション  入力
ファイルでの 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

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

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

為替情報には次を含む。

通貨

−  基本通貨に対する為替レート

−  国名

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

サブグループはないので,為替情報 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

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

項目ヘルプが 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

二つのアプリケーションが,同一の 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

 
 
 
 

人事情報システム

人事情報システム

正社員

派遣社員

社員

扶養家族

正社員 

派遣社員

社員

 
 
 

凡 例 :

属 性 実 体 型

実 体 型

の 一 対 多 の 関 係

実 体 副 型

図 15−データモデル図

新人事情報システムに社員情報を追加するため,旧人事情報システムの社員ファイルを使用する。

7.7.6.3

  EIF の識別

利用者要件から,旧社員情報ファイルが EIF であるかを決定する。分析の概要を次の表に示す。

EIF 識別規則

規則の該当・非該当

データ又は制御情報のグループは,論理的で利用者
視点によるものである。

当てはまらない。 
旧社員情報ファイルは,利用者の観点から論理的な
データのグループではない。

データのグループは,計測対象アプリケーションの
外部にあって参照されるものである。

当てはまらない。 
旧社員情報ファイルは,システムの外部にあるが,
参照されない。しかし,更新用データとして使われ
る。

データのグループは,計測対象アプリケーションに
よって維持管理されない。

当てはまる。 
旧社員情報ファイルは,人事情報システムで維持管
理される。

EIF として識別したデータのグループは,他のアプリ
ケーションの ILF として維持管理される。

当てはまる。 
旧社員情報ファイルは,旧人事情報システムの ILF
として維持管理される。

社員情報のファイルは,新システムに移行される社員情報のトランザクション  ファイルとなる。変換処

理は,新人事情報システムのアプリケーション境界の内部に入った後,社員情報を維持管理する。

旧社員情報ファイルは,

新人事情報システムの利用者の観点から,論理的なデータのグループではない。

したがって,EIF ではない。旧社員情報ファイルを外部入力として計測する方法を知るためには箇条 

参照する。

7.7.7

事例 6:トランザクション  入力ファイル

7.7.7.1

  利用者要件

利用者は,次の機能を要求している。

任 意 の 1 対 多 の 関 係


63

X 0142

:2010

−  オンラインによる業務情報の追加,更新,削除,照会及び報告書作成。

−  バッチ方式での業務情報の追加及び更新。

7.7.7.2

  レコードレイアウト

バッチ方式での業務情報の追加及び更新におけるレコードレイアウトを,

図 16 に示す。

図 16−レコードレイアウト

7.7.7.3

  レコード内容

各レコード型の内容を,

表 に示す。

表 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

データのグループは,計測対象アプリケーションの外
部にあって参照されるものである。

当てはまる。 
トランザクション  ファイルは,処理されるアプリケ
ーション境界の外部に存在する。

データのグループは,計測対象アプリケーションによ
って維持管理されない。

当てはまる。 
このデータは,維持管理されない。

EIF として識別したデータのグループは,他のアプリ
ケーションの ILF として維持管理される。

当てはまらない。 
業務 ILF を更新するためにアプリケーション境界の内
部に存在するトランザクションは,要素処理を構成す
る。トランザクションファイルを更新する要素処理は
存在しない。

この事例では EIF は存在しない。トランザクション入力ファイルを外部入力として計測する方法を知る

ためには箇条 を参照する。

7.7.8

事例 7:異なる利用者及び/又は異なる利用者記述

7.7.8.1

  利用者要件

人事情報システムの利用者は,新入社員の情報を維持管理することを要求している。

人事情報システムによって維持管理されるデータは,次のとおりである。

−  社員 ID

−  社員氏名

−  社員住所

−  社員給与等級

−  社員業務名称

新入社員レコードの作成に伴い,社員の年金受給資格日が自動計算され,他の社員情報とともに保存さ

れる。

年金システムの利用者は,

年金受給資格予定日で社員一覧を作成することができることを要求している。

7.7.8.2

  データフロー図

この事例のデータフロー図を,

図 17 に示す。

利用者

社員の 
生成

社 員 ID 
社 員氏名 
社 員住所 
社 員給与等級 
業 務名称 
年 金受給資格日

Screen

社員

利用者

社員 ID 
社員 氏名 
社員 住所 
社員 給与等級 
社員 職位 
年金 受給資格日  
セキ ュリティレ ベル

社員一覧の
印刷

社員 氏名 
年金 受給資格日

人事情報システム

年金システム

図 17−データフロー図


65

X 0142

:2010

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

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

EIF 識別規則

規則の該当・非該当

データ又は制御情報のグループは,論理的で利用者視
点によるものである。

当てはまる。 
すべてのデータは,利用者によって理解されている。

データのグループは,計測対象アプリケーションの外

部にあって参照されるものである。

当てはまらない。

データ及び社員一覧表の作成処理は,人事情報システ
ムの外部ではない。

データのグループは,計測対象アプリケーションによ
って維持管理されない。

当てはまらない。 
データは,人事情報システムで維持管理される。

EIF として識別したデータのグループは,他のアプリ
ケーションの ILF として維持管理される。

対象外。

社員情報を作成するために使用される社員一覧情報は,人事情報システムの EIF ではない。

7.7.10

  計測した EIFRET 及び 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




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

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

8.1.3

EQ

計測対象のアプリケーション境界の外部にデータ又は制御情報を送り出す要素処理。EQ は,ILF 又は

EIF からデータ又は制御情報を取り出すことによって利用者に情報提供することを主目的とする。EQ は,

処理ロジックに“数式又は演算の実行”を含まない。さらに,導出データを生成しない。処理中に ILF を

維持管理せず,システムの振る舞いの変更も行わない。

8.1.4

EI

EO

及び EQ の概要

トランザクション  ファンクション型間の主な違いは,主目的の違いである。

表 に各トランザクション

ファンクション型で実行できる機能を要約し,各々の主目的を示す。EI についての主目的に注意する。こ

れは,EO 及び EQ との主要な違いである。EO と EQ との主な違いは,EO は,利用者への情報提供という

主目的を実行するとき,システムの振る舞いを変更する機能又は一つ以上の ILF の維持管理を行う機能を

実行できることにある。両者のその他の違いについては,各トランザクション  ファンクションが使用する

処理ロジックの様式を 8.28.9 で示す。

表 7EIEO 及び 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

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

j)

システムの振る舞いの変更

例  給与支払日が,“毎月 15 日及び月の最終日”から“隔週の金曜日”に変更する場合,給与支払

の要素処理の振る舞いを変更する。

k)

アプリケーション境界の外部への情報の準備及び提供

例  利用者に社員一覧を提供する。

l)

アプリケーション境界の内部へ入力されるデータ又は制御情報を受け取る能力がある。

例  顧客の注文をシステムに追加するため,利用者は幾つかのデータを入力する。

m)

データの再構築又は再配列

例  利用者は,アルファベット順の社員一覧を要求する。

注記  データの再構築又は再配列は,トランザクション  ファンクションの型の識別すること又は重

複がないことに影響を与えない。

8.1.6

EI

EO

及び EQ が使用する処理ロジックの概要

EI,EO 及び EQ がどの処理ロジックを実行するかの概要を,表 に示す。各トランザクション  ファン

クション型に対して,それぞれトランザクション  ファンクション型の主目的を達成するために,実行しな

ければならない処理ロジックがある。

表 8−処理ロジックの概要表

トランザクション  ファンクション型

処理ロジックの定型手順

EI EO EQ

1  妥当性確認の実行

可能

可能

可能

2  数式又は演算の実行

可能

必す(須)

(最低一つ)

不可

3  等値変換の実行

可能

可能

可能

4  データの複数の組を比較するための特定の基準を使用し
たデータの抽出及び選択

可能

可能

可能

5  どちらを適用するかを決めるための条件の分析

可能

可能

可能

6  一つ以上の ILF の更新

必す(須)

(最低一つ)

必す(須)

(最低一つ)

不可

7  一つ以上の ILF 又は EIF の参照

可能

可能

必す(須)

8  データ又は制御情報の取得

可能

可能

必す(須)

9  既存データの変換による導出データの生成

可能

必す(須)

(最低一つ)

不可

10  システムの振る舞いの変更

必す(須)

(最低一つ)

必す(須)

(最低一つ)

不可

11  アプリケーション境界の外部への情報の提供

可能

必す(須)

必す(須)

12  アプリケーション境界の内部へ入力されるデータ又は
制御情報の受入れ能力

必す(須)

可能

可能

13  データの再構築又は再配列

可能

可能

可能

凡例:必す(須)

この処理ロジックを必ず実行しなければならない。

      必す(須)

(最低一つ)  これらに属する処理ロジックのうち最低一つは実行しなければならない。

      可能

この処理ロジックの定型手順を実行してもよいが,必す(須)ではない。

      不可

この処理ロジックの定型手順を実行してはならない。


72

X 0142

:2010

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

するかを決定するために,次の規則を適用する。要素処理を他と重複のない 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

−  維持管理される 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

−  要素処理の実行時に維持管理される各 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

例 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 の寄与の決定            

図 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

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 の複雑さ及び未調整ファンクションポイントへの寄与を計算する。

手順

複雑さの手順 
EI の場合: 
  EI の複雑さの定義及び規則を使用して,FTR 及び DET の数を計測する。

  次の複雑さ表に従って,EI の複雑さを評価する。 
 DET 
FTR

1∼4 5∼15 16 以上

0∼1

2

4

3 以上

手順

複雑さの手順 
EO 及び EQ の場合: 
  EO 又は EQ の複雑さの定義及び規則を使用して,FTR 及び DET の数を計測する。 
  次の複雑さ表に従って,EO 又は EQ の複雑さを評価する。複雑さを評価するために,重複しないよう
に,FTR 及び DET の累積値を使用することに留意する。 
 DET 
FTR

1∼5 6∼19 20 以上

0∼1

2∼3

4

4 以上

手順

寄与の手順 
EI 及び EQ の場合: 
  次の寄与表を使用して,EI 又は EQ の複雑さを未調整ファンクションポイントに変換する。

ファンクションの複雑さの評価

未調整ファンクションポイント

低 3

中 4

5

高 6


78

X 0142

:2010

手順

寄与の手順 
EO の場合: 
  次の寄与表を使用して,EO の複雑さを未調整ファンクションポイントに変換する。

ファンクションの複雑さの評価

未調整ファンクションポイント

低 4

中 5

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

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−事例一覧

事例

概要

社員及び扶養家族データの新規登録

複数の処理が一つの要素処理を構成することを示す事例

小切手の発行及び支払済みのマーク

要素処理の主目的の概念を示す事例

業務割当ての閲覧

報告書を作成するための選択条件の入力が要素処理でないことを示す

事例

業務割当ての印刷及び選択基準の保存

後で使用するために印刷条件を保存することが独立した要素処理であ

ることを明白に示す事例

社員の個人データ及び面談情報

複数の処理が一つの要素処理を構成することを示す二つ目の事例

社員の個人データ及び運転免許情報

複数の処理が一つの要素処理を構成することを示す三つ目の事例

8.5.2

事例 1:社員及び扶養家族データの新規登録

8.5.2.1

  利用者要件

利用者が新入社員を追加する場合,次のデータを入力しなければならない。

a)

社員の基本データ

b)

扶養家族の人数が一人以上の場合,扶養家族人数

社員情報を更新するときに,トランザクション  ファイルが作成される。このトランザクション  ファイ

ルは,定期的に福利厚生システムへ送られる。


80

X 0142

:2010

8.5.2.2

  扶養家族情報なしでの社員情報の追加

扶養家族がいる場合,関連する扶養家族情報なしで,社員情報を追加することが要素処理であるかを決

める。

次の表にその分析を示す。

要素処理の識別規則

規則の該当・非該当

その処理は,利用者にとって意味のある業務活動の最小

単位である。

当てはまらない。

社員に扶養家族がいる場合,社員を追加するための利用
者要件を示すためには扶養家族情報を含まれなければ
ならない。

その処理は,自己完結しており,計測するアプリケーシ
ョンが実行する業務を矛盾のない状態にするものであ
る。

当てはまらない。 
社員に扶養家族がいる場合,社員情報だけを登録しても
業務は矛盾のない状態ではない。

関連する扶養家族情報なしで,社員情報を追加することは,要素処理の要求事項に適合しない。

8.5.2.3

  扶養家族情報だけの追加

社員情報なしで,扶養家族情報だけを追加することが要素処理であるかを決める。

次の表にその分析を示す。

要素処理の識別規則

規則の該当・非該当

その処理は,利用者にとって意味のある業務活動の最小
単位である。

当てはまらない。 
社員データの維持管理処理と独立して,この作業を実行
することはできないので,この登録作業は明らかに利用

者にとって意味がない。

その処理は,自己完結しており,計測するアプリケーシ
ョンが実行する業務を矛盾のない状態にするものであ

る。

対象外。

関連する社員情報なしで,扶養家族情報を追加することは,要素処理の要求事項に適合しない。

8.5.2.4

  扶養家族情報を伴う社員情報の追加

扶養家族がいる社員の場合,

関連する扶養家族情報を伴う社員情報の追加が要素処理であるかを決める。

次の表にその分析を示す。

要素処理の識別規則

規則の該当・非該当

その処理は,利用者にとって意味のある業務活動の最小
単位である。

当てはまる。 
人事情報システムに社員を追加するために,社員情報及

び扶養家族情報の両方を使用する。

その処理は,自己完結しており,計測するアプリケーシ
ョンが実行する業務を矛盾のない状態にするものであ

る。

当てはまる。 
この処理は,それ自体で意味がある。必要な情報はすべ

て,人事情報システムに追加されるので,業務は矛盾の
ない状態のままである。更新ファイルを作成し,福利厚
生システムへ送ることができる。

扶養家族情報を伴う社員情報の追加は,要素処理の要求事項に合致する。

8.5.2.5

  トランザクション  ファイルの福利厚生システムへの送付

トランザクション  ファイルを福利厚生システムへ送る処理が,追加の要素処理であるかを決める。

次の表にその分析を示す。

要素処理の識別規則

規則の該当・非該当

その処理は,利用者にとって意味のある業務活動の最小
単位である。

当てはまる。 
内部で起動されたこの処理は,異なる利用者要件を反映
している。この要件は,独立した処理として構築される。


81

X 0142

:2010

その処理は,自己完結しており,計測するアプリケーシ
ョンが実行する業務を一貫した状態にするものである。

当てはまる。 
この処理は,自己完結している。福利厚生システムの更

新に使用されるトランザクション  ファイルに更新レコ
ードを作成した後,このシステムは矛盾のない状態にあ
る。

トランザクション  ファイルを福利厚生システムへ送る処理は,要素処理の要求事項に合致する。

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

支払済みの印を付けることは,要素処理に対する要求事項に合致しない。

8.5.3.3

  小切手の印刷及び支払済みの印付け

小切手の印刷及び支払済みの印付けが,要素処理であるかを決める。

次の表にその分析を示す。

要素処理の識別規則

規則の該当・非該当

その処理は,利用者にとって意味のある業務活動の最小

単位である。

当てはまる。

小切手を印刷するために,項目の印刷及び印付けの両方
が要求される。

その処理は,自己完結しており,計測するアプリケーシ

ョンが実行する業務を一貫した状態にするものである。

当てはまる。

この処理は,それ自体で意味がある。小切手の印刷及び
支払済みの印付けの両方が処理の達成に要求されてい
る。

小切手の印刷及び支払済みの印付けは,要素処理の要求事項に合致する。

利用者の要件は,小切手を印刷することである。支払済み区分に印を付けることは,小切手印刷処理の

一部になる。小切手の印刷及び印付けは共に,利用者にとって意味のある業務活動の最小単位である。処

理全体が自己完結しており,システムの業務を矛盾のない状態にする。

8.5.4

事例 3:業務割当ての閲覧

8.5.4.1

  利用者要件

ある期間の業務割当て一覧を閲覧する。利用者は,選択基準を入力することができる。一度報告書を作

成した後,選択基準を保存するという要求はない。

この事例に対するデータフロー図を,

図 21 に示す。


83

X 0142

:2010

図 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

要素処理の識別規則

規則の該当・非該当

その処理は,利用者にとって意味のある業務活動の最小

単位である。

当てはまらない。

利用者にとって意味があるのは,選択基準の入力及び一
覧表の閲覧である。

その処理は,自己完結しており,計測するアプリケーシ

ョンが実行する業務を一貫した状態にするものである。

当てはまらない。

この処理は,選択基準を入力によって独立して実行でき
ないので,自己完結しない。

選択基準を入力せずに業務割当て一覧を閲覧することは,要素処理の要求事項に合致しない。

8.5.4.4

  選択基準の入力及び業務割当て一覧の閲覧

選択基準の入力及び業務割当て一覧の閲覧が要素処理であるかを決める。

次の表にその分析を示す。

要素処理の識別規則

規則の該当・非該当

その処理は,利用者にとって意味のある業務活動の最小

単位である。

当てはまる。

利用者にとって意味があるのは,選択基準の入力及び一
覧表の閲覧である。

その処理は,自己完結しており,計測するアプリケーシ

ョンが実行する業務を一貫した状態にするものである。

当てはまる。

業務を矛盾のない状態に保つためには,選択基準の入力
及び業務割当て一覧の閲覧の両者が実行されなければ
ならないので,この処理は自己完結している。

選択基準の入力及び業務割当て一覧の閲覧は,要素処理の基準に合致する。

制御情報は,EO 又は EQ の入力側である。どんなデータを検索若しくは生成するか,及び/又はどのよ

うにしてデータを検索若しくは生成するかを指定する要件は,利用者にデータを提供する要素処理の一部

になるが,それ自身は要素処理ではない。

選択基準を入力することは,利用者にとって意味のある最小の業務単位ではない。この処理は,報告書

を作成することと独立して実行できないので,自己完結しない。選択基準の入力及び報告書の作成は,一

緒になって,利用者にとって意味のある最小の業務単位となり,自己完結し,業務を矛盾のない状態にす

る。

8.5.5

事例 4:業務割当ての印刷及び選択基準の保存

8.5.5.1

  利用者要件

ある期間の業務割当て一覧を印刷する。利用者は,選択基準を指定できる。後で使用するために,選択

基準を保存できるようにするという利用者要件がある。

この事例のデータフロー図を,

図 22 に示す。


85

X 0142

:2010

図 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

業務割当て一覧の印刷が,選択基準の保存の有無にかかわらず,要素処理であるかを決める。

次の表にその分析を示す。

要素処理の識別規則

規則の該当・非該当

その処理は,利用者にとって意味のある業務活動の最小
単位である。

当てはまる。 
業務割当て一覧の印刷は,最小の業務単位であり,利用

者にとって意味がある。

その処理は,自己完結しており,計測するアプリケーシ
ョンが実行する業務を一貫した状態にするものである。

当てはまる。 
業務割当て一覧の印刷は,業務割当て一覧の閲覧とは独

立して実行できる。

業務割当て一覧の印刷は,選択基準の保存とともに,要素処理の要求事項に合致する。

選択基準の入力は,利用者が明白に基準を保存できるので,確かに利用者にとって意味がある。報告書

の印刷又は選択基準の保存は,いずれも独立して実行できる。そして,どちらも業務を矛盾のない状態に

保つ。

選択基準の保存及び報告書の作成のどちらの処理も,自己完結しており,業務にとって意味があり,業

務を矛盾のない状態に保つ。要素処理の識別規則によって,二つの要素処理がある。

8.5.6

事例 5:社員の個人データの面談情報

8.5.6.1

  利用者要件

新入社員を追加するときに,社員の個人データ(すなわち,保険者番号,社員氏名,住所など)に加え

て,その社員への面談結果の詳細を追加しなければならない。面談情報は,面談者氏名,面談実施日及び

面談者所感を含む。

この事例のデータフロー図を,

図 23 に示す。


87

X 0142

:2010

図 23−データフロー図

8.5.6.2

  社員の個人データ登録

社員の個人データだけを登録することが要素処理であるかを決める。

次の表にその分析を示す。

    社員の新規登録 

  保険証番号

  登録

取消

面談結果の詳細の追加 

面談者氏名

面談実施日

面談者所感

  追加

取消

社員情報の作成

面談結果の詳細の追加

面談情報 ILF

    保険証番号      面談者氏名

    氏名            面談実施日

    住所              面談者所感

    ……            ********************

  氏名 
 
  住所


88

X 0142

:2010

要素処理の識別規則

規則の該当・非該当

その処理は,利用者にとって意味のある業務活動の最小

単位である。

当てはまらない。

利用者にとって意味があるのは,社員の個人データの登
録及び面談結果の詳細の追加の両方である。

その処理は,自己完結しており,計測するアプリケーシ

ョンが実行する業務を一貫した状態にするものである。

当てはまらない。

この処理は,面談結果の詳細の追加と独立して実行でき
ないので,自己完結していない。

面談結果の詳細の追加をしないで,社員の個人データを登録することは,要素処理の要求事項に合致し

ない。

8.5.6.3

  面談結果の詳細の追加

面談結果の詳細だけを追加することが要素処理であるかを決める。

次の表にその分析を示す。

要素処理の識別規則

規則の該当・非該当

その処理は,利用者にとって意味のある業務活動の最小
単位である。

当てはまらない。 
利用者にとって意味があるのは,社員の個人データの登

録及び面談結果の詳細の追加の両方である。

その処理は,自己完結しており,計測するアプリケーシ
ョンが実行する業務を一貫した状態にするものである。

当てはまらない。 
この処理は,社員の個人データの登録と独立して実行で

きないので,自己完結していない。

社員の個人データの登録をしないで,面談結果の詳細を追加することは,要素処理の要求事項に合致し

ない。

8.5.6.4

  社員の個人データの登録及び面談結果の詳細の追加

面談結果の詳細の追加とともに,社員の個人データを登録することが要素処理であるかを決める。

次の表にその分析を示す。

要素処理の識別規則

規則の該当・非該当

その処理は,利用者にとって意味のある業務活動の最小
単位である。

当てはまる。 
利用者にとって意味があるのは,社員の個人データの登
録及び面談結果の詳細の追加の両方である。

その処理は,自己完結しており,計測するアプリケーシ
ョンが実行する業務を一貫した状態にするものである。

当てはまる。 
測定対象のアプリケーションの業務を矛盾のない状態
に保つので,この処理は自己完結している。

8.5.6.5

  結論

二つの入力処理が,常に連続し,お互いに依存している[二つの処理が必す(須)である。

]場合,一つ

の要素処理及びファンクションが存在する。

新入社員の情報は,社員の個人データ及び面談結果の詳細の両者が入力されるまで,登録できない。社

員の個人データの登録だけでは,利用者にとって意味のある最小の業務単位にならないし,アプリケーシ

ョンの業務を矛盾のない状態に保たない。

要素処理の識別規則によって,ただ一つの要素処理がある。

8.5.7

事例 6:社員の個人データの運転免許情報

8.5.7.1

  利用者要件

新入社員を追加する場合,保険者番号,社員氏名,住所及び運転免許の有無を社員の個人データとして

登録する。社員が運転免許をもっている場合,二番目の処理として,社員の運転免許証番号,免許の種類

及び有効期限の登録を完了しなければならない。


89

X 0142

:2010

この事例のデータフロー図を,

図 24 に示す。

図 24−データフロー図

8.5.7.2

  運転免許情報なしでの社員の個人データの登録

社員の個人データだけを登録することが,運転免許をもっていない社員にとって,要素処理であるかを

社員の新規登録 

  保険証番号 
 
  氏名 
 
  住所

登録

取消

運転免許証情報の追加 

運転免許証 
 
運転免許証番号 
 
免許の種類 
 
有効期限

追加

取消

社員情報 ILF 
  保険証番号 
  氏名 
  住所 
  運転免許証 
  運転免許証番号 
  免許の種類 
  有効期限

運転免許の有無

運転

免許証

社員の新規登録

運転免許証情報の登録


90

X 0142

:2010

決める。

次の表にその分析を示す。

要素処理の識別規則

規則の該当・非該当

その処理は,利用者にとって意味のある業務活動の最小
単位である。

当てはまる。 
社員の個人データを追加することは,最小の処理単位で

あり,利用者にとって意味がある。

その処理は,自己完結しており,計測するアプリケーシ
ョンが実行する業務を一貫した状態にするものである。

当てはまる。 
その処理は,アプリケーションの業務を矛盾のない状態

に保つので,自己完結している。

運転免許情報なしで社員の個人データを追加することは,運転免許をもっていない社員に対する要素処

理の要求事項に合致する。

8.5.7.3

  運転免許情報の登録

社員の個人データなしで,運転免許情報を登録することが要素処理であるかを決める。

次の表にその分析を示す。

要素処理の識別規則

規則の該当・非該当

その処理は,利用者にとって意味のある業務活動の最小
単位である。

当てはまらない。 
社員の個人データの追加の処理なしで,運転免許情報を
登録することはできないので,利用者にとって,これは

意味がない。

その処理は,自己完結しており,計測するアプリケーシ
ョンが実行する業務を一貫した状態にするものである。

当てはまらない。 
その処理は,社員の個人データの登録とは独立して実行

できないので,自己完結していない。

社員の個人データの登録なしで,運転免許情報を登録することは,要素処理の要求事項に合致しない。

8.5.7.4

  社員の個人データ及び運転免許情報の追加

社員の個人データを運転免許情報とともに登録することが要素処理であるかを決める。

次の表にその分析を示す。

要素処理の識別規則

規則の該当・非該当

その処理は,利用者にとって意味のある業務活動の最小
単位である。

当てはまる。 
社員の個人データの追加及び運転免許情報の登録は,最

小の処理単位であり,利用者にとって意味がある。

その処理は,自己完結しており,計測するアプリケーシ
ョンが実行する業務を一貫した状態にするものである。

当てはまる。 
社員の個人データの追加及び運転免許情報の登録は,計

測対象のアプリケーションの業務を矛盾のない状態に
保つので,その処理は,自己完結している。

8.5.7.5

  結論

二つの入力処理が常に連続しお互いに依存しているが,二つ目の処理が任意である[しかし,適用され

る場合は,必す(須)である。

]場合,一つの要素処理とする。

社員の追加には,一つの要素処理がある。社員が運転免許をもっていない場合は,運転免許情報の登録

の手順は不要になる。社員が運転免許をもっている場合は,要素処理を完了しアプリケーションの業務を

矛盾のない状態に保つために,2 番目の画面入力を完了しなければならない。

8.6

EI

EO

及び EQ の計測事例

ここでは,人事情報システムを事例として,トランザクション  ファンクションを計測するための手順を

示す。

注記  この細分箇条の事例には,次の二つの目的がある。


91

X 0142

:2010

−  ファンクションポイントの計測規則を,与えられた利用者の要件に対してどう適用するかを示

す。

−  計測手順の使用に習熟する。

計測者は,次の点に注意しなければならない。

−  計測対象のプロジェクト又はアプリケーションの利用者要件を分析する。

−  利用者要件に基づいて計測する。

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

計測及び/又は識別の基礎情報

利用者要件

1  Xxxxxxxxxxxx

  2   Xxxxxxxxxxx 
  3   Xxxxxxxxxxx

 
 
 
 
 
 
 
 

識別表

                                                  EIEO 及び EQ の識別

識別規則 

規則の該当・非該当 

  Xxxxxxxxxxxxxxxxxxxxxxxx 
  Xxxxxxxxxxxxxxxxxxxxxxxx 
  Xxxxxxxxxxxxxxxxxxxxxxxx 

当てはまる。  又は  当てはまらない。  説  明  ―――― 
当てはまる。  又は  当てはまらない。  説  明  ―――― 
当てはまる。  又は  当てはまらない。  説  明  ――――

識別した EI,EO 及び EQ に対して,FTR 及び DET を計測する。

識別規則 

規則の該当・非該当 

  Xxxxxxxxxxxxxxxx 
  Xxxxxxxxxxxxxxxx 
  Xxxxxxxxxxxxxxxx 

  説  明  ――――― 
  説  明  ――――― 
  説  明  ―――――

図 25−構成要素及び情報の流れ

8.6.1.3.1

  計測及び/又は識別の基礎情報

各事例は,最初に計測及び/又は識別の基礎情報を提示する。

図 25 に示すように,計測及び/又は識別

は,次の情報に基づいて行う。

−  利用者要件

−  データモデル及びプロセスモデル

−  画面,画面情報又は報告書

注記  図のすべての情報がすべての例に含まれているわけではない。事例の中には,利用者要件だけ


93

X 0142

:2010

が計測の基本になるものがある。他の例では,データモデル又はプロセスモデル,画面,画面

情報及び報告書を含んでいるものもある。

8.6.1.3.2

  識別表

ファンクションを識別するための分析は,そのファンクションの識別規則を列挙した表を用いて使用し

て行う。その規則は,計測及び/又は識別の基礎情報を作り上げる構成要素に適用する。分析内容は,表

中の規則の該当・非該当の欄で説明する。

注記  すべての規則が当てはまる場合は,事例を EI,EO 又は EQ として計測する。

次に示す表は,識別した各ファンクションに対する複雑さの識別規則及びその説明を示している。

8.6.1.4

  識別した EIEO 及び EQ の概要

各事例に対してすべての規則を適用した後,計測したもの及び計測しなかったものを概要の項で一覧表

示する。

8.6.1.5

  すべての EIEO 及び EQ に対する複雑さ及び寄与の合計

説明の最後の項は,未調整ファンクションポイントに対する複雑さ及び寄与の計算を示す。

8.6.2

すべてのトランザクション  ファンクションに共通の規則

すべての事例を分析する手順は,箇条 の初めで記述した手順に従う。手順は,要素処理,主目的及び

トランザクション  ファンクション型を 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

表 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

 

 

図 26−業務割当て報告書入力画面

手順 1  要素処理の識別

そのトランザクション  ファンクションは,要素処理の
識別規則に適合するか。

当てはまる。

手順 2  主目的の決定及び分類

そのトランザクション  ファンクションは,EI の主目的

を満たすか。

当てはまる。

主目的は,ILF の維持管理である。

手順 3  EI 識別規則に対する妥当性確認

EI 識別規則

規則の該当・非該当

データ又は制御情報は,アプリケーション境界の外部か
ら入力される。

当てはまる。

人事情報システム 

        社員        業務        割当て        事業所        ヘルプ

業務割当て報告書 

並替えの順序

[3]業務 ID

[2]社員番号

[1]社員氏名

 1,2,3 で順序を指定

印刷装置のポート

[  ]LPT1

[  ]LPT2

[  ]LPT3

実行

取消

前回の指定値

実行

前回の指定値

取消

印刷の実行

プルダウンメニューに戻る

前回の指定値を表示

□  マイクロフィッシュへのコピー

□  印刷


96

X 0142

:2010

アプリケーション境界の外部から入力されたデータが
システムの振る舞いを変更する制御情報でない場合,少

なくとも一つの 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

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

識別した処理に対して,次の三つのうちいずれか一つを
適用する。

−  処理ロジックが,このアプリケーションの他の 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

注記  前の事例では,オンライン処理を見たが,この事例では,業務情報をバッチ処理で追加するこ

とに焦点を当てる。

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

手順 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

結論: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

 

図 29−データフロー図

手順 1  要素処理の識別

そのトランザクション  ファンクションは,要素処理の
識別規則に適合するか。

当てはまる。

手順 2  主目的の決定及び分類

そのトランザクション  ファンクションは,EI の主目的
を満たすか。

当てはまる。 
主目的は,ILF の維持管理である。

手順 3  EI 識別規則に対する妥当性確認

EI 識別規則

規則の該当・非該当

データ又は制御情報は,アプリケーション境界の外部か

ら入力される。

当てはまる。

未確定業務情報を修正するデータは,アプリケーション
境界の外部から入る。

アプリケーション境界の外部から入力されたデータが,

システムの振る舞いを変更する制御情報でない場合,少
なくとも一つの ILF を維持管理する。

当てはまる。

業務情報の未確定業務情報 ILF が更新される。

利用者

業務及び業務説明

未確定業務情報

バッチでの業務

の追加

バッチでの業 務

の変更

未確定業務情報の

維持管理

業務情報報告書

の印刷

業務情報の報

告書

業務及び業務説明の報告書(マイクロフィッシュ)

業務情報及び説明の報告書(紙書類)業務番号,業務名称,給与等級,説明,業務の合計数

修正した未確定ジョブ情報

未確定ジョブ情報の追加,変更,削除

業 務 ト ラ ン ザ ク

ションの変更

業務トランザク

ションの追加

ID,業務番号,業務名称,

給与等級

未確定ジョブ情報

業務情報の追加

業務番号,業務名称,給与等級,説明

業務名称,給与等級,説明

業務番号

業務番号,業務名称,給与等級,行番号,説明


103

X 0142

:2010

識別した処理に対して,次の三つのうちいずれか一つを
適用する。

−  処理ロジックが,このアプリケーションの他の 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

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

図 31−データフロー図

  業務割当て 

  利用者 

  利用者

業務割当て 

業務割当て 

の追加 

業務割当て

の変更 

業 務 割 当 て

の変更 

業務割当て報告書

の印刷 

保険証番号,業務番号,発効日,査定等級,給与

氏名

氏名

業務名称

業務名称

保険証番号

業務番号

発効日

査定等級

給与

保険証番号

業務番号(新旧)

発効日

査定等級

給与

発効日

査定等級

給与

保険証番号

業務番号

業務割当て情報

保険証番号

業務番号

発効日

査定等級

給与

氏名

業務名称

保険証番号,氏名

業務番号,業務名称

保険証番号

氏名

業務番号

業務名称

発効日

査定等級

給与

業務割当て報告書

保険証番号

氏名

業務番号

業務名称

従事社員合計

    業務 

    社員 

    業務 

業務割当ての

照会 

    社員 


106

X 0142

:2010

手順 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

処理中のエラー発生の通知,処理の完了確認又は処理続
行の確認のために,アプリケーション境界の外部にシス

テム応答メッセージを出力する機能を 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

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

8.7.8

事例 7:他システムからのデータ参照

8.7.8.1

  利用者要件

人事情報システムに対する次の利用者要件がある。

−  すべての非正社員には,円建てで支払わなければならない。

−  利用者が社員情報を追加及び変更する場合,人事情報システムは,為替システムを利用し,為替レー

トを取り出さなければならない。為替レートを取り出した後,人事情報システムは,社員の現地標準

時給を次の式を使用して円建て時給に変換する。

 
 

標準時給 
為替レート

=

円建て時給

この事例のファイルの関係を,

図 33 に示す。

凡例:

必す(須)の 1 対 多の関係

任意の 1 対多の 関係

属 性実体型

実 体型

実 体副型

図 33−ファイルの関係図

8.7.8.2

  変換の情報

変換のための情報を,次に示す。

為替ファイル

−  為替基準に対する為替レート

−  国名

手順 1  要素処理の識別

そのトランザクション  ファンクションは,要素処理の

要求事項に当てはまるか。

当てはまらない。

データの参照は,社員の追加と連携したときにだけ,意
味がある。

為替システム

人事情報システム

為替レート

社員

    正社員

  非正社員

扶養家族


110

X 0142

:2010

結論:変換情報の検索について,EI は識別できない。変換情報が EIF として計測されるかもしれない理由

を知るためには,箇条 の 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

識別した処理に対して,次の三つのうちいずれか一つを
適用する。

−  処理ロジックが,このアプリケーションの他の 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

一覧は,社員番号及び社員氏名を表示する必要がある。業務情報一覧は,業務番号及び業務説明を表示す

る必要がある。業務に割り当てられた社員の社員番号は,その記録を保存した後で表示する。

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

アプリケーション境界の外部から入力されたデータが,シ
ステムの振る舞いを変更する制御情報でない場合,少なく

とも一つの 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

8.7.11

  EIFTR 及び 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

社員情報の移行 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 のファンクション型に対する寄与の合計を計算する。

ファンクション型

ファンクションの複雑さ

複雑さの合計

ファンクション型の合計

 5     低

×  3  =  15

 2     中

×  4  =  8

EI

 1     高

×  6  =  6

 

 29

この合計は,すべてのファンクションを一覧にする表に記録される。すべてのファンクション型に対す

る最終合計が,未調整ファンクションポイントとなる。

8.8

EO

の計測事例

ここでは,人事情報システムを例にして,EO 計測手順を示す。

8.8.1

EO

計測事例の概要

EO の計測事例を,表 13 に示す。 

表 13−事例一覧

事例

概要

紙書類報告書の出力

紙書類報告書の計測を示す事例

オンライン報告

オンライン報告の計測を示す事例

他のシステムへの送信トランザクション

あるアプリケーションで作成され,他のアプリケーションに送ら
れるトランザクションを示す事例

エラーメッセージ又は確認メッセージ

エラーメッセージ又は確認メッセージを EI と計測しない理由を示

す事例

通知メッセージ

通知メッセージを計測する方法を示す事例

アプリケーション境界の外部から,データなし
に起動される EO

EO が,アプリケーション境界の外部から,データなしで起動され
る概念を示す事例

EO の主機能 EO がファイルを更新できることを示す事例 
EO トランザクション  ファイル

計算処理があることが,要素処理を EQ ではなく EO であると決定

することを示す事例

8.8.2

すべてのトランザクション  ファンクション型に共通の規則

すべての事例を分析する手順は,箇条 の初めで記述した手順に従う。手順は,要素処理の識別,主目

的及びトランザクション  ファンクション型の EI,

EO 及び EQ への分類という規則を適用することによる。

次の表に適用されなければならない規則を一覧表示する。

要求処理の識別規則

規則の該当・非該当

その処理は,利用者にとって意味のある業務活動の最小単位である。

その処理は,自己完結しており,計測するアプリケーションが実行する業務を

矛盾のない状態にするものである。


116

X 0142

:2010

トランザクション  ファンクション型が要素処理となるためには,

二つの識別規則のいずれの質問に対し

ても,

“当てはまる”でなければならない。

表 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

手順 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

次のすべてを満たすデータ項目は,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

手順 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

次のすべてを満たすデータ項目は,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

図 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

手順 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

動作□      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

手順 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

次のすべてを満たすデータ項目は,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

手順 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

ある DET がアプリケーション境界の外部から入力され,
外部にも出力される場合,その要素処理に対して 1DET

とだけ計測する。

対象外。

処理中のエラー発生の通知,処理の完了確認又は処理続

行の確認のために,アプリケーション境界の外部にシス
テム応答メッセージを出力する機能は,1DET と計測す
る。

対象外。

同一の論理的処理を起動する手段が複数あっても,処理
を指定する機能を 1DET と計測する。

対象外。

要素処理の実行中にシステムによって取得又は導出さ
れて,ILF に格納されるデータ項目は,そのデータ項目
がアプリケーション境界をまたがらない場合,DET とし

ては計測しない。

対象外。

文字列は,DET としては計測しない。

ページ変数又はシステムが生成するスタンプは計測し
ない。

結論:DET の数は,3 となる。

複雑さ

1FTR 及び 3DET

複雑さは,低である。

手順 5  寄与の決定

寄与が 1 で,複雑さが低 4FP になる。

8.8.9

事例 7EO の主機能

8.8.9.1

  利用者要件

小切手を印刷し,その結果として,勘定書の支払済みフラグを立てる。小切手に印刷するすべてのデー

タは,既に小切手ファイルに保存されている。

この事例についてのデータフロー図を,

図 42 に示す。

図 42−データフロー図

手順 1  要素処理の識別

このトランザクション  ファンクションは,要素処理の
要求事項に当てはまるか。

当てはまる。

小切手 ILF

                小切手番号

                支払額

                受取人

                支払済み区分

AB12345

      小切手

支払地  東京都千代田区 XXX 
千代田銀行永田町支店

金額         

¥1,000,000*

上記の金額をこの小切手と引換えに 
持参人へお支払ください。 
    受取人    山田  太郎 
拒絶証書不要 
振出日  平成  年  月  日 
振出地  東京都

株式会社  東京商事

振出人    代表取締役  岡本  太郎

小切手の印刷


128

X 0142

:2010

手順 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

ある DET がアプリケーション境界の外部から入力され,
外部にも出力される場合,その要素処理に対して 1DET

とだけ計測する。

対象外。

処理中のエラー発生の通知,処理の完了確認又は処理続

行の確認のために,アプリケーション境界の外部にシス
テム応答メッセージを出力する機能は,1DET と計測す
る。

対象外。

同一の論理的処理を起動する手段が複数あっても,処理
を指定する機能を 1DET と計測する。

対象外。

要素処理の実行中にシステムによって取得又は導出さ
れて,ILF に格納されるデータ項目は,そのデータ項目
がアプリケーション境界を越えない場合,DET としては

計測しない。

対象外。

文字列は,DET としては計測しない。

ページ変数又はシステムが生成するスタンプは計測し
ない。

結論:DET の数は,3 となる。

複雑さ

1FTR 及び 3DET

複雑さは,低である。

手順 5  寄与の決定

寄与が 1 で,複雑さが低 4FP になる。

8.8.10

  事例 8EO トランザクション  ファイル

8.8.10.1

  利用者要件

月末に,トランザクション  ファイルを作成し,アプリケーション B へ送付する。小切手番号及び支払

額は,その月に処理した小切手の枚数及び印刷した小切手の合計金額を記録したファイルに含まれる。

8.8.10.2

  データモデル

この事例のデータフロー図を,

図 43 に示す。

図 43−データモデル図

手順 1  要素処理の識別

このトランザクション  ファンクションは,要素処理の
要求事項に当てはまるか。

当てはまる。

月次小切手ファイルの生

        小切手 ILF

                  小切手番号

                  支払い額

                  −

アプリケーション A

月次小切手ファイル

小切手番号

支払額

印刷済み小切手の枚数

全小切手の合計金額

アプリケーション B


130

X 0142

:2010

手順 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

ある DET がアプリケーション境界の外部から入力され,
外部にも出力される場合,その要素処理に対して 1DET

とだけ計測する。

対象外。

処理中のエラー発生の通知,処理の完了確認又は処理続

行の確認のために,アプリケーション境界の外部にシス
テム応答メッセージを出力する機能は,1DET と計測す
る。

対象外。

同一の論理的処理を起動する手段が複数あっても,処理
を指定する機能を 1DET と計測する。

対象外。

要素処理の実行中にシステムによって取得又は導出さ
れて,ILF に格納されるデータ項目は,そのデータ項目
がアプリケーション境界をまたがらない場合,DET とし

ては計測しない。

文字列は,DET としては計測しない。

ページ変数又はシステムが生成するスタンプは計測し
ない。

結論:DET の数は,4 となる。

複雑さ

1FTR 及び 4DET

複雑さは,低である。

手順 5  寄与の決定

寄与が 1 で,複雑さが低 4FP になる。

8.8.11

  計測した EOFTR 及び 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

最終手順は,次に示すとおりである。

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 のファンクション型に対する寄与の合計を計算する。

ファンクション型

ファンクションの複雑さ

複雑さの合計

ファンクション型の合計

 4     低

×  4  =  16

 2     中

×  5  =  10

EO

 0     高

×  7  =  0

 

 26

この合計は,すべてのファンクションを一覧にする表に記録される。すべてのファンクション型に対す

る最終合計が,未調整ファンクションポイントとなる。

8.9

EQ

の計測事例

ここでは,EQ を計測するための手順を示すために,人事情報システムを使用する。

8.9.1

すべてのトランザクション  ファンクション型に共通の規則

すべての事例を分析する手順は,箇条 の初めで記述した手順に従う。手順は,要素処理の識別,主目

的及びトランザクション  ファンクション型の EI,EO 及び EQ への分類という規則を適用することに関係

している。次の表に適用されなければならない規則を一覧表示する。

要求処理の識別規則

規則の該当・非該当

その処理は,利用者にとって意味のある業務活動の最小単位である。

その処理は,自己完結しており,計測するアプリケーションが実行する業務

を矛盾のない状態にするものである。


133

X 0142

:2010

トランザクション  ファンクション型が要素処理となるためには,

二つの識別規則のいずれの質問に対し

ても,

“当てはまる”でなければならない。

表 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

人 事 情 報 シ ス テ ム

社 員

業 務

割 当 て

勤 務 地

報 告 者

セ キ ュ リ テ ィ

ヘ ル プ

新 規

表 示

編 集

印 刷

図 44−人事情報システムのメインメニュー

社員ドロップダウンメニューで新規を選択すると,

図 45 の社員情報設定画面を表示する。

図 45−社員情報設定画面

人事情報システム

社員情報設定

OK

取消

OK

取消

アプリケーションメニュー画面に戻る

決定

  姓

  名

保険証番号

扶養家族数

事業所

通貨

給与種別

()時給 
()月給

        −      −

社員    業務    割当て    勤務地    報告者  セキュリティ    ヘルプ


135

X 0142

:2010

手順 1  要素処理の識別

このトランザクション  ファンクションは,

要素処理の要

求事項に当てはまるか。

当てはまらない。 
メニューオプションの選択は,利用者にとって意味のあ
るデータを含んでいない。

結論:要素処理はない。

8.9.4

事例 2:検索データの一覧

8.9.4.1

  利用者要件

利用者の要件は,次のとおりである。

−  社員一覧の表示。

この事例では,人事情報システムで社員一覧を表示することに焦点をしぼる。

この事例のデータフロー図を,

図 46 に示す。

社 員及 び 扶養 者

情報

利用者

社員照会

保険証番号

社員情報

保険証番号,氏名,社員種別

労働組合,扶養者保険証番号,扶養名

扶養者生年月日,勤務地

保険証番号,氏名,社員種別

給与種別

社員一覧

の照会

表示の要求

アクセス許可

アクセス許可

社員の

セキュリティ

社員情報

社員一覧

図 46−データフロー図

8.9.4.2

  計測手順

人事情報システムのドロップダウンメニューを,

図 47 に示す。表示項目及び入力キーは,この事例の入

力側に作っている。


136

X 0142

:2010

図 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

手順 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

システムによって取得又は導出される 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

図 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

要素処理の処理ロジックは,導出データを生成しない。

当てはまる。

要素処理の処理ロジックは,システムの振る舞いを変更
しない。

当てはまる。

結論:一つの 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

8.9.6.2

  計測手順

社員データ画面を,

図 51 に示す。

図 51−社員データ入力画面

利用者がカーソルを時給項目上に置いて F1 キーを押すと,

図 52 のヘルプテキストを含むテキストボッ

クスを表示する。

社員リスト

人事情報システム

社員データ

山田

太郎

345-67-8901

非正社員データ

時給

労働組合

扶養家族

社員    業務    割当て    勤務地    報告者    セキュリティ    ヘルプ


142

X 0142

:2010

図 52−ヘルプ表示

手順 1  要素処理の識別

このトランザクション  ファンクションは,

要素処理の要

求事項に当てはまるか。

当てはまる。

手順 2  主目的の決定及び分類

トランザクション  ファンクションは EQ の主目的に当
てはまるか。

当てはまる。 
主目的は,情報の表示である。検索データだけが含まれ
ている。

手順 3  EQ 識別規則適合の検証

EQ 識別規則

規則の該当・非該当

アプリケーション境界の外部へデータ又は制御情報が出
力される。

当てはまる。 
ヘルプ情報は,アプリケーション境界をまたぐ。

識別した処理に対して,

次のいずれか一つが当てはまる。

−  処理ロジックが,このアプリケーションの他の EO

又は EQ のものと異なっている。

−  識別したデータ項目の組が,このアプリケーション

の他の EO 又は EQ のものと異なっている。

−  参照する ILF 又は EIF が,このアプリケーションの

他の EO 又は EQ のものと異なっている。

 
当てはまる。 
この機能を実行する他の EQ がない。 
対象外。 
 
対象外。

要素処理の処理ロジックは,データ又は制御情報を ILF
又は EIF から取得する。

当てはまる。

要素処理の処理ロジックは,ILF を維持管理しない。

当てはまる。

要素処理の処理ロジックは,

“数式又は演算の実行”を含

まない。

当てはまる。

要素処理の処理ロジックは,導出データを生成しない。

当てはまる。

人事情報システム

時給

労働組合

扶養家族

社員    業務    割当て    勤務地    報告者    セキュリティ    ヘルプ

時給

勤務時間 1 時間に対して支払われる給与額

この情報は,非正社員に対して必す(須)項目である。

有効値:時給を表す任意の値

デフォルト値:なし

デフォルト値:デフォルト値はなし


143

X 0142

:2010

要素処理の処理ロジックは,システムの振る舞いを変更
しない。

当てはまる。

結論:一つ 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

社員データ画面を,

図 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

要素処理の処理ロジックは,ILF を維持管理しない。

対象外。

要素処理の処理ロジックは,

“数式又は演算の実行”を含

まない。

対象外。

要素処理の処理ロジックは,導出データを生成しない。

対象外。

要素処理の処理ロジックは,システムの振る舞いを変更
しない。

対象外。

結論:これは要素処理であるが,このシステムの中では重複した機能であるので,計測しない。項目レベ

ルヘルプは既に計測されている。

8.9.8

事例 6:明示的には記述されていない照会

8.9.8.1

  利用者要件

業務割当てに関する情報閲覧の利用者要件がある。それは明確には記述されていないが,業務情報を変

更する前に業務情報を検索しなければならないことは暗黙の了解事項である。

利用者にとって,

そもそも,

既存の業務割当て情報を閲覧せずにこれを変更するのは効率的でない。これを,明示的に記述されていな

い照会という。

8.9.8.2

  計測手順

社員氏名及び業務番号だけの業務割当て編集画面を,

図 54 に示す。

図 54−業務割当て編集画面

人事情報システム

社員    業務    割当て    勤務地    報告者    セキュリティ    ヘルプ

社員割当て

業務割当て編集

山田

太郎

労働組合

OK

日付

給与

確定給与率

5 月号−表紙の印刷

取消

リストア

削除

RD15379305

OK

取消

リストア

削除

変更決定

変更取消し

前回の指定値を表示

確認メッセージの後,業務割当てを削除


146

X 0142

:2010

社員氏名及び業務番号を入力すると,

図 55 の業務情報を表示する。

図 55−業務割当て表示画面

手順 1  要素処理の識別

このトランザクション  ファンクションは,

要素処理の要

求事項に当てはまるか。

当てはまる。

手順 2  主目的の決定及び分類

トランザクション  ファンクションは,EQ の主目的に当

てはまるか。

当てはまる。

主目的は,情報の提供である。検索データだけが含まれ
ている。

手順 3  EQ 識別規則適合の検証

EQ 識別規則

規則の該当・非該当

アプリケーション境界の外部へデータ又は制御情報が出

力される。

当てはまる。

業務情報を表示する。

人事情報システム

社員    業務    割当て    勤務地    報告者    セキュリティ    ヘルプ

社員割当て

業務割当て編集

山田

太郎

労働組合

OK

日付

給与

確定給与率

5 月号−表紙の印刷

取消

リストア

削除

RD15379305

OK

取消

リストア

削除

変更決定

変更取消し

前回の指定値を表示

確認メッセージの後,業務割当てを削除

25/072006


147

X 0142

:2010

識別した処理に対して,

次のいずれか一つが当てはまる。

−  処理ロジックが,このアプリケーションの他の 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

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

システムによって取得又は導出される 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

識別された処理に対して,

次のいずれか一つが該当する。

−  処理ロジックがこのアプリケーションの他の 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

結論:DET の数は,2 となる。

複雑さ

1FTR 及び 2DET

複雑さは,低である。

手順 5  寄与の決定

寄与が 1 で,複雑さが低 3FP になる。

8.9.11

  計測した EQFTR 及び 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

ドロップダウンリストボックス 1  2

項目レベルヘルプ 1

6

週次の会員情報 1

3

日ごとの小切手ファイル 1

2  低

8.9.12.2

  EQ の寄与への変換

次の表で,EO の複雑さを寄与に変換する。

ファンクションの複雑さの評価

未調整ファンクションポイント

低 3

中 4

高 6

複雑さは,次の表に示す。

8.9.12.3

  EQ の寄与の計算

次の表で,EQ のファンクション型に対する寄与の合計を計算する。

機能要素

複雑さ

寄与

寄与の合計

 5     低

×  3  =   15

          中

×  4  =

EQ

          高

×  6  =

15

この合計は,すべてのファンクションを一覧にする表に記録される。すべてのファンクション型に対す

る最終合計が,未調整ファンクションポイントとなる。 


附属書 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 の規定

(III)国際規格の規定

(IV)JIS と国際規格との技術的差異の箇条
ごとの評価及びその内容

箇 条 番 号
及び題名

内容

(II) 
国際規格

番号

箇条番号

内容

箇 条 ご と
の評価

技術的差異の内容

(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 には不

要。

153

X 014

2


2

010


(I)JIS の規定

(III)国際規格の規定

(IV)JIS と国際規格との技術的差異の箇条

ごとの評価及びその内容

箇 条 番 号
及び題名

内容

(II)

国際規格
番号

箇条番号

内容

箇 条 ご と
の評価

技術的差異の内容

(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……………  国際規格を修正している。

154

X 014

2


2

010