之前寫《做產(chǎn)品為什么要畫這些圖？》，介紹產(chǎn)品常用視圖后，一直想深入介紹每一種圖的用法，卻生怕理解不到位，又不想當文字搬運工，遲遲不敢開寫。

這次趁著打磨課程，逼自己猛啃幾本書，結(jié)合這幾年做產(chǎn)品的經(jīng)歷，總算提煉出自己的思路。

我首先要講的是用例圖，用例是 UML 中最重要的一個元素，后續(xù)分析流程、設計功能，都是圍繞它展開的。

本文先介紹為什么要畫用例圖，再為你解讀用例圖知識，最后用一個案例演示如何畫用例圖。

文章有點長，不過相信你看完，對如何做需求分析會有新的認識。

一、用例圖有啥了不起

做產(chǎn)品前幾年，我很少畫用例圖，直到做數(shù)據(jù)中臺，碰到的需求更復雜，我重翻《大象：Thinking in UML》找靈感。

讀到用例時，我恍然大悟，原來我放著用例這么好的法寶不用，簡直暴殄天物。

后來，我從業(yè)務調(diào)研開始，用用例的分析方法，把業(yè)務研究透、描述出來，系統(tǒng)該做成怎樣，腦海里漸漸清晰。

當然，并非每個需求都得畫用例圖，簡單的需求完全可以不用牛刀。

1、用戶視角

用例的設計之初，是希望我們別老在系統(tǒng)內(nèi)執(zhí)著功能，而是跳到系統(tǒng)外，以用戶的眼光看系統(tǒng)，思考什么情況下給什么人提供什么支持。

如果我們學會了用例圖的分析思想，理解它的表達邏輯，至少能試著站在用戶的角度去看問題。

?????開啟這種視角，才不會總用晦澀難懂的術語，將用戶搞暈，才能用業(yè)務方的語言去溝通，真正以用戶為中心去獲取需求，轉(zhuǎn)化為產(chǎn)品服務。

練習的辦法，便是按用例的規(guī)則和方法，一點點做， 逐漸轉(zhuǎn)變思考的方式。

2、場景化思維

用例的另一個特點是，關注用戶在什么情況下做什么事，這是典型的場景化思維。

這讓我想起，以前給老媽換手機，要教會她使用，可讓我頭疼了。

每次跟她說，這是查號碼，這是打電話，這是聽歌，這是看視頻等等，她都記不住。我一度以為人年紀大了，記憶力不好，很難接受新東西。

后來，我反思自己，改變策略，只給她講，她用手機會做的幾件事情。

打電話，我只告訴她第一步按哪，第二步按哪，每一步有什么標記符號，再把常撥號碼，設置成快捷鍵，每次只需一步操作。

結(jié)果，她居然記住了。

發(fā)現(xiàn)沒？功能描述容易脫離用戶使用場景，讓人困惑。

所以，我們要從場景出發(fā)，圍繞用戶在具體情況下，要做的事情，告訴他怎么做就好了。

3、系統(tǒng)思維

每個講產(chǎn)品經(jīng)理的思維方式，都會講系統(tǒng)思維。可，真能用系統(tǒng)思維去思考的人，可謂鳳毛麟角。

究竟什么是系統(tǒng)思維呢？

系統(tǒng)思維，即思考問題時，要全面考慮系統(tǒng)內(nèi)事物之間的互相影響，關注整體的運行規(guī)律，而不是只考慮個別事物的情況。

做產(chǎn)品時，如果只討論功能，就是孤立的看待產(chǎn)品。

產(chǎn)品脫離了使用者，就沒有意義。只有當我們把產(chǎn)品和使用者都考慮進去，才算是系統(tǒng)的思考。

用例的本質(zhì)，就是將產(chǎn)品和使用者當成一個系統(tǒng)來看。

下面一起看看用例為何物吧。

二、解讀用例圖

1、何為用例

用例，是 UML 中用來捕獲功能性需求的一種方法，它從不同視角，描述不同角色用系統(tǒng)/產(chǎn)品做什么事，即什么人做什么事。

一個用例，就是參與者為完成某個特定目標的一系列活動或功能的集合。

