1. 程式人生 > >需求用例文件編寫建議 --事件流程(基本流程和擴充套件流 (

需求用例文件編寫建議 --事件流程(基本流程和擴充套件流 (

每個用例表示使用者為實現某個目標與系統的一次互動,而事件流程則是對實現該目標的描述,事件流程包括基本流程(又稱為主成功流程)和可選流程(又稱為擴充套件流程);對這部分的編寫應該清晰的描述不同的物件(使用者、系統)完成目標的活動序列,例如,像這種方式:球員甲將球傳給球員乙,球員乙運球,球員乙將球傳給球員丙。 
編寫一個良好的事件流程有以下準則: 

準則一:使用簡單語法 
主語+謂語+賓語,例如: “系統從帳戶餘額扣除一定數量金額“,簡單的語句與使用者溝通起來對需求的理解會更準確。 

準則二:明確寫出“誰控制球”(比喻) 
控球的執行者會做下列事情:自己運球或將球傳給別人,在步驟結束時要問問“把球給誰了”。 

準則三:從系統外部的角度來編寫用例 
始終站在使用者的角度來編寫,而不是系統的角度,例如,不要出現這樣的描述“系統讀取卡號和密碼,並從帳號餘額中扣除一定的金額”,而要從系統外部的角度來編寫,如: 
1)使用者輸入ATM卡並輸入密碼 
2)系統從帳號餘額中扣除一定的金額 

準則四:描述過程向前推進 
每一個步驟都要離目標更進一步,步驟不要太細,也不能太粗,一般對基本流程3-10步是合適的,過多則會使用例文件顯得太長。 

準則五:描述執行者的意圖而不是動作 
編寫用例常見的問題就是在操作介面來描述,這應該需要避免,例如: 
用例1 
1) 系統要求使用者輸入名字; 
2) 使用者輸入名字; 
3) 系統要求使用者輸入地址; 
4) 使用者輸入地址; 
5) 使用者點選“確認” 
6) 系統顯示使用者簡介 
修改後: 
1) 使用者輸入名字和地址 
2) 系統顯示使用者簡介 
雖然在操作介面進行描述能很精確的定義需求,但過多關注細節會花費大量的精力,同時文件也會變得很長,難以維護。 

準則六:包含“合理”的活動集 
對場景的描述可以把每個部分作為一個單獨的執行步驟,也可以以不同的方式合併其中的幾個部分,如何分隔要儘量按“是否合理”進行。一個常用的步驟模板如下: 
1) 使用者向系統傳送請求資料 
2) 系統驗證請求 
3) 系統更新內部狀態 
4) 系統顯示成功處理結果 
任何用例流程的描述,都可以在上述基礎上進行適當的擴充套件完成。 

準則七:“確認”而不是“檢查與否” 
描述中不要出現“如果”字句,例如 
2) 系統檢查密碼是否正確 
3) 如果密碼正確,系統顯示主頁面 
要修改為: 
2) 系統確認密碼正確 
3) 系統顯示主頁面 
對於密碼錯誤的流程,則放到可選流程中處理 

準則八:習慣描述“迴圈執行步驟X到Y,直到條件滿足” 
例如“使用者重複步驟3-4,直到完成選購” 

準則九:對於可選流程,格式如下: 
如準則七的中的例子 
2a:無效密碼: 
1)系統顯示登陸失敗頁面 
2b:使用者沒有響應(超時) 
1)系統自動關閉該頁面 

參考資料: 
《編寫有效用例》