高級需求分析師培訓要點，如何正確編寫需求用例的5個提示！

用例文檔的編寫最困難的地方在於，這是一種單調的寫作方式，又需要富有完美的表達能力，使讀者願意閱讀。當用例書寫完畢以後，需要分析和回顧已寫完的用例，使思路不斷地被完善和清晰起來。用例編寫的注意力應該放在文字上而不是畫圖上，對於正確的寫作風格，我們將給出一些有益的提示。

使用例易於閱讀

要是需求文檔短小簡明，而且易於閱讀。從文法上說：要在現在時態中使用主動詞。不是使用被動語態，要使用主動語態。要明確句子的主語在哪裡，只寫真正是需求的東西，不要提及與需求無關的東西。下面的一些習慣可以使你達到這個目的。

• 讓問題短小、切題。長用例當然可以滿足大的需求，但很少有人喜歡閱讀。

• 從頭開始，用一條主線貫穿始終。頂部是一些對全局有重要意義的用例，再從這裡分離出用戶目標和最終的子功能用例。

• 用動詞短語來給用例命名，這些動詞表達了用例所要達到的目的。

• 從觸發事件開始一直連續，直到目標實現或者被取消。

• 用完整的主動語態句子來描述所要完成的子目標。

• 確保每一步中參與者及其意圖是可見的。

• 突出失敗條件，並使恢復動作是可讀的，最好是不必為每個步驟編號，人們就能清楚地知道下一步該做什麼。

• 把可選行為放在擴展部分，而不是放在用例主事件流的條件語句中。

• 只在非常必要的情況下才生成擴展用例。

僅使用一種句型

在編寫用例的每個執行步驟的時候，只採用一種句型。

• 現在時態的句子。

• 在主動語句中使用主動動詞。

• 描述參與者成功到達的目標，這些目標推動了整個過程的前進。

在擴展的條件部分可以使用不同的語法形式，這樣就不會使它和執行步驟產生混淆。

「包含」子用例

很重要的一條經驗就是，大部分子用例的加入使用包含關係。

混合使用飽含、擴展與泛化往往使讀者產生混淆。也就是只在必要的時候使用擴展，當然在框架（Framework）設計的時候使用泛化有一定的好處，但只是在需要的時候使用。

兩個結局

每個用例都有兩個可能的結局：成功和失敗。

記住：當一個執行步驟調用一個子用例的時候，被調用的用例可能成功也可能失敗。如果是在主事件流中調用，則把失敗處理放在擴展中。如果調用來自擴展，則成功和失敗的處理均放在同一個擴展中。

對於目標的成功與失敗，編寫者實際上有兩個職責：一個是確定對每個被調用用例的失敗都進行了處理；另一個是確定用力滿足了每一個項目相關人員的利益，特別是目標失敗的情況下。

項目相關人員需要保證

用例不僅僅記錄了主參與者和系統之間公共的可見的交互操作。如果用例僅僅完成了這些操作，那麼它不是一個可接受的行為需求，而僅僅是一個文檔化了的用戶界面。

系統是為了達到項目相關人員利益上的目的。其中一個相關人員便是主參與者，在一般的用例格式中，其它相關人員並沒有被列出來。但是用例需要滿足這些項目相關人員的利益，並提供滿足這些利益的保證。

一般主事件流和它的擴展瞄準了項目相關人員的利益，所以從主事件流開始閱讀，看看是不是考慮了所有相關人員的利益，你會發現遺漏是經常的事情。例如，沒有想到失敗，因而沒有記錄下恢複信息，檢查一下全部的失敗處理是否保護了所有相關人員的利益。

在編寫主事件流之前先編寫保證條件是一個好的策略，因為在第一遍編寫的時候就會考慮必要的保證，而不是後來發現它們再返回來對文本進行修改。