每個人的個性、經驗和經受的鍛煉不同，每個開發組織都有其特有的人員、歷史和文化;
不同的項目有不同的需要;
不同的編寫團隊需要不同程度的規范和嚴格度;
在組織中使用公共的編寫形式有助于交流;
在同一個項目上使用不同的模板不是一個好主意;
因此：根據項目相關的風險性、項目特點，和所涉及到的人員選擇用例的編寫格式，并在該項目的開發過程中的組織內部使用。
3.4 TowTireReview(評審)
許多人都可能需要評審用例，這是一件昂貴耗時的事情。
原因：
對于驗證和確認編寫及內容來說，評審是必要的;
涉眾在用例上有一種既得利益;
使每個人參與編寫過程非常昂貴、麻煩并且緩慢;
如果僅由一個小的編寫組進行評審，就不會考慮所有涉眾的利益;
評審可能是昂貴的、乏味的、耗時的。
所以：
進行兩種類型的評審：第一種是由較小的內部小組進行的評審，可能要重復進行很多次;第二種是由整個團隊進行的評審，可能只進行一次。
3.5 QuittingTime
開發一個超出了涉眾和開發人員需要的用例模型不僅浪費資源，而且會拖延項目進度。
原因：
忽視重要需求的巨大恐懼使構建人員和涉眾延長了需求收集活動;
大多數人可以用一種合理的模糊性工作，即不言自明;
詳細講述謊言并不能使他們更為精確;
所以：
在用例完整并且符合參與者的需要后，停止開發用例;
用例模型完整性的檢驗：完整、可讀、邏輯上正確、對開發人員足夠詳細。
是否識別了所有的參與者和目標并將其編成了文檔?
客戶及其代表是否承認用例集是完整的，而且每個用例都是可讀的和正確的?
設計人員是否能夠實現這些用例?
3.6 WriterLicense
小的格式差別并不重要，解決了所有系統問題后，及時還存在一些格式問題，也可以停止編寫;
文章來源于領測軟件測試網 http://www.kjueaiud.com/
