用例、用例圖肯定不少人聽說過，也都基本知道它們大概是什么，我之前也是如此，直到最近偶然發(fā)現(xiàn)一本軟件工程的書：《編寫有效用例》，帶著好奇心讀了一遍，了解了一下軟件工程技術(shù)角度對(duì)軟件設(shè)計(jì)的思維方式，這里發(fā)文mark一下
一、重新理解用例
1、《編寫有效用例》的內(nèi)容總結(jié)
? ? ? ?你會(huì)發(fā)現(xiàn)可能比原來網(wǎng)上看到的用例多了一些東西，多了使用語境、范圍、級(jí)別、項(xiàng)目相關(guān)人員和利益、技術(shù)和數(shù)據(jù)變化列表這5點(diǎn)，其實(shí)在描述產(chǎn)品需求的時(shí)候，完全可以不描述這幾個(gè)點(diǎn)，前4點(diǎn)更多屬于設(shè)計(jì)產(chǎn)品時(shí)的考量，和實(shí)際的系統(tǒng)行為無關(guān)，最后一點(diǎn)則可以合并到擴(kuò)展中，但是我認(rèn)為有必要理解其中的思想，以便在我們從業(yè)務(wù)邏輯、從場(chǎng)景中提取產(chǎn)品需求后，對(duì)整體產(chǎn)品的功能邏輯進(jìn)行更全面的考慮，下面介紹主要的點(diǎn)：
1、項(xiàng)目相關(guān)人員：包括了所設(shè)計(jì)系統(tǒng)外的一切人或物，可理解為系統(tǒng)的利益相關(guān)者，只是不像我們?cè)谛枨蠓治鰰r(shí)關(guān)注的那么廣，此時(shí)只是聚焦到當(dāng)前用例所涉及到的人，其實(shí)就是產(chǎn)品設(shè)計(jì)中對(duì)主要、次要、反面人物模型的梳理；
1）主執(zhí)行者：書中說是請(qǐng)求系統(tǒng)提供服務(wù)的人（不得不吐槽這個(gè)描述太那啥了），其實(shí)就是指用戶，可能包括多個(gè)角色，在《交互設(shè)計(jì)精髓》中則可理解為主要人物模型，從描述產(chǎn)品需求的目的出發(fā)的話，我們只需要講清楚該用例是關(guān)于哪些用戶、哪些角色即可
2）輔助執(zhí)行者：為使系統(tǒng)運(yùn)轉(zhuǎn)所起來到的外部人或物，比如訂單系統(tǒng)需要依賴庫存系統(tǒng)才能知道我這訂單能不能生成，點(diǎn)餐系統(tǒng)需要依賴后廚打印機(jī)廚師才可接到單子
2、范圍（設(shè)計(jì)范圍）：指設(shè)計(jì)時(shí)考慮的部分，由于一個(gè)用例可能涉及到本次無需設(shè)計(jì)的部分，此時(shí)通過這一點(diǎn)其實(shí)就是在說明該需求涉及到的部分是哪里，哪里是沒有涉及到的
3、級(jí)別：指的是目標(biāo)級(jí)別，目標(biāo)的層次很好理解就不多說了（舉個(gè)例子就是吃飯是一個(gè)層次目標(biāo)，吃飯是為了生存是另外一個(gè)層次的目標(biāo)，生存是為了找到自身價(jià)值又跑到另外一個(gè)層次的目標(biāo)，扯遠(yuǎn)了。。），實(shí)際上只需要在設(shè)計(jì)時(shí)明確用戶目標(biāo)即可
4、前置條件：必要條件，執(zhí)行用例前必須滿足的前提
5、最小保證：系統(tǒng)對(duì)項(xiàng)目相關(guān)人員的承諾，保證多方利益，特別是失敗情況下的承諾，比如多次輸入密碼失敗后還是能申訴
6、成功保證：即系統(tǒng)成功執(zhí)行后的結(jié)果
7、觸發(fā)事件：?jiǎn)?dòng)用例的事件，有時(shí)也是用例的第一步
8、主成功場(chǎng)景：以理解為該用例的主干流程（書中將用例的每個(gè)步驟集稱為一個(gè)場(chǎng)景，比如添加規(guī)則，可以是導(dǎo)入的方式，也可以是手動(dòng)的方式，兩個(gè)分支對(duì)應(yīng)著不同的步驟，也就對(duì)應(yīng)著不同的場(chǎng)景）
9、擴(kuò)展：包括其他分支、異常情況以及對(duì)應(yīng)情況下的處理，著重考慮幾種以下幾種情形：
1）其他正常情況路徑
2）操作錯(cuò)誤的情況
3）無任何操作的情況
4）系統(tǒng)確認(rèn)/校驗(yàn)不通過的情況
5）從外部系統(tǒng)/人沒有得到響應(yīng)或響應(yīng)錯(cuò)誤
6）系統(tǒng)崩潰
2、如何理解運(yùn)用
? ? ? ?現(xiàn)在講究效率的背景下，編寫冗長(zhǎng)的用例會(huì)耗費(fèi)不少時(shí)間，除非很有必要（比如規(guī)范規(guī)定）。所以要記得用例本身只是一種描述產(chǎn)品需求的方式，所以從這個(gè)目標(biāo)出發(fā)，我重新整理了在實(shí)際中如何去運(yùn)用這種描述需求的思路：將上面提到的概念運(yùn)用到畫功能流程圖中（適合在最后細(xì)化的使用，不要一上來就畫到很細(xì)，書中也提到用例本身也是不是一次性完善的，而是逐步確認(rèn)逐步再細(xì)化的），如下：
? ? ? ?可以看出用例中提到的點(diǎn)基本都囊括在了功能流程圖中，在寫PRD時(shí)再注意將對(duì)應(yīng)的點(diǎn)描述出來（這其實(shí)也是書中提到的用例的表達(dá)方式之一）
3、文檔表達(dá)需求的注意點(diǎn)（摘錄自書中）
1）用例名：簡(jiǎn)單的”主謂（前置短語）賓“
2）從第三方的角度進(jìn)行描述
3）顯示執(zhí)行者的目標(biāo)而非操作界面的動(dòng)作，不涉及界面元素，減少維護(hù)和改動(dòng)成本（在進(jìn)入具體設(shè)計(jì)階段之前）
二、重新理解用例圖
? ? ? ?用例圖描述的是用例之間的關(guān)系，網(wǎng)上說到有泛化、擴(kuò)展、包含，但我建議如果不是有很強(qiáng)的必要性，不去管這些UML用例圖中提到的關(guān)系，只專注于你只是希望想傳播出功能范圍這件事即可，用簡(jiǎn)單的分支幫助自己梳理清楚功能間的關(guān)系，幫助團(tuán)隊(duì)了解到需求的范圍。
三、總結(jié)
工具為目的服務(wù)才是關(guān)鍵，標(biāo)準(zhǔn)有時(shí)候是有道理的，有時(shí)候也要加以改變，特別是老的思想，需要在新的背景下結(jié)合使用，以上便是讀完《編寫有效用例》后的感受，歡迎交流~
微信公眾號(hào)：產(chǎn)品有溫度
