在需求分析的階段，非功能需求也是十分重要的乙個階段。部署圖和構件圖就能很好的描述非功能需求。
部署圖從硬體的角度、物理層次上進行系統的整體規劃，包括當前的it架構以及改造後的it構架，包括：node：用來表示物理的裝置，如電腦、pc、伺服器等；tag 用來表示裝置的數量 作業系統 **端等相關資訊;communication path 節點間的連線；component的定義：能實現一定的功能，或者提供一些服務，如介面不能獨立執行，要作為系統的一部分，但可單獨維護，公升級，替換，而不影響整個系統。artifact 描述系統中的乙個物理單元，同樣是可替換的部分，如原始檔，安裝程式，指令碼等。
在閱讀的乙個例子中我對次有了更深刻的理解。乙個軟體公司採用.net技術體系研發了一套電力系統，該系統使用的是sql server資料庫。但安裝系統時，客戶發現該系統使用的資料庫是sql server時，要求必須使用oracle，如此一來，軟體公司只能修改系統，這樣的軟體改動工作量是很大的。所以一定會需要軟體技術框架，如果忽視了在軟體技術框架、軟體架構上的要求的話，會給軟體後期工作帶來想不到的麻煩。很多專案往往在初期就會對技術框架有一定的限制，常見的情況有：1.新專案需要在原系統的基礎上開發；2.新專案需要與某些存在的系統做對接；3.新專案需要充分利用客戶的現有it資源，尊重和保護客戶投資；4.軟體公司承接新專案時；5.有安全性、可靠性和效能等方面的要求。
需求階段一般不會決定全部的技術細節，但是往往會需要確定技術框架層次的一些要求。部署圖的主要目的是在物理層次上做整體的系統規劃，當然網路拓撲結構圖也能起到這個作用，但是建議使用部署圖，因為部署圖的作用更加強大，最重要的是還可以在此基礎上繼續細化設計。
UML大戰需求分析 閱讀筆記06
狀態機圖和活 在樣子比較相似，但狀態機圖是用來為物件的狀態及造成狀態改變的事件建模。我們大二學習uml統一建模語言狀態機圖模組時了解到，uml的狀態機圖主要用於建立物件類或物件的動態行為模型，描述系統中某乙個物件所經歷的各個狀態 引起狀態或活動轉移的事件，以及因狀態或活動轉移而伴隨的動作。但在以前的...
UML大戰需求分析 閱讀筆記04
讀 uml大戰需求分析 有感04 開發某系統的重要前提是 這個系統有誰在用？這些人通過這個系統能做什麼事？一般搞清楚這件事，再畫個業務流程圖，就能條例清楚的表達系統的需求了。作為乙個開發人員，不僅要懂得如何從使用者那裡獲取有用的資訊，還要懂得怎麼清晰地描述自己的想法，給客戶呈現出乙個結構完整 功能全...
UML大戰需求分析 閱讀筆記03
讀 uml大戰需求分析 有感03 狀態機圖和活 在樣子比較相似，但狀態機圖是用來為物件的狀態及造成狀態改變的事件建模。我們大二學習uml統一建模語言狀態機圖模組時了解到，uml的狀態機圖主要用於建立物件類或物件的動態行為模型，描述系統中某乙個物件所經歷的各個狀態 引起狀態或活動轉移的事件，以及因狀態...