做一個產品容易，但做一個好的產品非常難。對於一般的從互聯網行業轉行而來的產品經理和業務分析人員來說，敏捷開發是常用的方法。但在做企業管理系統等ToB產品時，涉及到非常複雜的業務場景。如果沿用原來那一套業務流程圖、功能流程圖、頁面流程圖、數據流程圖，則總是會出現一些邏輯漏洞，或者說沒有一條主線邏輯告訴你，業務是怎樣一步一步的轉化成功能和頁面的，如何一步步轉化成系統交互和類的。而UML或者統一過程就是這樣一個工具，更多的是一種思維方式，清晰的告訴大家如何進行業務分析，如何自然而然的將業務轉變成功能和頁面而不出現遺漏。故結合我這幾年學習的理論和實踐經驗，將一般的過程介紹給大家，一塊討論學習。由於完全半路出家，都是靠自己學習、領悟和實踐，有偏差和錯誤的地方，請專家指出。
0.前言
0.1 優點和必要性
1、UML統一了各種方法對不同類型的系統、不同開發階段以及不同內部概念的不同觀點，從而有效的消除了各種建模語言之間不必要的差異。
2、UML建模能力比其它面向對象建模方法更強。它不僅適合於一般系統的開發，而且對並行、分佈式系統的建模尤爲適宜。
3、UML使硬件組件和軟件組件之間將會有更大的透明度。便攜性和綜合效率將會增加。
1 對於開發團隊的層面來說：有利於隊員間在各個開發環節間確立溝通的標準，便於系統文檔的制定
和項目的管理。
因爲UML的簡單、直觀和標準性，在一個團隊中用UML來交流比用文字說明的文檔要好得多。
2 對與各個開發項目來說：可以通過UML共享開發經驗和資源
3 uml只是面象對象分析、設計思想的體現，和具體的實現平臺無關，用UML建模和設計的系統可以用JAVA或C#來
實現。
4 這點對我們最有用啦：可以做爲系統分析設計過程使用的表示和體現工具。
5 對於公司的運營層面：UML已經是世界標準，使用UML方便公司的國際化。
好處：幫助開發團隊以一種可視化的方式理解系統的功能需求。
1，UML統一了各種方法對不同類型的系統、不同開發階段以及不同內部概念的不同觀點，從而有效的消除了各種建模語言之間不必要的差異。
2，UML建模能力比其它面向對象建模方法更強。它不僅適合於一般系統的開發，而且對並行、分佈式系統的建模尤爲適宜。
1. UML概念和元素
按照業務分析的順序，逐一介紹分析過程中經常用到的概念。
業務目標
業務目標就是客戶對要建設的系統的期望。業務目標清楚後，可以從業務目標角度去定義業務邊界。如，1.1.根據銷售訂單，創建成品和半成品的生產訂單—是一個客戶期望的業務目標。
業務邊界
明確了目標後，要確定業務邊界。業務邊界決定了參與者和用例。在定義業務邊界過程中，需要從需求出發。但是在明確需求的時候，邊界通常應該是確定的。兩者之間存在矛盾。因此，邊界確定是一個在需求調研過程中不斷調整的活動。
舉個例子來說，我們在做生產管理系統的時候，爲了滿足“1.1.根據銷售訂單，創建成品和半成品的生產訂單”的業務目的，究竟是否要包含產品計劃拆分成零部件計劃呢？如果劃分到生產管理系統中，則參與者就多了一個，該參與者作爲主角就會帶來計劃拆分的用例，進而擴大了系統的邊界。因此，在做前期規劃時，需要先假設該場景在生產管理系統內。在調研過程中，發現客戶已經上了ERP系統，實現了該場景，則我們會將計劃拆分場景移出生產管理系統邊界，縮小系統邊界。
用例
一般分爲業務用例、概念用例和系統用例。用例就是一件事情，要完成這件事，需要做的一系列活動；用例就是在確定了業務邊界後，以業務主角的角度發現的所有功能性需求的彙總。
用例視圖
業務用例視圖包括業務主角和業務用例，它是業務的高層和概要視圖，並作爲其他建模要素的組織點存在。業務用例的顆粒度，實現某一個業務目標爲一個業務用例；
用例場景
業務用例場景用來描述該業務用例在該業務的實際過程，說明業務主角是如何執行完成業務目標的。業務用例場景一般使用活動圖或泳道圖來表示。用活動圖來描述業務用例場景，必須將參與者和業務工人作爲活動圖的泳道，將參與者和業務工人所完成的工作作爲活動。依據實際業務流程中的執行順序將這些活動連接起來，形成業務場景。
1. 在描述業務用例場景時不能帶有“設計”的思想，必須是真實業務的體現。
2.不要繪製充滿分支，巨大的活動圖。
用例實現
將業務用例實現關係連接到業務用例，每個業務用例實現代表了業務用例目標的一種實現方式。
用例實現場景
業務用例實現場景針對每個業務用例實現，說明該實現方式的步驟，即如何實現的，重點在於清晰描述用戶和計算機系統的交互和操作。與業務用例場景類似，但更爲明確。我們可以用頁面流程圖替換。業務用例實現場景是製作系統原型的基礎。
業務用例規約
業務用例規約針對每個業務用例編寫，它要說明業務用例的使用者、目標、場景、相關業務規則和業務實體等。
業務規則
業務規則是客戶執行業務必須遵守的法律法規、慣例、各種規定，也可能是客戶的操作規範、約束機制。業務規則可能影響軟件外觀、內部功能甚至架構。我們用到的必有的規則爲對象交互規則和對象內置規則。交互規則可以標註在頁面裏；對象內置規則在對象描述裏。
業務對象模型
描述業務模型中關鍵的業務對象，以及他們是如何貢獻於業務目標的。一般用例場景或用例實現場景採用動詞+名詞描述。業務對象就是名詞裏面篩選出來的，與系統實現有關的東西。對於跨多個領域的對象，在每個用例場景分析完成後，將每個場景的表達相同意思的對象合併，就可以構成一個複雜的對象。在進行系統設計時，開發人員會用來參考進行數據庫和系統對象設計。
包圖
包圖組織業務用例。可以按業務模塊分包，也可以按業務主角分包，還可以按照組織結構分包。分包策略取決於具體環境更注重哪方面。
-
活動圖和泳道圖一致
-
時序圖，重在消息傳遞順序，用於描述消息傳遞等邏輯
-
協作圖，描述關係
-
領域 ，對於跨多個領域的對象，在每個用例場景完成後，進行組合彙總，形成業務對象
-
用語儘量和客戶需求保持一致
-
交互規則，對象內部規則就是對象說明
-
非功能性需求:
2. 和系統設計的關聯
分析模型
在完成業務用例的基礎上，可以對複雜或核心的用例場景創建分析模型，考慮到軟件架構，使用時序圖進一步描述核心用例場景的底層邏輯。分析模型完成後，也就能出來頁面原型了。
系統用例
系統用例是業務用例通過映射、抽象、合併、拆分和演繹等創造出來的。系統用例也和業務用例分析過程一致：從業務用例映射成系統用例，通過活動圖和時序圖描述用例場景。此時，就可以得到類圖，其中的一些活動轉變爲某些類的內部方法，一些活動轉化爲接口。不同的類通過抽象形成數據庫表。
對於業務人員來說，得到用例圖描述用例，活動圖或泳道圖描述業務實現場景，對象模型描述對象屬性和規則，分析模型描述頁面功能和系統內部運轉邏輯，並據此推斷出頁面上的功能交互規則和底層的對象交互規則，避免了功能丟失。
出來了分析模型，也就出來了頁面，對象，業務規則和邏輯
下一篇以具體例子來介紹整個業務分析的流程和方法。