我常在許多軟體公司與專案經理們討論軟體人員的職掌時，發現到，耶？ 怎麼我所認知的 SA/SD 與他們實際的工作內容大大不同。嗯，所以我想就針對 SA/SD 來給個正名與定位吧。
SA, 系統分析師(System Analyst)，是對設計中(Under Design)的系統來作分析，既然是分析，那麼，應該是需要 “剖開” 系統內容，來對其系統內部的結構組成元素，以分析其脈絡。所以我覺得系統分析師，也可以稱之為 “結構分析師(Structure Analyst)。
系統分析師的工作，是著重在系統的內部，應該是要能找出與描述系統組成結構的靜態(Static)元素，並利用元素，動態組合以滿足系統外部的功能需求。也就是說，靜態面的結構元素，與功能面的行為(Behavior)描述，均是屬於系統分析師的範疇。幾個主要的產出，包括類別(Class)圖、循序(Sequence)圖、資料庫的 E-R(Entity-Relationship)圖，是 SA 所該負責的，而且，上述的產出是偏向於建立領域概念的模型(Domain Conceptual Model)，並非為與平台相依的軟體規格模型(Software Specification Model)，與平台相依的軟體模型，是屬於 SD(System Designer) 的範疇。
而一般軟體公司對 SA 的定位，是在於對客戶端操作者(Operator)與領域專家(Domain Expert)的需求訪談。但是，需求面是屬於系統外部的功能面觀點，我一直不認為這是屬於 SA 的工作，正確地來說，這應該是 “需求分析師(RA, Requirement Analyst)” 的範疇。
有趣的是，我發現到，一般對 SA 的要求，還需要包括對使用者介面(User Interface)的設計，為何會需要 UI 的設計？ 我想應該是與 SA 訪談的對象，都比較偏於層級比較低的終端操作者，而這些操作者，會很重視 UI 的操作，卻很少能正確地說明系統真正要的功能，往往都是以局部操作者的角度來看待系統。
我發現到，一般軟體公司對 SA 的角色定位太過模糊，以致於 SA 根本就搞不清楚他們要做的是到底是屬於系統外面的工作，還是屬於系統內部的工作。如果能正確地將系統外部的需求分析與系統內部的結構分析作區分，需求分析由 RA 負責；結構分析由 SA 負責。如此，才能界定與釐清系統內與外的工作。
至於 SD，系統設計師(System Designer)，焦點仍就於系統內部的結構，與 SA 所不同的是，SA 所建構的是屬於偏向於領域的概念模型；而 SD 則是根據領域模型，再配合實體的平台，如 .NET or J2EE的框架(Framework)，考量其效能、穩定、分散與安全性等，所建構而得的軟體規格模型。SD 的主要產出，仍包括了類別圖、循序圖以及 Database Schema，而這些產出，都會與實體的平台相依。例如，具化的軟體模型是以 J2EE 來實做，而就永續層(Persistent Layer)設計考量，SD 是以 Hibernate Framework 來實做，以橋接領域物件與資料庫的永續儲存。
不過，軟體公司對 SD 的定位，反而僅在於對資料庫 Schema 的設計。其實呢，對於 E-R 與 DB Schema，也並沒有相對切分邏輯(Logical)與實體(Physical)的層次(Layer)。邏輯與實體之分，簡單的說，實體的 DB Schema 會考量到與現實所使用的資料庫系統的特性相關，諸如欄位資料型別的定義、Index and Constraint 的設計等…。
一個基本的結論，系統外部的功能性需求分析，係由 RA 所負責。而系統內部的分析與設計，是交由 SA 與 SD 來負責的，而 SA 與 SD 的界限，可以以是否有與實體的平台相依來界定。我們也可以以兩句話來說明分析與設計的關係：
“Do the right thing (分析)”and “Do the thing right (設計)”。
所以這篇的重點是….？
我個人在矽谷工作，也是從事科技創新這行，有時候說真的，看到這種文章的第一個感想是：whats your point? what are you trying to say/suggest/remedy?
重點是：擔任 SA/SD 的角色時，所看待系統開發的角度與其應對的職掌~
這位小丹讀者：不能只是從自身的工作去看待許多事情，那會使得視野變得較狹隘。
Hello sune:
謝謝您發表了這麼詳細的回覆。
>但我完全不能同意同人「把需求和系統分析分開對系統設計概念的完整性與一致性會造成風險，而且也是不切實際的做法。」
這一點我反而與同人的想法是差不多的。 🙂
>其中一個最被廣泛採用的就是軟體驗證與確認
這點我倒是蠻認同您的看法，甚至呢，我們是 “Test First” 呢。
從頭到尾的標的都是需求，相當不錯，這應該是以需求導向的開發模式；不過切記，若不自覺被需求牽著鼻子走，那反而是需求先行的方式，那挺危險的。(需求變動性與維護的議題)
在2年後才後到這篇有內容的文章與精闢的回覆。
我以我們公司作為實際例子。由於我們是子公司，會將母公司的專案外包，我們進行資訊顧問的角色。
在系統開發的過程中：進行需求分析、系統分析、系統設計的是三組不同的人。
我同意同人的觀點「所以需求訪談與需求分析是交錯反覆進行的，專案必須兼顧到利害關係人的每一個需求，如果無法兼顧則必須要有所取捨，這就是分析需求要做的事」。
但我完全不能同意同人「把需求和系統分析分開對系統設計概念的完整性與一致性會造成風險，而且也是不切實際的做法。」
一個進行系統開發的系統，依靠的是這個系統的規範、流程、介面，不是靠某個人的參與，因為當開發標的的規模很大時，就必須作需求和系統分析的切割，因為需求分析的標的有質和量的限制。質是指Domain Knowhow，量是指開發的規模。當開發的規模夠大時，就必須有一個能支持開發標的的開發系統。這是為什麼系統工程會在近幾年大行其道的原因，不論是CMMI、ISO或是其他的（軟體）開發系統。
因為這些系統的假設是「人是靠不住的」，所以他們的方法能瀰補人為的不足，因此設計了許多的方法。
其中一個最被廣泛採用的就是軟體驗證與確認( V&V )。
驗證的工作可以在生命週期中任何活動的期間來進行…
確認則是在生命週期中任何活動的最後…
驗證與確認活動有許多個層次，會就不同的產品/工作產品、不同的目的，而邀請不同的人員參與，這些人員涵蓋合約的甲乙雙方各個不同層次、工作領域的人員…
我們公司會接類似甲方監工的案子，通常會依照產品的特性，將產品切割成數個小單元分批進行驗證與確認。
由下一個階段的「接收者」「驗證」目前階段的「工作產品」對於需求的符合性；
由上一個階段的「產出者」「確認」目前階段的「工作產品」是否符合使用目的；
同一階段的Peer，則以平行的觀點，定位（確認）雙方角色目前的「位置」是否有偏差。
上/下一個階段的人員，則不限甲/乙雙方的角色，只要能達到目的的角色，我們就會邀請他參加，這樣，我們可以在一次的會議、討論中，推進一個小單元的「生命週期」。
所以，只是每個階段的產出都是建立在上個階段的投入，每個階段的差異是工作方法與觀點不同，但我們從頭至尾的標的都是需求。
這樣花錢嗎？還挺花錢的！但效果和以前相比還是比較好，因為總成本降低了。
哇！！ 木金老大真是用心，能提出如此詳盡的資料來說明系統分析師的角色。
看來下次與木金見面時，我們可有得話題好辯論了。
太好了。 ^^
此篇文章提出了對SA/SD的一些假設，然而這些假設是否可當成軟體開發角色定位的結論？個人覺得有些疑問，於是上網找了一些資料，從這些資料再加上我個人的經驗及觀點做推論，看來似乎並不能支持克明兄的論點，提供如下大家參考。
依據教育部國語辭典查到下列術語～
「系統」有兩義：(1)同類事物，按一定秩序相連屬，而自成一整體。(2)兩個或兩個以上相互有關聯的單元，為達成共同任務時所構成的完整體。
「系統分析」則為：對一個具有某種意義或功能的集合體，如活動、過程、方式或技術，所進行的全面分析，分析的結果指出應採取的步驟、順序、需要的條件以及和其它活動間的關係等。
「系統設計」則為：針對系統要完成的目標及現有的資源作評估考量，設計各種解決方案的過程。
由上解釋不難發現兩件事～
(1)系統是結構化的整體（理性觀點，機械論），但也是具有協調性的整體（有機觀點，生物論）。
(2)分析的結論是一種what-if的計劃，目的是找出可行解，而設計則是需達成此計劃的目標並依據限制而作出設計。
所以系統分析師所分析的系統不應只有系統內部，還應包括系統外部，只管剖開系統內部的做法是忽略了系統的有機觀點，這也是軟體開發時常見的分工理論迷思。
也上網查了英英字典對system analyst的定義～
Also called systems analyst.A person who designs or modifies an information system to meet the requirements of its end user.System analysis includes investigating the program’s feasibility and cost, producing documentation, and testing a prototype of the system at several stages of its design.
系統分析師設計或修改某資訊系統以滿足系統使用者需求。系統分析包括調查程式的可行性與成本、產出文件及在設計階段測試系統雛型。
Study of the design, specification, feasibility, cost, and implementation of a computer system for business. What a systems analyst does.
職務，系統分析師是研究用於商業用途的電腦系統之設計、規格、可行性、成本及實作。
上述提到可行性分析及規格是屬需求工程（SWEBOK稱為需求流程）的一部分，需求工程一般包括可行性分析、導出需求、分析需求、規格及需求確認。顯見一般對系統分析的定義是包括了需求面，SWEBOK提到「需求流程不是離散的軟體生命週期之前端活動；而是從初始於專案開始並貫穿整個生命週期，不斷精煉的一個流程」，所以需求訪談與需求分析是交錯反覆進行的，專案必須兼顧到利害關係人的每一個需求，如果無法兼顧則必須要有所取捨，這就是分析需求要做的事，把需求和系統分析分開對系統設計概念的完整性與一致性會造成風險，而且也是不切實際的做法。
而在實務上，開發軟體所投入的資源是有限的，如何用有限的資源完成專案目標是最重要的一件事，多了需求分析師的資源，卻別忘了溝通界面也增加了，這樣的成本花費是否符合專案效益？此篇文章對SA/SD的假設應是基於良好的軟體開發流程，而開發成員彼此的溝通是順暢沒有問題的，否則就算你把責掌切分的很清楚，問題還是會出在溝通協調上，如果溝通順暢是難以做到的，把工作切細不是明智之舉。
論 SA/SD 的角色與定位