很多資訊軟體委外案的 RFP 都要求軟體開發商撰寫「工作日誌」，以及「需求訪談紀錄」、「軟體需求規格書」（或系統分析報告）、「軟體設計說明書」等文件，請問它們的必要性與價值為何 ?

最近有一些新式的軟體開發方法，宣稱可以不需要上述繁瑣的文件，因此很快就可以開發出符合業主需要的軟體系統，請問這樣子好嗎 ?

我們目前有一個兩千多萬元的資訊系統委外案，承包單位是國內著名機構已通過 CMMI Level 3 的單位，宣稱採用 Unified Programming 模式開發軟體，可用 Papid Prototyping 方式直接與使用者溝通需求，一邊開發一邊修改可以縮短軟體開發的時程，因此對於上述的軟體開發文件常常是以應付 RFP 要求為主，最近因「軟體需求規格書」被監造單位審查不通過，要求加強以書面方式跟我們使用單位進行軟體需求確認工作，而且每個使用案例（Ues Case、含畫面）都需要使用單位代表簽認，軟體開發進度因為需求再確認工作（含修改更正後再請使用單位簽認）而延遲了近一個月，請問監造單位的堅持有必要嗎 ?

關於軟體開發文件的價值，如果就成本而言，可能就是實際撰寫這些文件所花費的工時。以下是我過去曾經遇到的三個實際案例，大家可以想想軟體開發文件的價值為何 ?

案例一：有個一千六百萬元的政府資訊軟體委外案，軟體開發進行了六個月後，因法律糾紛而中止，軟體開發商因而向業主求償已投入的需求訪談、系統分析、軟體設計等工時費用，但業主認為軟體開發商浮濫虛報工時數，要求提出「工作日誌」供公正第三者審核，軟體開發商卻拿不出像樣的文件 …… 目前此案還在法院審理中。

案例二：有個五百多萬元的民間軟體外包案，當軟體開發完成後，卻被其競爭者控告軟體有抄襲侵權之嫌，上了法院後，控告者提出完整的「研發工作日誌」、「軟體設計規格書」等文件證明其研發智財權，而被告一方委託的軟體開發商卻拿不出相當的軟體開發文件，證明其軟體開發的過程 ……

案例三：有個一千八百多萬元的政府資訊軟體委外案，因為軟體開發商的需求訪談報告、系統分析書、軟體設計書等一直通不過監造單位的審查要求，最後軟體開發商竟以「進度將嚴重落後」、「不排除拒絕承包」為由說服業主讓步，直接開始進行軟體設計工作，結果軟體開發完成後果然一直不符合業主需求而一改再改，此案合約應該於九十四年十二月底驗收，到了九十五年底的時後，軟體開發人員已陸續離職，僅剩下了X先生一人，很多修改都必須由X先生重新撰寫程式才行，此案因而拖延至今還未驗收，如果X先生也離職，這個一千八百多萬元的資訊系統後續將很難修改維護 ……

由以上三個實例可見，軟體開發文件的價值，可能不僅止是實際撰寫這些文件所花費的工時吧。

前文提到「關於軟體開發文件的價值，如果就成本而言，可能就是實際撰寫這些文件所花費的工時。」這個成本究竟應該是多少呢 ? 我知道有一個實際案例，不妨跟大家分享：

幾年前軍方有一個數千萬元的資訊系統委外案，由台中某大知名的資訊系統整合公司得標，RFP中有要求得標廠商必須依照 IEEE/EIA 12207規範，交付約二十餘種技術文件，得標廠商沒想到軍方是玩真的，交付的文件通通被認定不合格，因此只好向外尋求協助，好不容易找到一位曾經在美國服務多年的IEEE/EIA 12207專家，據說開價要1400萬元，最後只好花幾十萬元找了幾位國內學者專家授課指導撰寫，結果此案拖到最後還是沒有被驗收，這家公司後來已經解散，負責人目前已到了中國大陸。

由此可見，投標廠商對於RFP的軟體技術文件要求千萬不可掉以輕心。不過話又說回來，在『講 CMMI 笑話給你聽』討論區的蔣效化先生談到「除非政府有心理準備所有IT相關的採購專案必須依據PA來概估成本，否則政府預算不增編，卻要廠家增加工作事項，這就是不知民間疾苦…」，不知當初那個軍方數千萬元的案子在編預算時，有沒有考慮到二十餘種技術文件的製作成本。

今天中國時報 [時論廣場] 刊出貴會前理事長程家麒先生的文章，內文也有提到軟體技術文件的重要性 :

以專業立場來看，民國百年「電腦年序錯亂」只是個技術問題，對政府與企業而言，若能妥善處理，危機其實也可能是轉機。因為目前尚未因應民國百年「電腦年序錯亂」的資訊系統，多為早期設計的系統，當時的軟體工程觀念尚不成熟，多半沒有完整的軟體技術文件，如今要修改資訊系統就如同維修建築物管線卻沒有線路圖，恐怕很多資訊系統都必須重新開發；但是現在重新設計資訊系統時，已經有了軟體工程和技術文件的國家標準，可依循標準規範來施作，日後的維護修改也可以一勞永逸。

