「委外問題多，品質不符是元凶」這是資訊傳真週刊第738期的標題，該期引述行政院主計處發布的委外表滿意度報告指出：委外問題發生的類型包括「需求增加或變更(76.3%)」、「進度落後(62.7%)」、「廠商人員異動(49.2%)」、「廠商品質不符需求(41.8%)」，而認定品質是委外問題的元凶。也有業界先進認為「與其談委外品質，不如對委外時程的掌控更加著墨」。當然其中也有委方認為在與業者簽訂合約時，多半對品質都能加以限制，不過，「何時完成，反而是考驗」... 云云。

　　依筆者的觀察，委外的品質的確是個問題，但品質問題是一個結果，源於或歸因於前面所說的：「需求增加或變更」、「進度落後」、「廠商人員異動」、「廠商品質不符需求」，最終使資訊服務委外以遺憾收場。但是，前面這些問題的原因何在？歸結其原因，其實就是委外的需求不清，而這個問題多半是由委方所造成的，委方的需求不清，預算編列不實，當然後面就問題多多。而談到「需求」的議題，就不能不談談「系統分析師」這個角色。這裡談的系統分析師，指的不單是供應商執行產品開發團隊裡的SA，也包括委方的系統分析師。

　　我們假設一個狀況，某政府機關編列了五百萬元的預算，委外開發電子公文系統。在RFP中述及了許多且完整的功能需求，並且要求系統應俱備「友善的使用者介面」、「方便的操作流程」、「強固而且完整的資訊安全機制」、「資料處理要有高度的完整性」、「快速列出公文的本文及附件」。委外單位提出這樣的系統需求，供應方在評估專案的成本與期程的時候，其實是相當困難的，因為這個專案及系統的需求(包含非功能性需求)很不清楚。供應方如果承包了此案，做到失敗是必然的。 或許委外單位會認為，因我的專業素養本來就不夠，所以需求提得不好是應該的，而且有供應方進來承接，顯然這個RFP是可以接受的，因此，做得不好或品質有問題，其責任就不在委方，而是承包商了。但這樣的想法，並無法為甲方需求不清找到合理的立足點。

　　根據政府採購法及軟體生命週期過程國家標準，委外單位有責任要把需求說清楚，即「應依功能或效益訂定招標文件」，其所謂的功能或效益的範圍請參閱政府採購法相關條文。在專案當中如果需求(包含功能性與非功能性的需求)非常清楚的話，專案的成功是可以期待的。而現在委外的專案之所以問題多多，總體來說就是因為需求講不清楚，因此，一步錯後面的每一步都有問題：需求不清、預算不足、專案沒有充分的執行時間。或許有人會說，我們在提出需求的時候，都有相關領域的專業人員或是資訊單位人員協助，但事實是，這些人員的參與似乎沒有發揮多少功效，因為執行系統分析的人員，並沒有扮演好應有的角色。

　　以目前而言，不論是政府部門的系統分析師，或者是供應商開發團隊的系統分析師，其最擅長的多是軟體需求分析及設計的技術，他們在結構化分析設計，或是物件導向分析設計方面的技能都不差，但是事實上，這些技術在談到最初的需求分析時，似乎是不太管用的(當然個中好手亦所在多有)。委外單位在提出需求時，多數都是到處去打聽有那些親朋好友的單位做過類似的系統，然後東抄一點西截一段，最後來個乾坤大挪移，就完成了一份建議徵求書（RFP)，審查這份RFP的長官看到洋洋灑灑一大篇的需求與規格資料，不免會問上兩句「提出這些，有沒有問題啊？」而承辦人會「很老實」地回答：「這裡面的東西○○單位及ＸＸ單位也是這樣做的，沒有問題的....」於是長官就想啦：「別的單位可以做出來，那麼技術上是沒有問題的，應該是OK的。」於是就放行了。由於缺乏完整的思考與邏輯推論，這樣出來的東西，當然是沒有辦法符合委外單位的需求，到後來常常發生需求變更是不足為奇的。到了供應商的系統分析師這端，開始做系統分析時，也是把功能需求確定，透過需求訪談，將軟體的功能需求弄清楚，通常前述的：「友善」、「方便」、「強固而且完整的」、「高度的完整性」、「快速」等要求，會是等到產品做出來後，再去問委外單位的意見，這個時候就有可能會發現，原來整個產品的架構根本是錯的，無法達到委外單位的要求。問題是東西做出來了，時間也超出了預定的時程，而委外單位也有預算執行的壓力，因此，只好看看合約中的功能是否都達到了，如果達到了就結案吧。事實上，一個稱職的系統分析師（SA)應該可以將客戶所提的：「友善」、「方便」、「強固而且完整的」、「高度的完整性」、「快速」等要求，轉化為具體的物理性需求，而且是可以計量的，可以測量出來的，可以驗證的。

