通過在問題定義和歸結模型階段的工作，已經分析並定義了與系統開發目標相關的各種模型 、 分析出了系統的功能清單 、 效能要求等，解釋了 「 系統目標是什麼 」 的問題。在系統方案階段，主要完成的工作則是解釋 「 系統如何實現 」 的問題。
系統方案制訂的最主要內容，包括以下幾個方面。
在問題定義階段得到的軟體概念模型使用各種工具定義了專案的開發目標。在系統方案制訂階段才開始真正考慮如何去實現軟體。其中最重要的工作，就是制定系統的實現架構。
系統的實現架構與一些很具體的方面相關：
（1）分析模型的結構
例如，採用結構化分析方法得到的功能分解體系，或物件導向的類和 「 物件－關係圖」、 「 物件－行為圖 」。
（2）一些對應於系統目標的最基本、最重要的實現要素
例如，關鍵的用例 、 最主要的控制類 、 物件組織的模式 、 常用和最關鍵的實現演算法模型等。這些實現要素對應於系統目標實現最重要的場景，表示了整個系統最主要的控制流程和實現機制。
（3）特性和要點的解釋
這些附加的內容解釋系統的一些特性、服務等是如何實現的。
關鍵性的實現要素通常包括：
關鍵性的實現手段通常包括：
通常，提供開發工具和開發環境的組織總是有一些標準的計算體系可以選擇（例如， .net 和 j2ee 等），因此對於大多數系統開發專案來說，比較各種標準計算體系與預期目標之間的匹配程度即可選定計算體系。選擇標準的計算體系去實現系統可以忽略大多數基礎平台和底層支撐技術的實現問題，從而大大提高系統的質量 、 降低開發風險和成本。
開發人員常根據基礎平台的系統實現能力支援，公司或專案組在特定實現平台上的技術積累，甚至技術的 「 先進性 」 或流行程度這樣的因素去選擇系統的實現技術體系。
在另一些情況下，出於各種諸如使用者投資力度，與使用者現有的 it 設施保持一致性 、 相容性 、 擴充套件性及未來維護的能力等因素，系統的基礎平台很可能在專案的論證階段就已經被確定，如作業系統 、 資料庫系統 、 web伺服器 、 開發工具或開發環境等。在這種情況下，系統的實現體系實際上已經確定。
通過同時參考系統概念模型，將前面得到的系統功能清單和系統實現的各種關鍵要素整理並分類，然後與現有的技術 、 標準的實現體系進行比較和匹配，就可以將系統概念模型定義的系統目標，進一步對映到真正可計算 、 可實現的系統架構上。
這個過程可以理解為一種不斷歸結 、 比較並匹配的過程。進行匹配的過程常常是一種雙向的選擇和**過程，一方面拿出乙個系統目標中的功能或實現要素，詢問：這部分功能屬於表示層 、 業務邏輯 、 還是資料服務？另一方面，也研究標準計算體系提供的功能，例如：放在業務邏輯層合適嗎？技術人員具有這方面的開發經驗積累嗎？甚至是標準構件或服務可用嗎？
各種標準的計算體系可能很複雜，但通常總是包括一些邏輯上的劃分，例如， .net 體系將應用系統理解為三個層次，表示層 、 事務邏輯層和資料服務層構成。
（1）表示層
（2）事務邏輯層
負責處理表示層的應用請求，完成商務邏輯的計算任務，並將處理結果返回給使用者。事務邏輯處理層是將原先置於客戶端的事務邏輯分離出來，集中置於伺服器部分，為所有使用者共享。事務邏輯層是整個應用的核心部分，而元件物件模型 com 則相當於其心臟。事務邏輯層通過 com 進行事務處理，並由 iis （ internet information server ， internet 資訊伺服器）和 mts （ microsoft transaction server ，微軟事務處理伺服器）為各種應用元件提供完善的管理。
（3）資料服務層
為應用提供資料**。和以往的兩層架構不同，資料庫不再和每個活動客戶保持乙個連線，而是若干個客戶通過應用邏輯元件共享資料庫的連線，從而減少連線次數，提高資料伺服器的效能和安全性。
相同的三層計算模式，也會表現為不同的實現方式。例如，表示層可能是單一應用系統的使用者介面 、 c/s 計算的客戶端 、 或 b/s 計算的 web 頁面和元素；事務邏輯層可能是單一應用系統的程式模組 、 c/s 的伺服器端服務 、 b/s 應用伺服器中的業務指令碼或業務物件；當利用類似儲存過程來實現資料操作邏輯的時候，儲存過程也被看作事務邏輯層的一部分，但如果利用 ado （ activex dataobject ， activex 資料物件）這樣的資料訪問元件訪問資料時， ado 和後台的資料庫系統及資料庫的邏輯則被看作資料服務層的一部分。
在必要的情況下，某個層次還可能進一步細分，例如，使用物件導向設計方法的系統常常會將事務邏輯層劃分為基本的計算物件 、 業務物件及黏合業務物件實現功能的指令碼 「 膠水 」 或一些控制類。
歸結系統實現要素到計算體系的時候，要點在於理解各種計算體系的大致分層和構成，比較實現要素的目標和實現手段之間的 「 適合程度 」 ，而不是生搬硬套某種實現機制，或盲目追求某種 「 流行的 」 或 「 先進的 」 算體系。
系統方案制訂後，需要根據有關標準進行評價，找出不符合實際的地方，然後進行改進。
系統架構設計 系統工程師 系統架構設計
系統架構設計包含硬體架構和軟體架構，功能的模組化和描述輸入輸出是基本思維。並且系統架構設計是做系統級失效模式影響分析 sfmea 的輸入。硬體架構設計是根據iso26262 2018第5章中的附錄d，再結合具體的客戶要求的功能，畫出系統層級的硬體拓撲結構，包含如下要求 主晶元選擇 ad，i o，ca...
系統架構設計 一
領域建模與需求分析緊密結合，建模是為了更好的進行需求總結和分析，整理出其中不變的模型，建立專業的詞彙。其可作為對現實世界的某種抽象,需要有選擇的進行忽略，而有選擇的進行忽略和保留都取決於你所要進行的模型設計。最終是抽取其中不變的部分和內容。需求 於三大部分 功能 質量屬性 商業需求。關鍵需求決定架構...
Java 系統架構設計
首先分為閘道器和引擎等多個部分 第一部分 閘道器 1 主要負責 請求和一些過濾操作，處理一些非法的重複ip請求，以及使用者安全鑑權操作，分出來這一層的原因是，防止惡意攻擊的請求太頻繁，導致有邏輯業務的機器壓力過大，導致宕機，這樣子影響其他業務的處理，所以分出來了。2 這裡面還需要加白名單或者黑名單之...