編輯導語：用例圖是UML的其中一種，合理使用用例圖，可以更清晰地展示用戶需求與用戶所需服務，讓産品團隊更好地站在用戶角度去思考問題，并建立場景化思維。本篇文章裡，作者總結、分享了用例圖的類型與用法，一起來看一下。

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

這次趁着打磨課程，逼自己猛啃幾本書，結合這幾年做産品的經曆，總算提煉出自己的思路。

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

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

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

一、用例圖有啥了不起

做産品前幾年，我很少畫用例圖，直到做數據中台，碰到的需求更複雜，我重翻《大象：Thinking in UML》找靈感。

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

後來，我從業務調研開始，用用例的分析方法，把業務研究透、描述出來，系統該做成怎樣，腦海裡漸漸清晰。

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

1. 用戶視角

用例的設計之初，是希望我們别老在系統内執着功能，而是跳到系統外，以用戶的眼光看系統，思考什麼情況下給什麼人提供什麼支持。

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

開啟這種視角，才不會總用晦澀難懂的術語，将用戶搞暈，才能用業務方的語言去溝通，真正以用戶為中心去獲取需求，轉化為産品服務。

練習的辦法，便是按用例的規則和方法，一點點做， 逐漸轉變思考的方式。

2. 場景化思維

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

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

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

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

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

結果，她居然記住了。

發現沒？功能描述容易脫離用戶使用場景，讓人困惑。

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

3. 系統思維

每個講産品經理的思維方式，都會講系統思維。可，真能用系統思維去思考的人，可謂鳳毛麟角。

究竟什麼是系統思維呢？

系統思維，即思考問題時，要全面考慮系統内事物之間的互相影響，關注整體的運行規律，而不是隻考慮個别事物的情況。

做産品時，如果隻讨論功能，就是孤立地看待産品。

産品脫離了使用者，就沒有意義。隻有當我們把産品和使用者都考慮進去，才算是系統的思考。

用例的本質，就是将産品和使用者當成一個系統來看。

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

二、解讀用例圖

1. 何為用例

用例，是 UML 中用來捕獲功能性需求的一種方法，它從不同視角，描述不同角色用系統/産品做什麼事，即什麼人做什麼事。

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

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

所以說，用例不是功能，而是由參與者驅動的，是有明确目标的，是從用戶視角看問題的。

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

2. 用例圖的構成

用例圖，由參與者、用例、邊界和關系構成。

1）參與者，用小人表示

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

産品面向的用戶，也是在系統之外的參與者。

有時，系統内部也有一些人或對象，參與完成業務，這種稱之為業務工人，并非參與者，需區分清楚。

2）用例，用橢圓表示

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

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

粒度的确定，一直是個難題，沒有标準，隻能根據實際情況分析。一個大型系統，可能會有上百個用例，一個小産品，也許隻有幾個用例。

這有 2 個經驗供你參考：

1. 完整性，一個用例是一個完整的使用場景，不是零散的動作步驟。比如，拿起手機刷微信是個完整的場景，拿起手機隻是一個步驟。
2. 獨立性，一個用例有一個明确、獨立的目标，如果一個用例包括多個目标，則可再逐層細化出子用例。

3）邊界，用矩形表示

邊界将系統内外分開，參與者在外面，用例在裡面。邊界内的用例，就是系統要實現的事情。

一個系統的好壞，常取決于邊界是否清晰，即明确做什麼、不做什麼。邊界内的事，是系統的任務；如沒有特定條件推動，系統與外界沒有聯系。

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

因此，做産品要多回歸定位，檢查産品有沒有越界。一個好的産品，是界限分明的，做什麼不做什麼從不含糊。

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

UML 中關系挺多的，常用的有關聯、包含、擴展、實現四種。

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

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

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

3. 用例圖的類型

在 UML 中，用例圖的常見類型，有業務用例圖和系統用例圖。

1）業務用例圖

業務用例圖，是從業務的視角，對業務進行描述。即描述沒有新系統或産品前，業務是如何進行的。

