我們通常都是用自上而下的方式來描述用例的，這通常會包括一個容易了解的典型場景，這其中會使所有項目有關人員的利益得到滿足，而其他場景也都會由此産生或者擴充。主場景中包含的元素會有場景執行的條件和完成的目标，執行的步驟和結束條件以及其中的擴充。執行步驟會有一些有文法的限制，不管是複雜還是簡單一些的用例，都需要遵行使用簡單的文法來表述執行步驟以確定資訊的完整性，避免丢失活動執行者或其他資訊。其次要從系統使用者之外的開發人員的角度來編寫用例，還要具有一定的靈活性；人機互動界面的描寫不一定是實際需求，而僅僅是作者在某個時刻所想象的使用者界面，是以應該讓使用者界面設計師來進行界面的設計；執行步驟的編寫可以很靈活，允許采用不同的形式進行來描述；有些步驟的描述如果不甚準确的話，會出現一些偏差，是以要慎用詞語；适當的時候也要有時間限制；“使用者讓系統A與系統B互動”，要比“使用者點取按鈕，從B獲得資料”的表述要更準确；完整正式的用例格式需要進行編号。
接下來要對主成功場景裡進行擴充，可以單獨寫出每一個場景，也可以使用條件句來進行擴充；但這兩種分别有自己的缺陷，比較常用的是将主場景從開始到結束按時間的順序寫出來，然後再每個分支進行擴充。由于擴充差別于失敗或者異常處理，是以擴充也要包括成功和失敗兩種條件。由于會有很多個擴充，是以為了可以編寫的全面一點，避免丢失，要集中讨論所有可能的情況，包括快捷成功的路徑、等待密碼逾時、無效密碼、無效賬号、響應逾時、發現崩潰的事務日志等條目。擴充要有合理性，該合并的合并，該去掉的也要去掉。
當可以用不同的方法來完成相同目标是，就不能使用擴充了，這是需要将相關資訊寫到“技術和資料變化”清單中，比方說驗證身份可以用身份證、指紋識别等方法。 如果執行步驟某個步驟中有标記就說明是一個子用例，有時兩個用例之間也需要另一種類似擴充機制的連接配接。隻有當有很多使用者可能使用的異步服務或中斷服務且不影響基用例的時候，或者為一個已經鎖定的需求文檔編寫附加文檔的時候才使用擴充用例。
用例格式可以是正式的或者非正式的，又有單清單格格式、雙清單格格式、RUP格式、條件語句格式、Occam格式、圖形方式幾種格式，可以根據不同的情境使用不同的格式。書寫時要了解需求，甚至包括用例根本不在最後的需求文檔中使用的情況；業務過程模組化，設計和量化系統需求；還要注意在一個短期高強度的項目中編寫功能需求等。
隻有在已經命名了與系統相關的全部主執行者及其使用者目标、捕獲了系統的全部觸發條件（包括用例觸發條件、擴充條件）、編寫了所有使用者目标用例以及必要的概要用例和子功能用例、每個用例描述足夠清晰使投資方、使用者、開發人員都确認相關資訊之後才算完成任務。不同的項目組根據其不同的實際情況，通常采用不同的政策，一些項目組也許是為了對項目投标，一開始就草拟了所有用例，還有的是在快結束時，每一種都有可取之處。 對大量用例進行處理時，可以對每個用例進行簡單說明或者把用例分為多個簇。第一種給每個用例單獨命名時它就會作為第一級精度，對每個用例的描述就是第二級精度；第二種要建立用例簇的話可以按照執行者或按概要用例、開發組和版本号、主題域分類。 分析用例的核心業務時，要弄清在組織行為中的項目相關人員、必須滿足其需求的外部主執行者、必須響應的觸發事件以及該組織提供的服務和對項目相關人員的成功結果。業務用例與系統用例具有相同的特征，是以經常有人會把它們弄混，為了減少這種混亂用過在用例模闆中标明用例範圍及級别。 用例隻是需求文檔的行為需求，它們不包括系統性能需求、業務規則、界面設計、資料描述、優先級以及其他狀态，這些需求會以文檔的形式附在用例上，并且可以根據重要性進行調整相關内容。資料需求通常會被分為資訊别名、域清單或資料描述、域的細節和域校驗三個精度級别。資料格式不是用例的一部分，但是用例指明了資料的需求，是以可以在用例和資料之間建立超連結。同樣，複雜的業務規則也不适合寫入用例，但卻可以在包含他們的實體之間建立一個連接配接。