換句話說，用例是參與者為滿足自己的期望，而完成的事情。

所以說，用例不是功能，而是由參與者驅(qū)動的，是有明確目標的，是從用戶視角看問題的。

比如，人喝水，大致要做拿杯子、倒水、喝這幾個動作，人喝水是用例，拿杯子卻不是，因為不會有人沒有目的只拿杯子。

2、用例圖的構(gòu)成

用例圖，由參與者、用例、邊界和關系構(gòu)成。

1）參與者，用小人表示

按官方文檔的定義，參與者是在系統(tǒng)外部與系統(tǒng)交互的人或事物，可以是人、部門或系統(tǒng)。

產(chǎn)品面向的用戶，也是在系統(tǒng)之外的參與者。

有時，系統(tǒng)內(nèi)部也有一些人或?qū)ο?，參與完成業(yè)務，這種稱之為業(yè)務工人，并非參與者，需區(qū)分清楚。

2）用例，用橢圓表示

用例，表示參與者為完成某個目標的一系列活動。用例名稱，以動賓短語出現(xiàn)，表示參與者做的事情。

用例是業(yè)務分析、需求分析、系統(tǒng)分析與設計過程的基本單位，粒度可大可小。

粒度的確定，一直是個難題，沒有標準，只能根據(jù)實際情況分析。一個大型系統(tǒng)，可能會有上百個用例，一個小產(chǎn)品，也許只有幾個用例。

這有 2 個經(jīng)驗供你參考：

一是完整性，一個用例是一個完整的使用場景，不是零散的動作步驟。比如，拿起手機刷微信是個完整的場景，拿起手機只是一個步驟。

二是獨立性，一個用例有一個明確、獨立的目標，如果一個用例包括多個目標，則可再逐層細化出子用例。 

3）邊界，用矩形表示

邊界將系統(tǒng)內(nèi)外分開，參與者在外面，用例在里面。邊界內(nèi)的用例，就是系統(tǒng)要實現(xiàn)的事情。

一個系統(tǒng)的好壞，常取決于邊界是否清晰，即明確做什么，不做什么。邊界內(nèi)的事，是系統(tǒng)的任務；如沒有特定條件推動，系統(tǒng)與外界沒有聯(lián)系。

設計產(chǎn)品時，一出現(xiàn)自相矛盾、疑惑的問題，往往可能是不知不覺偏離了最初的定位，跑到邊界外部。

因此，做產(chǎn)品要多回歸定位，檢查產(chǎn)品有沒有越界。一個好的產(chǎn)品，是界限分明的，做什么不做什么從不含糊。

4）關系，用常見的箭頭連線

UML 中關系挺多的，常用的有關聯(lián)、包含、擴展、實現(xiàn)四種。

關聯(lián)關系，一般由參與者指向用例，意味著參與者發(fā)起用例。當然，也有少數(shù)情況，是用例指向參與者，如推送消息，是系統(tǒng)自動觸發(fā)用戶。

包含關系，指一個用例包含了子用例，由父用例指向子用例。請注意，父用例并不等于所有子用例之和，它的范圍可以大于所有子用例。子用例是一定會執(zhí)行的。

擴展關系，指一個用例在某種情況下需要完成特定活動，由擴展用例指向被擴展用例。與包含關系不同，擴展是特殊分支，在特定情況下才出現(xiàn)的支流，如電商的訂單退款。

實現(xiàn)關系，連接用例與用例實現(xiàn)，表示一個用例可以有哪幾種實現(xiàn)方式。

5）用例表，圖形之外的文字補充

除了畫圖，UML 中用例圖還會寫用例表，以描述說明用例，內(nèi)容包括用例名稱、用例描述、參與者、前后置條件、基本流程等。

3、用例圖的類型

在 UML 中，用例圖的常見類型，有業(yè)務用例圖和系統(tǒng)用例圖。

1）業(yè)務用例圖

業(yè)務用例圖，是從業(yè)務的視角，對業(yè)務進行描述。即描述沒有新系統(tǒng)或產(chǎn)品前，業(yè)務是如何進行的。

