和Use case相比，產品經理更喜歡用界面原型來表達用戶和產品的交互，也難怪，想想最早的Use case概念是：Ivar Jacobson在1967年定義愛立信AXE系統的構架時開始提出的，畢竟那時的人機交互還是非常生澀難懂的，時隔半個世紀了，現在的設計理念更提倡簡單，直觀，所見即所得的模式。
架構師和開發工程師會喜歡用Use case嗎？答案是：不，他們更喜歡用序列圖，活動圖，狀態圖等更細節和系統化，參數化的設計方式，來表達系統狀態，數據變遷和行為，而用類圖表達信息的靜態結構。
測試工程師會用嗎？也不會，她們直接根據功能設計和界面原型編寫測試用例，測試用例（Test case）不同於Use case，測試用例更加系統化，更強調嚴謹的輸入，輸出定義。
那誰會用Use case呢？ 呵呵，經過上面的分析，妳肯定覺得Use case就是雞肋啊，完全可以廢棄掉了。妳先別忙，我還沒有講完，這並不是上面這些角色的錯，也不是Use case完全無用，只是我們經常把Use case用錯了地方， 其實Use case是業務分析過程而不是設計過程，準確來說Use case是銜接業務分析和系統設計的承上啟下的過程。
在軟件工程中我們通常把軟件的研發過程大體分為：分析，設計，開發和測試四個階段，而在目前以電商經濟作為主導的互聯網產品研發體系中，對於軟件的分析過程我們的確很容易忽略，這裏不是說電商系統不用分析，而是由於這個行業同質化的產品太多，借鑒和抄襲的效率更高，那誰還願意認真分析業務本質呢？
Use case被忽略的另壹個原因是對敏捷開發的壹些誤解，敏捷開發提倡的是快速交付，用客戶檢驗設計優劣，用市場檢驗產品成敗。這就容易讓我們誤解為軟件或者所服務行業的業務分析就不需要了，其實分析-設計-開發-測試的過程就像語言中的主謂賓結構壹樣，無論妳用什麽樣的語速或者花哨的修辭手法，基本結構是不會變的。
敏捷的研發體系其實是壹改過去傳統的整體系統全部分析完成結束後，再進入設計和開發階段的方式為：單壹業務過程場景分析到設計到開發到測試的方式。而至於單壹業務過程場景的劃分粒度，可以參考我之前的文章： 《初建電商優先關註的7個流程（壹）》 。
如果大家認同以上觀點，我們繼續聊聊Use case到底有什麽用和怎麽用？本文並不是講解如何繪制UML的Use case圖，因為網絡上有太多這方面免費的介紹，妳連書都可以不用買，就能理解。我們重點聊的是怎麽使用Use case才能讓它的功能發揮出來。
前面我講到Use case是銜接業務分析和系統設計的承上啟下的過程，目前在軟件工程中對Use case常用的定義是：Use case是壹種在開發新系統或者軟件改造時捕獲潛在需求的技術。其實仔細理解定義，妳就能明白“捕獲潛在需求”其實就是壹種系統的分析過程。Use case最適合使用在對抽象業務過程活動開展進壹步分解的過程。
下來我們將通過Use case和業務過程（Business process），界面原型和系統設計的相關關系討論來認清Use case定位和作用。
壹. Use case和業務過程分析的關系：
要講Use case就首先要講講什麽是業務過程（Business process），因為他們是相輔相成的，Business process?在維基百科中的定義中是：壹組相關的、結構化的活動或任務，它們為特定的客戶或客戶群體，提供特定的服務或產品(為特定的目標服務)。這裏用Business process而不是用Business Flowing，是想和workFlow 區分開，WorkFlow是更系統化，更嚴謹，更技術化的活動描述。而Business process則和系統和技術無關，有些時候純粹描述人工業務過程，這是真正描述業務需求的壹種方式。 而業務過程分析和Use case分析各有側重點，業務過程是采用流程化的方式表達業務發展的連續性和方向性；而Use case則重點對單個業務活動，開展面向對象的解構分析。
例如：我在 《初建電商優先關註的7個流程（壹）》 中說到的：?Request-to-answer（請求到響應）過程中所繪制的：
Request-to-answer過程是壹種業務過程，他是企業運營體系中若幹業務過程中的壹種，因為他滿足了從客戶發起到滿足客戶為終止end2end的原則，所以我們可以可以單獨分析該過程，這也符合敏捷理論的快速響應，閉環分析，最小價值開發理念。
Use case的作用是以人機交互和用戶為中心的方式通過分析業務過程中的這些業務活動實體場景（比如：上圖中的咨詢，判斷銷售前景，匹配產品，提供銷售建議書等），獲取該活動詳細的功能性需求。對， Use case是形成功能性需求的關鍵 ，所以是需求分析/系統分析工具，所以如果妳已經先有了系統功能，再做Use case 分析妳就會發現Use case完全是多余的， 這裏再次重申Use case不是設計工具，而是業務分析工具。
為了證明此觀點我們可以看看，UML 圖例的主要結構：
從上圖中我們可以看到Use case 是由Actor，case，relation，system/module構成，而這中間的關系又主要分為：包含，泛化，使用，擴展。怎麽樣？看到這些圖例是不是覺得：這不就是用面向對象的系統思維方式來分析和解釋業務活動嘛！對，當我們在處理陌生需求或者業務活動時，要將純粹的業務需求和過程轉化為面向對象思維的系統需求，就需要作Use case分析。這時是沒有具體功能，沒有類模型，沒有數據模型，最多只有大致的系統或者模塊。
二.? Use case和界面原型的關系
在做Use case分析的時候，也許妳已經有界面原型（因為當下的設計潮流是提倡界面原型和需求分析同步的，界面原型同時也是客戶需求確認的工具），但妳絕對不要在Use case中去表現界面需求或者用界面需求反推導出Use case，因為Use case的分析重點是分析業務過程的發生的本質（采用5W1H分析），有些可能有界面，有些則可能沒有，有些是抽象實體，有些是實例實體。而界面原型的重點是用顯性，可視化的表達手段，把業務過程分析的結果表現出來。?
例如上圖中的：用戶登錄，泛化出了昵稱登錄和手機號登錄兩個case（實體），而在界面設計中也許是壹個界面（通用登錄界面），也許是兩個界面（交互設計師會有壹大堆理由告訴妳那種設計更好，但壹般沒有壹種是按照用戶 業務可能性驅動 分析的，因為交互設計師不喜歡研究業務過程，哈哈！交互設計師不要打我哈！）。如果我們用界面設計來反推導Use case，就非常容易限制我們業務發展的可能性，上面的例子中，按照業務過程的抽象和泛化的分析結果，妳完全還可以得出用掃碼登錄方式的case。所以Use case和界面原型是相互驗證的關系，而不是相互替換。 而Use case的另外壹個作用就是分析業務可能性。
三. Use case和系統設計的關系
這裏講的系統設計涵蓋了UML常見過程如：模塊設計，類設計，時序設計，系統活動設計，以及領域驅動設計中的信息模型設計。Use case 分析除了能產生功能型需求和提供業務可能性分析外， 它還能為後續的系統設計提供了結構化設計和行為設計的壹手素材 ，因為整個分析過程采用了系統化的面向對象的分析方法。
所以說Use case提供了用系統化語言翻譯客戶需求的能力，編寫或者繪制Use case的人壹定是業務分析能力和系統思維能力的結合體。Use case是銜接業務過程分析和系統設計的關鍵環節，Use case的好壞直接關系業務的可能性，是否能在系統功能上體現。
要作好Use case就要求產品經理要有足夠的系統化思維，架構師要有足夠的業務過程分析思維，但這卻是目前互聯網研發體系中比較弱的壹環。在有些大型IT企業中，其實還有壹類介於產品經理和架構師的角色：系統分析師或者業務架構師，只是因為由於目前產品經理角色在行業內興起，大有逐漸代替了他們的趨勢，但他們的實際工作內容卻容易被遺忘，所以如果妳的企業看中業務分析的能力，要不就要求產品經理具備有系統化分析思維，架構師具備業務過程分析思維，要不就請設置系統分析師和業務架構師的角色，只有這樣才能真正將行業內的業務需求挖掘，轉換和擴展延伸為優質的產品。
確定Use case 的分析粒度，其實是整個分析過程中最麻煩的部分，也是最容易被大家忽略的地方，被忽略的結果就是我們選擇的Use case既沒有代表性，也沒有承接性（承接業務過程分析），更沒有全面性，而壹旦Use case沒有辦法提供詳細，完整的功能性需求和系統設計需要的結構和行為分析，Use case就變成了壹份如同雞肋般的形式化文檔。
壹. 首先，需要確定Use case 表達的粒度：
Use case 是銜接業務分析和系統設計的承上啟下的過程，所以它壹定不是靠經驗，孤立設置或者直接拍腦袋定義出來的，它必須遵循業務分析的延續性，從業務過程分析到Use case的分析就是這是這種延續性，而Use case的粒度定義可以設置在業務過程中的業務活動上。 註意：設定Use case的基點就必須是業務過程中的活動而非界面結構。
以 《初建電商優先關註的7個流程（壹）》 的Order-to-confirmation（訂購到確認）為例，我們要建立Use case的分析粒度要從業務過程中的業務活動開始，也就是說我們需要對：發布訂單，費用計算，拆解訂單，交付產品，評估和跟蹤，確認完成等這些活動，分別建立Use case描述。
這邊特別要指明，Order-to-confirmation（訂購到確認)只是抽象業務過程，由於行業的差異性和復雜程度不同，壹個業務活動可能會繼續拆解成更多業務活動，比如：“拆解訂單”，就會分為“分解產品訂單，分解服務訂單和分解資源訂單”等三個。請註意這裏的業務活動不是指系統的具體操作步驟，所以千萬不要把業務活動的最後分解為：增加，刪除，修改，插入，查詢等這些具體系統操作上，因為這些操作是建立在系統實現上的，而非業務分析的基礎上。
把Use case建立在業務活動上的原因也正是看重業務活動無系統限制，無技術約束。業務活動壹定是展現壹種業務發展的可能性，而不是具體系統實現，Use case的粒度也是如此。
二. 其次，有了Use case 的粒度，我們怎麽來生成Use case呢？我介紹壹個生成Use case的方法。
我們要為每個Use case提供壹個腳本描述，描述要簡潔意駭，而且基本語句結構要符合語句為：時間，地點，誰，做了什麽，怎麽做，為什麽做的5W1H模式，而最終影響Use case 的變量需要系統分析師、業務架構師或者產品經理根據業務特征決定。
我們以Order-to-confirmation（訂購到確認）中的“發布訂單”的業務活動為例，建立了如下Use case分析模型如下：
這是壹個最簡單也最有效的Use case生成工具，首先，由業務架構師定義和選擇，可以影響該業務活動的 業務可能性 的維度，妳可以參考5W1H方式，圖中所提到的“時間區間”，“客戶類型”，“渠道類型”，“訂購方式”，“產品類型”和“觸發條件”，只是我舉例的維度，妳可以根據自己行業的業務特征，定義自己的維度。定義維度的要點是尋找Case的差異性，如果無差異維度，可以直接丟棄掉，如：上午和下午對於發布訂單的活動並無差異性，就忽略掉。其次，需要填充相關維度參數，也許是某種類型或者具體的實例。最後將這些維度參數做笛卡爾積運算，就能得出最直接的Case。
我們大多生成Use case的時候，都缺少方法，用經驗也罷，看界面原型也罷，以至於拍腦袋等方式都很難保證不遺漏我們分析的 業務可能性， 所以我建議妳采用以上方法試試。當然妳看到有432條Case的時候肯定要瘋了，什麽，這麽多？其實這432條Case只是 業務可能性 的Case，妳可以根據自己行業的業務特征，用排除法很容易的就能排除掉不可能的，無效的，無差異的Use case，實際使用的Case，就能控制在2位數以內。
也許保留下來的就是：“晚上新客戶，接受了平臺推薦的商品，在線上自有渠道采用商品比較分析的方式訂購了家電產品” 等，這就是Use case的腳本。而基於這個腳本妳就可以接下來繪制Use case 圖例了，而從中分析出業務的功能性需求，結構模型和行為模型的初稿和業務可能性。這裏就不再講述Use case UML圖例繪制的過程，您可以參考UML 的Use case文稿。
三. 最後，我要再澄清壹個業界關於Use case的概念爭議
對於Use case 業內有兩種不同看法，壹種認為Use case是抽象視圖，往往不用帶上具體的業務參數。另外壹種認為Use case就是實例，是被參數化的視圖。這兩種說法都各有道理，前提是有沒有把業務過程分析納入和Use case的關聯分析中，我們知道業務過程分析本身就是壹種抽象分析，業務過程本身也有抽象過程和實例化過程之分，抽象過程用於系統分析，實例化過程用於系統工作流設計，而Use case承接的抽象化過程，所以對抽象化的業務活動進行實例化分析就是有必要的。而這個實例化其實也不是最終的系統實例化，因為在Use case創建過程中需要選擇有差異化的Case，從而進行業務差異化分析，所以我們可以認為Use case的case實例化是有限度的實例化。
本文並沒有去重點闡述具體UML 的Use case繪制方法，因為妳去百度壹下，既能得到很多相關方法，我把重點放到了Use case到底有用無用和Use case如何生成的討論上，我14年的系統設計，開發經驗告訴我，很多的工具和方法如果不關聯使用，不去了解它存在的意義和實際業務目的，那我們往往做出來的是形式化設計，對產品和系統不會有太多幫助。
Use case就有這樣的問題，首先我們要搞清楚它是分析過程，不是設計過程，它是對業務過程分析到系統設計的承上啟下的過程，如果不搞清楚這個問題，Use case可能對產品研發各角色來說都是雞肋。
其次，我們要知道Use case到底能為我們提供什麽？ 它可以幫助我們 分析功能性需求 和 業務可能性， 這是我覺得最為重要的部分，也就是說如果我們已經有了功能性需求或者限制了業務可能性的分析，那妳再做Use case都會覺得完全是多余的。
再有，我強調了Use case的粒度選擇壹定要放到業務過程分析中的業務活動中，這樣的分析過程才具備設計的連貫性和最小代價的完整性，這也符合敏捷設計的理念。
最後，我提供壹套生成Use case的方法，可以幫助妳快速生成有限實例化的Case，我們可以通過差異化的case分析， 生成功能性需求和業務可能性 ，並且為後面的系統結構化設計和行為設計提供必要的設計參考。
好了今天就到這裏了，年前希望能再寫壹篇文章，題目待定。祝：各位新春快樂！