其中，首先要導向的是建立符合長遠發展的軟人文管理理念。二是有更靈活的空間和與經營理念相匹配的長效機制和長期反饋機制。以促進二元環境下數值和運算的高效溝通模式。提高執行力，優化經濟成本流組織模式，降低內外部交易成本，註重時效性和實用性的SOP。有效提升產品和團隊的競爭力。並根據長效機制，制定合理的調整機制，快速調整資源配置量。從而在人員、時間和有效資源的優化配比下，創造更大的利潤空間和更多的附加值延伸。
企業信息系統由五個基本要素組成:組織結構、流程、數據、業務規則和功能(性能)。其中，從用戶的角度出發，我們主要關註的是流程，這是核心。通過流程，其他要素貫穿，需求分析師也要從這個角度和用戶溝通；從開發者的角度，主要關註企業的數據、業務規則和功能，以便於系統的實現；從實施者的角度，主要關註企業的組織結構和功能，以便於制度的發布和實施。
1)企業的組織模式
即企業的組織架構，包括部門設置、崗位設置、崗位職責等。樹形組織結構圖是描述企業組織模型的壹種常用方法。可以用來明確部門之間的領導關系，各部門內部的人員配備情況，職責分工等。它是劃分系統範圍和規劃系統網絡的基礎。在組織結構圖中，應逐層詳細描述用戶的組織結構，並簡要描述各部門的職責。組織結構是用戶企業的業務流程和信息的載體，對於分析人員了解企業的業務和確定系統的範圍非常有幫助。獲取用戶的組織結構圖是需求獲取步驟中的基本任務之壹。
用戶環境中的企業崗位或角色，和組織壹樣，也是分析師了解企業業務、提取對象的基礎。
用戶的角色識別往往會漏掉計算機系統的系統管理員，角色識別不徹底，會對以後的功能識別造成盲區。
(2)業務流程模型
即企業的業務流程，包括哪些流程，流程之間的關系，每個流程包括哪些活動，每個活動涉及的崗位。企業的工作流程首先要有壹個總的業務流程圖，描述企業內各項業務之間的關系，然後詳細描述每壹項業務，這樣才能把業務流程和部門的職責結合起來。詳細的業務流程圖可以是直線業務流程圖的形式。對於企業來說，需要定義業務流程圖的描述標準，大家用同壹個圖例來描述，方便管理。
業務流程圖的優點:
■繪圖的過程其實就是組織工作流程的過程。
■表達直觀，易於與用戶溝通，易於項目團隊內部溝通。
研究成果需要得到用戶的認可，這就需要與用戶交流研究成果和文獻。
文件要通俗易懂，不能用專業術語。
■可用作培訓實施者和技術服務人員的文件。
業務流程圖的缺點:
■對高級管理人員的實際需求調查不清。
壹方面是因為用戶沒有接觸過電腦，采用電腦後的管理會是什麽樣子？現在的人工操作，電腦能做什麽？什麽工作可以做，什麽工作現在不能用手做，沒有明確的概念，所以用戶無法反映這些問題。另壹方面說明分析師沒有經驗，沒有深入挖掘原始資料，無法從用戶提供的資料中提取用戶的真實需求，無法發現當前管理中存在的問題。
■沒有表達各業務之間的整體關系。
直線業務流程圖可以清晰地表達企業各項業務的處理流程，但沒有表達業務之間的關系。壹個業務的流程圖很清晰，但是整合不了。作為需求分析的文檔，表達不夠完整。
■不使用工具，畫法繁瑣。
圖形可以清晰的描述過程，但是需要壹些文字來解釋，比如業務的發生頻率，事故的處理，高峰時段的業務發生頻率等。流程圖不能描述的，需要用文字詳細描述。
(3)企業數據模型
企業中的信息載體有哪些？以及對這些信息載體的詳細描述，包括對企業各種文件、賬冊、報表的描述。在需求報告中，文檔的描述要格式化，要描述的內容包括:
文件的用途，即文件用在哪裏？
文件的格式:需要繪制清晰，有實際例子有數據，能具體直觀的說明問題；
文檔中數據項的具體描述:長度、類型、計算和生成方法、約束條件等。
哪些不同類型的角色填寫文檔的數據項，包括那些可以由計算機填寫的數據項。
文檔中的哪些數據是必需的，哪些是不必需的。
文檔流量:平均每天產生多少條記錄，高峰期的數量；
單據的分類:可以從多個角度對單據進行分類，如:按業務類型(采購/銷售/生產)、按生成方式(手工錄入/自動生成)、按格式變化頻率(易變/穩定)、按展現形式(列表/卡片類型)等等。
文檔之間的關系:引用關系等。
同樣，所需的報表和書籍也可以參照上述項目進行詳細描述。
(4)企業的業務規則模型
企業中的商業規則是什麽？這些規則用在哪裏？業務規則從影響範圍上可以分為兩類:壹類是局部規則，比如不允許負庫存，壹類是整體規則，比如把所有物料管理到批次。業務規則壹般隱藏在功能模型或者流程模型中，不需要單獨描述，但是壹些復雜的業務規則需要提取出來單獨描述，比如企業的各種單據記賬的業務邏輯，5)企業的功能模型。
功能需求是用戶最重要的需求，用戶功能需求的描述可以用文字描述，也可以用語言和圖形描述，只要能完整、準確、輕松地描述用戶的需求。對於功能需求復雜的系統(如超過10個功能項)，可以先描述壹個概要，簡單的系統可以直接詳細描述。要對用戶的功能需求進行分類，分類方法要讓用戶容易理解，比如按照用戶的部門設置來描述各個部門的需求，這樣也便於組織用戶復習。以下是分類方法的示例:
按部門分類:如采購部、銷售部、計劃部、生產車間、財務部、統計部、總經理等。
按功能類型分類:如單據錄入、單據審核、單據查詢、記賬、賬簿查詢、統計報表、系統維護等。
功能需求的分類在不同的層次可以采用不同的方法。
每個功能都應有壹個功能編號，以便與功能規範中的章節相對應。每項功能的描述應表明用戶的輸入、過程方法、系統輸出以及對該功能的其他要求。功能要求還應指出使用該功能的職位。系統管理員要求的特殊功能可以在這裏註明，非特殊需求可以在需求分析說明書中詳細討論。如果用戶權限可以分級，應該有操作日誌等。
功能需求和性能需求是不可分割的。壹般的性能需求沒有任何意義，必須針對某個特定的功能需求，這是分析師在分析系統時容易忽略的。
以上五個基本要素可以描述為壹個五元組“組織、流程、功能、數據、業務邏輯”。對於用戶來說，習慣於從組織維度來看待系統，即某個部門有哪些工作，每個工作參與哪些活動(職能)，某個職能上操作了哪些數據，對這些數據進行了哪些邏輯處理；開發者習慣於從功能維度來看待系統，即壹個功能操作了哪些數據，對這些數據進行了哪些邏輯處理，這個功能屬於哪個流程，哪些崗位可以使用；設計人員可能習慣於從數據維度來看待系統:即系統中有哪些數據，可以對這些數據做哪些處理，這是按照OO的思想對數據對象的操作。
描述以上五個基本要素，其實就是系統建模的過程。為保證模型的可操作性，除上述五個基本要素外，需要重點描述的內容有:
(1)新系統帶來的應用模式變化
包括組織結構、工作流程、文件格式、書籍和報告、業務規則等的變化。
(2)新系統的接口模型
使用開發工具快速繪制用戶界面，讓用戶心中有數。如果時間允許，可以將界面原型與數據庫表和字段連接起來，真正做出系統的原型，即快速原型法。