3、 可擴充性：系統方案的升級、擴容、擴充性能
　　系統在建成后會有一段很長的運行周期，在該周期內，應用在不斷增加，應用的層次在不斷升級，因此采用的構架設計等方案因充分考慮升級、擴容、擴充的可行性和便利。

　　4、 可移植性
　　不同客戶端、應用服務器、數據庫管理系統：如果潛在的客戶使用的客戶端可能使用不同的操作系統或瀏覽器，其可移植性必須考慮客戶端程序的可移植性，或盡量不使業務邏輯放在客戶端；數據處理的業務邏輯放在數據庫管理系統中會有較好的性能，但如果客戶群中不能確定使用的是同一種數據庫管理系統，則業務邏輯就不能數據庫管理系統中；

　　達到可移植性一定要注重標準化和開放性：只有廣泛采用遵循國際標準，開發出開放性強的產品，才可以保證各種類型的系統的充分互聯，從而使產品更具有市場競爭力，也為未來的系統移植和升級擴展提供了基礎。

　　5、 需求的符合性
　　從源代碼的組織結構看需求的符合型主要考慮針對用戶需求可能的變化的軟件代碼及構架的最小冗余（同時又要使得系統具有一定的可擴展性）。

　　五、寫系統構架設計文檔應考慮的問題

　　構架工作應該在需求開發完成約80％的時候開始進行，不必等到需求開發全部完成，需要項目經理以具體的判斷來評估此時是否足以開始構建軟件構架。

　　給出一致的輪廓：系統概述。一個系統構架需要現有概括的描述，開發人員才能從上千個細節甚至數十個模塊或對象類中建立一致的輪廓。

　　構架的目標應該能夠清楚說明系統概念，構架應盡可能簡化，最好的構架文件應該簡單、簡短，清晰而不雜亂，解決方案自然。

　　構架應單先定義上層的主要子系統，應該描述各子系統的任務，并提供每個子系統中各模塊或對象類的的初步列表。

　　構架應該描述不同子系統間相互通信的方式，而一個良好的構架應該將子系統間的通信關系降到最低。

　　成功構架的一個重要特色，在于標明最可能變更的領域，應當列出程序中最可能變更的部分，說明構架的其他部分如何應變。

　　復用分析、外購：縮短軟件開發周期、降低成本的有效方案未必是自行開發軟件，可以對現有軟件進行復用或進行外購。應考慮其對構架的影響。

　　除了系統組織的問題，構架應重點考慮對于細節全面影響的設計決策，深入這些決策領域：外部軟件接口（兼容性、通信方式、傳遞數據結構）、用戶接口（用戶接口和系統層次劃分）、數據庫組織和內容、非數據庫信息、關鍵算法、內存管理（配置策略）、并行性、安全性、可移植性、網絡多人操作、錯誤處理。

　　要保證需求的可追蹤性，即保證每個需求功能都有相應模塊去實現。

　　構架不能只依據靜態的系統目標來設計，也應當考慮動態的開發過程，如人力資源的情況，進度要求的情況，開發環境的滿足情況。構架必須支持階段性規劃，應該能夠提供階段性規劃中如何開發與完成的方式。不應該依賴無法獨立運行的子系統構架。將系統各部分的、依賴關系找出來，形成一套開發計劃。