國內的軟體公司在追求文檔規範的同時，忽略了圖表示意、互動操作類比對調研內容傳遞的重要作用。
文檔只是作為對需求調研內容輔助描述的一種手段，如果把他作為需求調研內容的唯一載體那將是一個極其悲哀的一件事情。上文所說的文檔我暫且把它限定在平面化的文檔，也就是缺乏使用者互動體驗的文檔。
包括CMM軟體成熟模型要求的文檔化，隨著軟體系統的複雜，應用水平的提高，其文檔化的內涵必然不斷地擴充和延伸。隨著多媒體技術的發展以及應用軟體模型化開發的普及。國內對需求調研的真實度、模擬度的要求必定越來越高。
我們曾經走過一些改良的路子：利用成型的軟體來做需求調研的原形。這不失為一個好方法，可以將自己的管理理念、系統功能快速的介紹給使用者，使使用者的思維儘早的轉換到“今後我用這個系統的時候，他還有何缺陷，有沒有更好的實現方法？”的思維模式上來，而不是“今後這個系統應該具備什麼功能，這個功能應該如何?？”。但是我們同樣也遇到這樣的困惑，成型的系統，面對使用者的特殊需求，需求調研人員由於開發技術上的缺陷無法快速按照使用者的需求構造出一個可互動類比的業務辦公原形與使用者進行溝通，從而喪失寶貴的第一手資料。
因此我們可以採用業務快速建模的方式完成業務手工辦理模式的電腦類比。使項目的需求調研內容可以直觀通過電腦的類比操作來進行解釋說明，使需求調研內容不只停留在訪談和文字描述的階段，當然文檔補充描述是必不可少的。
一般情況下，我們在進行需求調研時，會形成3個主要的成果：組織圖調研、商務程序調研、軟硬體環境調研。將這三個方面的成果映射到使用者的需求模型的電腦描述：組織模型、業務模型、資源模型。
- 組織模型再細分可以分為：使用者、崗位、許可權；
- 業務模型再細分可以分為：業務狀態、業務角色、業務許可權、業務表單（輸入、查詢、新增修改、輸出）、業務報表、商務程序、資料模型、業務資源（組件、服務（web service、job service）、指令碼、訊息）；
- 資源模型再細分可以分為：基礎類庫、擴充類庫、模板中心、註冊組件、註冊服務。
以上是靜態管理架構的準系統需求，還缺少一個動態支援業務流轉的運行架構。下面以抽象的業務辦理流程為例說明業務模型定義、類比啟動並執行主要功能需求。一般業務在電腦實現基本上包括以下幾個方面：錄入資訊、查詢資訊、辦件通知、辦件過程查詢、辦結通知、退件通知、辦件流轉。
- 辦件流轉、辦件通知是組織管理業務辦理各要素，並使之協作的根本；
- 資訊採集是業務辦理的本質需求；
- 資訊查詢（匯總）是業務辦理的輔助需求。通過商務程序來將狀態、許可權、角色、表單、報表、資源等各個要素組織起來形成可流轉的業務模型。每個工作節點分別由辦理角色、動作表單、操作報表、操作資源、辦理時限（是否計入工作時間）、工作任務提交處理機制業務模型元素來描述每個工作節點的內容。
並且通過業務模型可以產生業務調研的成果，比如word文檔。
