在CIM階段后，系統分析員已初步生成了系統用例，讓相關的決策人員從中挑選出首期開發的系統用例，這也就是首期的系統范圍。
隨后，項目正式進入PIM階段，也是正式進入分析階段，系統分析員將針對首期的系統用例詳述細節規格，作為正式需求文件的一部分，也作為業務人員與開發人員之間的溝通文件。
PIM-1~PIM-4的UML產生結果，將作為需求文件中的一部分，而其余非UML產生的結果，系統分析員視項目規定或以往經驗自行產生。
在PIM階段中，系統分析員負責生成PIM-1~PIM-4，至于其余的PIM或PSM，則由其他開發人員負責生成。
PIM-1~PIM-4的產生結果如下：
PIM-1：分析系統流程（系統用例敘述）
PIM-2：分析業務規則（狀態圖）
PIM-3：定義靜態結構（類圖）
PIM-4：定義操作及方法（序列圖）
在進入PIM階段之后，系統分析員將所有系統用例依相關性分成若干組，以組別方式生成該組系統用例涉及的PIM-1~PIM-4產生的結果，隨后交給后續的開發人員進行設計，編碼及測試。然后逐步生成一組一組的PIM-1~PIM-4產生結果，跟CIM的生成方式不同。
系統分析員逐步生成PIM的可能情況：
第一階段，進行CIM-1，生成業務用例
第二階段，進行CIM-2，生成活動圖
第三階段，進行CIM-3，生成系統用例
第四階段，決策人員從CIM-3挑選出一些系統用例，作為首期系統范圍。接著，系統分析員將挑選出來的系統用例，以其領域知識的相關性分組。
第五階段，生成第一組系統用例相關的PIM-1~PIM-4分析文件，并交由后續的開發人員進行設計、編碼及測試。
第六階段：依次生成其它組的系統用例相關的PIM-1~PIM-4分析文件，并交由后續的開發人員進行設計、編碼及測試。
PIM-1：系統用例敘述
針對每一個系統用例，系統分析員分析其內部細節，并編寫成系統用例敘述（UC Description）。
一份用例敘述格式里頭包含多項字段，系統分析員可以從中挑選適用的字段組成自己的用例敘述格式。
1、 用例基本數據
●用例名稱
●用例編號
●用例簡述
●用例圖
●系統
●執行者
●相關用例
2、 執行流程
●主要流程（Basic Flow）
● 替代流程（Alternate Flows）
● 例外流程（Exception Flows）
3、 條件及規則
●啟動事件或條件（Triggers）
●前置條件（Preconditions）
●后置條件（Post conditions on Success）
●失敗時狀態（Status on Failure）
●業務規則（Business Rule）
4、 相關文檔
● 用例敘述的歷史版本
●UML圖
●參考畫面
●其他非UML文檔
5、 其他事項
●優先性（Priority）
●迭代等級（Iteration）
●待解決問題（Issues）
● 基本假設（Assumptions）
●相關人員
●特殊需求（Special Requirements）
相關用例：常見的相關性有兩方面，其一是執行用例前必須先行執行過某相關用例，其二是執行用例期間可能驅動其他的包含用例（Inclusion Use Case），或是因條件符合驅動其他的擴展用例（Extension Use Case）。
就系統內部而言，各用例在其幕后都是共享同一群對象。也就是說，UC之間自然就具有“共享對象”之關系。但是，由于用例圖只呈現系統外觀，所以在用例圖里看不到這種關系。在外觀方面，UC之間有兩種關系，分別是“包含”（Include）和“擴展”（Extend）關系。
兩個用例之間可以有“包含”關系，用以表示某一個用例的對話流程中，包含著另一個用例的對話流程。一旦出現數個用例都有部分相同的對話流程時，將相同的流程記錄在另一個用戶中；前者稱為“基用例”（Base UC），后者稱為“包含用例”（Inclusion UC）。
如此一來，這些基用例就可以共享包含用例了。
簡言之，包含關系是來自于抽象（Abstraction），即從數個不同的用例之中，抽離出共同的部分，而成為可以重用的用例。
兩個用例之間還可以有“擴展”關系，用以表示某一個用例的對話流程，可能會依條件臨時插入另一個用例的對話流程中。前者稱為“擴展用例”（Extension UC），后者稱為“基用例”（Base UC）。
簡言之，擴展關系來自于用例內執行活動的過程分為主要過程（Main Course）及可選擇性過程（Alternative Course）。
執行流程
主要流程：這是用例敘述最核心的部分，其記載了整個用例正常的執行過程。
替代流程：一個用例敘述里面，通常會包含一段主要流程，同時可以包含數段替代流程。
例外流程：用例執行失敗的情況。
用例成功執行的過程中，正常流程就是主要流程，期間出現的小插曲就是替代流程。但是，例外流程處理的是，用例執行失敗的情況。
條件及規則
啟動事件或條件：記錄啟動用例的重要事件或條件。
前置條件：這是執行用例之前的檢驗，唯有在滿足某些重要條件時，才會執行該用例，以確保用例可以正確執行。
后置條件：相對于前置條件，后置條件代表用例執行完畢時，可以通過后置條件自行檢驗是否執行成功。
失敗時狀態：記錄用例執行失敗時的狀態。
業務規則：重要的業務規則或計算公式都要記錄下來。
業務人員在執行業務流程時，會使用到許多重要的業務規則或計算公式，這些也都是系統必須遵守的條件及規則，所以必須記錄下來。
相關文檔
由于用例驅動（Use Case Driven）是當今軟件開發的基礎模型，所以用例敘述常作為系統開發文件的匯集點，同它鏈接到相關的文檔。
用例敘述的歷史版本：用例改版時，用例敘述也跟著同步改版。用例敘述是參與人員的智慧成果，也是業務組織的重要資產。所以如果有需要保留用例敘述的歷史版本時，可以在現行版本里多加一個字段，以鏈接舊有的歷史版本及改版說明。
UML圖：跟該用例相關的業務用例圖、活動圖、系統用例圖、狀態圖、類圖或序列圖，等等。
參考畫面：有時候附上畫面設計的圖片，讓閱讀者可以對該用例有更具體的想象。
其他非UML文檔：例如會議記錄、表設計等。
其他事項
優先性：替用例標示其重要度或優先性，可以協助訂定開發用例的順序，越重要的越優先開發。
迭代等級：替用例標示其細致度或迭代等級，方便開發人員經過多次迭代的過程逐步定義出用例的細節。
待解決問題：在用例分析與開發期間，可能會出現還沒有定論的問題，這時候通過用例敘述把問題記錄起來，方便指派負責人員以及日后查閱。
基本假設：如果該用例是基于某個基本假設而設計出來的，記下這個重要的基本假設。
相關人員：每一份用例敘述都涉及幾種不同身份的相關人員，包括制作者、閱讀者和審核者，等等。
特殊需求：跟該用例相關的非功能性需求等特殊需求，都可以記錄在這個字段中。