用例、用例圖肯定不少人聽說過，也都基本知道它們大概是什麼，我之前也是如此，直到最近偶然發現一本軟體工程的書：《編寫有效用例》，帶著好奇心讀了一遍，瞭解了一下軟體工程技術角度對軟體設計的思維方式，這裡發文mark一下

一、重新理解用例

1、《編寫有效用例》的內容總結

完整的用例體

       你會發現可能比原來網上看到的用例多了一些東西，多了使用語境、範圍、級別、專案相關人員和利益、技術和資料變化列表這5點，其實在描述產品需求的時候，完全可以不描述這幾個點，前4點更多屬於設計產品時的考量，和實際的系統行為無關，最後一點則可以合併到擴充套件中，但是我認為有必要理解其中的思想，以便在我們從業務邏輯、從場景中提取產品需求後，對整體產品的功能邏輯進行更全面的考慮，下面介紹主要的點：

1、專案相關人員：包括了所設計系統外的一切人或物，可理解為系統的利益相關者，只是不像我們在需求分析時關注的那麼廣，此時只是聚焦到當前用例所涉及到的人，其實就是產品設計中對主要、次要、反面人物模型的梳理；

1）主執行者：書中說是請求系統提供服務的人（不得不吐槽這個描述太那啥了），其實就是指使用者，可能包括多個角色，在《互動設計精髓》中則可理解為主要人物模型，從描述產品需求的目的出發的話，我們只需要講清楚該用例是關於哪些使用者、哪些角色即可

2）輔助執行者：為使系統運轉所起來到的外部人或物，比如訂單系統需要依賴庫存系統才能知道我這訂單能不能生成，點餐系統需要依賴後廚印表機廚師才可接到單子

2、範圍（設計範圍）：指設計時考慮的部分，由於一個用例可能涉及到本次無需設計的部分，此時透過這一點其實就是在說明該需求涉及到的部分是哪裡，哪裡是沒有涉及到的

3、級別：指的是目標級別，目標的層次很好理解就不多說了（舉個例子就是吃飯是一個層次目標，吃飯是為了生存是另外一個層次的目標，生存是為了找到自身價值又跑到另外一個層次的目標，扯遠了。。），實際上只需要在設計時明確使用者目標即可

4、前置條件：必要條件，執行用例前必須滿足的前提

5、最小保證：系統對專案相關人員的承諾，保證多方利益，特別是失敗情況下的承諾，比如多次輸入密碼失敗後還是能申訴

6、成功保證：即系統成功執行後的結果

7、觸發事件：啟動用例的事件，有時也是用例的第一步

8、主成功場景：以理解為該用例的主幹流程（書中將用例的每個步驟集稱為一個場景，比如新增規則，可以是匯入的方式，也可以是手動的方式，兩個分支對應著不同的步驟，也就對應著不同的場景）

9、擴充套件：包括其他分支、異常情況以及對應情況下的處理，著重考慮幾種以下幾種情形：

1）其他正常情況路徑

2）操作錯誤的情況

3）無任何操作的情況

4）系統確認/校驗不透過的情況

5）從外部系統/人沒有得到響應或響應錯誤

6）系統崩潰

2、如何理解運用

       現在講究效率的背景下，編寫冗長的用例會耗費不少時間，除非很有必要（比如規範規定）。所以要記得用例本身只是一種描述產品需求的方式，所以從這個目標出發，我重新整理了在實際中如何去運用這種描述需求的思路：將上面提到的概念運用到畫功能流程圖中（適合在最後細化的使用，不要一上來就畫到很細，書中也提到用例本身也是不是一次性完善的，而是逐步確認逐步再細化的），如下：

基於用例的思想來畫功能流程圖

       可以看出用例中提到的點基本都囊括在了功能流程圖中，在寫PRD時再注意將對應的點描述出來（這其實也是書中提到的用例的表達方式之一）

3、文件表達需求的注意點（摘錄自書中）

1）用例名：簡單的”主謂（前置短語）賓“

2）從第三方的角度進行描述

3）顯示執行者的目標而非操作介面的動作，不涉及介面元素，減少維護和改動成本（在進入具體設計階段之前）

二、重新理解用例圖

       用例圖描述的是用例之間的關係，網上說到有泛化、擴充套件、包含，但我建議如果不是有很強的必要性，不去管這些UML用例圖中提到的關係，只專注於你只是希望想傳播出功能範圍這件事即可，用簡單的分支幫助自己梳理清楚功能間的關係，幫助團隊瞭解到需求的範圍。

三、總結

工具為目的服務才是關鍵，標準有時候是有道理的，有時候也要加以改變，特別是老的思想，需要在新的背景下結合使用，以上便是讀完《編寫有效用例》後的感受，歡迎交流~

作者：PM小森
連結：