謝謝您發表了這麼詳細的回覆。

>但我完全不能同意同人「把需求和系統分析分開對系統設計概念的完整性與一致性會造成風險，而且也是不切實際的做法。」
這一點我反而與同人的想法是差不多的。

>其中一個最被廣泛採用的就是軟體驗證與確認
這點我倒是蠻認同您的看法，甚至呢，我們是 "Test First" 呢。

從頭到尾的標的都是需求，相當不錯，這應該是以需求導向的開發模式；不過切記，若不自覺被需求牽著鼻子走，那反而是需求先行的方式，那挺危險的。(需求變動性與維護的議題)

我以我們公司作為實際例子。由於我們是子公司，會將母公司的專案外包，我們進行資訊顧問的角色。

在系統開發的過程中：進行需求分析、系統分析、系統設計的是三組不同的人。

我同意同人的觀點「所以需求訪談與需求分析是交錯反覆進行的，專案必須兼顧到利害關係人的每一個需求，如果無法兼顧則必須要有所取捨，這就是分析需求要做的事」。

但我完全不能同意同人「把需求和系統分析分開對系統設計概念的完整性與一致性會造成風險，而且也是不切實際的做法。」

一個進行系統開發的系統，依靠的是這個系統的規範、流程、介面，不是靠某個人的參與，因為當開發標的的規模很大時，就必須作需求和系統分析的切割，因為需求分析的標的有質和量的限制。質是指Domain Knowhow，量是指開發的規模。當開發的規模夠大時，就必須有一個能支持開發標的的開發系統。這是為什麼系統工程會在近幾年大行其道的原因，不論是CMMI、ISO或是其他的（軟體）開發系統。

因為這些系統的假設是「人是靠不住的」，所以他們的方法能瀰補人為的不足，因此設計了許多的方法。

其中一個最被廣泛採用的就是軟體驗證與確認( V&V )。

驗證的工作可以在生命週期中任何活動的期間來進行…
確認則是在生命週期中任何活動的最後…
驗證與確認活動有許多個層次，會就不同的產品/工作產品、不同的目的，而邀請不同的人員參與，這些人員涵蓋合約的甲乙雙方各個不同層次、工作領域的人員…

我們公司會接類似甲方監工的案子，通常會依照產品的特性，將產品切割成數個小單元分批進行驗證與確認。
由下一個階段的「接收者」「驗證」目前階段的「工作產品」對於需求的符合性；
由上一個階段的「產出者」「確認」目前階段的「工作產品」是否符合使用目的；
同一階段的Peer，則以平行的觀點，定位（確認）雙方角色目前的「位置」是否有偏差。
上/下一個階段的人員，則不限甲/乙雙方的角色，只要能達到目的的角色，我們就會邀請他參加，這樣，我們可以在一次的會議、討論中，推進一個小單元的「生命週期」。

所以，只是每個階段的產出都是建立在上個階段的投入，每個階段的差異是工作方法與觀點不同，但我們從頭至尾的標的都是需求。

這樣花錢嗎？還挺花錢的！但效果和以前相比還是比較好，因為總成本降低了。

看來下次與木金見面時，我們可有得話題好辯論了。

太好了。 ^^

依據教育部國語辭典查到下列術語～

「系統」有兩義：(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的假設應是基於良好的軟體開發流程，而開發成員彼此的溝通是順暢沒有問題的，否則就算你把責掌切分的很清楚，問題還是會出在溝通協調上，如果溝通順暢是難以做到的，把工作切細不是明智之舉。