PIM-1：分析系统流程，生成系统用例叙述
随后，项目正式进入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文档：例如会议记录、表设计等。
其他事项
优先性：替用例标示其重要度或优先性，可以协助订定开发用例的顺序，越重要的越优先开发。
迭代等级：替用例标示其细致度或迭代等级，方便开发人员经过多次迭代的过程逐步定义出用例的细节。
待解决问题：在用例分析与开发期间，可能会出现还没有定论的问题，这时候通过用例叙述把问题记录起来，方便指派负责人员以及日后查阅。
基本假设：如果该用例是基于某个基本假设而设计出来的，记下这个重要的基本假设。
相关人员：每一份用例叙述都涉及几种不同身份的相关人员，包括制作者、阅读者和审核者，等等。
特殊需求：跟该用例相关的非功能性需求等特殊需求，都可以记录在这个字段中。