UseCase事件描述叙事流规范
文化/fasiondog
整理的用例需求編寫規范。分享部分UseCase事件描述敘事流規范。其中。標準5~10、12來自哪里《編寫有效用例》（[美國]?Alistair Cockburn 該）一本書，自身實踐和要求。
事件流包括正常事件流、可選事件流、異常事件流程，前述三者合在一起的本質就是用文字描寫敘述的流程。
事件流由文字描寫敘述的步驟組成，寫作過程中應遵循下面準則，這些準則是對用例寫作過程中的常見問題和最佳實踐的總結。下述規范中如沒有特殊說明，事件流同一時候指正常事件流、可選事件流、異常事件流。
準則1：文字描寫敘述與流程圖保持一致
事件流的本質其實就是文本描寫敘述的流程。
因此，對用例輔以說明的流程圖應與文字表述的事件流保持一致。其實，用例是以文字描寫敘述為主，流程圖為輔。編寫用例應該養成“先寫文字后繪圖”的習慣。保持一致意味著：
- 流程圖中的動作（含推斷）的數量與事件流中的步驟數量一致（因為不同的圖形表示方法的限制。最低程度應保證和正常事件流中的步驟數量一致）
- 流程圖中的動作（含推斷）與事件流中的步驟描寫敘述一致
句子的結構應簡單明了：“主語+謂語動詞+直接賓語”。輔以必要的修飾詞。
準則3：一個步驟描寫敘述中僅包括一個主語
在一個步驟中僅包括一個主語。這意味著一個步驟描寫敘述中能夠是一個運行者運行一個動作。也能夠是一個運行者運行多個連貫的動作，但不能出現多個運行者運行多個不同的任務。
比如：
錯誤的描寫敘述形式： 1.【用戶】輸入訂購號碼，【系統】發現這個號碼與本月中獎號碼匹配。將用戶和訂購號碼注冊為當月的中獎者，發電子郵件給銷售經理，祝賀客戶，并告訴他們怎樣領取獎金 正確的描寫敘述形式1： 1.【用戶】輸入訂購號碼。 2.【系統】發現這個號碼與本月中獎號碼匹配。將用戶和訂購號碼注冊為當月的中獎者，發電子郵件給銷售經理，祝賀客戶，并告訴他們怎樣領取獎金。正確的描寫敘述形式2： 1.【用戶】輸入訂購號碼。 2.【系統】發現這個號碼與本月的中獎號碼匹配。 3.【系統】將用戶和訂購號碼注冊為當月的中獎者。 4.【系統】發電子郵件給銷售經理。 5.【系統】祝賀客戶，并告訴他們怎樣領取獎金。在編寫用例時，能夠依據此準則。對較冗長的多個步驟進行合理的合并。所謂合理，是指合并后的步驟。應不影響可選事件流、異常事件流的插入點。
準則4：在步驟中明白標識參與人
通過在步驟中使用“【參與人】”的方式明白標識“參與人（Actor）”，防止因遺漏主語（以及部分賓語），而使讀者不知道誰是活動的運行者。演示樣例：
“【用戶】插入ATM卡并輸入PIN?！?/span>準則5：從系統外部的角度來編寫用例
缺少經驗的用例編寫者（尤其是對系統內部實現有所了解的開發者）在描寫敘述用例場景時。常常有意或無意實現系統內部結構并試圖從系統內部動作來描寫敘述系統。他們可能寫出這種句子“讀取ATM卡和PIN號碼。并從賬戶剩余金額中扣除一定數量?！?/span>
而從系統外部來編寫用例，則是：
1.【用戶】插入ATM卡并輸入PIN號碼； 2.【系統】從賬戶剩余金額中扣除一定數量。準則6：顯示過程向前推移
選擇過小的步驟將導致用例過長。假設一個用例有13~17個步驟。說明每個步驟完畢的工作過少。假設將一些小的步驟合并。能夠使用例的可讀性更好、更清晰。而且保持原有的基本信息。一般，一個用例的步驟數量應控制在7個以內。
為了有效合并用例步驟，應找到具有較高層次目標的步驟。能夠提出這種問題“為什么參與人須要做這件事？”?？赡堋ｍ氁啻卧儐柎藛栴}才干得到愜意的答案，而這個問題的答案就是步驟實現的目標。
下面是一個通過問“為什么”來提高目標層次的樣例。
“用戶按下Tab鍵”為什么用戶要按下Tab鍵？是為了將焦點移到地址框中。
為什么她要將焦點移到地址框中呢？由于在系統開始工作前。她要輸入username和地址。她想讓系統完畢一些工作，為了使系統工作，她必須輸入她的username和地址。
因此，一個清晰描寫敘述過程向前移動的主動語態句子是：
“【用戶】輸入名字和地址”準則7：顯示參與人的意圖而不是動作
通過操縱用戶界面來描寫敘述用戶的動作，這是編寫用例時常見的一種嚴重錯誤，它使得編寫的目標處于一個非常低的層次。界面細節描寫敘述使得需求文檔質量變差，主要體如今：
- 文檔冗長拖沓使閱讀困難、維護費用高昂。
- 不論什么用戶界面的變化都將導致用例文檔失效
通常情況下。當一些連續步驟的數據在同一方向上運動時。能夠將這些步驟合并成一個步驟（視情況而定。合理合并）。如以下的演示樣例及對它的改動：
改動前： 1.【系統】要求用戶輸入姓名 2.【用戶】輸入姓名 3.【系統】要求用戶輸入地址 4.【用戶】輸入地址 5.【用戶】點擊“確定” 6.【系統】顯示用戶的簡單介紹改動后： 1.【用戶】輸入姓名與地址 2.【系統】顯示用戶的簡單介紹準則8：“確認”而不是“檢查是否”
大家常常會遇到描寫敘述系統檢查某個條件的步驟。而在步驟描寫敘述中，使用“檢查”這個動詞并不好，這樣說并沒有讓過程明顯的向前發展，它并非真正的目的，同一時候它使得檢查的結果是不確定的。那么為什么系統要檢查條件？答案是為了確認、驗證或確保某些事情。
這些都是非常好的能夠表示目標的動詞。比如。能夠將“系統檢查password是否正確”替換為：
“【系統】驗證password正確”準則9：習慣用語：“用戶讓系統A與系統B交互”
在編寫用例時?？赡軙龅嚼缫韵虑闆r，正在設計的系統A須要從系統B中獲取信息?；蛘吲c系統B有一個交互過程。
通常能夠使用兩個步驟來描寫敘述：
1.【用戶】通知【系統A】從【系統B】獲取數據 2.【系統A】從【系統B】獲取后臺數據。上述寫法盡管能夠接受。但在某些情況下顯得笨拙和冗余，尤其是用例比較復雜時。更好的寫法例如以下：
1.【用戶】命令【系統A】從【系統B】獲取后臺數據準則10：習慣用語：“循環運行步驟X到Y，直到條件滿足”
有時候，我們會遇到須要反復的步驟。
對于僅僅有一個步驟須要反復。能夠直接在步驟中描寫敘述，如：“【用戶】在各種各樣的產品文件夾中尋找、直到發現所須要的產品。”
對于多個步驟須要反復的情況，能夠把表達反復運行的語句放在這些反復步驟的前面或后面。比如：
1.【客戶】提供賬號或名字和地址 2.【系統】查出客戶的愛好信息 3.【客戶】選擇一個商品，并做上購買的標記 4.【系統】將該商品增加客戶的“購物車”中客戶反復步驟3、4，直到客戶指明自己完畢了選購 5.【客戶】購買全部在“購物車”中的商品還有一種形式： 1.【客戶】提供賬號或名字和地址 2.【系統】查出客戶的愛好信息步驟3、4可反復運行 3.【客戶】選擇一個商品，并做上購買的標記 4.【系統】將該商品增加客戶的“購物車”中 5.【客戶】購買全部在“購物車”中的商品注意：在表達反復語句前面不須要加上序號。
準則11：命名可選與異常事件流分支
為可選事件流、異常事件流中的分支進行適當的命名。有助于測試和理解。通過簡單的命名，有利于檢視分支的覆蓋情況，保證全部的分支情況都得到了處理。
比如某系統登錄時的異常事件流：
5a.（錄入password方式認證失敗）假設password方式認證失敗，返回步驟3 5b.（連續輸入password錯誤限制）假設連續3次輸出password錯誤，則鎖定登錄。用例結束。5c.（錄入指紋方式認證失敗）假設指紋認證方式失敗，返回步驟3a
準則12：條件處理的縮排方式
縮進那些指明條件怎樣處理的運行步驟，并在字母后又一次從編號1開始。運行步驟遵循前面的準則。
演示樣例：
5a.假設輸入password錯誤：5a1.（password錯誤）假設password錯誤。系統提示錯誤信息，返回步驟4。5a2.（連續password錯誤限制）假設連續3次輸入password錯誤。賬戶鎖死。用例結束。5a3.（累計password錯誤限制）假設當日password錯誤達到10次，賬戶鎖死，用例結束。準則13：同一條件處理的分支應在一起
提出此準則的原因是在某些條件處理的分支中，被分別放置在可選事件流和異常事件流中，影響閱讀和理解，也不利于檢視發現錯誤。
錯誤的示比例如以下： 正常事件流: …… 3.柜面通過核心系統檢驗賬戶支取方式為預留password； …… 可選事件流： 3a．柜面通過核心系統檢驗賬戶支取方式為印鑒——3a1．柜面提示“請檢查密封”3a2．柜員后檢查憑證，單擊提交隨機密鑰，回報6修改后，它是統一的事件的替代流: 可選的事件流： 3a．（印章的方式平局）賬戶取款設定方式斬：3a1．【系統】提示客戶檢查憑證；3a2．【出納員】檢查簽名后，。確認提交系統，運行步驟6。 3b．（稅票秘密，畫畫等有效證件）假設占非印度秘密的方式繪制，畫畫等有效證件，【系統】提示“稅票秘密帳戶不支持的金融賬戶開放”，用例結束。轉載于:https://www.cnblogs.com/blfshiye/p/4560759.html
總結
以上是生活随笔為你收集整理的UseCase事件描述叙事流规范的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 用c#开发微信 (14) 微统计 - 阅
- 下一篇： 线性表之链式存储结构