隨后，項目正式進入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文檔：例如會議記錄、表設計等。

其他事項

優先性：替用例標示其重要度或優先性，可以協助訂定開發用例的順序，越重要的越優先開發。

迭代等級：替用例標示其細致度或迭代等級，方便開發人員經過多次迭代的過程逐步定義出用例的細節。

待解決問題：在用例分析與開發期間，可能會出現還沒有定論的問題，這時候通過用例敘述把問題記錄起來，方便指派負責人員以及日后查閱。

基本假設：如果該用例是基于某個基本假設而設計出來的，記下這個重要的基本假設。

相關人員：每一份用例敘述都涉及幾種不同身份的相關人員，包括制作者、閱讀者和審核者，等等。

特殊需求：跟該用例相關的非功能性需求等特殊需求，都可以記錄在這個字段中。