UML 使用業(yè)務用例圖，旨在把業(yè)務描述清楚，發(fā)現(xiàn)業(yè)務問題和目標，新系統(tǒng)才能更好的解決問題，實現(xiàn)業(yè)務目標。

簡單需求，很少畫業(yè)務用例圖；復雜需求，用這個思路分析，更好發(fā)現(xiàn)業(yè)務問題，保證產(chǎn)品需求不跑偏。

2）系統(tǒng)用例圖

一般說用例圖，默認指系統(tǒng)用例圖，它描述參與者使用新系統(tǒng)或產(chǎn)品做什么事，從而實現(xiàn)業(yè)務目標。

它是從業(yè)務用例分析推導出來的，是新系統(tǒng)的藍圖、開發(fā)范圍。

從業(yè)務用例如何分析、推導出系統(tǒng)用例呢？下面的案例馬上講到。

三、如何畫用例圖

畫圖是為了表達、傳遞信息，當我們畫用例圖時，本質(zhì)是在分析業(yè)務場景、系統(tǒng)功能性需求，并描述出來。

因此，與其說學如何畫用例圖，不如說是在學如何分析，用例圖只是分析的結(jié)果。

下面，我將通過用一個簡單的案例，把這個分析過程，一步步展示出來。

以手機話費充值業(yè)務為例，假設我們接到一個需求，要開發(fā)一個話費充值 APP ，為用戶提供充值服務。

常規(guī)做法，接到需求，會想到去調(diào)研業(yè)務、研究競品，列出功能結(jié)構(gòu)圖，再畫流程圖，很快就能畫原型，寫 PRD 。

對于簡單的產(chǎn)品，這么做沒問題。但碰到復雜的系統(tǒng)，就得有一套好的分析思路和方法工具。

用例圖，可以幫我們從業(yè)務場景分析入手，理清業(yè)務，逐步推導出系統(tǒng)功能。

具體怎么做呢？我總結(jié)了這 3 步：

1、分析業(yè)務場景，找出人、事、物、目標

如今，我們早已離不開手機，為了能上網(wǎng)、打電話，要用手機就得有話費。

這個業(yè)務的“人”比較好找，就是普通手機用戶。目標，是為了保證手機可用，得充話費。

充話費，我們可以去微信充值、也可以去支付寶，或用運營商的 APP 。

由此，得出充值話費的幾種實現(xiàn)方式，而我們要做一個充值 APP ，便是實現(xiàn)方式之一。

△ 充值話費業(yè)務用例實現(xiàn)

2、分析業(yè)務流程，細化目標，得出業(yè)務用例圖

明確業(yè)務用例的實現(xiàn)方式，我們挑典型的微信充值來研究，以便了解業(yè)務。拿出手機，打開微信手機充值，體驗一番，把整個流程理出來。

△ 微信手機充值過程

當我們從用戶的視角，繪制出微信充值的流程后，不難發(fā)現(xiàn)這個過程中，大致可分為兩個階段：

一個是充值，這個過程不能中斷，一斷充值就不成功，所以，可以得到一個小目標：充值話費。

一個是查結(jié)果，支付完成后，不一定馬上有結(jié)果，但基本都會成功，這時用戶可選擇離開；還有一種場景，發(fā)現(xiàn)話費快用完了，查什么時候充值的。可見，查看結(jié)果目標也相對獨立。

△ 用戶視角下的微信手機充值活動圖

有上面的分析，我們可以把兩個有完整目標的活動集合，歸納為兩個業(yè)務用例：充值話費、查看結(jié)果。

再把視角縮到充值過程，充值得支付金額，而支付一般是通用的，供其他模塊使用，在系統(tǒng)內(nèi)部看相對獨立，可抽出來，作為子用例。

當查看結(jié)果時，發(fā)現(xiàn)話費并未到賬，需要聯(lián)系客服處理，雖然這不多見，但偶有發(fā)生，所以是一個特殊情況下才會發(fā)生的支流，可作為擴展用例。

△ 微信手機充值業(yè)務用例圖

3、由業(yè)務用例推導出系統(tǒng)用例

經(jīng)過從場景到流程的分析，業(yè)務用例基本清楚。就到最關鍵的一步，推導出系統(tǒng)用例。

