原文分析法（Textual Analysis），是在用例说明与流程分析的基础上进行的业务领域分析，是一项在需求研讨会后整理和分析需求的工作。当我们完成了用例图的绘制，为每个用例编写出用例说明以后，原文分析的工作可以开始了。要讲解原文分析，我们还是用一个实例更简单明了：

　　这是一个实际项目的用例说明。在进行原文分析的时候，我们首先要做的事情是对用例说明中事件流部分的文字描述，提取其中的名词。在这个实例中都有些什么名词呢？这些名词我在用例中用蓝色标注了出来，经过整理是这些：触发器、考核指标（简称指标）、执法行为、指标定义、过错标准（过错判断标准）、过错行为、考核结果、年度、月份、机关、分子数、分母数、过错数、正确率。
　　领域模型中的实体，往往在我们通过原文分析提取出来的这些名词中，但需要我们进行进一步分析。并不是所有名词都可以成为实体，那么哪些可以呢，而哪些又不能呢？首先，系统外的参与者不能。系统外的参与者是触发本系统某个事件的人或者物，但它本身存在于系统之外，比如用户使用鼠标点击了一个按钮，而领域模型是描述系统之内的事物，因此系统外的参与者应当被排除。本例中的触发器是系统外的参与者（参见《功能角色分析与用例图》），它应当被排除。
　　其次，系统之内的事物转化到领域模型中，可能会变成两种东西：实体与实体中的属性。什么变成实体而什么变成实体中的属性呢？自身有自己的属性，可以成为系统中行为的执行者或施与者的，才是实体。比如考核指标是实体，因为它有它的考核标准、过错行为、分子数、分母数、过错数、正确率等属性，它在系统中会去执行考核，所以是实体；分子数是不是实体呢？它仅仅是一个数据，没有自己的属性和方法。另一个判断是实体还是属性的方法是判断它将如何持久化。如果一个事物被持久化到数据库中时是一个表，则是一个实体；如果仅仅是表中的一个字段，则是一个属性。
　　然而，是实体还是属性并不是那么，关键看系统对这个事物进行怎样的处理。比如过错标准是一个实体还是一个属性呢？如果我们在系统中仅仅是一个文字描述则是考核指标中的一个属性，如果需要对它进行分解，有它的判断公式，需要让它去执行判断，则应当是一个实体。在需求分析的初期，可以先将其设计成一个属性，待日后的细化阶段再进行调整。
　　另外一个非常重要、值得我们着重关注的地方是名词的多义性。在本例中，我们考察一下“过错行为”这个名词。“一种过错行为”与“一个过错行为”显然不是一个概念。“一种过错行为”代表的是一种类型，有它的过错定义与判断标准；“一个过错行为”则代表的是一个实例，一个执法行为中的某个错误的行为。正因为它们概念上的差异，我们在领域模型中将其分为“过错类型”与“过错行为”。
　　经过一番分析，我们绘制出了一个基本的领域模型。毫无疑问，这个领域模型使用的是一个类图，实体在图中是一个个的类。同时，我们将各个类之间的关系标注出来：一对一、一对多、多对多、聚集、组合、继承，等等。为了提高模型的可读性，我们在必要时可以标注关系的名称。如考核指标与执法行为之间是类型与实例的关系，等等。
　　现在，让我们重新回到原文分析。这次要分析的不是用例说明中的名词，而是动词，在本例中我用红色标注出来。后，我们整理出这些动词：触发、执行考核、预警、采集、判断、是过错、是正确、打分、统计。