原文分析法（Textual Analysis），是在用例說明與流程分析的基礎上進行的業務領域分析，是一項在需求研討會后整理和分析需求的工作。當我們完成了用例圖的繪制，為每個用例編寫出用例說明以后，原文分析的工作就可以開始了。要講解原文分析，我們還是用一個實例更簡單明了：



這是一個實際項目的用例說明。在進行原文分析的時候，我們首先要做的事情就是對用例說明中事件流部分的文字描述，提取其中的名詞。在這個實例中都有些什么名詞呢？這些名詞我在用例中用藍色標注了出來，經過整理就是這些：觸發器、考核指標（簡稱指標）、執法行為、指標定義、過錯標準（過錯判斷標準）、過錯行為、考核結果、年度、月份、機關、分子數、分母數、過錯數、正確率。

領域模型中的實體，往往就在我們通過原文分析提取出來的這些名詞中，但需要我們進行進一步分析。并不是所有名詞都可以成為實體，那么哪些可以呢，而哪些又不能呢？首先，系統外的參與者不能。系統外的參與者是觸發本系統某個事件的人或者物，但它本身存在于系統之外，比如用戶使用鼠標點擊了一個按鈕，而領域模型是描述系統之內的事物，因此系統外的參與者應當被排除。本例中的觸發器就是系統外的參與者（參見《功能角色分析與用例圖》），它應當被排除。

其次，系統之內的事物轉化到領域模型中，可能會變成兩種東西：實體與實體中的屬性。什么變成實體而什么變成實體中的屬性呢？自身有自己的屬性，可以成為系統中行為的執行者或施與者的，才是實體。比如考核指標就是實體，因為它有它的考核標準、過錯行為、分子數、分母數、過錯數、正確率等屬性，它在系統中會去執行考核，所以是實體；分子數是不是實體呢？它僅僅是一個數據，沒有自己的屬性和方法。另一個判斷是實體還是屬性的方法就是判斷它將如何持久化。如果一個事物被持久化到數據庫中時是一個表，則是一個實體；如果僅僅是表中的一個字段，則是一個屬性。

然而，是實體還是屬性并不是那么絕對，關鍵看系統對這個事物進行怎樣的處理。比如過錯標準是一個實體還是一個屬性呢？如果我們在系統中僅僅是一個文字描述則是考核指標中的一個屬性，如果需要對它進行分解，有它的判斷公式，需要讓它去執行判斷，則應當是一個實體。在需求分析的初期，可以先將其設計成一個屬性，待日后的細化階段再進行調整。

另外一個非常重要、值得我們著重關注的地方是名詞的多義性。在本例中，我們考察一下“過錯行為”這個名詞。“一種過錯行為”與“一個過錯行為”顯然不是一個概念。“一種過錯行為”代表的是一種類型，有它的過錯定義與判斷標準；“一個過錯行為”則代表的是一個實例，一個執法行為中的某個錯誤的行為。正因為它們概念上的差異，我們在領域模型中將其分為“過錯類型”與“過錯行為”。

經過一番分析，我們繪制出了一個基本的領域模型。毫無疑問，這個領域模型使用的是一個類圖，實體在圖中就是一個個的類。同時，我們將各個類之間的關系標注出來：一對一、一對多、多對多、聚集、組合、繼承，等等。為了提高模型的可讀性，我們在必要時可以標注關系的名稱。如考核指標與執法行為之間是類型與實例的關系，等等。

現在，讓我們重新回到原文分析。這次要分析的不是用例說明中的名詞，而是動詞，在本例中我用紅色標注出來。最后，我們整理出這些動詞：觸發、執行考核、預警、采集、判斷、是過錯、是正確、打分、統計。

對用例說明中的動詞分析，是為了定義各個實體之間的各種行為。同樣，并不是所有動詞都是實體的行為。參與者的行為顯然不是實體的行為，應該被排除掉，如：實例中的“觸發”。還有一些動詞是某個行為的一個細節，如：“是過錯”、“是正確”，被合并到“過錯判斷”中。最后，將行為添加到行為的執行者中。最后繪制出這樣一個領域模型：



領域模型有別于后期的分析模型，其中最關鍵的就是目的，它的目的僅僅是分析需求，因此在很多地方會比較模糊而不考慮技術實現，比如本例中的“指標定義”、“過錯標準”。另外一個比較關鍵的地方就是，系統中的行為到底由誰來執行，這個標準常常是說起來容易做起來難。我給大家的建議是參考GRASP中的“信息專家”模式。

GRASP是一種職責驅動設計的系統分析方法，它的“信息專家”模式是這樣描述的：應當將系統中的行為交給信息專家去執行，而信息專家就是掌握著執行該行為所需數據的實體。在本例中，由于考核指標掌握著指標的定義，還有那些執法行為，所以它可以執行考核，而過錯類型則掌握著過錯標準，因此可以執行過錯的判斷。注意，這里的“執行”什么行為，是軟件意義上的概念，即一個類可以擁有什么行為，而非現實世界的概念。要知道現實世界中的事物是不可能有主動執行什么操作的能力的。

過去我們拿到需求不知道該怎樣去業務領域分析。有了原文分析方法，給了我們一個簡單可行、易于操作的方法，讓我們準確而高效地完成業務領域分析。

我們應當怎樣做需求分析
我們應當怎樣做需求調研：初識
我們應當怎樣做需求調研：拜訪
我們應當怎樣做需求調研：研討會
我們應當怎樣做需求調研：需求研討
我們應當怎樣做需求調研：迭代
我們應當怎樣做需求調研：需求捕獲（上）
我們應當怎樣做需求調研：需求捕獲（下）
我們應當怎樣做需求分析：功能角色分析與用例圖
我們應當怎樣做需求分析：業務流程分析（上）
我們應當怎樣做需求分析：業務流程分析（下）
我們應當怎樣做需求分析：用例說明
我們應當怎樣做需求分析：查詢報表分析
我們應當怎樣做需求分析：子用例與擴展用例
我們應當怎樣做需求分析：行動圖和狀態圖
我們應當怎樣做需求分析：業務領域分析
我們應當怎樣做需求分析：原文分析法
我們應當怎樣做需求分析：領域驅動設計
我們應當怎樣做需求分析：非功能需求
我們應當怎樣做需求確認：需求列表
我們應當怎樣做需求確認：一個需求列表的實例
我們應當怎樣做需求確認：快速原型法
我們應當怎樣做需求確認：需求規格說明書
我們應當怎樣做需求確認：評審與簽字確認會

（續）

我們應當怎樣做需求分析：原文分析法