常用的推導方法有：映射、抽象、拆分、合并和補充等。

1）映射，指一種特殊的對應關系，可直接對應過去。比如，微信充值有“充值話費”用例，與我們要做的 APP ，目標一致，可直接映射。

這容易被誤以為是抄襲。實際上，如今大部分產(chǎn)品功能都類似，很少有完全創(chuàng)新的東西。如能從用例去分析，就知道為什么這個功能要“抄”，哪個不“抄”，“抄”了要不要改，改哪些。

2）抽象，是找共性，把有相同特征的歸納成一類。比方說，在微信充值中查看結(jié)果，但做個新 APP? ，得考慮更多操作，這些屬于訂單的范疇，可歸納為“管理訂單”用例。

3）拆分、合并，把一些大的用例進行拆解，或小的用例進行合并，合并類似抽象歸納。

4）補充，根據(jù)實際情況，發(fā)現(xiàn)業(yè)務上沒有的，而新產(chǎn)品必不可少，則需要增加相應的用例來完成目標。例如，微信充值中，只能用微信支付，我們做 APP ，要支持多種支付方式，所以補充“支付寶支付”用例。

同理，還要補充“管理賬號”用例，用戶才能注冊登錄、查看自己的訂單。

經(jīng)這一推導，新 APP 的參與者，也顯而易見：充值得有運營商支持；支付對接微信支付、支付寶；協(xié)助用戶處理未到賬，還需有運營人員介入?？梢?，整個充值 APP ，還應包括后臺管理系統(tǒng)。

這些都是后續(xù)系統(tǒng)分析、梳理系統(tǒng)關系、設計系統(tǒng)架構(gòu)的基礎。

為方便說明，我只簡化出核心部分，并把子用例合在一起展示。

△ 充值 APP 系統(tǒng)用例圖

至此，充值 APP 的系統(tǒng)用例圖就出來了。

有這份新系統(tǒng)的藍圖，就可以細化前端 APP 和管理后臺的用例，進而再分析系統(tǒng)流程、系統(tǒng)關系、設計產(chǎn)品功能。

這一路的分析推導下來，再畫原型圖，寫 PRD，你自然知道要寫什么，設計出來的功能，也更有依據(jù)、有邏輯，不容易被人以為是靠拍腦袋的。

四、總結(jié)

用例圖的基本用法，到此結(jié)束了，看累了吧？沒關系，我?guī)湍阈〗Y(jié)下，記住這幾條就夠了。

1、為什么要畫用例圖

用例是從用戶視角去思考的，學會站在用戶的角度去看產(chǎn)品，更能理解業(yè)務，表達清楚需求。

用例的本質(zhì)，是場景化思維和系統(tǒng)思維的體現(xiàn)。畫圖的過程，實際上是在鍛煉我們的思維方式。 

2、什么是用例圖

用例，是 UML 中用來捕獲功能性需求的一種方法，它從不同視角，描述不同角色用系統(tǒng)/產(chǎn)品做什么事，即什么人做什么事。

一個用例，就是參與者為完成某個特定目標的一系列活動或功能的集合。

用例圖，由參與者、用例、邊界、關聯(lián)構(gòu)成，寫用例表，更完整。

用例圖，常見類型有業(yè)務用例圖和系統(tǒng)用例圖。

3、如何畫用例圖

1）分析業(yè)務場景，找出人、事、物、目標

2）分析業(yè)務流程，細化目標，得出業(yè)務用例圖

3）由業(yè)務用例圖推導出系統(tǒng)用例圖

常用推導方法有：映射、抽象、拆分、合并和補充等。

最后，不是所有需求都要畫用例圖，視情況而定。

用例作為一種需求分析方法，不管你在是否用到它，關鍵是理解它的分析思路和表達邏輯。

善用用例，可以提高我們在需求分析、產(chǎn)品設計中的理解、思考和表達能力，確保我們的輸出是高效、準確、有理有據(jù)的。

從學用例開始，以用戶之眼看產(chǎn)品。

從今天起，做個說人話的產(chǎn)品經(jīng)理。

-END-