原文分析法（Textual Analysis），是在用例说明与流程分析的基础上进行的业务领域分析，是一项在需求研讨会后整理和分析需求的工作。当我们完成了用例图的绘制，为每个用例编写出用例说明以后，原文分析的工作就可以开始了。要讲解原文分析，我们还是用一个实例更简单明了：
这是一个实际项目的用例说明。在进行原文分析的时候，我们首先要做的事情就是对用例说明中事件流部分的文字描述，提取其中的名词。在这个实例中都有些什么名词呢？这些名词我在用例中用蓝色标注了出来，经过整理就是这些：触发器、考核指标（简称指标）、执法行为、指标定义、过错标准（过错判断标准）、过错行为、考核结果、年度、月份、机关、分子数、分母数、过错数、正确率。
领域模型中的实体，往往就在我们通过原文分析提取出来的这些名词中，但需要我们进行进一步分析。并不是所有名词都可以成为实体，那么哪些可以呢，而哪些又不能呢？首先，系统外的参与者不能。系统外的参与者是触发本系统某个事件的人或者物，但它本身存在于系统之外，比如用户使用鼠标点击了一个按钮，而领域模型是描述系统之内的事物，因此系统外的参与者应当被排除。本例中的触发器就是系统外的参与者（参见《功能角色分析与用例图》），它应当被排除。
其次，系统之内的事物转化到领域模型中，可能会变成两种东西：实体与实体中的属性。什么变成实体而什么变成实体中的属性呢？自身有自己的属性，可以成为系统中行为的执行者或施与者的，才是实体。比如考核指标就是实体，因为它有它的考核标准、过错行为、分子数、分母数、过错数、正确率等属性，它在系统中会去执行考核，所以是实体；分子数是不是实体呢？它仅仅是一个数据，没有自己的属性和方法。另一个判断是实体还是属性的方法就是判断它将如何持久化。如果一个事物被持久化到数据库中时是一个表，则是一个实体；如果仅仅是表中的一个字段，则是一个属性。
然而，是实体还是属性并不是那么绝对，关键看系统对这个事物进行怎样的处理。比如过错标准是一个实体还是一个属性呢？如果我们在系统中仅仅是一个文字描述则是考核指标中的一个属性，如果需要对它进行分解，有它的判断公式，需要让它去执行判断，则应当是一个实体。在需求分析的初期，可以先将其设计成一个属性，待日后的细化阶段再进行调整。
另外一个非常重要、值得我们着重关注的地方是名词的多义性。在本例中，我们考察一下“过错行为”这个名词。“一种过错行为”与“一个过错行为”显然不是一个概念。“一种过错行为”代表的是一种类型，有它的过错定义与判断标准；“一个过错行为”则代表的是一个实例，一个执法行为中的某个错误的行为。正因为它们概念上的差异，我们在领域模型中将其分为“过错类型”与“过错行为”。
经过一番分析，我们绘制出了一个基本的领域模型。毫无疑问，这个领域模型使用的是一个类图，实体在图中就是一个个的类。同时，我们将各个类之间的关系标注出来：一对一、一对多、多对多、聚集、组合、继承，等等。为了提高模型的可读性，我们在必要时可以标注关系的名称。如考核指标与执法行为之间是类型与实例的关系，等等。
现在，让我们重新回到原文分析。这次要分析的不是用例说明中的名词，而是动词，在本例中我用红色标注出来。最后，我们整理出这些动词：触发、执行考核、预警、采集、判断、是过错、是正确、打分、统计。
对用例说明中的动词分析，是为了定义各个实体之间的各种行为。同样，并不是所有动词都是实体的行为。参与者的行为显然不是实体的行为，应该被排除掉，如：实例中的“触发”。还有一些动词是某个行为的一个细节，如：“是过错”、“是正确”，被合并到“过错判断”中。最后，将行为添加到行为的执行者中。最后绘制出这样一个领域模型：
领域模型有别于后期的分析模型，其中最关键的就是目的，它的目的仅仅是分析需求，因此在很多地方会比较模糊而不考虑技术实现，比如本例中的“指标定义”、“过错标准”。另外一个比较关键的地方就是，系统中的行为到底由谁来执行，这个标准常常是说起来容易做起来难。我给大家的建议是参考GRASP中的“信息专家”模式。
GRASP是一种职责驱动设计的系统分析方法，它的“信息专家”模式是这样描述的：应当将系统中的行为交给信息专家去执行，而信息专家就是掌握着执行该行为所需数据的实体。在本例中，由于考核指标掌握着指标的定义，还有那些执法行为，所以它可以执行考核，而过错类型则掌握着过错标准，因此可以执行过错的判断。注意，这里的“执行”什么行为，是软件意义上的概念，即一个类可以拥有什么行为，而非现实世界的概念。要知道现实世界中的事物是不可能有主动执行什么操作的能力的。
过去我们拿到需求不知道该怎样去业务领域分析。有了原文分析方法，给了我们一个简单可行、易于操作的方法，让我们准确而高效地完成业务领域分析。
我们应当怎样做需求分析
我们应当怎样做需求调研：初识
我们应当怎样做需求调研：拜访
我们应当怎样做需求调研：研讨会
我们应当怎样做需求调研：需求研讨
我们应当怎样做需求调研：迭代
我们应当怎样做需求调研：需求捕获（上）
我们应当怎样做需求调研：需求捕获（下）
我们应当怎样做需求分析：功能角色分析与用例图
我们应当怎样做需求分析：业务流程分析（上）
我们应当怎样做需求分析：业务流程分析（下）
我们应当怎样做需求分析：用例说明
我们应当怎样做需求分析：查询报表分析
我们应当怎样做需求分析：子用例与扩展用例
我们应当怎样做需求分析：行动图和状态图
我们应当怎样做需求分析：业务领域分析
我们应当怎样做需求分析：原文分析法
我们应当怎样做需求分析：领域驱动设计
我们应当怎样做需求分析：非功能需求
我们应当怎样做需求确认：需求列表
我们应当怎样做需求确认：一个需求列表的实例
我们应当怎样做需求确认：快速原型法
我们应当怎样做需求确认：需求规格说明书
我们应当怎样做需求确认：评审与签字确认会
（续）
这是一个实际项目的用例说明。在进行原文分析的时候，我们首先要做的事情就是对用例说明中事件流部分的文字描述，提取其中的名词。在这个实例中都有些什么名词呢？这些名词我在用例中用蓝色标注了出来，经过整理就是这些：触发器、考核指标（简称指标）、执法行为、指标定义、过错标准（过错判断标准）、过错行为、考核结果、年度、月份、机关、分子数、分母数、过错数、正确率。
领域模型中的实体，往往就在我们通过原文分析提取出来的这些名词中，但需要我们进行进一步分析。并不是所有名词都可以成为实体，那么哪些可以呢，而哪些又不能呢？首先，系统外的参与者不能。系统外的参与者是触发本系统某个事件的人或者物，但它本身存在于系统之外，比如用户使用鼠标点击了一个按钮，而领域模型是描述系统之内的事物，因此系统外的参与者应当被排除。本例中的触发器就是系统外的参与者（参见《功能角色分析与用例图》），它应当被排除。
其次，系统之内的事物转化到领域模型中，可能会变成两种东西：实体与实体中的属性。什么变成实体而什么变成实体中的属性呢？自身有自己的属性，可以成为系统中行为的执行者或施与者的，才是实体。比如考核指标就是实体，因为它有它的考核标准、过错行为、分子数、分母数、过错数、正确率等属性，它在系统中会去执行考核，所以是实体；分子数是不是实体呢？它仅仅是一个数据，没有自己的属性和方法。另一个判断是实体还是属性的方法就是判断它将如何持久化。如果一个事物被持久化到数据库中时是一个表，则是一个实体；如果仅仅是表中的一个字段，则是一个属性。
然而，是实体还是属性并不是那么绝对，关键看系统对这个事物进行怎样的处理。比如过错标准是一个实体还是一个属性呢？如果我们在系统中仅仅是一个文字描述则是考核指标中的一个属性，如果需要对它进行分解，有它的判断公式，需要让它去执行判断，则应当是一个实体。在需求分析的初期，可以先将其设计成一个属性，待日后的细化阶段再进行调整。
另外一个非常重要、值得我们着重关注的地方是名词的多义性。在本例中，我们考察一下“过错行为”这个名词。“一种过错行为”与“一个过错行为”显然不是一个概念。“一种过错行为”代表的是一种类型，有它的过错定义与判断标准；“一个过错行为”则代表的是一个实例，一个执法行为中的某个错误的行为。正因为它们概念上的差异，我们在领域模型中将其分为“过错类型”与“过错行为”。
经过一番分析，我们绘制出了一个基本的领域模型。毫无疑问，这个领域模型使用的是一个类图，实体在图中就是一个个的类。同时，我们将各个类之间的关系标注出来：一对一、一对多、多对多、聚集、组合、继承，等等。为了提高模型的可读性，我们在必要时可以标注关系的名称。如考核指标与执法行为之间是类型与实例的关系，等等。
现在，让我们重新回到原文分析。这次要分析的不是用例说明中的名词，而是动词，在本例中我用红色标注出来。最后，我们整理出这些动词：触发、执行考核、预警、采集、判断、是过错、是正确、打分、统计。
对用例说明中的动词分析，是为了定义各个实体之间的各种行为。同样，并不是所有动词都是实体的行为。参与者的行为显然不是实体的行为，应该被排除掉，如：实例中的“触发”。还有一些动词是某个行为的一个细节，如：“是过错”、“是正确”，被合并到“过错判断”中。最后，将行为添加到行为的执行者中。最后绘制出这样一个领域模型：
领域模型有别于后期的分析模型，其中最关键的就是目的，它的目的仅仅是分析需求，因此在很多地方会比较模糊而不考虑技术实现，比如本例中的“指标定义”、“过错标准”。另外一个比较关键的地方就是，系统中的行为到底由谁来执行，这个标准常常是说起来容易做起来难。我给大家的建议是参考GRASP中的“信息专家”模式。
GRASP是一种职责驱动设计的系统分析方法，它的“信息专家”模式是这样描述的：应当将系统中的行为交给信息专家去执行，而信息专家就是掌握着执行该行为所需数据的实体。在本例中，由于考核指标掌握着指标的定义，还有那些执法行为，所以它可以执行考核，而过错类型则掌握着过错标准，因此可以执行过错的判断。注意，这里的“执行”什么行为，是软件意义上的概念，即一个类可以拥有什么行为，而非现实世界的概念。要知道现实世界中的事物是不可能有主动执行什么操作的能力的。
过去我们拿到需求不知道该怎样去业务领域分析。有了原文分析方法，给了我们一个简单可行、易于操作的方法，让我们准确而高效地完成业务领域分析。
我们应当怎样做需求分析
我们应当怎样做需求调研：初识
我们应当怎样做需求调研：拜访
我们应当怎样做需求调研：研讨会
我们应当怎样做需求调研：需求研讨
我们应当怎样做需求调研：迭代
我们应当怎样做需求调研：需求捕获（上）
我们应当怎样做需求调研：需求捕获（下）
我们应当怎样做需求分析：功能角色分析与用例图
我们应当怎样做需求分析：业务流程分析（上）
我们应当怎样做需求分析：业务流程分析（下）
我们应当怎样做需求分析：用例说明
我们应当怎样做需求分析：查询报表分析
我们应当怎样做需求分析：子用例与扩展用例
我们应当怎样做需求分析：行动图和状态图
我们应当怎样做需求分析：业务领域分析
我们应当怎样做需求分析：原文分析法
我们应当怎样做需求分析：领域驱动设计
我们应当怎样做需求分析：非功能需求
我们应当怎样做需求确认：需求列表
我们应当怎样做需求确认：一个需求列表的实例
我们应当怎样做需求确认：快速原型法
我们应当怎样做需求确认：需求规格说明书
我们应当怎样做需求确认：评审与签字确认会
（续）