　　不論是合約甲方或乙方，一位稱職的系統分析師除了要會分析與設計的技能(需求的展現方式，例如DFD、UML、IDEF...等等)，及具備撰寫技術文件(需求規格書)的能力外，還需要具備哪些本職學能呢？筆者認為，一個稱職的系統分析師，應該要有系統思考的能力、具備系統觀，在需求發展階段，應該要能夠考慮到軟體品質的課題，此一部分可參考CNS 14948-1 品質模型(ISO/IEC 9126系列標準)，亦即應具備功能性、可靠性、可用性、效率、可維護性及可攜性等軟體品質因子及其所屬次因子的知識，了解這些因子對於所開發產品的意義，這些因子對於客戶、使用者及更廣大的利害關係人的意義。並將這些品質因子予以具體化、數量化為功能性與非功能性的需求，然後按選定的工程程序與步驟，進一步將這些需求配置到系統組件上，並基於可測試性及可實作性，做折衷與調整，使需求配置達到平衡。如此，方可使後續各別的設計，例如軟體設計、硬體設計、人工流程設計有所依據，最終產品的變動性也將會降至最低，專案的成本及時程也容易控制。

　　上述結合軟體品質因子的分析設計方法與實務，目前在學校教程中並未成為顯學，然而提升系統分析師在這方面的素質，應該是軟體業界降低專案衝繫、提高專案品質及客戶滿意度、增加獲利，必須要做的投資。因為唯有透過系統分析師本職學能的提升，在專案的早期即確立客戶的品質需求，並將之規劃及實現到產品當中，才能夠有效減少重製(rework)流程，降低專案成本，進而從減少的重製中，獲致更多的利潤。

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

根據統計，導致資訊系統專案無法如期(如預算)完成的四個最常見原因是：
– 缺少與使用者的良好溝通 !
– 不正確或不完整的需求與規格 !
– 不能瞭解使用者真正的需求 !
– 需求與規格的變更及管理失控 !
因此，如何做好資訊系統的需求分析、確認與管理，實為供需雙方的系統分析師及專案經理們非常重要的關鍵任務。

最近我看了一份國內某個已經通過CMMI Level 3 軟體發展部門，為某個政府專案而寫的系統分析書，實在有點訝異與失望。

需求分析首要的挑戰是「要找對人問對的話」，另外就是如何去做專業而嚴謹訪談的紀錄。在這份系統分析書中，我覺得他們做的訪談不僅層次不足，範圍也不夠，而被記錄下來的東西更是少得可憐。要做好系統分析與設計的工作，一定要獲得充分而且明確的資訊與資料才行，如果需求訪談紀錄不正確，參考價值低，未來需求變更的風險就會變得很高，需求管理也更難做。而要做好需求的誘導，需求訪談的工作一定先要有計畫，而且訪談小組的人要先做好功課，最起碼RFP裡的需求項目要先做整理，知道那些是已經知道的，那些是不足的，那些還要再補強，同時也要交叉印證RFP中的東西，需求資料夠不夠完整，是不是一致，在實作上有沒有困難，然後帶著問題去與需求提供者訪談，這樣才會比較週延。

更令人驚訝的是這份系統分析書中的需求規格(SRS)，竟然大部份只是將RFP的相關內容直接貼上去，看不到任何專業的系統分析，而有關功能要求的文字敘述不但說明籠統不易驗證，也都沒有系統效能(Performance)的任何敘述，我真不知道如果根據這樣的系統分析書去設計資訊系統，以後怎麼來驗收 !

一個已經通過CMMI Level 3 的知名軟體發展部門都寫出這樣的系統分析書，我們在系統分析的教育上是不是有問題呢 ? 系統分析師對於軟體工程與品質的學養是否有待加強呢 ?