小弟在"工作條款(SOW)"討論串中，曾提及：

引文:
在此舉個例子：
數年前有位軟體業的朋友，在閒聊的時候，提到：在行政院下某部會的某局的一個案子，其RFP中有條敘述(此條敘述屬於系統需求規格)，"系統應提供問題回報機制"。這項需求廠商的認知是：就是在該系統中提供幾個頁面，讓使用者於該系統發生問題時可以回報系統問題而已。而甲方在RFP中，對於該項需求亦無進一步說明(當然更不會有PWBS與WBS字典，可以參考)，而也順利發包了，而得標廠商亦依照其所認定的範圍實作系統。問題是當專案進入驗收期的時候，甲方才說，這個"問題回報機制"，範圍並非只在此新建系統內，該是該局內所有系統的問題回報均要透過此系統收容處理，然後，其功能應該還包括.....云云。結果，廠商專案驗收延後了數個月，同時教育訓練的範圍亦因而擴大，也使廠商增加了數個月的成本，還未包括因為專案延遲的罰款。

當然在這個案例當中， "系統應提供問題回報機制"這項需求有可能是抄來的。因為該局所新建的系統，在地方政府相對已經建立，該局的RFP許多需求是抄襲而已(當然，其說法可以是--如此才能與地方政府的相關系統"無縫接軌")，獲取者大概也不會真的(或有時間)逐項去深究這些需求是否恰當，瞭解這些需求對於中央級機關而言，是否充分，或者該有不同的作法。而任何審查RFP的人員，面對龐雜的需求項目，其實也無從理解起，更看不出所謂的適當性，只能依其經驗判斷而已。

如果，在RFP的格式裡，強制性地要求列入專案WBS與WBS字典，並就計畫風險考量，將"主要任務系統"分解至WBS第五層，亦即CSCI層次，那麼，需求描述不充分的問題立刻就會浮上檯面。因為，需求撰寫者或審查者，會發現這個所謂的"機制"，只有一個"標題性"的敘述，而沒有實質詳細的需求。就算撰寫RFP的人員疏漏了，在相關審查人員看到沒有按照規定分解到第五層時，也可以立即指出可能的問題來，再者經由RFP需求、WBS、WBS字典的三方交叉對照，問題很容易就浮上檯面，更何況WBS是一項循著系統工程需求過程的結果，本身就可以協助計畫人員思考問題，及提出計畫需求。對於RFP審查人員而言，看到WBS，很快就能對RFP的範圍有完整的概念，並對獲取產品(要開發之新系統)有一定程度的理解，將該RFP的需求與邏輯有效連接，如此也能降低RFP審查人員的工作負荷。而對於有意的投標廠商而言，也可以經由RFP需求、WBS、WBS字典的三方交叉對照，很快就能發現出沒有詳細說明的部分，立即提出請甲方澄覆，以免誤判專案的期程、品質、與成本。

廠商常常抱怨的是甲方的產品需求(亦即，該產品應具備什麼功能、要達到什麼樣的品質需求)講不清楚、寫不清楚。但是若問題甲方為何產品需求、品質需求講不清楚，有一種說法是：開放讓乙方有開創性的作法。但是環顧所有的標準，包括國家標準、國際標準、IEEE標準、美國軍方標準等，所開放給乙方有開創性作法的，均是開發的方法論、技術，但是規定一定要說清楚的還是最終產品的需求。因為把需求說清楚是"甲方的責任"，也是"專案成功的最重要的第一步"。而WBS的運用，有助甲方將專案產品需求定清楚。

----------------
引文: