對產品經理來說,如何寫需求用例
對小公司的產品經理來說,經常會要求寫需求用例。這篇文章, 作者分享了如何又快又好寫好需求用例的方法,供大家參考學習。
一、什么是需求用例
用例(Use Case),指實際工作中可能發生的場最。在需求分析階段的用例,稱為“需求用例”,是指用戶通過產品解決特定問題、完成指定任務的方式與步驟,也包括各步驟用到的約束、規則等。一個用例,往往對應著用戶需要完成的某個明確而具體的任務。
但也有兩種特殊的用例:一種是上層用例,另一種是底層用例。
- 上層用例,指結合一些有關聯的普通用例完成一個抽象的由若干普通任務組成的大任務。
- 底層用例,指完成某些小任務的用例,這種用例可能會在許多普通用例中被引用。
二、用例的構成
一個完整的用例,一般包括:用戶、前置條件、后置條件、主場景、擴展場景、規則等方面。
1. 用戶
用例的重點在于用戶的操作場景,在考慮用例的場景之前,需要先確定用例的用戶,因為所有的使用場景都是為某些特定的用戶服務的。一個用例可以面向一種或多種用戶,例如,用例“倉庫結賬”,只是面向倉庫核算員的,而用例“倉庫交易分析”,會面向多種用戶,如倉管員、核算員、計劃員、采購員等。
根據面向的用戶不同,可以將用例分成幾大類:面向普通用戶的用例、面向關鍵用戶的用例、面向系統管理員的用例、面向所有用戶的用例。
- 面向普通用戶的用例,是普通用戶從事業務處理的用例。由于使用者是一般工作人員,學習能力、文化水平、軟件知識參差不齊,設計這種用例時往往會在易學性、健壯性、易用性上下更多的工夫。這種用例設計得不好,會影響工作效率。
- 面向關鍵用戶的用例,主要用于系統數據的初始化、業務功能的配置、基礎數據的管理等,如“用戶管理”“倉庫配置”“組織結構建立”之類的用例。使用這種用例的用戶,雖然沒有系統管理員對軟件理解深刻,但對軟件比較熟悉,使用這種功能進行操作對系統的影響非常大,但一般來說影響的幅度與程度不及面向管理員的用例。
- 面向系統管理員的用例,主要用于系統配置、運行監控、異常分析,功能維護等,這些用例一般會涉及系統的正常運行,操作稍有不慎就可能導致系統異常甚至崩潰,所以一般只能給系統管理員使用。
- 面向所有用戶的用例,提供給所有登錄本系統的用戶的用例。如“修改密碼”“工作日志”之類,只要是登錄本系統的用戶,就可以使用這些用例。當然,既然是面向所有用戶的,自然也應該歸于面向普通用戶的用例,這是一種特殊形式。
2. 前置條件
前置條件,是為了保證本用例可以成功執行,而需要滿足的前提條件。例如,在某電商網站,用例“下訂單”的前置條件是會員登錄成功,并且會員信息中的一些必備資料填寫完整;用例“撤銷訂單”的前置條件是會員登錄成功,并且訂單還沒有發貨:而用例“退貨”的前置條件是訂單已經發貨。
3. 后置條件
后置條件,是指用例執行結束后的系統狀態,無論成功還是失敗。例如。年前一般都會取現金包紅包。就拿這個舉例來講,銀行ATM機,用例“提款”的后置條件是:如果用例執行成功,ATM機鈔票減少,減少額等于用戶的提款金額;如果用例執行不成功,ATM機鈔票不變,用戶的銀行賬號余額不變。
4. 主場景
“場景”指用戶使用軟件功能完成工作任務的操作過程。場景是由一系列人機交互的步驟構成的,強調的是人做了什么操作,機(軟件系統)有什么應答,來來往往,經過若干回合后,結束了某項任務,有可能成功,也有可能不成功。
由于用例都是有明確的任務的,因此,每個用例都應該有個主目標,這個主目標就是支持用戶通過這個用例完成某項具體任務,但為了使這個目標實現得更高效、更準確、更容易,犯了錯誤可以得到糾正,一些異常事件可以得到處理,需要軟件提供一系列的額外功能。
根據二八法則,平均下來應該有20%的功能是用來完成主目標的,而80%的功能是為了提高效率、降低錯誤率、糾正錯誤的。
例如,用例“倉管員根據采購單收貨”,它的主要目標是將收貨記錄錄入到系統,因此錄入并保存收貨記錄是主目標。
而編輯功能是為了糾正錯誤或應對變化,刪除功能是為了糾正錯誤,導入功能是為了錄入更快速,這些都不能稱為這個用例的主目標。
用戶為實現自己的主目標而進行操作的過程,稱為用例的主場景。大部分情況下,一個用例只有一個主目標,只有一個主場景。如果主場景不明確,往往說明這個用例是上層用例(文章開頭第二段有解釋,忘了的回去看)。
例如:“會員登錄”用例主場景包括:用戶錄入會員卡號、密碼,登錄成功這個過程。
別的處理密碼輸入錯誤、忘記密碼之類的場景,不屬于主場景,因為用戶到這里是為了登錄,輸錯了密碼,或者忘記了密碼只是一些意外情況。
主場景是實現用戶主目標的過程,但未必是最常用的場景。例如:“文員進行客戶檔案維護”用例,錄入客戶信息是這個用例的主目標,是主場景,但最常用的場景卻是瀏覽客戶信息。所以,我們要注意判斷。
5. 擴展場景
每一個用例,都有各種各樣的使用場景,主場景只是若干種場景中的一種。主場景之外的場景,稱為“擴展場景”。例如,一個簡單的用例“用戶登錄”,主場景是用戶輸入用戶名、密碼,驗證成功后進入系統。但還有別的可能,如用戶密碼輸錯了怎么辦,用戶忘記了密碼怎么辦等,這些都要有相應的處理場景,稱為擴展場景。
用“用戶登錄”的擴展場景用例,列舉2個場景進行分析,包括:密碼輸入錯誤、用戶忘記密碼。
擴展場景一:密碼輸入錯誤。
- 用戶錄入用戶名、密碼,確認登錄。
- 系統驗證用戶名、密碼,密碼驗證錯誤,提醒用戶只允許輸入三次。
- 用戶重新輸入密碼。
- 系統驗證密碼,如果驗證正確,則進入系統。如果驗證錯誤,且輸入已經超過三次則鎖定該用戶,并提醒用戶賬號已經被鎖定,如果沒有超過三次,則用戶重新輸入密碼。
擴展場景二:用戶忘記密碼。
- 用戶錄入用戶名、密碼,確認登錄。
- 系統驗證用戶名、密碼,密碼驗證錯誤,系統提醒是否需要取回密碼。
- 用戶確認取回密碼。
- 系統發送驗證短信到本賬號所綁定的手機。
- 用戶提交短信驗證碼。
- 系統確認驗證碼正確。
- 用戶錄入新密碼。
- 系統將當前用戶的密碼重置為新密碼。
6. 規則
規則是指本用例用到的業務規則、邏輯算法等。有的用例邏輯簡單,幾乎沒有什么規則;無非只是些數據的錄入、保存而己,而有些用例,邏輯非常復雜,需要進行大量的運算、判斷,在這種情況下,就需要整理進行運算、判斷的規則。
在這里整理的規則更傾向于用戶,描述用語以一般用戶能理解基本要求,應當盡量避免使用太多技術化的IT語言,另外,這里也不是用戶在需求調研時提供的規則的簡單記錄;應該有一個整理、分析、抽取、加工的過程。
三、總結
在互聯網軟件研發工作中,大家聽到最多的是測試人員寫的測試用例,需求用例聽到的相對較少,但是需求用例也是非常重要的。由于在實際工作中,產品經理的工作內容比較繁雜,而且很多時候是多任務并行,不一定會產出像測試那么細致的測試用例文檔。 但是我們在思考產品功能和撰寫PRD文檔時,要有必要的需求用例思維,去設計和驗收產品功能。
目前主流互聯網公司,大多采用敏捷研發。至于產品經理是不是需要寫需求用例,根據公司情況、部門要求、任務的復雜程度、自己的工作任務靈活決定。 所有的工具和方法都是為了輔助我們,更好的完成工作的,不可生搬硬套而忽略了自己的實際情況。
專欄作家
忻蕓,人人都是產品經理專欄作家。專注于B端、SaaS產品,擅長技能用戶體驗設計、交互設計、用戶研究、數據分析、項目管理。
本文原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自 Unsplash,基于 CC0 協議。
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論,等你發揮!