需求原文分析法

原文分析法（Textual Analysis），是在用例分析的基础上进行的业务领域分析，是一项在需求研讨会后整理和分析需求的工作。采用原文分析法之前我们首先应当将业务需求整理成用例模型，为每个用例编写用例说明。在编写完成了用例说明之后，我们才可以开始进行原文分析。

在前例的工资系统中，原始的需求经过整理，有两个用例：建立员工档案与发放员工工资。其中，发放员工工资的用例我们编写如下：

 

用例标识			PJ201317-SALARY-02		用例名称	发放员工工资
创建人			某某		创建日期	2013-11-23
版本号			V1.0		用例类型	业务操作
用例描述			人力资源每月依次对员工档案中的所有员工填写工资项目。在完成所有员工工资的填写以后执行工资发放操作，完成工资的发放，并打印出工资表来。
参与者			人力资源
触发事件			人力资源进入工资填写功能
前置条件			员工档案已经建立好
事 件 流	基流		1. 人力资源进入工资填写模块，在一个表格中显示出员工档案中的所有员工； 2. 依次为每个员工填写各个工资项目，包括基本工资、考核工资、业务费、项目提成、奖金、个人所得税、住房公积金、养老保险、失业保险、工伤保险、迟到扣款、早退扣款、旷工扣款、请假扣款； 3. 根据填写的内容计算出应发工资与实发工资； 4. 完成所有员工工资项目的填写后，执行工资发放操作； 5. 打印工资表。
	分支流		2.1 在工资填写中可以进行暂存，下次可以继续填写。
	替代流		无
后置条件			当月的工资表被确定下来并不能再修改
非功能需求			1. 工资填写时应当自动显示出所有员工，并且填写方便； 2. 应发工资与实发工资的计算应当准确。
假设与约束			1．员工工资项目未完成填写前不能执行工资发放操作； 2．应发工资=基本工资+考核工资+业务费+项目提成+奖金 3．实发工资=应发工资-个人所得税-住房公积金-养老保险-失业保险-工伤保险-迟到扣款-早退扣款-旷工扣款-请假扣款
补充规格说明书			无
备注			无		优先级	高
业务需求列表
创建人		版本		描述			创建日期
某某		1.0		人力资源手动填写所有员工的工资项目			2013-11-23
某某		1.0		系统自动计算出应发工资与实发工资			2013-11-23
某某		1.0		工资表填写完成以后经过确认才能发放工资			2013-11-23
某某		1.0		工资发放以后就不能再修改			2013-11-23

 

完成用例说明的编写以后就可以进行领域模型的原文分析了。所谓原文分析，就是对用例说明中事件流的文字描述进行原文分析。首先，将文字描述中的名词提取出来，它们包括人力资源、员工档案、员工、工资项目、基本工资、考核工资、业务费、项目提成、奖金、个人所得税、住房公积金、养老保险、失业保险、工伤保险、迟到扣款、早退扣款、旷工扣款、请假扣款应发工资、实发工资、工资表。注意，在原文中还有一些名词并不代表相关业务，如“表格”、“模块”等。这些名词应当被忽略。

然后，我们开始逐一对这些名词进行分析。并不是所有名称都应当进入领域模型，那些本次需求范围之外的事物应当被排除，它们包括参与者与外部系统。参与者就是触发本用例某些操作的人或设备，如这里的人力资源。参与者还包括系统在某个固定周期触发的操作，如每个一小时触发一次、每天某个时间点触发，以及月末触发。外部系统就是本业务范围需要调用、抽取、访问的外部系统，如HR系统、项目管理系统等等。为了描述的需要，有时也将外部系统绘制在领域模型中，但应当特殊注明。

还有一些名词，它包含了其它很多的名词，如这里的“工资项目”。工资项目囊括了基本工资、考核工资、业务费等各种工资项目，它是否加入领域模型，需要我们仔细斟酌。如果我们需要设计一个动态工资表，那么在工资表中不应当有基本工资、考核工资、业务费等具体的工资项目，而是一个抽象的工资项目。但如果我们仅仅需要做一个静态工资表，那么工资表就不应当有抽象的“工资项目”，而是其它各种具体的工作项目，如基本工资、考核工资、业务费等。注意，领域模型中所有的名词应当有准确的内涵外延，不能有二义性，同时不能有相互的重合与包含。同理，员工与员工档案也应当取其一而不能兼之。

排除了应当排除的名词以后，剩下的就是领域模型中应当使用的名词。但是，这些名词在领域模型中的存在形式可能有两种：类与类中的属性。一个名词在领域模型中到底是类还是属性，这需要我们仔细分析。一般来说，某个名词中如果存在其它属性，甚至还承担相应的操作，那么它就是一个类，今后在数据库设计中会对应成一个表。如果这个名词其下没有其它属性，它承载的数据就是某个字符串、数字或日期，那么它就是某个类中的一个属性。

拿本例来说吧，员工档案是一个类还是属性呢？员工档案其下包含了员工姓名、性别、出生日期等各种属性，因此是一个类。同理，工资表包含了基本工资、考核工资、业务费等诸多属性，因此也是一个类。而那些基本工资、考核工资、业务费等工资项目记录的都是一些具体的数字，因此都是作为工资表中的一个属性存在。

然而，是类还是属性有时候并不是那么的绝对。软件需求在变化，它必将会带来领域模型的调整，这集中体现在属性与类的相互转换上。比如，在员工档案中的“电话号码”应当是属性还是类。起初就存一个电话号码，因此是属性，但随着软件的越来越精细，要详细记录员工的工作电话、家庭电话、手机等信息，因此逐渐转变成类了。同理，“地址”起初是一个属性，随后需要记录地址所在的省份、地市、乡镇、街道等信息，进而逐渐转化为一个类。我们要拥抱变化，就是要让领域模型随着软件需求的变化而变化，进而指导软件设计的变更。

完成了对原文中名词的分析，接着我们开始对动词进行分析。本例在用例说明中事件流的文字描述，包含以下动词：显示、填写、计算、发放、打印、暂存。原文分析中对动词的分析，就是在分析领域模型中各个类的相互协作，进而形成类的方法。在这部分，我们应当透过这些动词去分析系统实质的操作。如动词“显示”，其实质应当是“查询员工档案”。按照职责分配原则，这个动作应当分配给谁呢？根据“信息专家”模式（详见6.2大对象的拆分过程），执行这个动作所需的数据是员工档案，因此应当分配给“员工档案”类中。“填写”实质是“填写工资项目”，“计算”实质是“统计工资单”，“发放”是“发放工资”，“打印”是“打印工资单”，“暂存”是“暂存工资单”，它们都应当分配给“工资单”类中。

最后，分析类与类之间的相互关系，包括一对一关系、一对多关系、多对多关系、聚合/组合关系，等等。最后，工资系统最初始版本的领域模型就被绘制出来（如图15.6所示）。

图15.6工资系统初始的领域模型

 

需求总是在变化的，因此我们的领域模型总是在跟着变化。如果我们采用原文分析法，那么总是先变更用例模型，这种变更可能是增加新的用例，也可能是变更既有用例的事件流。然后，我们根据用例模型变更的部分，重新进行原文分析，然后调整我们的领域模型。