FDD 方法來自于一個大型的新加坡銀行項目。FDD 的創立者 Jeff De Luca 和 Peter Coad 分別是這個項目的項目經理和首席架構設計師。在 Jeff 和 Peter 接手項目時，客戶已經經歷了一次項目的失敗，從用戶到高層都對這個項目持懷疑的態度，項目組士氣低落。隨后， Jeff 和 Peter 采用了特征驅動、彩色建模等方法，最終獲得了巨大成功。
FDD 是也是一個迭代的開發模型。FDD的每一步都強調質量，不斷地交付可運行的軟件，并以很小的開發提供精確的項目進度報告和狀態信息。同敏捷方法一樣，FDD 弱化了過程在軟件開發中的地位。雖然 FDD 中也定義了開發的過程，不過一個幾頁紙就能完全描述的過程深受開發者的喜愛。
1．FDD 角色定義
FDD 認為，有效的軟件開發不可缺少的三個要素是：人、過程和技術。軟件開發不能沒有過程，也不能沒有技術，但軟件開發中最重要的是人。個人的生產率和人的技能將會決定項目的成敗。為了讓項目團隊能夠緊密地工作在一起，FDD 定義了 6 種關鍵的項目角色：
（1）項目經理。項目經理是開發的組織者，但項目經理不是開發的主宰。對于項目團隊來說，項目經理應該是團隊的保護屏障。他將同團隊外界（如高層領導、人事甚至寫字樓的物業管理員）進行溝通，努力為團隊提供一個適宜的開發環境。
（2）首席架構設計師。不難理解，首席架構設計師負責系統架構的設計。
（3）開發經理。開發經理負責團隊日常的開發，解決開發中出現的技術問題與資源沖突。
（4）主程序員。主程序員將帶領一個小組完成特征的詳細設計和構建的工作，一般要求主程序員具有一定的工作經驗，并能夠帶動小組的工作。
（5）程序員。若干個程序員在主程序員的帶領下形成一個開發小組，按照特征開發計劃完成開發。
（6）領域專家。領域專家是對業務領域精通的人，一般由客戶、系統分析員等擔當。領域專家作為關鍵的項目角色正是敏捷宣言中“業務人員同開發人員緊密合作”的體現。
根據項目規模的大小，有些角色是可以重復的。例如在一個小規模項目中，項目經理自身的能力很強，他就可以同時擔當項目經理、首席架構設計師和開發經理的角色。
2．核心過程
FDD 共有 5 個核心過程，如圖 6-6 所示。

（1）開發整體對象模型。開發整體對象模型也就是業務建模的階段。不過 FDD 強調的是系統地完整地面向對象建模，這種做法有助于把握整個系統，而不僅僅關注系統中的若干個點。在這一階段，領域專家和首席架構設計師相互配合，完成整體對象模型。
（2）構造特征列表。完成系統建模后，需要構造一個完整的特征列表。所謂特征指的是一個小的、對客戶有價值的功能。采用動作、結果和目標來描述特征，特征的粒度最好可以在兩周之內實現。在這一階段中，可以整理出系統的需求。
（3）計劃特征開發。很少看到有哪個軟件在開發過程中明確包含計劃過程，其實任何一個軟件項目都必須有計劃——無論是重載方法還是敏捷方法。在這一階段中，項目經理根據構造出的特征列表、特征間的依賴關系進行計劃，安排開發任務。
（4）特征設計。在這一階段，主程序員將帶領特征小組對特征進行詳細設計，為后面的構建做準備。
（5）特征構建。特征構建和特征設計這兩個階段合并起來可以看做特征的實現階段，這兩個階段反復地迭代，直到完成全部的開發。
3．最佳實踐
組成 FDD 的最佳實踐包括：領域對象建模、根據特征進行開發、類的個體所有、組成特征小組、審查、定期構造、配置管理、結果的可見性。
其中，最有特色的莫過于類的個體所有。幾乎所有的開發模型都是代碼共有，程序員們負責開發系統中的全部代碼，并通過配置管理和變更控制來保持代碼的一致性。在 FDD 中，將類分配給特定的任何小組，分配給 A 成員的代碼將全部由 A 來維護，除 A 外的角色都不能修改它，只能使用它。這樣做當然有它的優點：個人對所分配的類很容易保持概念的完整性；開發類代碼的人肯定是最熟悉這個類的主人；而對這個類的支配感會促使開發人員產生自豪感，從而更出色地完成任務。不過 FDD 也提到了類個體所有的缺陷：項目中的依賴關系增強、當 A 需要 B 修改他自己的類時，必須等待 B 完成修改才能使用；類的個體所有增加了員工離職的損失。面對這些優點和缺陷，顯然 FDD 認為類的個體所有對系統開發更有幫助。
除類的個體所有外，審查也是 FDD 中很具特色的一項實踐。不少人都認為審查是非常嚴格的軟件過程所特有的，因為進行審查不但要花費不少的人力和時間，對審查者本身的素質也有要求。然而在 FDD 中，明確地將審查作為一項最佳實踐提出。審查是一種很有效的發現缺陷的手段，但經常被忽視，國內的軟件組織中很少有嚴格審查制度保證軟件質量。有效的審查可以發現很多潛在的問題，而這些問題往往是無法通過測試發現的，例如建模、需求和設計期的缺陷。這些潛在的缺陷大多要到系統測試甚至發布后才能發現，修正這些缺陷的代價是很大的。