系統分析、Business Model
企業需求、企業流程、企業願景
緣起:
以往在軟體系統開發時，常常不清楚自己該從何處著手來做分析，並且欠缺相關的流程指引，導致系統分析人員無所適從。
以下就我個人系統分析的經驗做個小小的心得分享。
目的:
Business Model的目的是建立願景、訂立系統範疇，並與相關人員(Stakeholder)取得開發上的共識，ex:專案是否有價值，願景是否符合期待。
總覽
圖:Business Model的結構以及其目錄分類
流程:
找出相關人員
透過系統定位(發展緣由、要達成的目標..)，系統定位通常來自某個企業目標、問題，而發起人可能是
高階主管、客戶找出於此系統相關的人員，像是使用者、系統管理者、MIS、客戶等等...(感謝gipi大提供)
，以便於日後跟相關人員討論開發事宜，如問題，解決方案等。
圖:相關人員
定義願景(Vision):我們解決是同一個問題嗎?
系統開發的主要目標，通常可以從關鍵問題來找願景，不同的相關人員角色可能會有不同的願景，
使用者的願景為方便操作，而客戶代表的願景可能為縮短時程，老闆願景為Cost down等。
圖:願景圖
定義企業需求:我們解決的是對的問題嗎?
透過與相關人員討論及問題誘導，可得到系統開發的主要需求，用來定義系統開發範圍，
也可用此來初估成本與時程，簡而言之，定義系統需求就是記錄系統該做的事。
可透過定義企業需求來轉化出系統特性(System Feature)，系統特性定義是「由系統提供能滿足相關人員需要的服務」，如 [系統] 能 [產生雛型]。
圖:企業需求UC圖
圖:願景與需求對應
分析企業流程
定義企業需求後，再針對每一個企業需求，分析其工作流程，並產出活動圖(Activity Diagram)，並以此流程與相關人員達成共識。
建立Requirement Model時可透過產出之企業流程，從中得到數個使用案例(Use Cases)與參與者(Actors)
圖:企業流程圖(Activity Diagram)
UI規格(Prototype)
透過UI規格描述以及使用者介面原型，可於初期時，較具體的向相關人員解釋需求與流程間的關係，
以便釐清需求(有時也可能就技術問題做研究實驗)，由UI規格與企業流程的搭配可以導出客戶確切的
需求。
圖:UI描述
定義領域模型
定義系統的詞彙與概念，並描述各實體間的關係，領域模型可提供日後系統設計的類別圖發展。
總結:
以上只是我一些系統分析上的小心得，範例圖片跟文字敘述不甚完備，還望見諒，並請大家不吝給予實務上的指導。