⑴ 系統架構圖怎麼畫
系統架構圖屬於系統設計階段，系統架構圖只是這個階段一個產物，要正確的、合理的畫系統架構圖需要全面的理解用戶需求以及業務流程，當理解了這些東西後，剩下的就是如何進行表達了，一般而言，可以參照RUP的用例驅動來進行邏輯架構，開發架構等設計工作，你的系統架構圖可以反應在各個視圖裡面，我估計你所說的系統架構圖是屬於邏輯架構裡面，比如分多少層，每層分多少模塊等。
至於，繪制的工具，有很多很多。可以選擇微軟的visio,或者EA,rose,power
designer等UML建模工具，當然，你甚至可以用PPT,Word來繪制。
當然，系統架構不是一日之功，需長期努力，跟經驗和技術都有很大關系。
今天興致來了，回復了這么多，不知滿意不。
⑵ 系統架構圖都包括什麼，應該用什麼來畫
系統架構圖主要是展現系統的大致框架，以及流程、流向、流轉等標注，讓懂或不懂開發的人員通過圖例可以明白系統的整個架構。因為涉及到畫圖中，是需要各種不同的模型來表示，所以通常我們採用微軟office套裝中的visio工具來進行繪制。裡面自帶了很多種不同的模板，很方便的拖放，標注。不要有壓力，這個工具很好用，你可以自己試試。
以上答案由CNNTEC
中國微軟.NET技術交流社區提供，希望對您有所幫助。
⑶ 一張圖講清楚產品架構，手把手教你畫產品框架圖
什麼是產品架構圖
產品架構圖是產品經理用來表達自己產品設計機制的一張概念圖：
它將可視化的具象產品功能，抽象成信息化、模塊化、層次清晰的架構，並通過不同分層的交互關系、功能模塊的組合、數據和信息的流轉，來傳遞產品的業務流程、商業模式和設計思路。
由於產品架構圖通常用於比較復雜的產品項目中，目前介紹產品架構圖的相關書籍和資料極少（尤其是入門級別的資料很少提及），卻是設計復雜產品時不可或缺的文檔之一。
沒有資料的探索過程漫長且沒有方向，在終於有所沉澱後，我花了四周寫下了這篇總結，希望可以為你繪制產品框架圖時提供簡明的參考。
為什麼要畫
梳理自己對產品方向的判斷：
思考這張圖如何設計的過程，也是幫助你梳理「半年內自己的產品該往何處去、需求應該如何分期和落地、和其他產品的依賴&競爭關系是什麼、未來的可拓展性在哪裡」等問題的過程。
為技術&運營的輸出形成支撐：
當這張圖被設計出來後，按照產品架構圖的結構和路徑，項目的里程碑（RoadMap）就可以被清晰的拆解出來，同時項目成員也可以根據這張架構圖產出運營計劃、技術系統架構方案等強依賴產品方向的方案。
讓他人可視化的理解你的產品架構：
能較為清晰簡單的呈現自己的思路、明確自己的產品邊界、指明發展的方向，常用於在項目規劃或項目總結中進行演示，幫助不了解你的產品的人快速的建立對你的產品結構、功能、復雜度的認知。
何時需要畫
建議在復雜項目開始前寫：
當你要開始設計一個系統性、完整的需求時，如果跳過畫產品架構圖的步驟，直接開始畫原型、寫PRD、kick off，就很容易發生「改了又改」、「做了一版需求然後又推翻」的情況。
但「種一棵樹最好的時間是十年前，其次是現在」：
如果你的項目已經進行到一半，自己卻從未產出過這張圖，那麼就從此刻開始，按照下文的步驟嘗試為自己的產品產出一張產品架構圖吧。
如何畫
之前我們分享了【AR最全乾貨及資料】設計AR產品，你一定要看的總結 ，你可能對AR相關的背景知識已經有所了解。為了分享的延續性，我們來做一個大膽的假設*：
假設你是 微信-掃碼功能 的產品經理，有一天老闆把你叫到辦公室，一番鼓勵後拍著你的肩對你說：
「蘋果發布會看了沒？蘋果這么重視對AR能力的支持，我們微信也要趕緊把AR功能做起來。這是個Allen（張小龍）很重視的項目，你回去好好設計一下，明天來跟我過方案。記住，要能夠一炮打響，全民參與喔！」
啊，張小龍級別的項目啊！明天就要出方案，怎麼辦 ？
畫前准備
列出問題域
在需求初期，產品經理得到的往往只是一句比較模糊的需求描述，它們可能來自於老闆、運營或用戶。
直接把這句話作為核心產品功能是不恰當的，合理的做法是先把這個產品所有的問題域列清楚。
「問題域」是指自己的產品能夠解決的所有問題的空間集合。從核心需求出發，將所有當前需要解決、未來可能要解決的問題放入產品框架的范圍，能夠幫助你的產品架構圖擁有更高的可拓展性，在後續具備迭代和優化的空間。
以微信AR的需求為例，問題域是這樣一個集合：
詳細操作步驟：
1. 找到收到的需求中，跟產品形態、產品目標相關的詞句，去列出「XX的流程會是什麼樣」、「XX該怎麼達成」之類的問題，直到如果這些問題解決，能夠實現核心需求的方向和業務目標。
2. 去逐次尋找這些問題需求被解決的過程中，是否有其他要先解決掉的問題、或者其他跟業務相關的問題能夠被解決/改善。
3. 按照層級去羅列出所有的問題，並附上自己的初步回答，從而形成一個初步的、自己的產品能夠解決的「問題域」。
確定產品方向
在經過問題域的羅列後，你應該能夠得到一個模糊的產品方向和功能范圍。把這些問題域的答案抽象總結成一個確定的產品需求。
以微信AR的需求為例，根據問題域，我們發現需求不只是掃碼組件增加AR識別能力這么簡單，整個需求里需要引入廣告主的角色，並且需要和廣點通、騰訊開放平台等團隊合作。最終得到的產品方向描述是這樣的:
詳細操作步驟：
問題域的環節非常發散，這一步需要回歸基礎，把模糊的需求補充、拓展和翻譯成一個在商業模式和用戶體驗上能夠形成閉環的產品需求。
1. 核心需求確定：我的產品核心解決的是哪批用戶、哪個用戶需求？
2. 產品目標：如果以一個數字指標衡量我的產品，它應該是什麼？
3.用戶場景：核心需求基本的產品形態、用戶使用的路徑是怎樣的？
清晰的業務流程
這一步需要根據核心產品需求和問題域的答案，畫出簡單的業務流程。業務流程是產品設計中常見的圖表，繪制方法就不再多做說明。
以微信AR的需求為例，從廣告主准備AR互動，到用戶在前台使用攝像頭參與互動，整個業務流程如下:
著手繪制
搭建基礎框架
基礎的產品框架脫胎於業務流程，但相比業務流程，更加註重產品功能的枚舉、功能模塊之間的分界。
詳細操作步驟：
1. 對照業務流程，根據自己設想的產品機制、基本產品形態和用戶的使用路徑，列出需要的頁面&功能&模塊等前後端邏輯。
2. 將剛剛得到的多個流程圖中所有功能類似或者范圍有包含關系的機制/功能放在一起，以模塊化的形式形成一張簡單的矩陣圖。
3. 將明顯是同一個產品范圍、同一組產品功能的模塊放在同一層級，得到一個基礎的產品框架。
明確架構分層
一個具備前後台關系的產品架構圖至少分為三層：用戶感知層（在何種場景下通過何種方式觸達用戶）、功能模塊層（通過哪些功能模塊實現產品的核心功能、和哪些外部平台功能有信息交互）、數據層（產品的數據從哪裡來、產品的數據沉澱到何處去）。
在上一步進行簡單分層後，我們已經得到一個初步框架，但是難免會有分層不明確的問題。此時需要按照兩種維度來處理架構圖的層級：不同信息層級的邊界、同一層級內模塊和模塊的邊界。
1. 處理不同信息層級的邊界：
架構圖的層級表達的其實是信息之間的流轉關系，不同信息層級之間一定是有邏輯關系的。
其中用戶感知層和數據層通常可以簡化為一層（用戶端的功能表達往往邏輯簡單、數據的來源問題則不是自己產品的核心功能），而功能模塊層則需要按照自己產品的邏輯去將功能模塊層內的主要模塊變成新的層級。
2. 處理同一層級內子模塊的邊界：
各層次之間雖然相關，但同一層次內的子模塊之間一定是互相獨立、界限分明的（常常對應著不同的開發團隊和系統應用）。將解決不同問題的功能拆分成兩個子模塊，做到一個問題只在同一層解決，避免牽一發而動全身的情況出現。
3. 明確產品間的邊界：
產品邊界對於開發設計系統架構、業務間的合作模式都非常重要。用不同顏色標識清楚產品框架中，各個部分所屬產品的邊界，通常其中屬於自己團隊的部分用亮色表示。
加入信息流轉機制
產品架構圖在表達產品的核心功能外，也應該體現信息流動的路徑：當前層級數據的交互形成產品功能，產品功能又產生新的數據，從而推動下一層級的功能運轉起來。
如果當前產品的主要使用角色只有一個，則只需要用箭頭標明模塊間信息流動的方式即可。如果當前產品會涉及的主要角色比較多，則需要用不同顏色的線條將他們和各個模塊之間的信息交互關系外化出來。
最終檢查
一張好的產品架構圖，應該具備以下特點。
清晰的模塊功能邊界
功能經過抽象，做到標准化、互相獨立
上下游產品功能邊界清晰，架構分層明確合理
具備迭代優化的能力
記得不斷根據你的產品的發展情況來更新產品架構圖，每次修改的過程對提升產品架構能力的幫助非常巨大。
————————————————
原文地址：https://blog.csdn.net/pmcaff2008/article/details/78111282
⑷ 系統邏輯架構圖怎麼畫
系統邏輯架構圖根據系統組成繪制，不同類型的系統，邏輯架構圖會有些許差異，本文以軟體系統為例，介紹如何繪制系統邏輯架構圖。
繪制工具：PPT 或 VISIO ，當然也可以使用其他工具
本文使用PPT繪制，點擊「開始」——「OFFICE」——「PowerPoint」，打開一個空白文稿
軟體系統架構圖可以分為基礎設施、數據層、應用層、用戶層四個層次。首先繪制基礎設施層，基礎設施層包括：網路、伺服器、存儲設備等硬體環境，是系統運行的基礎保障，如下圖所示。
其次，繪制數據層。數據層用於存儲系統的數據，系統數據有多種類型，包括系統配置資料庫、用戶管理資料庫、元資料庫、文件資料庫等，如下圖所示。
然後，繪制應用層。應用層根據實際系統設計，可以分為業務應用層和服務層。
（1）服務層介於數據層和業務應用層，為業務應用層提供功能支持，也就常說的中間件層，包括即時通訊系統、簡訊平台、數據訪問組件、安全審計組件、數據交換等。
（2）業務應用層是指具體的業務應用系統功能模塊，包括業務報表、GIS管理、業務統計、綜合查詢、業務表單、業務流程等。
最後，繪制用戶層。用戶層為用戶提供使用系統的入口，包括門戶管理系統、單點登錄系統等。
至此，一個系統的邏輯架構圖就畫好了，當然，這里是一個相對簡單的系統邏輯架構圖，詳細的要根據實際系統設計來繪制。
⑸ 產品架構圖的定義和基本畫法
本小節主要介紹 產品架構圖 的相關知識，整個內容框架分為三個部分，分別是： 產品架構圖是什麼（what） ； 為什麼要畫產品架構圖 （why） ； 如何畫產品架構圖（how） ，下文將對各部分的內容做詳細介紹。
1、產品架構圖的定義
產品架構圖是一種將具象產品的業務架構、功能架構、信息架構、技術架構，生態架構以及商業模式等，通過層級劃分、模塊組合，而設計出的可視化圖形，其抽象且精簡的表達形式，很適合用來介紹復雜產品體系。常見的產品架構圖有業務架構圖、功能架構圖、信息架構圖，以及混合架構圖。
有句俗語叫做： 思考常常越復雜，形式往往越簡單 。人類歷史上許多偉大的知識和定律都是以精簡而優美的形式表達出來的，例如亞里士多德的三段論表述、牛頓的三大定律、歐拉的上帝公式，達爾文的進化論表述等。思考的足夠通透後，只需要用簡單的形式就可以表達復雜的體系結構和邏輯關系，相反很多看似簡單的表現形式，背後卻承載著巨大的復雜。
對比各種產品輸出物（文檔、原型圖，流程圖等），產品架構圖的形式最為精簡，都是由單一的矩形控制項排列組合形成，但卻在所有的產品輸出物中擁有最高的抽象程度和復雜度，輸出產品架構圖是對產品經理產品設計能力的衡量和體現。
2、為什麼要畫產品架構圖
在進行產品設計的時候，首先應該輸出的是產品功能架構圖，思考這張圖如何畫的過程，是幫助你梳理產品設計思路以及確定產品邊界過程。例如，現在讓你設計一個CRM系統，可以試著先畫出具體業務的CRM系統的功能架構圖，在畫的過程中，會輔助你思考整個CRM系統有哪些核心功能模塊組成，各模塊的關聯關系是怎樣的，每個階段應該做什麼，從而形成完成的產品設計思路。
其次，產品設計的過程就像是蓋大樓的過程，輸出產品功能架構圖就好比是搭建大樓地基的過程，產品原型設計的過程就像是大樓建造的過程，地基沒有問題，後面的添磚加瓦就不會有太大問題。如果一開始地基質量就有問題而沒有被重視，後續蓋了一半發現整個工程出現問題，修復重建則會浪費巨大的資源和成本。所以項目初期產品功能架構圖是很重要的交付物，當你要開始設計一個完整的產品方案時，如果跳過畫產品架構圖的步驟，直接開始畫原型、寫PRD文檔，就很容易發生改了又改，甚至是做了一版需求然後又推翻的情況。
最後，在產品上線後無論是對內普及還是對外推廣都需要有高度抽象，簡潔易懂的載體來介紹產品整個情況，介紹和推廣的不可能去用繁雜的頁面和文字去描述，這個時候產品架構圖會是介紹整個產品理念，功能和設計的一個很好的傳達媒介。
3、如何畫產品架構圖
上文介紹了什麼是產品架構圖以及為什麼要畫產品架構圖，接下來要介紹如何畫產品架構圖，產品架構圖的畫法主要分為四個步驟，分別是：（1）確定對象；（2）拆解結構；（3）挖掘關系；（4）表達輸出。
圖5-1產品架構圖的畫法
（1）確定對象
首先要明確產品架構圖描述對象的范圍和邊界是什麼，例如，對於一個CRM系統，要畫的是CRM系統的業務架構圖、功能架構圖、信息架構圖、還是綜合了多種元素混合在一起的混合架構圖。
（2）架構拆解
確定好描述對象的類型後，要對其進行架構拆解，例如，輸出一家借貸平台的業務架構圖圖，可以拆解為貸前業務、貸中業務，貸後業務等。又例如輸出一個CRM系統的功能架構圖可以拆解出整個CRM系統的功能模塊，如賬戶管理模塊、客戶管理模塊、用戶管理模塊、許可權管理模塊，系統設置模塊等。
（3）關系挖掘
輸出對象的架構拆解完成後，需要發掘出各個模塊之間的關聯關系，同樣以CRM系統的功能架構圖為例，在拆分完整個系統的功能模塊時，接下來要分析出各個功能模塊的關系，產品架構圖內部元素之間的關聯關系主要有四種：統計並列關系、父子包含關系、輔助支撐關系，底層支撐關系。
（4）表達輸出
確定了各個功能模塊的關系之後，則需要進行關系表達，層級相同的模塊元素，則按照同級並列關系，需要排列在一起。
例如，在CRM系統中，客戶管理模塊和許可權管理模塊就屬於同層級的並列關系。而許可權管理模塊和許可權分配這個功能模塊之間則屬於父子包含關系，在表達父子包含關系時，通常父級模塊會包含住子級模塊。
其次，一些產品的非核心的功能模塊或者產品之外的一些功能模塊，例如第三方平台的簡訊功能模塊，這些模塊對產品自身功能的實現起到了一定的輔助作用，與其他產品功能模塊呈現出輔助支撐的關系，輔助支撐模塊一邊畫在產品架構圖的右側。
最後是底層支撐關系，例如產品的 會員體系 是建立在賬戶體系的基礎上的，所以賬戶體系與會員體系屬於底層支撐關系。底層支撐關系的表達方式一般是支撐模塊在底下，被支撐模塊在上面。這些基本關系的圖形化表達方式，會在後面小節結合實際的案例做詳細介紹。
整個邊界范圍內的結構關系表達完成後，整體檢查一遍是否有遺漏和錯誤，檢查完畢後配上整個架構圖的標題，架構圖標題往往是對整個架構圖內容的說明，一般放在最上面或者框架左右兩邊，最終輸出完整的產品架構圖。
愛因斯坦說過： 如果你不能把一件事情用最簡潔的語言描述清楚，說明你還沒有理解他。 對於產品架構圖而言： 如果你不能用簡單的矩形， 通過 排列組合的方式 ， 把一個復雜的產品 結構描述 清楚，說明你還沒有真正理解 你做的產品 。 所以，在日常的產品工作中，要培養自己去畫產品架構圖的習慣，培養抽象思考能力的同時，輔助自己高效的完成產品方案設計。
原文地址：https://www.cnwebe.com/articles/157113.html