在需求分析工作中，最后一項分析工作就是業務領域分析啦。業務領域分析，就是對需求分析中涉及到的業務實體，以及它們相互之間關聯關系的分析。前面我們談到了功能角色分析，或者說用例分析，它是從整體的角度對整個系統人機交互的分析與整理。隨后我們談到了業務流程分析，它是在對系統人機交互的分析與整理的基礎上，更加細致的去分析和整理那些業務流程，以及組成這些流程的一個個業務操作。業務流程分析是對系統進行的一種動態的分析，分析的是那些行為，那些操作。但是，所有的行為，所有的操作，最終施與的對象都是那些實體。這句話怎么理解呢？比如，我們執行填寫操作，施與的對象必然是那些表單，最終產生的結果必然是形成一份完整的表單，表單就是那個行為施與的對象。再比如，我們執行查詢操作，施與的對象必然是一個報表，最終產生的結果必然是查看到了這個報表的結果。這里的表單、報表，都是存在于系統的靜態實體，它們中的大多數也最終以數據結構的形式持久化保存于系統的數據庫中。因此，系統中應當有哪些實體，這些實體都有哪些屬性，被賦予了哪些行為，它們之間的相互關系是怎樣的，就成為了業務領域分析的重要內容，而業務領域分析也就成為了對系統進行的一種靜態分析。

我們的軟件系統，毫不夸張地說，就是對現實世界的真實模擬。現實世界中的事物，在軟件世界中就被模擬成一個對象。該事物在現實世界中賦予什么職責，在軟件世界中就賦予什么職責；在現實世界中擁有什么特性，在軟件世界中就擁有什么屬性；在現實世界中擁有什么行為，在軟件世界中就擁有什么函數；在現實世界中與哪些事物存在怎樣的關系，在軟件世界中就應當與它們發生怎樣的關聯。這正是面向對象編程的核心思想。



我們進行業務領域分析，就是基于這樣一個思想進行的。什么叫業務領域，就是客戶所在的知識領域，譬如財務人員所在的是財務領域，稅務人員所在的是稅務領域，營銷人員所在的是銷售領域。不同的知識領域擁有各自不同的領域知識，需求分析人員就應該通過客戶中的領域專家去學習這些知識、掌握這些要點，并最終體現在我們的需求分析中。然而，這必然是一個長期的過程。從這個角度說，業務領域分析不僅出現在需求分析階段，還應當貫穿與設計階段、開發階段、測試階段，甚至延續到后期的維護與升級。從另一個角度講，現在的軟件研發概念，已經不再是一錘子的買賣，而是延續到數年的不斷升級完善中了。而軟件的升級完善，從本質上說就是對業務領域不斷深入的認識。我們對業務領域的認識深入一點兒，我們的軟件系統就完善一分，再深入一點兒，就再完善一分。這就是世界級軟件分析大師Eric Evans提出的領域驅動設計的核心思想。

因此，我們進行業務領域分析，就是通過與用戶進行交流，掌握領域知識，然后繪制成業務領域模型，去指導我們軟件開發的過程。日后我們去設計開發系統時，應當設計哪些類，類中都應當有什么屬性和行為，以及怎樣去設計數據庫，都是以這個領域模型為基礎的，雖然有時并不完全與領域模型完全一致。過去，沒有一個切實可行的方法來指導我們的業務領域分析，而現在，我們可以通過兩種分析方法一步步進行：原文分析法與領域驅動設計。隨后，我們將就這兩種方式進行詳細分析。

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

（續）

我們應當怎樣做需求分析：業務領域分析