暫缺
可以看到，用例表示的內容和用戶故事并沒有太大的差別，但用例比較強調格式。雖然不同的團隊有不同的格式，但是在同一個團隊中，盡可能使用相同和相似的格式（不同的用例可能需要不同的用例格式）基本流程中的每一個步驟都代表了業務人員和系統一次交互，流程非常的簡單，但是已經覆蓋了一個成功的流程。我們看到，流程的每一步都高度抽象的原因是該用例的層次是業務流程級別的。（業務流程級別也僅僅是一種約定，并不是標準）。利用層次的概念對用例進行精度的劃分。在上面的例子中，低精度的用例主要的目標是把握系統的全貌。在RUP中，這種用例也被稱為業務用例（Business Use Case）。在原先的用戶故事中，對分支情況描述比較含糊，但采用了用例的這種描述形式，分支情況就一目了然了，和前面一樣，分支情況的表述也有很多種的形式。
用例技術從提出到現在，已經有了大量的經驗積累。在XP項目中采用用例技術并不是什么新鮮事。但在XP中應用用例也必須遵循XP的原則，以及精益編程的思路。所幸的是，這些思路是非常自然的，使用用例技術是完全可以實現的。本文并不打算詳細的描述用例技術，如果要深入了解用例技術，有幾本書是非常值得一看的（見附錄）。
先把握系統的全貌：在做需求的時候，常常出現的一種情況是需求分析人員花費了很多的心思來精華、完善某個用例。對XP來說，這種做法并不推薦，而根據精益原則，這種行為存在浪費的可能性。我們對軟件、對項目的認識是不斷深入的。因此，我們在項目一開始就深入到需求、故事、或用例的細節，分析人員的能力可能很強，能夠正確的捕捉到用戶的實際需要。但是一個星期之后我們對需求的認識就有可能發生變化，也許是原先對用例范圍的界定出現了問題，也許從另一個角度分析用例效果會更好，也許原先處理用例的思路不正確。不管如何，需求變化的可能性是非常大。用例越詳細，發生變化的可能性就越大。這時候，原先花在精化用例上的時間就被浪費了。
因此，不要在一開始就精化需求，一開始的工作重點應該是放在盡可能全面的收集用例，了解整體的業務流程，分析主體業務流程等工作上。在獲得了系統的全貌之后，你會發現你原先對系統的認識是不充分的，用例需要根據新的思路進行重新排列，用例的優先級需要調整，在UML圖中，往往有一張系統的用例概覽圖，這張圖所表示的就是系統行為的一個概述。
尋找優先級高的用例進行精化：我們在上文提到了需求優先級的判斷，用例的優先級判斷和需求的優先級判斷相似。在討論迭代的時候我們說過，前幾次迭代的主要目的是要識別出項目風險。因此，尋找有代表性、優先級高的用例進行精化，能夠幫助開發人員更快的理解領域知識，構建起初步的領域模型。 繼續上面國際結算的例子，在完成總的用例圖之后，我們發現，銀行的業務非常的復雜，如果缺少領域專家，要在短時間內領會領域邏輯是非常困難的，同時，我們發現，匯款的業務在日常業務中所占的百分比是非常高的，而匯款業務涉及到了大多數的領域知識，而業務流程卻相對簡單。因此，我們決定，先把匯款的用例作為一個突破口，在完成了這個用例之后，我們的開發人員就會對業務領域有著比較深入的認識，也就能夠進行更復雜的工作了：
主要角色：業務人員
層次：業務流程級別
文章來源于領測軟件測試網 http://www.kjueaiud.com/
