繪制用例圖只是完成了用例建模最基本也是最簡單的一步，用例建模的核心在於編寫用例文檔，用例文檔又稱為用例規約或用例描述。顧名思義，用例文檔是用於描述用例的文檔，每一個用例對應於一個用例文檔，在用例文檔中需要用文字的方式描述用例的執行過程，即執行者與系統的交互過程。
用例文檔需要通俗易懂，不僅項目的開發人員能夠理解，系統的用戶以及客戶也能夠看懂用例文檔。一個完整的用例文檔包括用例編號、用例名、執行者、前置條件、后置條件、涉眾利益、基本路徑、擴展路徑、字段列表、業務規則、非功能需求和設計約束等組成部分。
一般在系統中需要給所有的用例一個統一規范的編號，如庫存管理系統，可以使用StockUC001、StockUC002等來對用例進行編號。每一個用例都需要提供一個清晰易懂的用例名，一般使用“動詞+名詞”的形式，如“查看庫存報表”、“增加員工信息”、“增加商品信息”等，對於一些俗語可以使用簡寫，如“登錄”、“注冊”、“入庫”、“出庫”等。
前置條件是用例執行之前系統所處的狀態，它必須是軟件系統可以識別到的狀態，如用例“入庫”的前置條件是“倉庫管理員已成功登錄”，而不能是“倉庫管理員已打開電腦”，因為是否“打開電腦”庫存管理系統不能識別到；后置條件是用例執行之后系統應該具備的狀態，它也必須是系統能夠識別到的，如用例“入庫”的后置條件是“系統保存入庫信息，更新相關商品的庫存量”，而不能是“用戶退出系統”，因為“用戶退出系統”不是“入庫”操作所達到的系統狀態。
涉眾利益是對用例執行過程和結果很關心但不直接操作用例的人，如倉庫管理員在入庫和出庫時，雖然經理不直接入庫，但是他們對這個過程和結果很關心；如在火車站買票時，直接使用售票系統的是售票員，但是乘客很關心用例的執行結果，擔心是否會弄錯時間和車次，因此乘客是涉眾。執行者是直接執行用例的人，他們通過用例來直接執行系統提供的功能；涉眾是執行者操作用例時的觀眾，他們對用例的執行過程和結果很關心，因為涉及到他們的利益。
路徑又稱為“流程”，是指執行者和系統交互的過程。用例文檔中最關鍵的部分是基本路徑，基本路徑又稱為“正常路徑”或者“開心路徑”，它是用戶最想看到、也最關心的路徑，是用例建模核心中的核心。在路徑中包含若干步驟，這些步驟構成了一個完整的交互過程，在描述基本路徑時，每一個步驟一般以執行者或者系統作為主語，如“倉庫管理員輸入待入庫商品信息”，“系統驗證該商品庫存是否達到上限”等。在編寫路徑時需要注意以下幾個問題：
(1) 需要對步驟進行編號，一般用阿拉伯數字1、2、3、…進行編號，表示步驟的先后次序。
(2) 不能出現專業術語，因為用例文檔需要系統的客戶和用戶都能夠看懂，因此不能出現諸如“JDBC”、“SQL”這樣的專業術語。
(3) 盡量使用主動語句，每一個步驟均以執行者或系統作為主語。
(4) 不要涉及到界面細節，如不能出現“倉庫管理員在文本框中輸入帳號”、“倉庫管理員在密碼框中輸入密碼”等句子，應該使用“倉庫管理員輸入帳號和密碼”來代替。
(5) 如果出現大量數據輸入或處理，需要將數據放入“字段列表”中，如系統管理員在增加員工信息時，需要增加員工帳號、員工密碼、員工所在部門、員工電話、員工郵箱等信息，可以在用例文檔中使用“系統管理員輸入員工信息”來代替，而對於“員工信息”的詳細描述可以放在用例文檔的“字段列表”中進行詳細說明。
(6) 注意分支和循環的處理，在用例文檔中，分支可放在接下來要介紹的擴展流程中；而循環可以直接放在步驟描述中，如在入庫時可以一次入庫多個商品的資料，中間某些步驟如下：“2. 倉庫管理員輸入待入庫商品信息；3. 系統驗證該商品庫存是否達到上限；4. 系統提示該商品入庫信息增加成功；”，如果需要重復這幾步，可以在基本路徑中用如下語句描述：“如果還有商品需要入庫，重復第2-4步”。
基本路徑是用例文檔的核心，通過路徑可以清楚了解執行者如何通過用例來實現相應的功能，因此，在編寫用例文檔時，需要認真細致編寫基本路徑，確保非專業人員都能夠在讀完基本路徑后理解執行者和系統的交互過程。
除了基本路徑之外，很多用例都存在一些替換路徑和異常路徑，通常可以將替換路徑和異常路徑統稱為擴展路徑。識別出一個用例的基本路徑並不難，但是要找到所有的擴展路徑是件很辛苦的工作。一個優秀的系統分析人員應該認真分析業務流程，試圖尋找出在基本路徑中每一個步驟可能存在的擴展方式，尋找出所有可能的擴展路徑。如倉庫管理員在入庫時可能會發生一些異常情況，如“供應商不存在”、“待入庫商品不存在”、“入庫時商品超過庫存上限”等，需要使用擴展路徑對這些情況進行清晰的描述，如“供應商不存在”，則需要設置一個擴展點，先執行“增加供應商信息”用例，再選擇供應商編號，在擴展流程中可以這樣表示：“1a. 供應商不存在 1. 擴展點1：執行用例——StockUC003增加供應商信息；2. 倉庫管理員選擇供應商編號。”。在這里需要注意擴展路徑的編號，如果是基本路徑中步驟1的擴展路徑，可以使用1a、1b、1c等方式表示，然后對於擴展出來的子路徑再用1、2、3、…進行編號，其中在該子路徑的第1步指明這是一個擴展點，該擴展點名為“擴展點1”，在此時需要執行另一個用例StockUC003“增加供應商信息”，則用例“入庫”和用例“增加供應商信息”之間是擴展關系，“增加供應商信息”是對“入庫”操作的擴展。如果沒有擴展點則直接書寫步驟，與基本路徑步驟寫法一致。
字段列表、業務規則、非功能需求和設計約束是對用例的補充描述，字段列表中包含某些步驟所涉及到的一些數據字段，如在“增加商品信息”用例中可以在其“字段列表”中詳細列出商品信息的內容，如“商品信息包括：商品編號，商品名稱，商品型號，商品類別，商品單價，商品數量，庫存上限，庫存下限”，“字段列表”為后續的數據庫設計工作提供了極大的幫助；業務規則用於描述在步驟中執行者或系統在執行某些操作時需要滿足的條件，如在“增加商品信息”用例中，其“業務規則”包括“商品編號不能為空，商品數量必須是大於等於0的整數，庫存下限必須低於庫存上限”等；非功能需求用於描述用例在可靠性、安全性、可用性、移植性等方面的一些要求，如“系統響應時間不能超過30秒”、“可以支持同時100個用戶在線訪問”等；設計約束是指設計過程中存在的一些待解決的問題，如“商品編號的編碼問題”、“如何快速輸入商品編號”等。
在實際軟件開發過程中，用例編號、用例名、執行者、前置條件、后置條件和基本路徑是一個用例必不可少的組成部分，其他部分可根據實際情況確定，可有可無。下面提供庫存管理系統中“入庫”用例的用例文檔，以供參考：
| 用例名稱 | 入庫 |
| 用例編號 | StockUC006 |
| 執行者 | 倉庫管理員 |
| 涉眾利益 | 經理：了解各種商品的庫存信息和每次入庫信息。 系統管理員：了解入庫操作是否能夠正常執行，系統是否正確記錄入庫信息並更新商品庫存。 |
| 前置條件 | 倉庫管理員已成功登錄。 |
| 后置條件 | 系統保存入庫信息，更新相關商品的庫存量。 |
| 基本路徑 | 1. 倉庫管理員選擇供應商編號； 2. 倉庫管理員輸入入庫商品信息； 3. 系統驗證該商品庫存是否達到上限； 4. 系統提示該商品入庫信息增加成功； 如果還有商品需要入庫，重復第2-4步 5. 倉庫管理員提交入庫信息； 6. 系統提示入庫成功。 |
| 擴展路徑 | 1a. 供應商不存在 1. 擴展點1：執行用例——StockUC003增加供應商信息； 2. 倉庫管理員選擇供應商編號。 2a. 待入庫商品不存在 1. 擴展點2：執行用例——StockUC005增加商品信息； 2. 倉庫管理員輸入入庫商品信息。 4a. 增加失敗 1. 系統提示商品增加失敗，超過庫存上限； 2. 倉庫管理員重新輸入商品數量； 3. 系統再次驗證該商品庫存是否達到上限，直至該商品入庫信息增加成功。 |
| 字段列表 | 入庫商品信息包括：商品編號、入庫數量、商品折扣。 |
| 業務規則 | 供應商編號不能為空； 商品編號不能為空； 入庫數量必須為正整數，且不能為空； 商品折扣為0-1之間的小數（可包含0和1），且不能為空。 |
| 非功能需求 | 系統響應時間不能超過30秒。 |
| 設計約束 | 如何快速輸入商品編號？ |