如果需求理解得很好，且約束了項目範圍①， RAD過程使得一個開發組能夠在很短時間內(如60 到90 天)創建出“功能完善的系統”[MAR91]。RAD 方法主要用於信息系統套用軟體的開發，它包含如下幾個開發階段[KER94]：
業務建模：業務活動中的信息流被模型化，以回答如下問題：什麼信息驅動業務流程？生成什麼信息？誰生成該信息？該信息流往何處？誰處理它？
數據建模：業務建模階段定義的一部分信息流被精化，形成一組支持該業務所需的數據對象。標識出每個對象的特徵(稱為屬性)，並定義這些對象間的關係。
處理建模：數據建模階段定義的數據對象變換成為要完成一個業務功能所需的信息流。創建處理描述以便增加、修改、刪除或獲取某個數據對象。
套用生成：RAD 假設使用第四代技術。RAD 過程不是採用傳統的第三代程式設計語言來創建軟體，而是復用已有的程式構件(如果可能的話)或是創建可復用的構件(如果需要的話)。在所有情況下，均使用自動化工具輔助軟體建造。
測試及反覆：因為RAD 過程強調復用，許多程式構件已經是測試過的，這減少了測試時間。但新構件必須測試，所有接口也必須測到。
RAD模型的不足之處：
1 對大型項目而言，RAD需要足夠的人力資源。
2 開發者和客戶都要實現承諾，否則將導致失敗。
3 並非所有系統都適合：不能合理模組化的系統、高性能需求並且要調整構件接口的系統均不適合。
