編輯導(dǎo)語：用例圖是UML的其中一種，合理使用用例圖，可以更清晰地展示用戶需求與用戶所需服務(wù)，讓產(chǎn)品團(tuán)隊(duì)更好地站在用戶角度去思考問題，并建立場景化思維。本篇文章里，作者總結(jié)、分享了用例圖的類型與用法，一起來看一下。

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

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

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

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

文章有點(diǎn)長，不過相信你看完，對如何做需求分析會有新的認(rèn)識。

一、用例圖有啥了不起

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

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

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

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

1. 用戶視角

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

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

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

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

2. 場景化思維

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

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

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

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

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

結(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ān)注整體的運(yùn)行規(guī)律，而不是只考慮個別事物的情況。

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

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

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

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

二、解讀用例圖

1. 何為用例

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

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

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

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

比如，人喝水，大致要做拿杯子、倒水、喝這幾個動作，人喝水是用例，拿杯子卻不是，因?yàn)椴粫腥藳]有目的只拿杯子。

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

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

1）參與者，用小人表示

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

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

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

2）用例，用橢圓表示

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

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

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

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

1. 完整性，一個用例是一個完整的使用場景，不是零散的動作步驟。比如，拿起手機(jī)刷微信是個完整的場景，拿起手機(jī)只是一個步驟。
2. 獨(dú)立性，一個用例有一個明確、獨(dú)立的目標(biāo)，如果一個用例包括多個目標(biāo)，則可再逐層細(xì)化出子用例。

3）邊界，用矩形表示

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

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

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

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

4）關(guān)系，用常見的箭頭連線

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

1. 關(guān)聯(lián)關(guān)系，一般由參與者指向用例，意味著參與者發(fā)起用例。當(dāng)然，也有少數(shù)情況，是用例指向參與者，如推送消息，是系統(tǒng)自動觸發(fā)用戶。
2. 包含關(guān)系，指一個用例包含了子用例，由父用例指向子用例。請注意，父用例并不等于所有子用例之和，它的范圍可以大于所有子用例。子用例是一定會執(zhí)行的。
3. 擴(kuò)展關(guān)系，指一個用例在某種情況下需要完成特定活動，由擴(kuò)展用例指向被擴(kuò)展用例。與包含關(guān)系不同，擴(kuò)展是特殊分支，在特定情況下才出現(xiàn)的支流，如電商的訂單退款。
4. 實(shí)現(xiàn)關(guān)系，連接用例與用例實(shí)現(xiàn)，表示一個用例可以有哪幾種實(shí)現(xiàn)方式。

5）用例表，圖形之外的文字補(bǔ)充

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

3. 用例圖的類型

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

1）業(yè)務(wù)用例圖

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

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

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

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

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

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

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

三、如何畫用例圖

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

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

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

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

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

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

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

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

1. 分析業(yè)務(wù)場景，找出人、事、物、目標(biāo)

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

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

充話費(fèi)，我們可以去微信充值、也可以去支付寶，或用運(yùn)營商的 APP 。

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

△?充值話費(fèi)業(yè)務(wù)用例實(shí)現(xiàn)

2. 分析業(yè)務(wù)流程，細(xì)化目標(biāo)，得出業(yè)務(wù)用例圖

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

△ 微信手機(jī)充值過程

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

一個是充值，這個過程不能中斷，一斷充值就不成功，所以，可以得到一個小目標(biāo)：充值話費(fèi)。

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

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

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

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

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

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

3. 由業(yè)務(wù)用例推導(dǎo)出系統(tǒng)用例

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

常用的推導(dǎo)方法有：映射、抽象、拆分、合并和補(bǔ)充等。

1）映射，指一種特殊的對應(yīng)關(guān)系，可直接對應(yīng)過去。比如，微信充值有“充值話費(fèi)”用例，與我們要做的 APP ，目標(biāo)一致，可直接映射。

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

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

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

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

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

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

這些都是后續(xù)系統(tǒng)分析、梳理系統(tǒng)關(guān)系、設(shè)計(jì)系統(tǒng)架構(gòu)的基礎(chǔ)。

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

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

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

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

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

四、總結(jié)

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

1. 為什么要畫用例圖

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

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

2. 什么是用例圖

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

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

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

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

3. 如何畫用例圖

1）分析業(yè)務(wù)場景，找出人、事、物、目標(biāo)。

2）分析業(yè)務(wù)流程，細(xì)化目標(biāo)，得出業(yè)務(wù)用例圖。

3）由業(yè)務(wù)用例圖推導(dǎo)出系統(tǒng)用例圖。

常用推導(dǎo)方法有：映射、抽象、拆分、合并和補(bǔ)充等。

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

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

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

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

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

作者：四月；公眾號：四月喃嘩

本文由 @四月 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。