最近在寫 ZDNet 專欄文章的時候，找到過去同人在點空間討論區回應克明兄的一篇文章，主題是討論有關系統分析與設計人員的角色與定位。克明克認為系統分析與設計人員是著重系統內部的分析與設計，而系統外部的需求分析應該是由專屬的需求分析人員來負責。
他提到一般軟體公司對系統分析人員的角色定位太過模糊，應該正確地將系統外部的需求分析與系統內部的結構分析作區分，需求分析由 RA 負責；結構分析由 SA 負責。如此，才能界定與釐清系統內與外的工作。
如此的軟體開發角色定位，乍看之下似乎權責分明，但實際上按照這種方式進行軟體開發卻常會面臨一些問題。這篇文章就是同人在點空間討論區提出的看法，後來經過克明兄的請求，我也以那篇文章的內容登在克明兄的網誌中當作對他文章的迴響。
而這一陣子再次看到這篇文章時，突然覺得應該將它在網誌中登出來，以明確呈現出個人對這個主題的看法。不過，同人想在登出這篇文章之前先提出我最近對軟體開發角色定位所體會到的兩個觀點。
第一個觀點是有關於需求分析人員的看法。雖然在台灣大部分的軟體公司都沒有明確地定義需求分析人員的角色，但事實上，這個角色是真實地存在於軟體開發過程的。我說的並非指系統分析人員身兼需求分析師的身份，而是指客戶或軟體使用者的代理人，例如產品經理或業務代表。他們會告訴系統分析人員系統該做些什麼，但卻不見得可以提出合理的使用者需求觀點。
其原因除了可能是他們欠缺需求分析的能力外，更大的原因是利益不相容的現象導致他們很難與系統分析人員進行良好溝通。顯然，明確地區分出需求分析師的角色並不一定能夠讓軟體開發角色定位更清楚，尤其當系統分析人員聽到「客戶永遠是對的，所以我是對的」的言論時，他們如何能寄望需求的產出有品質可言？
另一個觀點是有關於系統設計人員的看法。同人在過去曾經聽過一種有關系統開發角色定義的說法，認為由需求分析師（RA, requirement analyst）分析需求，而所謂的 SA 應該是 system architect 而不是 system analyst；其所持的理由是系統不是分析出來的，而是設計出來的。同人過去曾有一段時間受到這種說法的影響，這樣的觀點其實與克明兄的論述邏輯是貼近的，但當深入地思考後會發現這樣的觀點是不完備而有問題的。
沒有錯，系統是設計出來的而不是分析出來的。但為什麼需要設計呢？如果沒有透過對問題的分析，我們如何可以清楚地找到設計的主題，滿足利害關係人的需求呢？尤其是對於複雜的軟體應用系統而言，其複雜性是由需求與技術的不確定性的交互作用所產生的，必須從業務、組織、系統、流程等各層面觀點，彼此交織融合才能勾勒出軟體系統的真實輪廓。
因此，所謂的系統分析其重點並不在結構的設計而已，而在於對問題領域的分析才能依據問題脈絡提出可行的方案，而且系統分析不單只是考量技術觀點，還包括了業務、成本、甚至有時候還要注意法律、政策等層面的考量。
以下就是我當年在點空間回覆克明兄有關軟體開發角色定位的這篇文章。
克明兄此篇文章提出了對SA/SD的一些假設，然而這些假設是否可當成軟體開發角色定位的結論？個人覺得有些疑問，於是上網找了一些資料，從這些資料再加上我個人的經驗及觀點做推論，看來似乎並不能支持克明兄的論點，提供如下大家參考。
依據教育部國語辭典查到下列術語～
「系統」有兩義：(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.
（系統分析師設計或修改某資訊系統以滿足系統使用者需求。系統分析包括調查程式的可行性與成本、產出文件及在設計階段測試系統雛型。）<job> Study of the design, specification, feasibility,cost, and implementation of a computer system for business. What a systems analyst does.
（職務，系統分析師是研究用於商業用途的電腦系統之設計、規格、可行性、成本及實作。）
上述提到可行性分析及規格是屬需求工程（SWEBOK稱為需求流程）的一部分，需求工程一般包括可行性分析、導出需求、分析需求、規格及需求確認。顯見一般對系統分析的定義是包括了需求面，SWEBOK提到「需求流程不是離散的軟體生命週期之前端活動；而是從初始於專案開始並貫穿整個生命週期，不斷精煉的一個流程」，所以需求訪談與需求分析是交錯反覆進行的，專案必須兼顧到利害關係人的每一個需求，如果無法兼顧則必須要有所取捨，這就是分析需求要做的事，把需求和系統分析分開對系統設計概念的完整性與一致性會造成風險，而且也是不切實際的做法。
而在實務上，開發軟體所投入的資源是有限的，如何用有限的資源完成專案目標是最重要的一件事，多了需求分析師的資源，卻別忘了溝通界面也增加了，這樣的成本花費是否符合專案效益？克明兄對SA/SD的假設應是基於良好的軟體開發流程，而開發成員彼此的溝通是順暢沒有問題的，否則就算你把責掌切分的很清楚，問題還是會出在溝通協調上，如果溝通順暢是難以做到的，把工作切得太細不是明智之舉。
