起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識我們如何正確使用Use Case？
Use case 到底有什么用？又該如何正確使用呢？通過本文一起來了解下。
Use case, 作為UML重要的組成部分和類圖，時序圖，狀態圖，活動圖等一同經常出現在各類產品設計和開發文檔中，但Use case圖卻在實際運用UML圖例化表達中，顯得比較尷尬。不知你有沒有這種感覺，我們的設計文檔對于Use case的要求往往只是形式化存在，不是寥寥草草畫幾個收場，就是根本不畫。那Use case 真的就無用了嗎？
哪些人會用Use case？
和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 到底有什么用？
在軟件工程中我們通常把軟件的研發過程大體分為：分析，設計，開發和測試四個階段，而在目前以電商經濟作為主導的互聯網產品研發體系中，對于軟件的分析過程我們的確很容易忽略，這里不是說電商系統不用分析，而是由于這個行業同質化的產品太多，借鑒和抄襲的效率更高，那誰還愿意認真分析業務本質呢？
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
Request-to-answer過程是一種業務過程，他是企業運營體系中若干業務過程中的一種，因為他滿足了從客戶發起到滿足客戶為終止end2end的原則，所以我們可以可以單獨分析該過程，這也符合敏捷理論的快速響應，閉環分析，最小價值開發理念。
Use case的作用是以人機交互和用戶為中心的方式通過分析業務過程中的這些業務活動實體場景（比如：上圖中的咨詢，判斷銷售前景，匹配產品，提供銷售建議書等），獲取該活動詳細的功能性需求。對，Use case是形成功能性需求的關鍵，所以是需求分析/系統分析工具，所以如果你已經先有了系統功能，再做Use case 分析你就會發現Use case完全是多余的，這里再次重申Use case不是設計工具，而是業務分析工具。
為了證明此觀點我們可以看看，UML 圖例的主要結構：
Use case主要結構
從上圖中我們可以看到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的粒度定義可以設置在業務過程中的業務活動上。注意：設定Use case的基點就必須是業務過程中的活動而非界面結構。
Order-to-confirmation（訂購到確認）
以《初建電商需優先關注的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分析模型
這是一個最簡單也最有效的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分析，生成功能性需求和業務可能性，并且為后面的系統結構化設計和行為設計提供必要的設計參考。
好了今天就到這里了，年前希望能再寫一篇文章，題目待定。祝：各位新春快樂！
本文由 @烏士兒 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自PEXELS，基于CC0協議
Use Case 觀后感，希望能得到作者的反饋。
使用前提：功能在未開發前，在有產品設想后。
功能描述：重點對單個業務，開展面對對象對解構分析，分析業務可能性和形成功能性需求，是業務分析和系統設計承上啟下對過程。
顆粒度：針對業務的流程，而非具體的系統操作。
生成Use Case方法：5W1H
百度百科搬運工，use case：在軟件工程中，用例是一種在開發新系統或者軟件改造時捕獲潛在需求的技術。每個用例提供了一個或多個場景，該場景揭示了活動是如何同最終用戶或其它系統交互的，從而獲得一個明確的業務目標。用例要避免技術術語，取而代之的是最終用戶或者領域專家的語言。用例一般是由軟件開發者和最終用戶共同創作的。