需求分析能力之樣例：引入領域模型的前前後後
曾經遇到過一個系統需求，需求分析人員在聽到客戶說要增加“修改員工密碼”功能後，就原封不動的把這個功能寫在了文檔中。如果把這個需求交給實現人員，很多實現人員，會在“員工”（Employee）這個類中加一個屬性“password”。如果僅用名詞法，來驗證需求，完全符合：“員工”，是一個比較重要的概念。“什麼的什麼，可以提取爲屬性”，因此“員工的密碼”可以提煉爲“員工”類的password屬性。
實現人員噓了口氣：“萬事OK。”
真的OK嗎？
需求場景：員工和用戶的分離。
如果把密碼放在了員工中，基於CRUD的做法，我們通常會把對員工的修改放到了一個界面上。也就是說，管理員增加一個人員，系統默認設置對應人員的密碼。
這個時候，IT部門提出異議了，增加員工，是人力資源部門的事情，而是否給員工開放賬號，是信息中心的事情，不是所有的員工都開放賬號的，HR部門無權擅自開放賬號。
“賬號？”，“是啊，”IT部門的人說，“用戶賬號啊”。
得，我們丟了一個重要的概念 －－用戶。
同樣的道理，員工辦理離職的時候，也是要先去信息中心銷戶，然後再去HR部門辦理離職，因此，我們把Password放到員工中，是不合適的。員工需要和用戶分開。
需求場景：員工和客戶、供應商、合作伙伴的合併：
客戶提出新的需求：原先我們建立的都是員工和密碼，現在，我們要打通企業的供應鏈，給我們的供應商和客戶包括合作伙伴，有條件的開放系統的功能。因此，他們也要有賬號和登錄密碼。
是分開設置代理，還是把他們合併成一個抽象類？在不考慮系統性能的前提下，我們可以暫時套用《分析模式》的做法，抽象出Person （或Party）領域對象來。
需求場景：分別的賬號登錄
客戶說：“我希望員工在登錄後，只選擇他想使用的崗位角色？”什麼意思？
“比方說張X，在集團公司內是出納，而在集團的某個下屬公司，是會計，他上午在集團上班，下午，在下屬公司上班。因此，登錄的時候，需要選擇角色。”
客戶是不會太輕易的就區分出員工和用戶的區別的，在描述的時候，就會混淆着使用員工和用戶這兩個概念。另外，崗位和角色，也是非常類似的兩個概念。
在沒有統一的獨立的登錄服務器的情況下，你感覺，這種方式實現起來有問題（想想，都會有什麼問題？），於是說服客戶：“給你建兩個賬號行嗎？”，用戶也沒有細考慮，居然同意了。因此，這時的一個Person，就對應了兩個賬號，密碼呢？自然不能放到Person中了。
我們再想像一下這時的登錄過程，簡單的交互步驟如下。
actor使用賬號和密碼登錄，
系統驗證賬號和密碼有效，顯示允許的功能操作。
需求場景：選擇性激活
如果客戶堅持只能一個人只能用一個用戶賬號登錄，會是什麼樣子？
使用用戶賬號 和password 登錄，系統需要列出其所有的角色，角色按所屬公司列出，
actor激活某公司下的某種角色。（關於角色的動態激活，可以參考RBAC模型，這裏不再多講。）
要考慮的問題就產生了（用例中的擴展流）：
actor已經在其他的地方登錄了系統（激活了其它角色了）怎麼辦？
我們現有的領域模型是，角色是跟公司（法人）相關的，如果客戶又提出，角色和部門相關，哪該怎麼辦？
需求場景：限界上下文
我和BSP的主要負責人建華，曾經就人員和用戶，以及崗位和角色的類似，進行了大量的討論。得出來的結論是，這是從不同的角度在看待同一事物，在企業資源模型中，HR是重要的企業資源，而在權限模型中，人力是作爲受限單元的。因此，他們應該分屬於兩個不同的限界上下文，而限界上下文，也是領域模型的一個重要的組成部分。
題外話：
作爲LoushangBSP產品的參與者，我曾經爲這些需求問題（比我舉出來得要多的多）困擾過許久，還好，現在，BSP中的組織機構和權限模型已經相對豐富，足以應對這些需求場景了，現在，我可以把一些簡單的需求，共享給大家。