現在距離民國一百年元旦已剩下不到五百天，雖然時間緊迫，但筆者仍須提醒，無論修改舊系統或重新設計新系統，都需要透過周延的測試規畫設計來進行嚴謹的系統測試。尤其是事關民眾權益的自動化或資訊系統，妥善的風險管理和備援應變作業規畫更不可少。否則一旦發生意外狀況，輕者可能影響服務品質和聲譽形象，重者可能造成嚴重傷害或損失，絕不能掉以輕心。

以上謹供大家參考。

如果小弟看到RFP中"要求得標廠商必須依照 IEEE/EIA 12207規範，交付約二十餘種技術文件"的案子，再大的利潤一定不會去投標....

因為只有幾千萬的案子並不大，"(幾乎或近)全套文件照交"對籌獲者及供應者或發展者言，其風險均是極高的

編撰這份RFP的軍方單位或承辦者，恐怕並不懂得自古以來各種軟體規範(如1679→1703/2167→498→12207)的精義所在

這樣的原因，我想是因為大家誤解、或者連標準的條文都沒有弄清楚的關係。小型的專案按照IEEE/EIA 12207是不需要寫到那麼多文件的。更何況，所稱遵IEEE/EIA 12207寫文件時，根據IEEE/EIA 12207.1所提列的文件，共有八十多項，有較為明確之的內容範圍者，亦有三十多項，絕非所提的二十多項。認為是二十多項文件，應該是受到MIL-STD 498影響的關係吧。
IEEE/EIA 12207也好、ISO/IEC 12207或者CMMI-DEV也罷，使用者對於tailoring學習，是一項重要的工作，沒有學會tailoring之前，隨意訂出文件要求，恐怕會是專案成功的一項傷害吧。

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

關於這個問題，我提供一些方向讓大家思考一下。

要回答這個問題“軟體開發文件的必要性與價值？”之前，先要為“文件”做個定義，否則就會發生“鷄同鴉講” 的(這是軟體開發專案中最容易發生的事，也是軟體工程要解決的基本問題之一)事了。個人以為軟體開發中的文件，代表的是一“書面的資訊”。有了這樣的理解，接著，我們要問的是：軟體開發專案中除了“編寫程式”之外，還有哪些工作？也就是“需求分析”、“軟體設計”、“型態管理”、“品質保證”、“測試”乃至“問題追蹤與管理”、“專案規劃、監控”、“需求管理”…這一拖拉古有的没的，是不是軟體開發中的“工作”？如果，它們不是工作，那就没有討論下去的必要了。如果，這些是必要 (RFP要求) 的工作，那麼這些工作的結果(產出)不是文件，那又是什麼？我們如何認定專案中已“正確地”執行了這些工作？還有為什麼要執行這些工作？也就是這些工作的結果，是做什麼用的？如果，它沒有作用，那為什麼要做這件事？如果，它有用。那又是給誰用的？什麼時候要用？用它有什麼好處？我們要如何檢查它已被“正確地”執行了？還有我們如何知道工作已經完成了？我們如何管理這些已完成的工作結果？…

以上這些問題，如果您想通了，“軟體開發文件的必要性與價值？”的答案也就呼之欲出了，那您可以自己再問自己一些更深入的問題(譬如：業主要如何規範這些工作的成果？我們如何再利用以往類似工作的成果？我們如何…)。如果，您想不通，那就多看看、多聽聽，也再多想想吧。

順祝 平安愉快！

周茂松 敬上

再提供兩個觀點，讓大家思考一下：

1. 一個成功的軟體開發組織，有許多過去的工作成果可資“再利用(reuse)’，而卻只有少數的現前工作須要“重工(rework)”。反觀失敗的軟體開發組織正好相反，過去已完成的工作只有很少很少的部份可以“再利用”，而現前的工作又有太多太多的部份須要“重工”才能被客戶接受。其原因何在？

2. 如果，我們把“文件”這玩意從軟體工程中抽離。那麼，請問軟體工程還剩下什麼？沒有了軟體工程，又如何保障軟體的品質？如果，從CMMI中抽離軟體工程的概念，CMMI又還剩下什麼？各組織努力花大錢企望通過CMMI的評鑑與提昇評鑑等級，卻又不重視文件，又代表什麼？

最後，還是祝福大家

心想事成！

周茂松　敬上

是否有CMMI-Level x公司能分享完成一份Software Requirements Specification所需投入之資源?

1.開發案合約的roles只是12207(life cycle)中的一部份(籌獲方與供應方/發展方爾)，全部(開發案所需交付之)"文件"加總起來(就算未經裁適全數照標準列，且考量轉移至使用方與後續維護方，亦應)不致於有八十幾種那麼多，....

2.講到reuse的諸多"好處"....書上是說得很好聽啦，....實務上並不盡然...除非當初就是為reuse而作，否則有時代價還不如重寫....

3.講到"文件"與"軟體工程"...誠如周兄所言是也！