UML 使用業務用例圖，旨在把業務描述清楚，發現業務問題和目标，新系統才能更好地解決問題，實現業務目标。

簡單需求，很少畫業務用例圖；複雜需求，用這個思路分析，更好發現業務問題，保證産品需求不跑偏。

2）系統用例圖

一般說用例圖，默認指系統用例圖，它描述參與者使用新系統或産品做什麼事，從而實現業務目标。

它是從業務用例分析推導出來的，是新系統的藍圖、開發範圍。

從業務用例如何分析、推導出系統用例呢？下面的案例馬上講到。

三、如何畫用例圖

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

因此，與其說學如何畫用例圖，不如說是在學如何分析，用例圖隻是分析的結果。

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

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

常規做法，接到需求，會想到去調研業務、研究競品，列出功能結構圖，再畫流程圖，很快就能畫原型，寫 PRD 。

對于簡單的産品，這麼做沒問題。但碰到複雜的系統，就得有一套好的分析思路和方法工具。

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

具體怎麼做呢？我總結了這 3 步。

1. 分析業務場景，找出人、事、物、目标

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

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

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

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

△ 充值話費業務用例實現

2. 分析業務流程，細化目标，得出業務用例圖

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

△ 微信手機充值過程

當我們從用戶的視角，繪制出微信充值的流程後，不難發現這個過程中，大緻可分為兩個階段。

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

一個是查結果，支付完成後，不一定馬上有結果，但基本都會成功，這時用戶可選擇離開；還有一種場景，發現話費快用完了，查什麼時候充值的。可見，查看結果目标也相對獨立。

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

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

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

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

△ 微信手機充值業務用例圖

3. 由業務用例推導出系統用例

經過從場景到流程的分析，業務用例基本清楚。就到最關鍵的一步，推導出系統用例。

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

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

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

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

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

4）補充，根據實際情況，發現業務上沒有的，而新産品必不可少，則需要增加相應的用例來完成目标。例如，微信充值中，隻能用微信支付，我們做 APP ，要支持多種支付方式，所以補充“支付寶支付”用例。

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

經這一推導，新 APP 的參與者，也顯而易見：充值得有運營商支持；支付對接微信支付、支付寶；協助用戶處理未到賬，還需有運營人員介入。可見，整個充值 APP ，還應包括後台管理系統。

這些都是後續系統分析、梳理系統關系、設計系統架構的基礎。

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

△ 充值 APP 系統用例圖

至此，充值 APP 的系統用例圖就出來了。

有這份新系統的藍圖，就可以細化前端 APP 和管理後台的用例，進而再分析系統流程、系統關系、設計産品功能。

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

四、總結

用例圖的基本用法，到此結束了，看累了吧？沒關系，我幫你小結下，記住這幾條就夠了。

1. 為什麼要畫用例圖

用例是從用戶視角去思考的，學會站在用戶的角度去看産品，更能理解業務，表達清楚需求。

用例的本質，是場景化思維和系統思維的體現。畫圖的過程，實際上是在鍛煉我們的思維方式。

2. 什麼是用例圖

用例，是 UML 中用來捕獲功能性需求的一種方法，它從不同視角，描述不同角色用系統/産品做什麼事，即什麼人做什麼事。

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

用例圖，由參與者、用例、邊界、關聯構成，寫用例表，更完整。

用例圖，常見類型有業務用例圖和系統用例圖。

3. 如何畫用例圖

1）分析業務場景，找出人、事、物、目标。

2）分析業務流程，細化目标，得出業務用例圖。

3）由業務用例圖推導出系統用例圖。

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

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

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

善用用例，可以提高我們在需求分析、産品設計中的理解、思考和表達能力，确保我們的輸出是高效、準确、有理有據的。

從學用例開始，以用戶之眼看産品。

從今天起，做個說人話的産品經理。

作者：四月；公衆号：四月喃嘩

本文由 @四月 原創發布于人人都是産品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部