我直接先說結論好了，SA 根本不需要懂 “領域知識(Domain Knowledge)” ！！
SA 所需要具備的知識與技巧是，如何與領域專家(Domain Expert)溝通，並懂得如何將其領域知識轉化為抽象的軟體模型。
請記得，是與領域專家的溝通與討論，而並非僅是操作系統的操作員(Operator)，從操作員所得到的，大部分是零碎片面的需求，卻非是從企業經營的角度來看待整體企業的流程(Business Process)。
專案經理或IT 主管要求 SA 需要研究，或者起碼需要懂一些 Domain Knowledge，這似乎是業界根深蒂固的觀念，正因如此，SA 根本就沒有花太多時間在 “純” 軟體設計的學習與研究上。當然，會有太多的人質疑，若 SA 不懂領域知識，如何能建構最起碼所要求的 E-R Model 呢？畢竟，E-R Model, Class Diagram 的組成單元幾乎是從領域知識的專業術語而來。
這問題的答案，其實說起來，也不難回答，答案就是如前所述： SA 要能具備 “純” 軟體的技能與技術。
那麼，什麼是 “純” 軟體的技術？ 答案又是很簡單：抽象(Abstraction)、封裝(Encapsulation)、介面(Interface)與相依性(Dependency)分析的觀念 …等。
以抽象為例，當 SA 懂得抽象的技巧後，會發現到，各類的領域知識，其核心的本質是源自於 “交易(Transaction)”，交易即為事件(Event)，會因而延伸出與該交易所串連的人、事、時、地、物等。所以 SA 在與領域專家溝通討論時，就會用心在尋求該領域上的各類交易，以此為核心，逐漸延伸，而能建構出領域的物件模型。
簡單的實際例子，網路購物系統中，訂購(Order)即為重要的交易事件，顧客(人)會下訂購；下訂購的地點(Place)如超商需要被記錄下來；訂購需要出貨，可能會分次出貨，而出貨，又是一個重要的交易事件，它又可能會串連至出貨人員與出貨地點．．．等。
Peter Coad “Object Models” 一書中，早於 1997 年該書即已揭露出以交易為核心的 “Transaction Pattern”，來指導與協助 SA 以此來建構領域的物件模型。
這很有趣，有別於 SA 以為要經過需求的訪談後，透過需求文件的紀錄，才可能找出 “Entity”，建構領域模型。當 SA 是與真正精通的領域專家溝通時，運用抽象的技巧，反而可以不先需要透過片段局部的需求文件，就可以建構核心的領域模型。
但，問問看，又有幾個 SA 會去看如 Peter Coad 這樣的著書呢？ 更為悲哀的是，SA 根本就是花很少的時間在軟體設計的根本學習與思考上，去看各類 Domain 相關的書籍，反而還比較多。說難聽點，我到覺得有點不學無術。
你要問我，SA 有沒有可能成為好的領域專家，說什麼我都不可能相信。
答案又是很簡單，若可以成為專業的領域專家，那根本沒有必要擔任 SA，因為，領域專家的待遇比 SA 好上太多啦。
又，有沒有可能同時很懂領域知識與軟體設計的？ 我是聽過幾個自稱兼通的，但，這我更不相信。要專精每一個專業領域，最起碼沒有花上 5~10 年，是不可能成為專家的。請記得啊，軟體設計，也是一門專業的領域，而這一門領域，其門檻絕對不會來得比其它領域還要容易，對工程、管理、邏輯、心理、藝術等等，均需用心研究思考與學習，你還能有其它時間研究其它領域？
有些 SA 可能有心向學於純專業的軟體設計，但，回到現實面，環境卻不許可。
舉一個實際的例子，我一位目前任職於外商軟體公司的朋友，前兩年他去應徵國內某家大型有線寬頻電視的 MIS 部門，該部門的 IT 主管，出的考題，竟然是要我那位朋友寫出人事出缺勤管制系統的企業流程。 這．．． 我實在很難以想像，這是 IT 主管！！ ？
大環境確然不佳，但這仍端賴於 SA 個人目標的選擇。你要往其它的專業領域，例如 ERP，那麼，就應該要用心成為該領域真正的領域專家；或者，你仍情有獨鍾於軟體設計，那麼，就應該用心在軟體設計的思考與學習上，成為真正的軟體專家。你不可能雌雄同體，是 ERP 專家，又是軟體專家，這樣，是違背大自然法則的，一公與一母的感情結晶下，才有可能生出健康活力的寶寶的。
除了結尾「大自然」「一公一母」的比喻，讓人抖了一下之外(或許這又正好反過來證明懂電腦軟體不等於文思敏捷、常識正確？)是很有說服力的好文章！畢竟，那些名垂千古的歷史人物，也很少有人是因為有兩個專長而被記得的。
不一定要是專家，但知識領域還是要建立到能夠與專家對話阿！
不知道「噴子」為何物，如何能溝通，「噴子」的抽象、封裝、介面、相依！？
到最後你還是得從專家手上推敲出「噴子」的資料，無論你是從專家手上學到，還是事前先把資料準備好，最後都是要建立的。
yes, 這是我所認同的，在與領域專家的溝通過程中，本來就需要對該領域的專業術語能有共識與基礎的了解。
我所謂 SA 具備 “與領域專家溝通的能力”，對領域術語的定義與解讀，這些是在溝通過程中會建立起來的。
領域的關鍵知識，我比較主張 SA 不太需要花功夫與心思去學(除非你想當該領域的真正專家)；重要的還是在於：解讀與快速捕捉精要 (essential)的能力。
漂亮! 完全贊同!!
您最後的說明，完全消彌 前文的疑慮.
5 年之間，應該是有不同境界的體會!
本篇文章至今已事隔多年。
不過以我們團隊身體力行與至許多輔導單位觀察的結果，仍是與個人在當時所主張 SA 不須懂領域知識並沒有違悖的。
SA/SD 要了解的最基礎功夫是軟體抽象的能力。
以前我的老師用了一個相當有趣的比喻來說明 SA 與 Domain Expert 的角色。小孩子要能生出來，總是需要先生與老婆的結合才能生下來，而不是一個人就能擔負生小孩的責任。 ^^
溝通不是在於兩者的須具備共通的知識，重點卻是在於 “合作”。 這點在軟體開發中，為何會有各類不同專職的角色互補合作就可以知道的。
在國內的軟體業界諸多公司，的確幾乎都要求 SA 要能具備領域知識。但是相對來說，我個人所看到的 SA，卻幾乎沒有具備軟體分析的能力 (這可是很奇怪的現象)。
至於個人所主張 SA 不須具備領域知識，此點論點卻也不是空談，而是幾年下來，透過多年來在許多單位的顧問輔導，反覆的實證，更是證明此一論點。
如果有興趣討論這個議題，歡迎利用假日(星期六)來中國生產力中心找我，早上上完課後，一整個下午我可以陪你討論諸多軟體設計與開發的許多議題。 ^^
從溝通理論來看，兩個個體之所以可以溝通，是因為具有共同的知識，這雙方都擁有的共同知識是能夠溝通的基礎。如果SA完全沒有Domain Knowledge，而domain expert也不知道SA在做什麼，這個溝通的過程必然會非常辛苦。這是為什麼SA必須有domain knlwledge的原因 — 為了有效溝通，而不是為了變成domain expert直接提供解答。
現在的企業已經不像上個世紀那麼強調專業分工，而是強調多能工。因為在跨領域的工作場域中，太極致的專業分工造成的專業本位主義，溝通障壁一旦出現，企業就無法敏捷的對外在變化做出反應。
某些軟體工程學派認為，SA不必然需要了解後面接下來的軟體設計在做什麼，就如同SA不必然需要具備domian knowledge。你認為這真的行得通嗎？
Hello psy:
“SA應該明確的知道軟件的價值” ，這句話好！！ ^^
我觉得SA必然是软件设计专家，而领域建模是从软件设计角度对业务领域专家级认识，所以SA也必然是一个角度的领域专家。
在做领域分析时业务对象的领域专家固然重要，但是operator同样重要。一个完整的业务系统需要包括各种细节，而业务领域专家是不能提供这些的。
SA应该比业务领域专家更有价值，因为SA可以在系统分析业务领域的基础上帮助业务领域专家完善业务流程。
SA应该明确的知道软件的价值。
Hello nick
其實，我這一篇文章發表出來，就知道會有許多不以為然的批判。 🙂
不過，藉此思考 SA 該具備什麼樣的基本功夫、所擔任的角色與定位 …等，提供另類的參考。 ~_^
『軟體設計，也是一門專業的領域，而這一門領域，其門檻絕對不會來得比其它領域還要容易，對工程、管理、邏輯、心理、藝術等等，均需用心研究思考與學習』。有所感。