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