IDEF3
IDEF3記述は、2つの異なった観点:プロセス中心とオブジェクト中心、から開発される。これらのアプローチは、相互に排他的ではなく、IDEF3は、複雑なプロセス記述を表現するため、それらの間のクロス参照を可能にする。
そこでモデルは、それ自身の権利で設計されたシステムです。モデルは、正しくないことと知られる理想化されたシステムであるが、ドメイン内であらかじめ定義された関心の領域のための信頼できる予測要素を提供するのに十分近いと考えられる。その一方で記述は、個人の知識または経験の領域内での何かについて事実または信念の記録である。そのような記述は一般的に不完全である;すなわち、記述を与える人が、彼や彼女が無関係であると信じる、あるいはシステムを記述する成り行きで忘れた、事実を省略するかもしれない。記述はまた、他の人がそのドメイン内の観察した状況と矛盾しているかもしれない。IDEF3は、同じシナリオまたはプロセスの代わりの記述を獲得しあ押して組織化することを可能にする特定の機能を提供することで、これらの可能性を受け入れている。図を参照のこと。
当初のIDEFは、1970年代中頃から、彼らの既存システムがどのように統合されるかを意思決定するのに必要な人々の間でのコミュニケーションを強化するため開発された。IDEF0は、機能分割の過程と機能間の関係の分類化(すなわち、入力、出力、制約、及び機構の分類)を経てシステムの機能を記述を優しく拡張することを可能にするため設計された。IDEF1は、組織が、その目的を達成するため重要であると認める情報の記述を可能にするため設計された。
3番目のIDEF(IDEF2)は、当初ユーザー・インタフェース・モデリング手法を意図した。しかしながら、ICAM (Integrated Computer-Aided Manufacturing)プログラムは、シミュレーションのモデリング・ツールを必要として、結果としてIDEF2が、数学モデル・ベース・シミュレーションの仕様のためのフレームワークを提供する、製造におけるシステム資源の時系列的振舞を表現する1つの手法となった。この状況を正したいとのICAM内の手法論プログラムの意図があったが、それをすることを許さない資金的限界があった。結果として、システムの構造的なユーザー・ビュー (User_view)の記述の支援する手法の不足が、IDEFシステムの大きな欠点となった。手法論的視点からの基本的問題は、(既存または提案の)システムが何をすると想定するかの記述と、システムが何を行うかを予測するシミュレーション・モデルの表現を区別することである。その後者がIDEF2の焦点であり、前者がIDEF3の焦点である。