軟體需求分析中，用例會表會給人一個清晰的功能描述。一個開發組可以使用用例來制定軟體設計任務，以保持用例映射的及時性。設計任務步并不與用例單元整齊對應，是以一項設計任務産生的業務對象或者行為能同時用于多個用例。在制定粗略的系統功能圖時需要首先對系統采用的叙述方式達成共識；然後對應用領域達成共識，并集中讨論系統主執行者和系統目标；再編寫系統描述并彙總。然後對功能圖精确化，首先對格式達成共識，然後編寫用例繼而進行稽核。把應用描述作為用例編寫開始之前的練習，并把用例概述作為項目概要的一部分。
用例隻是需求文檔的行為需求，它們不包括系統性能需求、業務規則、界面設計、資料描述、優先級以及其他狀态，這些需求會以文檔的形式附在用例上，并且可以根據重要性進行調整相關内容。資料需求通常會被分為資訊别名、域清單或資料描述、域的細節和域校驗三個精度級别。資料格式不是用例的一部分，但是用例指明了資料的需求，是以可以在用例和資料之間建立超連結。
項目相關人員是對用例的行為具有特定利益的人和物。每個主執行者都是一個項目相關人員，但是一些項目相關人員盡管有權關心系統的行為，卻從來不與系統進行直接互動，例如：系統擁有者，公司的董事會和調控主體。這種未直接出現的項目相關人員也可以叫做沉默的執行者，加強對這些人的注意可以大大提高用例的品質，他們的利益在系統執行的檢查和确認中、建立的日志中、以及在系統執行的動作中得以展現。
用例，做為規範行為的契約，捕獲了與滿足項目相關人員利益相關的所有行為，并且僅限于此。為了滿足項目相關人員的利益，需要描述三種行為：（1）兩個執行者之間的互動（為了促進一個目标），互動過程中可能會有資訊的往返傳遞（2）确認（為了維護某一項目相關人員的利益所進行的确認）（3）内部狀态變化（代表項目相關人員）。
列出所有的項目相關人員和他們的利益，并用這個清單仔細的檢查以確定用例體中沒有任何内容被遺漏。然而，這個微小的改動卻能對用例的品質産生重大的影響。
設計任務步并不與用例單元整齊對應，是以一項設計任務産生的業務對象或者行為能同時用于多個用例。在制定粗略的系統功能圖時需要首先對系統采用的叙述方式達成共識；然後對應用領域達成共識，并集中讨論系統主執行者和系統目标；再編寫系統描述并彙總。然後對功能圖精确化，首先對格式達成共識，然後編寫用例繼而進行稽核。