Use Cases的大小
當開始做Use Cases的時候有個很顯然的危險就是它要么有很多步驟要么就很少步驟。如果在Use Case中有超過15個步驟，它可能包含一些實現明細。如果它只有非常少的步驟則檢查它的目標是否是達到一個沒有很多分支的活動的單一線索。
較少的人類行為者（Actor）
如果Use Case有較少的人類行為者，而大多數行為者是其它系統，通常的做法是修改這個Use Case。尋找系統必須做出反映或公認的事件勝過會見這些行為者。
需求捕獲和系統復雜性
總而言之，這些情節捕獲到系統復雜度的同時行為者：目標語句對容許大的系統以相對壓縮的格式說明。Use Case的格式的作用是用戶和開發者能標志出行為者，然后確認這些行為者工作職責對應（或不對應）的目標，代替一個大的很難讀的功能規格說明書。
僅僅這樣，用戶和開發者就有足夠的興趣進而研究那些情節的細節。
系統不僅僅有應得的功能性需求
一些Use Cases并沒有捕獲所有的客觀需求，僅僅是捕獲了系統怎么用的那些功能性需求。然而還有許多方面的需求需要去捕獲的。其中有的非功能性需求使用關聯以至于也能隸屬于個別的Use Case，如性能需求和系統容量的需求。另外的一些不是關聯的而是要單獨地去捕獲，它們是以下的需求：
l 系統范圍
l 系統用戶的目標
l 用戶界面原型
l 一般規則
l 約束
l 算法
文章來源于領測軟件測試網 http://www.kjueaiud.com/
