設計の手順にもよりますが・・・
通常、ユーザインタフェース設計終了後（あるいは実施しながら）、論理エンティティ関連図（論理データモデル）の作成を行います。
前回の説明では、ユーザインタフェースはできているが、論理エンティティ関連図（論理データモデル）はまだ作成されていない段階での見積もり方法を紹介しましたが、今回は、ユーザインタフェース設計も完了しており、論理エンティティ関連図（論理データモデル）も完成している段階での見積もりについて、紹介します。
ちなみに、論理エンティティ関連図（論理データモデル）の設計が完了しているということは、エンティティとリレーションと属性が全て洗い出されて、定義されているということを想定しています。
前回のユーザインタフェース設計完了段階での見積もりと異なる点は、論理エンティティ関連図（論理データモデル）が作成されているため、データ（エンティティ）のデータ項目（属性）が明確になっているという点です。
データ（エンティティ）のデータ項目（属性）が明確になれば、データファンクションについても、データ項目数やレコード種別数もある程度わかりますので、トランザクションファンクションと同様、ＩＦＰＵＧ（CPM）にのっとってＦＰを見積もることが可能となります。
手順としては以下のようになります。
【トランザクションファンクション】
①トランザクションファンクションの識別
②ファンクションタイプ（EI、EO、EQ）の判定
③DET数の算出
④FTR数の算出
⑤複雑度の判定
⑥未調整ＦＰの算出
データファンクションについてのＦＰ見積り手順としては以下のようになります。
【データファンクション】
①データファンクションの識別
②ファンクションタイプ（ＩＬＦ、ＥＩＦ）の判定
③DET数の算出
④RET数の算出
⑤複雑度の判定
⑥未調整ＦＰの算出
【トランザクションファンクションの見積り】
①トランザクションファンクションの識別
まずは、トランザクションファンクションですが、ユーザインタフェース（画面や帳票）がアプリケーションの最終成果物（つまりユーザに提供するサービス）と考えたならば、画面や帳票そのものがトランザクションファンクションと考えることができます。
②ファンクションタイプの判定
トランザクションファンクションのタイプとしては、ＥＩ（外部入力）、ＥＯ（外部出力）、ＥＱ（外部照会）があります。
画面から入力して、データベースを更新する処理が存在する場合は、全てＥＩ（外部入力）に分類します。
データを外部に出力する処理の場合は、編集処理があるかどうかでＥＯ（外部出力）とＥＱ（外部照会）に分類します。
編集処理（金額計算等）があれば、ＥＯ（外部出力）なければＥＱ（外部照会）に分類します。
帳票でも業務で使用する帳票はほとんどがＥＯになると思います。マスタデータの確認用の一覧出力の帳票はＥＱに分類します。
また、帳票だけではなく、照会画面等もＥＯとＥＱに分類する必要があります。
（この段階では、コード選択等のＥＱが識別されないこともあると思いますが、あまり気にする必要はないでしょう・・・）
③DET数の識別
DET数（データ項目数）については、ユーザインタフェース（レイアウト）が明確になっていれば、当該ユーザインタフェース（レイアウト）でどのようなデータ項目を対象としているかを判断することは容易です。
（レイアウト上に何個のデータ項目が定義されているかをカウントすればいいだけです。）
④FTR数の識別
FTR数（関連ファイル数）ですが、これも論理エンティティレベルで各ユーザインタフェースで関連するエンティティを特定することによりカウントすることが可能となります。
（ちょっと、想像の部分が入りますが、「受注入力画面」であれば、当然「受注」、「得意先」、「商品」が関連ファイル数にカウントされるでしょう、さらに、受注担当者を管理する必要があるという要件があれば、「担当者」や「部署」といったエンティティと関連を持つかもしれません。）
⑤複雑度の判定
DET数とRET数をカウントできれば、後は複雑度の判定テーブルに当てはめユーザインタフェースごとに複雑度を判定することができます。
【複雑度判定テーブル】
⑥未調整ＦＰの算出
ファンクションタイプ別の複雑度はわかれば、以下のテーブルに当てはめ、未調整のＦＰを求めます。
その値を全て集計することにより、全トランザクションファンクションの未調整ＦＰ数を求めることができます。
【未調整ＦＰテーブル】
【データファンクションの見積り】
①データファンクションの識別
論理エンティティ関連図（論理データモデル）のエンティティをそのまま、データファンクションとして識別します。（ただし、ＩＦＰＵＧのＣＰＭでは、データファンクションの条件として「論理的でユーザ視点の（ユーザにとって意味のある）データであるデータ」とう条件がありますので、注意が必要です。
・論理的であることというのは、物理的ではないと捉えればいいでしょう。
例えば、伝票番号の採番用の採番テーブルがあったとしても、論理的には最大の伝票番号にプラス１をすればいいだけであれば、データファンクションとしては識別しません。また、処理のための中間ファイルなども、データファンクションとしては識別しません。
・ユーザ視点であるといことですが、これはRET数のところにも絡んでくるのですが、１つのエンティティ（テーブル）だけでは、ユーザにとって意味のあるデータとなならいという場合は、概念的に一塊にしてデータファンクションを識別するということです。
例えば、「受注」エンティティと「受注明細」エンティティが存在したとしても、ユーザにとって意味のあるのは「受注」データであり、受注データのみをデータファンクションとして識別します。
②ファンクションタイプの判定
データファンクションのタイプとしては、ILF（内部論理ファイル）、EIF（外部インタフェースファイル）があります。
この段階では、論理エンティティ関連図（論理データモデル）のエンティティは全てILF（内部論理ファイル）とすればいいでしょう。
外部インタフェース一覧のデータをＥＩＦ（外部インタフェースファイル）として識別すればいいでしょう。
③RET数の算出
RET数（レコード種類数）というのは、当該テーブル（エンティティ）に何種類のレコードが保管されうるのかという数です。
ですので通常は、データファンクションのRET数（レコード種類数）は１となります。
しかし、サブタイプが存在する場合、例えば以下のような場合は、取引先テーブルには得意先レコードと仕入先レコードと納品先のレコードが存在する可能性がありますので、RET数は３ということになります。
（ちなみに、サブタイプはデータファンクションとしては識別しません。）
【サブタイプの例】
論理エンティティ関連図（論理データモデル）が作成され、適切にサブタイプが定義されていれば、サブタイプの数を集計することにより、RET数を算出することができます。
④DET数の算出
データファンクションのDET数とは、エンティティ（テーブル）の属性数（カラム数）に該当します。
この時点で論理エンティティ関連図（論理データモデル）が作成されているということであれば、当然、各エンティティの属性項目も明確になっているはずですから、各エンティティの属性項目をカウントしていけば、データファンクションのDET数を算出することができます。
ここで注意してもらいたいのは、RETと判定したサブタイプの属性です。サブタイプエンティティの属性についてはスーパータイプエンティティのDETとしてカウントする必要があります。（<==サブタイプはデータファンクションとしては識別しないため）
【サブタイプの属性の取扱】
⑤複雑度の判定
RET数とDET数をカウントできれば、後は複雑度の判定テーブルに当てはめデータファンクションごとに複雑度を判定することができます。
【データファンクションの複雑度判定】
⑥未調整ＦＰの算出
ファンクションタイプ別の複雑度はわかれば、以下のテーブルに当てはめ、未調整のＦＰを求めます。
その値を全て集計することにより、全データファンクションの未調整ＦＰ数を求めることができます。
【データファンクションの未調整ＦＰ】
質問なのですが、トップダウンから業務分析
を行った際に、ある程度、投資効果を試算
すると思います。
投資効果に見合うシステム規模を見極めた上で
各機能にリソースを割り振る方が、
「金喰い虫」批判をあとで受ける可能性が少ない
ように思います。（ユーザーの論理ですが）
リソースのめりはりをきちんとつけられるＳＥ
が少ない事が問題だと思っています。
きちんと説明能力があるＳＥが行った見積ならば
良いのですが、そうではない場合、ＦＰで見積もる
と「高い」と言われるのではないでしょうか？
トップダウンからの業務分析を行った段階での投資効果の見積については、ＦＰとかで見積もることはあまりないように思います。
（というか、この段階ではＦＰで見積もるための設計情報がまだ存在しないはずです。）
この段階では、基本的には期待効果と概算費用を見積もって評価することが多いと思います。
期待効果についても、金額で評価できるものであればいいのですが、必ずしも金額換算できないものもあります。
金額換算できないものについても、ＫＰＩを導入して数値で把握することが必要だと思います。
また、この段階での費用ですが、見積を実施するとすれば類推法（過去の類似プロジェクト／類似システムから類推する方法）で行っていることが多いのではないかと思います。
いくつかの指標を入力することにより、過去の実績データから最も類似するシステムの実績を特定し、見積を実施するようなツールも市販されています。（この場合、実績データとしてどれだけの質量が用意されるかがポイントとなると思います・・・）
ＦＰで見積もるそもそもの目的として、客観的な手法で見積を実施できる（＝>説明可能な見積である）ということがあると思います。
ＦＰで見積もると「高い」といわれるという問題ですが・・・
金額に換算するためには、規模×生産性×単価という計算をする必要があります。
しかし、ＦＰで見積もるのはあくまで「規模」です。
金額換算するためには「生産性」と「単価」という要素が必要になってきます。
個人的には、規模はあくまで規模ですので、変わりようがありません。
金額が高いといわれるのは、「生産性」が低い（工数が大きい）か、「単価」が高いため、結果的に金額で表したら「高く」なっているということではないかと思います。
但し、ＩＴ、システム投資というものは
「魔物」
のようなもので、ちょっとした匙加減で
金額のぶれが生じてしまいます。
投資する側からすると、この「ぶれ」は
非常に怖いです。
「ぶれ」を防止する為にこそ、ＦＰでの見積
があるのでしょうが、実際にＦＰで算出した
ベンダーの見積は、リスク回避の為なのか
金額が高めです。
金額が高くても、能力が高く品質が高いもの
を予算内で納めてもらえれば良いですが、
そういったベンダーは、様々な手法を
ちらつかせてプロジェクトを進めていくもの
の、最終的な金額はさらに高くなりがちです。
大体、予算オーバーしてしまいます。
これは実体験によるトラウマなのかも
しれませんが・・・
投資額に見合った「規模」をユーザー側に
提案するツールとしてＦＰが使われるように
なれば素晴らしいと思います。
もう一度、トップダウンから見直しをかける
際に・・・
（本当にＦＰに精通している技術者はもう、やってる
のかな？）
実際、そのようなプロジェクトを何個も見たり、体験したりしてましたので・・・
「ぶれ」を防止するためにＦＰを使っているかというと、どうもそうではないように思います。
一番多い理由としては、見積もりの妥当性を説明するために利用するというものではないでしょうか？
もちろん、見積もりの精度が高いほうが最終的な「ぶれ」は少なくなると思いますが、私個人は見積もりの目的は、「規模を予想する」ということだけではないと思っています。
見積もりはあくまで、将来（未来）に対する予測ですので、正しいか間違っているか最後までわかりません。
見積もりの目的としては、もう一つあると思っています。
それは、「目標値」としての見積もり結果を利用していくということです。
将来に対する予測ですので、正確であるかどうかの保障はありません。しかし、そのような規模に収めるために努力することによって、結果的に見積もった内容がやっぱり正しかった、というようにはできるのではないかと思っています。
見積⇒計画⇒管理⇒成功という図式は、目標としての見積もりということも考えてのことです。
ですので、見積もりだけで、「ぶれ」を少なくするということではなく、きちんと計画をして、計画どおりになるように実行および管理を行い、問題点に適時対応していくことにより、「ぶれ」を予防していくということになるのではないでしょうか？
そういう意味では、「見積」「計画」「管理（マネジメント）」が三位一体となって、「ぶれ」を少なくするという風に考えたほうがいいのではないかと思います。
また、別の機会（記事）で書こうと思っていますが、初期段階での費用対効果分析を行いということと、実行段階で見積を実施するということ、さらにはプロジェクト終了後の実績の把握と一定期間後に当初想定していた効果が得られたのかという評価を一連の見積プロセスとして実施していく必要があるのではないかと思っています。
ＰＦに精通している技術者が、実プロジェクトで実施しているかどうかという問題では、個人の実感としては、「まだまだ」という状況ではないでしょうか？
やはり、現場のバリバリの実装者は最新技術にキャッチアップしたり、開発を行うだけで手いっぱいであり、見積手法（ＦＰ法等）を勉強したり、現場に適用したりすることにそれほど積極的ではないと思います。
「上の方（ＰＭＯとか・・）でやれといわれているのでやっている。」というのが現実ではないでしょうか？
それさえも、実際にやっている開発ベンダーやプロジェクトは少ないと思いますが・・・
個人的には、もっと簡単にＦＰで見積もることが可能であり、もっと現場に生かすためのノウハウが定着し、もっと活用した事例（適用したら、こんあにメリットがあるんだよという事例）が出てこないとなかなか難しいのではないかと思っています。