臺中高等行政法院行政-TCBA,101,訴更一,2,20130620,1

臺中高等行政法院判決
101年度訴更一字第2號
102年5月30日辯論終結
原 告 衛展資訊股份有限公司
代 表 人 張幸助
訴訟代理人 陳峰富 律師
張簡勵如 律師
黃博駿 律師
被 告 台灣自來水股份有限公司
代 表 人 阮剛猛
訴訟代理人 黃仕勳 律師
複代理人 黃興木 律師
上列當事人間因政府採購法事件，原告不服行政院公共工程委員

會中華民國99年7月16日訴0000000號申訴審議判斷，提起行政訴
訟，經本院以99年度訴字第340號判決，原告不服，提起上訴，經最高行政法院以100年度判字第2187號判決廢棄發回，本院更為判決如下︰

主 文
確認原處分、異議處理結果及申訴審議判斷均違法。
本審及發回前上訴審之訴訟費用均由被告負擔。

事實及理由
一、程序事項：本件原告代表人於起訴時原為張欽祥，於訴訟繫屬中變更為張幸助，而被告代表人原為黃敏恭，於訴訟繫屬中變更為阮剛猛，茲據兩造之代表人張幸助、阮剛猛分別具狀聲明承受訴訟，核無不合，應予准許。
復按「撤銷訴訟進行中，原處分已執行而無回復原狀可能或已消滅者，於原告有即受確認判決之法律上利益時，行政法院得依聲請，確認該行政處分為違法。」
行政訴訟法第196條第2項定有明文。
本件原告起訴請求撤銷訴願決定及原處分，惟原處分於民國（下同）99年9月9日開始執行，拒絕往來期限至100年9月8日屆滿，此有刊登資料附卷可稽，因其刊登政府採購公報處分之執行已無回復原狀之可能，原告乃為訴之變更，請求確認原處分違法，核諸上開規定，並無不合，應予准許。
又原告曾因另案遭被告列為拒絕往來廠商並登載於政府採購公報，其起迄期間自99年7月28日起至100年7月28日止，而本件原告列為拒絕往來期間為99年9月9日至100年9月8日，其結束期日與前案結束期日100年7月28日尚差42天。
故原告提起本件確認行政處分違法之訴，如受確認之判決，原告如有損害依法即得向被告請求損害賠償，是原告即有受確認判決之法律上利益，自得提起本件確認行政處分為違法之訴訟，合先敘明。
二、事實概要：緣原告（原名稱為衛道科技股份有限公司）參與被告所辦理「會計管理資訊系統改版委外資訊服務案」採購案，兩造於97年4月3日簽訂「勞務採購契約條款」，包含軟硬體二部分，金額共計新台幣39,179,700元。
嗣被告認原告所交付之硬體設備與契約規範不符且拒絕改正，另軟體部分未照契約規定時限交貨，而予解除契約。
原告不服被告於99年1月13日以台水會字第1745號函（下稱原處分）通知其有政府採購法第101條第1項第12款規定之情事，將刊登政府採購公報，於99年1月27日向被告提出異議，經被告於99年2月6日以台水會字第0990003854號函復異議處理結果，仍維持原決定。
原告不服，提起申訴，經行政院公共工程委員會申訴審議判斷駁回，提起行政訴訟，經本院以99年度訴字第340號判決駁回，原告不服，提起上訴，經最高行政法院以100年度判字第2187號判決廢棄原判決，發回本院更為審理。
三、本件原告主張：
㈠被告所認定之98年9月30日乃本案契約原訂完成程式設計之履約期限，然履約過程中，因被告於確認需求內容後，數度變更及新增需求，依本案契約第7條第3項第4款規定略以「契約履約期間，有下列情形之一，確非可歸責於廠商，而需展延履約期限者，廠商應於事故發生或消失後，儘速以書面向機關申請展延履約期限：……⑷因辦理契約變更或增加履約標的數量或項目。」
被告自應展延合理之履約期間，不得以原訂時程認定原告逾期給付而解除契約：
1.被告於97年12月18日業已確認需求內容：原告於97年11月28日交付「系統需求規格書」（下稱需求規格書）供被告進行確認，被告並於97年12月18日發文確認該內容，原告即據此需求內容設計、開立程式規格。
軟體開發過程係由業主以文字、口頭方式闡述說明其所需要之軟體功能，再由軟體開發業者依據其所認知而開發，由於軟體功能的些微變更都將導致開發程序重大變更，故任何軟體開發案件對於軟體功能之確認實經過極為嚴謹的確認程序。
以本案為例，被告之需求內容，從最初步之招標公告之建議書徵求須知（下稱RFP）之記載，到原告得標後之需求訪談階段，至中期的雛形展示，乃經過雙方一再討論、商議，而形成被告最後所確認之「系統需求規格書」，當此「系統需求規格書」確認後，原告軟體開發之範圍即以此為依據，是否構成新增、變更需求也應以此為標準。
2.本案判斷是否構成新增、變更需求之情事，自應以「功能需求說明書」確認之時點為標準，亦即需求確認後，必須進行以下之作業，以利程式規格設計與程式撰寫：①須針對系統作業功能之數量、意義或定義進行分析。
②就系統功能提出未來系統操作模式之雛形構想說明，與系統之重要編碼原則。
③另於各功能細項中註明特別之注意事項。
④並依據需求階段所確認之需求功能，規劃進行建立主系統及子系統之架構及各功能之流程、人機介面操作設計、資料結構之設計、報表設計等作業。
⑤開立程式規格，絕非被告所稱僅為概括之需求說明，更無變更需求確認之內容而不影響系統設計之理。
故應非以「系統設計規格書」為依據，否則何需有「功能需求規格書」之確認程序。
茲提供其他軟體開發案件之規範供參。
3.被告辯稱應以「系統設計規格書」（下稱設計規格書）確認之時點作為判斷新增、變更需求之時點，顯然混淆「軟體功能需求」與「軟體規格設計」之差異。
查需求功能與程式設計乃屬二不同之概念，軟體之開發須在需求確認後始可進行程式之規格設計，不得以設計規格書仍進行審查，即遽稱此階段並無新增、變更需求之情事。
至於被告所提出之經濟部工業局軟體技術文件指引手冊、專案履約時程表更與本案認定新增、變更需求之時點完全無關。
蓋上揭手冊乃功能需求與設計規格之程序中，使用者與軟體開發業者必須持續溝通有關軟體開發之相關作業，故該手冊稱「確認程序」乃從需求審查一直持續到最後的產品測試，可知與判斷是否屬於新增、變更需求之時點無關，否則豈非至產品測試階段使用者變動軟體功能，仍不屬於新增、變更需求。
至於專案履約時程表，亦無從證明新增、變更需求之時點應以設計規格書確認為標準，反之從該時程表可知，系統程式之設計必須於需求確認程序結束後始得開始進行，二者具有關聯性，更足證需求確認之重要性，故於需求確認後再行變更需求之內容，自屬新增、變更需求。
㈡被告確認需求規格書後，變更軟體之功能與規格如本審卷第60-63頁附表1所列，共新增4項、變更4項軟體功能，又被告於履約過程中多次變更、新增需求之項目，原告已依契約規定，以98年7月23日衛展字第0980000273號、98年9月30日衛展字第0980000376號函、98年10月13日衛展字第0980000389號函、98年12月28日衛展字第0980000524號函多次發文請求展延履約之時程，然被告卻以各種不合理之理由拒絕同意，絕非原告未依契約請求展延工期。
㈢茲將被告變更項目4項臚列如下（註：關於「新增單位裁併及整併需求」乙項，原告準備書狀載為新增項目，但附表1列為變更項目，爰以附表為準列於變更項目下）：
1.專案計畫結構修改：被告於98年5月13日告知專案計畫須由二階層改為以三階層規劃，分別為主計畫、子計畫、孫計畫三階層。
此項變更非「需求規格書」之內容，嚴重影響資料庫結構之設計、程式開發、操作介面模式設計及報表資料之統計彙整等作業程序。
因此變更原告須調整工程會計、預算執行與控管二子系統所使用之主鍵值(專案計畫代碼)，且有重新定義資料讀取公式之判斷。
就此被告辯稱有關專案結構為二層或三層乃技術性問題，不涉及需求內容云云。
惟查程式規格的開立是必須確定該程式的資料輸入、輸出結果及程序邏輯規則。
而專案計畫結構的改變（由二層變更為三層）實已將資料結構的關連性破壞，對於系統之架構亦必須作變更，故先前所開立之程式規格及已著手或已完成之程式完全不可使用而必須重新撰寫，影響程式開發之進度至鉅，本案因此變更原告需修改已完成開立的程式規格約50支及需修改已完成撰寫的程式約15支程式。
又本案專案計畫之結構為二層或三層，乃被告之需求內容，並非被告所稱得由原告自行判斷、設計之項目。
被告於97年5月7日需求訪談紀錄中提出二層結構之需求內容，然於98年5月13日第10次專案會議中始提出三層計畫結構之需求，顯然構成變更需求之情事。
又被告所主張之（專案計畫-->降低漏水率實施計畫（WZ+WV）報表欄位內容）說明，與判斷二層或三層之專案結構無關，任何人皆無法依此判斷其究屬為三層之專案計畫結構或係採取二層之專案計畫結構。
2.新增單位裁併及整併需求：被告於98年5月14日提出單位裁併及整併需求，然組織為建構系統分析最基礎且重要之項目，當組織單位變動時已涉及原有系統架構之重建，就系統分析而言厥屬重大影響，對原告履約所需額外增加之時程。
被告至今仍未確認單位「裁併及整併」之具體情形，且新單位與現行單位之關係將影響資料轉換作業及系統權限之控管，須改變全系統架構之層面。
對此，被告辯稱有關判斷是否新增、變更需求之標準乃以設計規格書確認時為準，故單位裁併之變更並非變更需求云云，惟查，判斷新增、變更需求之標準乃係以被告確認「功能需求規格書」之內容作為認定之標準。
被告所為單位裁併之變更，因單位組織為系統基本之架構，故全系統皆須因應單位整併之需求做修正，所需修改之程式約共109支。
被告雖以「系統設計規格書SD4.0版第90頁」記載「另外『單位裁併與整併』之作業程序確定後，再進行該項維護作業之設計（不屬新增範圍）」，主張其於審查系統設計規格書中所提出之此項需求並非新增。
惟前開記載乃係說明有關維護作業之設計並非新增需求，顯與單位裁併、整併之功能需求是否屬於新增需求無涉。
3.報表查詢之功能變更：依RFP附錄一「三、功能需求說明8.3：所有報表皆可由使用者自行列印，並可轉檔為EXCEL或PDF格式。」
被告並於98年9月30日提出產製後之報表可修改其欄位及其值再行列印。
惟此將造成各個使用者於不同時間列印同一功能報表時，須以版本控制之方式記錄其結果，並可允許使用者進行修正。
況且被告亦未明確告知那些報表須具有此查詢及修正功能。
4.「web services」之交換方式：依RFP之規定與「系統設計規格書」之記載，「外部系統資料交換」乃係採「web services」之交換方式，此項履約時程應於98年9月30日交付。
然被告於規格確認後，於98年7月10日提出研擬變更外部系統資訊交換方式之主張，卻遲未確認最終內容，期間數度變更資訊交換之方式，並於98年12月16日發函通知原告變更契約內容，業已構成契約變更無疑，此項變更項目造成原告額外增加3.75個月之工作期間。
被告雖以98年9月17日第18次會議紀錄主張此項變更不影響契約時程，惟任何新增、變更需求應循契約有關變更之程序，被告遲至98年12月1日始通知辦理契約變更之程序，豈容再以原訂之98年9月30日履約時程認定原告遲延履約。
再者，第18次會議紀錄僅記載將變更外部交換資訊之方式，然而究竟有多少程式必須變更仍待被告正式發文通知，原告不可能依據該次會議紀錄即進行修改。
㈣茲將被告新增項目4項臚列如下：
1.新增「總分支會計子系統」、「工程會計子系統」產生報表檔供查詢及列印之功能，額外增加原告3.31個月之工期：被告於確認設計規格書後，另於98年9月30日之專案會議中提出「新增總分支及工程會計系統之月、季、年報表供查詢及列印之功能」，而總分支系統報表需產生之報表檔數量計70項、工程會計系統報表需產生之報表檔數量計15項，造成原告需額外投入6.77人月及延長工期3.31個月。
被告提出此項新增需求，須達成在報表列印畫面時，仍可修正其內容或欄位，而將修改後之畫面儲存列印。
換言之，此與一般查詢及列印之功能顯有差異，額外增加於資料維護系統外，修改報表內容，已形同「版本控制」之功能。
此將造成各個使用者於不同時間列印同一功能報表時，須以版本控制之方式記錄其結果，並可允許使用者進行修正，顯已非被告所認定之「查詢」、「列印」即可涵蓋其需求。
2.被告備援機制須達到異地備援機制及e-mail通知：依RFP「肆、三、安全需求：資料備份需包含資料備援、資料回復作業及當機時之處理功能。」
然被告擴大解釋需求，要求修正備援作業流程圖，影響系統功能審查及專案時程。
被告辯稱「異地備援機制及e-mail通知」係原告自行於「資訊安全規劃書」主動提及，RFP並未提及「異地備援」之功能云云。
惟查，被告自承「異地備援」之功能並非列於RFP所記載之項目，足以說明此功能並非契約之履約範圍，此項確屬被告新增需求項目。
又「資訊安全規劃書」所記載之內容係依據被告所要求之資訊安全標準所製作之文件，絕非原告所自行設定，蓋任何單位、事業之資訊安全標準皆有所不同，更不可能因為特定一個軟體專案去變更機關原訂之安全資訊標準，可知有關「異地備援」之功能確係被告所提出。
本項需求之提出乃係被告於需求規格書確認後，於設計規格書審查時提出「⒈本項是指在短時間內，無法恢復作業的情況下，應該在什麼樣的條件下，於另一個平台，甚至另一個地點，使系統能暫時恢復運作，以免原系統平台修復前，整個系統陷入長時間停擺的狀況……⒊針對前述需求，應訂定備援作業計畫，定期進行模擬演練，但計畫內容為何，如何執行及演練，均付之闕如」。
又有關「異地備援」之功能涉及軟體系統之設定與開發，並非單純之設備購置，被告稱此項功能不涉及原告之軟體開發顯不足採。
3.被告要求提供數位學習並嵌入會計系統中：依RFP「伍、三、㈧：可提供線上學習方案。」
但被告要求每一系統功能須嵌入數位學習功能，影響專案開發時程。
被告辯稱「嵌入式數位學習功能」乃本案契約範圍，非屬新增變更需求等語，惟RFP係記載「提供線上學習功能」，並非嵌入式數位學習功能，被告所要求者乃於操作系統介面時必須同時顯示學習功能，必須在系統設計時一併將學習功能納入系統作業中，絕非一般軟體系統所具備之功能，更無從包含於RFP「提供線上學習功能」之項目內，此項功能應屬新增。
4.被告要求安全機制與擴張契約解釋：
⑴依RFP附錄一「三、功能需求說明：1.2.1系統管理員、1.2.2會計管制員、1.2.3帳號管理員、1.2.4一般使用者。
」及RFP「肆、三、安全需求：㈦得標廠商於本公司進行轉檔、測試、並行作業、保固、維護等相關作業時，均須
遵照本公司資安規定辦理。」然系統設定時以角色為指定
權限之方式給予各個使用者之權限，被告使用者分類無限
擴張，但從未告知有多少分類或組織權限分類表。又被告
之資安為其管理之機制，應詳細告知與本案應用系統相關
之內容，而非至專案開發階段時再要求此項需求。且被告
從未提供任何資安規定之文件，卻於審查時提出各項資安
之要求，並敘明「除未來廠商與本公司進一步商談結果，
經本公司同意變更者外，都屬契約執行之一部分，均併契
約辦理。」
⑵被告辯稱有關指定權限僅有4類，並無原告所稱擴張分類且未告知標準之情事，惟查，被告於本案需求規格書確認
後，於程式設計階段提出使用者之存取管理必需有系統管
理者、監控人員、會計負責人、會計人員、一般人員、委
外廠商人員等之不同權限，且需區分完全控制、修改、讀
取及執行、寫入、執行、特殊權限等不同，並填報被告公
司「系統角色存取權限表」及「系統人員職掌對照表」共
計提出6種以上之使用者權限設定，此有被告於程式設計
階段，對於使用者之存取管理項次內所提出之審查意見可
稽，顯與REP中僅列有4種權限分類有所不同，核屬新增需求無疑。又被告並未明確告知其所要求之詳細分類共有幾
種，亦未提供被告之組織權限分類表，則其除已變更需求
內容外，更未明確告知變更後之明確需求內容為何，導致
原告無從進行軟體之開發作業。
⑶有關使用者權限之設定乃直接涉及本案系統的軟體功能需求，此觀RFP對於軟體功能需求之規格說明第1.1.1點：「程式依子系統別建立使用權限群組」、第1.1.2點：「畫面程式可依帳號不同分別設定使用權限，包括資料的新增
、刪除、修改、查詢、列印及匯出等」，皆係針對使用者
權限設定所為之功能需求規範，是被告辯稱有關使用者權
限之設定不涉及需求內容而僅為資訊安全規劃書之審查意
見，實不足採。
⑷被告先於答辯㈠狀稱從未提出擴張使用者權限之要求，嗣於答辯㈣狀復稱上開要求擴張使用者權限之審查意見僅為
「規劃」性質，前後反覆，何況，其所稱「規劃」之性質
為何，並無說明，以原告履約廠商觀點如何判斷被告所提
出之審查意見究屬何意。
㈤被告未善盡協力義務，導致設計規格書審查程序延遲長達6個月，導致原告履約困難，未能於原訂契約時限內完成履約項目，不可歸責於原告：
1.依本案契約第7條規定「契約履約期間，有下列情形之一，卻非可歸責於廠商，而需展延履約期限者，廠商應於事故發生或消失後，儘速以書面向機關申請展延履約期限。
……⑸機關應辦事項未及時辦妥。」
軟體開發絕非按圖製作，依據索引即可完成之工作，蓋專業軟體開發作業不同於一般套裝軟體可適用於一體適用於多數人的情形（例如：Windows、IE），特殊軟體開發作業乃是配合個別業主的需求而特別訂作，於開發過程中當然須隨時與業主確認軟體的功能是否符合需求，縱使在兩造隨時溝通的情形下都需要針對已開發完成的軟體進行測試，確認是否符合業主的需求，絕無可能由單方獨自進行開發。
故若被告於履約過程當中，違反其應盡之協力義務，自然嚴重影響本案軟體開發之時程，而屬非可歸責於原告之事由。
2.茲就被告違反協力義務事項詳述如下：
⑴設計規格書之審查程序，直接影響軟體開發進度。
本案軟體之開發建置乃係依據被告會計系統之功能需求，以為設
計開發之依據。本案需求內容之確認，除透過需求訪談、
審查「需求規格書」、確認「需求規格書」之程序外，另
有軟體雛形展示程序作為需求內容確認、軟體設計之重要
輔助。即在經過需求訪談後，原告將需求訪談內容先行設
計軟體功能，透過展示軟體雛形之程序供被告審視是否與
需求訪談內容相符，若展示結果不符需求，可立即進行修
改，並於修改完成後進行另一次之雛形展示，至此雙方對
需求內容與程式設計之方面已有一定之共識，原告即以此
進行「設計規格書」之撰寫，以供被告審查、確認「設計
規格書」，經確認後始得進行最後之軟體設計開發程序。
換言之，若被告於需求訪談、雛形展示階段未清楚表達需
求內容、遲延「設計規格書」之審查程序，或呈現擴散狀
之審查意見，將嚴重影響原告之履約時程。
⑵原告為瞭解被告需求，分別於97年10月27日起至97年12月18日止進行3個循環的系統雛形展示程序，讓其表達對系爭軟體設計之意見，將其意見撰入「設計規格書」及「資
訊安全規劃書」，並如期於97年12月31日提出供審查，然被告以適逢假期與機關會計年度結算機關事務繁忙為由，
通知原告審查程序將延期至98年2月9日始進行。
此等期間之延滯顯屬不可歸責於原告之事由，依據本案契約第7條
第1項第7款之規定應予展延履約期限。
被告遲至98年2月10日始提出審查意見，其資訊處於第一次審查意見時僅提
出47項審查意見，卻於原告修正完成後，於98年3月25日將審查意見擴張至216項，後於98年4月29日更將審查意見擴張至266項，茲將審查意見中影響原告履約重大者6項，表列如本審卷第143-144頁之附表六。
此等審查意見急遽擴張，無視本案契約設置雛形展示之程序，更造成原告於
第一次審查意見所為之修正完全白費，實已嚴重遲延原告
之履約時程與功效。
⑶被告拒絕提供進行資料轉換所必需之WSMGR軟體，更遲延交付資料檔案，嚴重影響原告之履約進度：查RFP三、安全需求㈥之記載：「得標廠商應自行負擔開發、測試所需
軟硬體設備，且使用之設備環境應予獨立，不應共用」，
而有關資料轉換作業之資料下載階段，僅係取得本案必須
轉換之資料，完全不涉及軟體開發、測試之作業，是無以
前開條文認定原告必須自行取得開發、測試所需之軟體，
反之被告本應提供所需轉換之資料予原告進行轉換作業，
若無至少應提供舊系統中下載資料所必備之軟體。惟查被
告反而要求原告必須自行取得讀取、下載資料檔案所需之
WSMGR軟體，造成履約時程之滯礙；
被告遲至資料轉換作業之履約期限前2日即98年7月29日，始完成Fujitsu GS8500主機所有舊系統資料檔案存放至暫存區供原告下載，嚴重違反本案契約之協力義務，構成阻礙原告履約行為。
㈥原告就軟體部分之履約並無遲延，退步言，縱有遲延亦未達20％之比例，被告據此登載政府採購公報之處分，違反政府採購法施行細則第111條規定：
1.被告以99年1月13日台水會字第1745號函通知原告將登載政府採購公報不良廠商，就軟體部分係以「履約遲延」為由，依政府採購法第101條第1項第12款規定登載政府採購公報。
實則，有關履約時限之爭議乃係同條項第10款「是否履約遲延重大」所規範，而依同法施行細則第111條規定，該第10款所稱延誤履約期限情節重大者乃指履約進度落後20％以上。
復按本案契約第13條第9項規定：「因可歸責於乙方之事由致延誤履約進度，情節重大者之認定，除招標文件另有規定外，適用採購法施行細則第111條規定」，故縱以政府採購法第101條第1項第12款事由登載政府採購公報，亦應受遲延是否達20％之限制，否則無異架空本案契約第13條第9項之規定與政府採購法施行細則第111條之規範。
蓋政府採購法對於有關履約遲延而登載政府採購公報已設有遲延達20％之相關規範，自不得逕以同條項第12款之規定，而脫免法律所設需遲延達20％之標準。
臺北高等行政法院100年度訴字697號判決亦同斯旨：「縱以如上方式計算原告履約進度落後情事，其未完成履約而進度落後部分尚未達政府採購法施行細則第111條第1項及第2項第1款所定20％以上，遲延情節並非重大，雖經被告限期催告而未履行，然徵諸比例原則，原告之所以有申訴審議判斷所指之履約遲延，仍肇因於被告招標文件不明、審標不嚴，契約範疇有疑，原告無從評估契約風險（包括履約能力、履約期限及契約利潤等）所致，尚難以其未於被告所命期限內完成應用軟體第二期東京分行平行上線運轉，終止契約，而認原告具有政府採購法第101條第1項第12款規範目的所指之足以彰顯其為不良廠商之可歸責性，遽為原告應刊登政府採購公報之處分。」
2.按政府採購法施行細則第111條第2項揭示之遲延比例計算方式，本案簽約日為97年4月3日，原訂之履約期限為98年9月30日，履約期間共計546日曆天；
按此計算由於被告於98年12月1日通知變更契約內容，故縱依被告主張上開變更契約之內容不影響履約時程，而自98年12月1日起負遲延責任則至被告99年1月13日解除契約止，共計遲延44日，遲延比例僅8.05％【（44日546日）100％】，未達20％之遲延比例。
縱以98年9月30日起算原告之遲延責任，至被告解除契約時，共計遲延105日，遲延比例亦僅19.23％，未達20％之遲延比例。
是被告以軟體部分遲延重大而為解除契約並登載政府採購公報之事由，顯屬無據。
㈦硬體設備部分：
1.原告所交付之硬體設備符合6顆內建硬碟之規格：依據國立臺灣科技大學99年7月27日鑑定報告記載可知，內建硬碟之標準存有爭議，鑑定報告乃提出不同之內建硬碟認定標準，並以若採取「是否存在於機櫃內」之標準加以認定，原告所交付之硬碟規格亦屬於內建硬碟之範疇，原告所交付之硬碟與本案契約之規範並無不符。
2.從上揭鑑定報告對於內建硬碟提出不同認定標準可知，實務上對內建硬碟確實存有不同之定義與認知，則被告於RFP內僅單純記載「內建硬碟」，並未對於「內建硬碟」有任何定義或說明，且觀被告於履約過程中亦一再變更其對於內建硬碟之認定標準，其曾提出以是否屬於機架裝載式伺服器而為判斷，以是否置於伺服器主機內而為判斷，復又稱應以是否搭載SEU2為準，另於鈞院審理過程中復再行提出硬碟是否使用伺服器主機之電源之標準，可知被告對於內建硬碟之認定標準亦存有認定上之爭議，而在RFP規格標準定義不明、招標文字未臻精確之情形下，豈可將此爭議所生不利益歸原告承擔。
又在公共工程案件，若因招標機關招標文字對於規格之說明未臻明確所產生之履約爭議，非可歸責於廠商，此觀我國政府採購案件相關實務見解即明：「特別是IT（資訊科技）相關產品之採購，對硬體和軟體、服務等購入要件的歸納，在建構新系統時，如果不確實定義需求條件，就可能導致新系統的失敗……故而，政府採購案如因採購需求說明書之文字未能明確說明需求內容，導致廠商得標後進行需求訪談時，招標機關之需求功能與投標廠商投標時之認知歧異，而有所爭議……是否即應認可咎責於得標廠商……尚有就個案再為推求之餘地。」
則本案原告所交付伺服器主機之硬碟亦屬內建硬碟範疇，縱認未符合最嚴格內建硬碟之標準，亦係因被告未明確定義內建硬碟之標準所致，非可歸責於原告，更無據此解除契約之理。
3.依本案契約原告並無交付SEU2之義務：原告所提之服務建議書中「廠商規劃軟硬體規格較建議書徵求須知規定優良表」，由對照表列可知RFP要求之規格與原告所提供之設備規格，均無任何交付SEU2設備之記載，足證SEU2並非原告之履約責任。
再從被告驗收報告之記載：「目視內建73GB硬碟僅2顆，另外4顆在伺服器外」可知，並未認定原告所交付之設備缺少SEU2作為驗收不合格之項目，顯見被告所認知之履約項目並無SEU2在內。
又臺灣高等法院臺中分院（下稱臺中高分院）民事庭囑託長榮大學於101年10月9日作成之補充鑑定報告書，其參酌完整之服務建議書內容，進而認定被告用以主張原告應交付SEU2之服務建議書第二冊附錄E-3-2文件，僅為伺服器RX8640之產品型錄說明，故其中有關SEU2之記載僅係介紹RX8640日後可擴充之功能範圍，不得以此作為認定原告應交付SEU2之義務；
其又參酌本案契約第2條第3項第2款之規定，進而認定應以原告所提出之「台灣自來水公司會計管理資訊系統廠商規劃軟硬體規格較RFP規定優良表」，作為認定原告應交付設備之標準，而在此優良表內並無SEU2之記載，據此而認定原告並無交付SEU2之義務。
4.退步言，原告所交付之硬體設備與契約效用、性能相符，縱認尚與契約規格有間，被告遽然解除契約實已違反民法第359條之規範意旨：
⑴臺灣科技大學鑑定報告書明確記載，原告所交付之硬碟設備，其功能與效用應與契約規範接近或符合，原告所交付
之硬體設備亦屬於內建硬碟之一，則原告所交付之硬碟規
格究竟是否符合嚴格標準之內建硬碟，顯不影響契約之效
用與目的，而非本案契約之重要事項與必要之點，無論本
案契約究屬買賣之性質抑或承攬之性質，被告皆無以此解
除契約事由。
依民法第359條規定「買賣因物有瑕疵，而出賣人依前5條之規定，應負擔保之責者，買受人得解除
其契約，或請求減少其價金。但依情形，解除契約顯失公
平者，買受人僅得請求減少價金。」縱認原告所交付之伺
服器主機非屬嚴格定義下之內建硬碟，然在考量上述情形
下，被告認定驗收不合格且解除契約顯失公平，與民法第
359條之規範意旨相違。
縱如被告主張本案乃屬承攬性質，依民法第494條規定「承攬人不於前條第一項所定期限內修補瑕疵，或依前條第三項之規定，拒絕修補或其瑕疵
不能修補者，定作人得解除契約或請求減少報酬。但瑕疵
非重要，或所承攬之工作為建築物或其他土地上之工作物
者，定作人不得解除契約。」被告亦無據此解除契約之餘
地。
⑵至於被告僅一再聲稱系爭硬碟規格會影響日後擴充之能力，卻未能提出任何事證說明其主張，實則原告所交付之硬
碟規格與電腦擴充能力完全無關，更不會對於電腦擴充能
力造成任何之影響。
㈧綜上，原告已交付符合契約規範之硬體設備，被告以驗收二次不合格且逾期未改正為據而解除契約，並無理由。
軟體部分，被告嚴重違反契約之協力義務，更屢次新增、變更需求之內容，依約自應展延履約期限，不得以原訂履約期間認定遲延履約，且退步言之，縱依原訂時程而認定原告之遲延比例亦未達20％之標準。
被告依政府採購法101條第1項第12款通知將刊登政府採購公報之處分，誠有違法之虞等情，並變更聲明求為判決確認申訴審議判斷、異議處理結果及原處分均違法。
四、被告則以：
㈠程序事項：兩造間除本件契約外，尚有另案「營運管理系統資料庫轉換作業乙式」契約，該案亦遭被告列為拒絕往來廠商並登載於政府採購公報，其起迄期間自99年7月28日起至100年7月28日，原告不服，提出行政訴訟，經鈞院以99年度訴字第328號判決駁回及最高行政法院100年度裁字第2833號裁定駁回上訴確定。
原告於上開期間列為拒絕往來廠商，已然確定。
而本件原告列為拒絕往來期間為99年9月9日至100年9月8日，其結束期日與前揭案件結束期日100年7月28日僅相差1月又11天。
故原告表示就本案處分嚴重影響其商譽，於登載期間不得參與政府公共工程，受有重大營業損害云云，自不足採，亦難謂原告就本案系爭處分是否違法有加以確認之法律上利益，不符行政訴訟法第196條之規定，程序上無理由，應予駁回。
㈡所謂「異地備援機制及e-mail通知」係原告提出之規劃，非被告要求，不成立新增項目；
又「異地備援」原告僅需提出規劃毋須設置執行，E-Mail通知是很平常之功能，均不會影響專案時程：
1.RFP第8頁「安全需求㈠需有完整之系統安全規劃，如資料安全及資料備份等」，僅載「資料備份」無「異地」二字；
所謂「異地備援」此概念係原告於「資訊安全規劃書」（98年4月10日）第14、15頁主動提到之概念，姑且不論該文件僅是規劃性質，並非真正要原告實際編寫程式，設計出異地備援的功能，況且該文件係由原告自行撰寫，被告自始至終從未提出，怎會有該新增功能項目。
原告僅單純為文案規劃，後續備援設備設置係由被告自身負責採購執行，此有「資訊安全規劃書」第13頁載「2.系統之備援規劃（5）備援之設備未來應由台水公司採購，執行人員已敘述應由資訊處會計系統負責人員或機房委外廠商負責執行。」
可稽，故不會影響原告本專案履行時程。
2.「自動備份電子郵件（E-Mail）通知系統管理人員及資訊處作業相關人員」，此方式係原告於「資訊安全規劃書」第17頁主動提到之概念，並非被告所要求，自非新增功能。
況E-Mail通知是很平常之功能，如同網路購物以E-Mail確認訂單一樣，原告認為會影響系統開發設計時程，實無理由。
3.倘若「異地備援」功能為被告審查時提出（假設語），則既然「異地備援」必須撰寫程式設計出對應的功能，為何原告歷次的「系統功能清單」（設計規格書上冊4.0版&5.0版第58至90頁）中，完全無任何「異地備援」的功能項目。
原告既未設計該功能，被告又怎麼可能通過「設計規格書」的審查，且辦理驗收付款？
4.原告以模糊的根據機關之資訊安全標準，推論出該功能為被告所提出，並非依據任何證明文件或紀錄，復將被告指陳原告「資訊安全規劃書」中「規劃」粗糙的審查意見，扭曲為被告此時提出需求；
惟依被告於設計規格書上冊5.0版審查意見的表達方式，在「修正內容」該欄項會清楚標示「OK」、「Not OK」來表示該意見廠商「已修改」、「未修改」，該內容明載「項次：59、冊別：資安、交付文件內容：業務永續運作之規劃、修正內容：⒉訂定備援作業－OK。
2.0台水補充說明：……」其文字為「備援作業」而非「『異地』備援作業」且「2.0台水補充說明」以下該段文字，無隻字片語要求設計異地備援功能，故所謂被告指稱原告之設計欠缺此項「異地備援」軟體功能云云，與事實不符。
㈢所謂「被告要求提供數位學習並嵌入於會計系統中」部分：1.RFP第11頁載「伍、管理需求說明：教育訓練㈧可提供線上學習方案」，線上數位學習為本案契約標的內容之一；
又本契約專案名稱為「會計管理資訊系統改版委外資訊服務案」就是關於會計系統之設計開發，「提供線上學習方案」當然係本專案整個會計系統均需能以數位方式學習。
故原告指稱此為為新增項目，影響專案開發時程云云，顯有誤會而不足採。
2.歷次審查意見也僅提到「無數位學習畫面」，所謂「嵌入式數位學習」之名詞係原告所創造，且原告謂「被告所要求者乃於操作系統介面時必須『同時』顯示學習功能」云云，亦是原告自己說詞，被告在所有訪談紀錄、會議紀錄、審查意見及任何系統文件中，從未有該段文字之意見陳述。
3.被告僅在審查意見第258項次（設計規格書上冊5.0版第862頁）中指出：「交付文件內容：⒈無數位學習畫面。
⒉無文件（使用【或操作】手冊、系統使用問答集【Ｑ＆Ａ】…等等）查詢或下載的畫面。」
、修正內容：「左列均屬RFP規定要做的項目，原本廠商就要主動提供解決方案（也就是不需透過訪談，廠商應該也會做），而非自來水公司告知廠商如何做。
如果目前SD未提及，是否以後衛展公司就可以不用負責相關解決方案，甚至當作屬新增功能項目？」被告當時審查意見果然「不幸言中」，原告果真在訴訟過程中，將該功能扭曲為被告事後要求之新增項目。
㈣所謂「安全機制與擴張契約解釋」部分：原告人員至被告進行轉檔等作業時，須遵照被告資安規定，此為契約明文規範，故被告要求原告進行轉檔時依規定填報「資通安全保密切結書」等文書，合乎規定亦不影響作業。
另使用者僅有契約所載4類，並無使用者分類無限擴張之情：
1.RFP第29頁載：「功能需求說明1.系統管制作業：1.2人員權限設定─1.2.1系統管理員、1.2.2會計管制員、1.2.3帳號管理員、1.2.4一般使用者」系統使用者就只有此4類，無所謂使用者分類無限擴張之情。
2.RFP第8頁明載「肆、安全需求：㈦得標廠商於本公司進行轉檔、測試、並行作業、保固、維護等相關作業時，均須遵照本公司資安規定辦理。」
原告在被告僅進行「轉檔」作業，其派遣至被告之人員，被告要求其等依規定填報「資通安全保密切結書」、「智慧財產權切結書」，合乎規定也不影響作業。
3.按「除未來廠商與本公司進一步商談結果……併契約辦理。
」為系統設計規格歷次審查意見第217項記載，係針對所有項目之制式化規範，並非只針對資安問題。
4.原告所提設計規格書第634、635頁「項次56」，係被告針對「資安」即「資訊安全規劃書」的審查意見，並非要求變更程式設計，同份文件中原告已於修改說明欄中自行註記「已修改」，足證該規劃書如被告前述僅為「規劃」之性質。
不可能於「設計規格書」（SD）審查仍未通過時，就已完成「程式設計的修改」，上揭註記「已修改」所指，絕非「程式已修改」，既然非指程式，又豈有程式設計受影響之說法，二者顯有矛盾。
原告該項註記，係指「資訊安全規劃書」第22頁第2行「針對各種角色的使用者權限，建議應參照台水『系統角色存取權限表』及『系統人員職掌對照表』，各應用系統管理者再針對使用應用系統之『權限申請表』審核，並自各系統之系統管理功能中授予相關之使用權限。」
該段文字，是被告自始至終並未要求變更SD之使用權限分類，僅需在將來系統上線後，依據系統已有的權限設定功能，「授予」每一個使用者如前揭RFP第29頁所載四種其中之一使用權限。
5.另提出「系統角色存取權限表」文件格式供參，該文件係被告資訊安全之制式文件，適用於任何資訊系統，以現有會計系統為例，並無監控人員、委外廠商人員、文書處理人員等等，故該表只需填列「系統管理員」及「一般使用者」二種角色；
以本開發案而言，只需再增加「會計管制員」及「帳號管理員」二種角色（即RFP所定四種角色分類其中二種），並在「系統角色存取權限表」勾選其使用權限即可；
此與要求增加角色分類並進行程式設計，根本是兩碼事。
㈤所謂「報表查詢之功能變更」部分：「總分支會計子系統」及「工程會計子系統部分」產生之月報表查詢及列印功能，為RFP所明載，非新增需求，被告於98年9月30日並無提出在報表列印畫面時，仍需可修正、儲存之功能：
1.「總分支會計子系統」及「工程會計子系統」均為RFP第24頁「會計管理資訊系統架構圖」中所明列之子系統；
又RFP第62頁「功能需求」載「7.2.7產出報表…均具有依條件查詢、瀏覽、列印及EXCEL匯出功能」、「8.報表作業：8.2結算報表（經日結、月結及年結產生的報表之查詢及列印。
）8.3報表列印：所有報表皆可由使用者自行列印，並可轉檔為EXCEL或PDF格式。」
故此二項系統產生之月報表檔查詢及列印功能，非新增之需求甚明。
2.原告聲稱被告於98年9月30日提出查詢及列印需求，須達成在報表列印畫面時，仍可修正其內容或欄位，而將修改後之畫面儲存列印等語，惟依原告所提98年9月30日第19次專案會議紀錄明載「三、結論：㈢台水再次強調已於數次訪談過程中提出總分支及工程會計的月報表（含季報、半年報、年報）需產生報表檔供查詢之用。」
被告只是重複上揭RFP所規範月報表之查詢功能，再多強調已於數次訪談過程多次提醒而已，並無如原告所述變更查詢列印功能之情。
㈥「單位裁併及整併需求」部分：被告需求內容於原告所提「系統設計規格書」經審查通過時為最終確認，判斷是否新增、變更功能應以「系統設計規格書」經審查通過時為準，而被告至少在「系統設計規格書」審查通過前幾個月就提出「單位裁併及整併處理」要求，非所謂新增功能要求：
1.原告進行本專案會計系統「程式設計」階段之前，需經過「需求訪談階段」、「軟體需求分析階段」（需求規格書為此階段之產品）及「軟體設計階段」（設計規格書為需求階段最終產品）等先行階段，先後提出「需求規格書」供被告審查通過，以確認軟體需求、系統設計標準後，原告始能進入「系統程式設計」階段，此有原告所提建議書第232頁「三、專案進度及時程規劃㈠專案細部時程規劃」及後附圖表4頁可稽。
另有原告起訴狀所載「按照本案合約時程規定，原告應於97年12月31日提出『設計規格書』及『資訊安全規劃書』供被告審查並確認軟體需求內容，以作為日後開發設計軟體之標準。」
原告101年2月4日準備㈠狀明載「對於本案需求內容之確認，除了需透過需求訪談、審查『需求規格書』、確認『設計規格書』之程序外……原告即以此進行『設計規格書』之撰寫，以供被告審查、確認『設計規格書』，經確認後始得進行最後之軟體設計開發程序。
換言之，為了符合被告之需求內容，必須在確實履行前開程序並經審查通過『設計規格書』後，原告始得進行開發程序」等可證。
2.既然被告之需求內容係於原告所提「設計規格書」經被告審查通過時才為最終確認，則判斷是否新增、變更功能之時間點，就是以「設計規格書」經審查通過當時為標準，並非以「需求規格書」確認通過當時為標準；
在「設計規格書」審查通過前提出者均不屬於新增功能需求，僅是確認軟體需求、設計標準之過程，因原告尚未進入系統程式設計開發程序，對於原告履約時程不致於造成重大影響。
被告早就提出「單位裁併或整併處理」要求，因原告未納入系統設計規格書1.0版之中，因此被告於98年2月10日第1次系統設計規格書審查會議中即提出審查意見，之後又於98年3月25日第2次審查會議（設計規格書3.0）及98年4月29日第3次審查會議（設計規格書4.0）中履次重申，甚至主動提出可能的設計方向供原告參考，亦即被告至少在「設計規格書」審查通過前幾個月提出「單位裁併或整併處理」要求，自非所謂新增功能要求。
3.依據設計規格書4.0版系統功能清單第90頁已清楚記載「單位裁併不屬新增範圍」，原文件內容如下：「上列系統功能清單為目前分析階段與各系統使用者歸納之成果，日後在程式設計階段尚或有增修，如需增修功能，則依據本專案契約書有關功能新增之規定辦理。
有關未來為配合台水公司『環境管理會計』作業，會計單位係配合單位，僅為傳票資料轉檔至環境管理會計系統（該環境管理會計系統非屬本專案範圍）。
另外『單位裁併或整併』之作業程序確定後，再進行該項維護作業之設計（不屬新增範圍）。」
該文所謂「該項維護作業」當然是指「單位裁併或整併」，豈能將完整的句子切割，斷章取義地指陳「維護作業非指單位裁併、整併」。
㈦關於「變更外部系統資訊交換方式」部分：
本部分應用系統因其本身的需求採其他交換方式，即可達到資料交換之目的，因與契約規定未符，原告唯恐損及其履約權益，因此兩造於98年9月17日取得共識，合意辦理契約變更，當日原告李總經理、專案經理及工程師均在場，並依其資訊專業判斷部分外部系統資料交換方式變更對程式設計無大影響，進而作成第18次專案會議紀錄「結論：㈥原合約規定與其他應用系統間，透過web service之服務導向架構（SOA），經與外部系統訪談後，部分應用系統因其本身的需求採其他交換方式，如中介表格及檔案方式，即可達到資料交換之目的，故不影響時程及價金。
因與合約之功能需求說明10規定有差異，台水公司將正式行文通知衛展公司辦理契約變更。」
被告於98年12月1日發函辦理契約變更，依上開會議結論不影響系爭契約履行時程及價金。
原告事後因程式設計進度嚴重落後，遂以外部系統資訊交換方式之變更，要求額外增加3.75個月工期，有違雙方之協議及信賴關係。
故被告於98年12月16日發函拒絕原告所提出因此需要增加工時及契約價金之要求。
況被告解除系爭契約時點於99年1月13日，在98年12月1日約1個半月後，故不因而改變解除契約時原告逾期未完成軟體之事實。
㈧專案計畫結構修改部分，非新增需求：
1.查舊系統之專案計畫「預算執行」部分，原本即有多層的執行控管作業，只是二者無法勾稽，故被告已於97年8月23日時向原告提出工程專案計畫，提及預算編列及執行均須控管之需求（專案計畫→降低漏水率實施計畫→WZ、WV即孫計畫）。
至於系統要使用成2層或3層的結構，資料表究竟要如何設計，來達成「預算編列」及「預算執行」相互勾稽之控管作業，按資料表（Table）之設計係屬資訊專業之範疇，本屬原告應分析及設計之責，被告會計人員豈能知道「技術面」該如何做，方能達到子計畫及孫計畫的需求。
2.被告參與訪談的會計人員，已於97年系統訪談時提出相關專案計畫需求，並已納入原告97年12月31日交付的系統設計規格書SD1.0中，原告所稱98年5月13日被告告知專案計畫之設計規格須由二層改為三層之結構絕非事實。
由SD2.0工程專案計畫之雛形畫面並無「子計畫」，而SD3.0雛形畫面已有「子計畫子目」，顯示被告會計人員的認知是SD3.0既已有「子計畫子目」，也就是應包括諸如「WZ、WV」之類的「子目」（都是「降低漏水率實施計畫」）；
會計人員根本無法分辨何謂二層、三層之結構，乃至由雛形畫面發現設計上的缺漏，故訪談雙方在溝通上應有落差，但被告早已提出相關需求則為事實。
3.因原告未及時發現「系統設計規格書」1.0版設計的缺失，且來不及將相關功能納入98年2月23日應交付的系統設計規格書2.0版中，經被告同意後於98年3月10日始將其列入系統設計規格書3.0版中，既然被告在「系統設計規格書」審查通過前，又再次提及相關功能，自非所謂變更（非新增）功能要求。
倘該功能的修改確已嚴重影響履約時程，為何原告未立即在專案管理會議提出展延時程要求，遲至確定無法如期交貨後，始於98年9月30日以公文要求展延，益證原告所述為推託之詞。
4.按97年5月7日為系統訪談之第3天，各子系統均剛開始進行初步訪談而已，原告所稱該日被告提出二層結構之需求內容，然該訪談紀錄附件清楚記載「專案計畫下多一層子目，有些計畫可能無子目」，該紀錄並未提及「二層結構」，也就是說「二層、三層結構」根本不是會計人員使用的名詞（專業術語），前述諸如「WZ、WV」之類計畫對會計人員而言同屬「子目」。
亦即系統訪談僅3天不可能談及「○層結構」等系統細部設計之內容，且主張係由被告主動提出亦不合常理。
5.97年5月7日該日為第3天之訪談，當時被告所提「專案計畫」係指例如：「降低漏水率實施計畫」（計畫代號145），而「子目」係指其下再細分「WZ、WV計畫」（計畫代號同樣為145），而「子目」多數專案計畫並沒有，當時的概念為：專案計畫（降低漏水率實施計畫）→子目（WZ、WV），一開始雙方對名詞的定義尚未確立，當時「專案計畫」係指後來概念裡的第2層。
因為舊系統中「專案型計畫」及「非專案型計畫」分別獨立存在於「工程會計」及「非計畫型會計」二個子系統中，而新系統必須將二者合併成一個子系統，也就是說工程計畫必須分成「專案型」及「非專案型」二類，因而原告在98年5月13日該次會議中提出之「第10次專案會議報告」，將被告一開始的「專案計畫」名詞（例如：「145降低漏水率實施計畫」，改名為「子計畫」，以便「專案型計畫」能與「非專案型計畫」做區隔，因而被告所稱的「子目」就變成原告所說的「孫計畫」。
因此，原告後來提出概念如下：專案型計畫→子計畫（降低漏水率實施計畫）→孫計畫（WZ、WV）。
亦即97年5月7日訪談被告所提需求並無變更過，二層、三層是原告自身設計架構變更，與被告無關。
6.原告宣稱「被告於98年5月13日（即一年後）第10次專案會議始提出三層計畫結構之需求」，然根據原告在98年5月13日該次會議中提出之「第10次專案會議報告」，所謂「專案計畫有子計畫、子計畫有孫計畫」係原告主動列入討論事項，並非被告所提出，而且「孫計畫」的名詞亦是原告所創。
按「專案會議報告」係原告於開會前一天（5月12日）即已列印，再於開會當日（5月13日）向被告提出報告，故原告所稱「三層結構為被告於98年5月13日始提出之需求變更」顯非事實。
7.因原告未及時發現「系統設計規格書」（SD）1.0～4.0版之設計缺失，以致程式設計可能遭受影響，責任自屬原告須自負，更何況若該結構的修改（非新增）確屬被告要求，且嚴重影響原告履約時程，為何其未於98年5月發現問題當時，立即正式提出展延時程的要求，甚至迄被告99年1月13日解除契約為止，從未以此理由要求展延。
㈨設計規格書多次審查，係可歸責於原告：
1.原告97年12月31日交付的設計規格書1.0版，當時設計的資料表僅161個，與最後定案之5.0版本所列212個資料表，差異比例達32％（51個），且供水系統成本及系統管理二個子系統之資料表，完全未設計，遑論品質不佳、內容錯誤百出，且因無「系統畫面及資料表(table)之對照表」及資料缺漏，導致被告不易進行審查，故被告於98年1月20日以電子郵件通知原告，原告回覆依照被告要求之格式補充相關資料，以利審查作業。
惟原告於第1次審查會議前仍未提供，最後遲至98年3月4日方始交付，被告提供原告三次改正機會，原告最後於98年5月15日交付的SD5.0文件三冊（含附錄）共逾2,300頁，被告於98年6月4日發文予以確認，準此，系統設計多次審查係可歸責原告非被告。
故當原告98年9月30日衛展字第0980000376號函以本案系統設計經多次審查為由，第二次要求展延所有子系統之程式設計及系統測試計畫交付日期，被告以98年10月15日台水會字第0980035060號函說明不同意其請求在案。
2.原告臚列4件要求展延之公文，其中98年7月23日函距離97年9月30日「需求規格書」交付截止日，間隔時間亦長達近10個月，其所列理由係因「資料匯出作業」之故，並非被告新增或變更功能需求，而被告當時已函覆不同意在案。
而其他3件展延公文發文時間都在98年9月30日（含）之後，益證原告在這長達1年時間從不認為被告有任何新增或變更功能需求之情事。
亦即原告自表定「系統需求規格書」交付截止日97年9月30日至表定「程式設計」應完成日98年9月30日，期間長達1年，從未正式提出（包括專案管理會議或函文）哪些功能係屬新增或變更需求，而必須展延時程的要求，直至無法如期於98年9月30日交付「程式設計」的軟體產品，才匆忙於「同日」函文要求展延時程，欲推卸逾期仍未完成程式設計之責。
㈩原告主張因被告拒絕提供WSMGR軟體，並遲延交付資料檔案，嚴重影響原告履約進度之說法，與事實不符：
1.資料轉檔作業與本案程式設計無關：資料轉檔作業與本案程式設計完全無關，此由原告於起訴狀「而本案有關資料轉換作業之資料下載階段，僅係取得本案必須轉換之資料，完全不涉及軟體開發」等語可證；
原告於98年7月23日以舊系統資料匯出作業直接關係程式分析及設計等理由，要求辦理工期展延，說辭前後矛盾。
另被告解除契約係因原告程式設計未完成與硬體不符契約規範，並非因轉檔作業未完成，原告之訴求實為模糊焦點。
2.契約規定廠商須自行負責開發過程所需軟硬體設備包含WSMGR軟體：RFP第8頁載「肆、需求說明：二、軟硬體設備需求㈣廠商須自行負責開發過程所需之軟硬體設備……廠商於本公司電腦設備所安裝的軟體，涉及版權部分，應由廠商負責。
三、安全需求：㈥得標廠商應自行負擔開發、測試所需軟硬體設備，且使用之設備環境應予獨立，不應共用。」
契約並無被告應協助提供相關技術或工具軟體之條文。
另按RFP第6頁載「參、現有會計系統架構說明」「一、預算會計、總分支會計、工程會計……供水成本會計子系統㈠作業平台為Fujitsu GS8500大型電腦主機，系統使用COBOL程式語言開發，資料為VASM檔案結構。」
，已清楚敘明，舊系統為VASM檔案結構，採用COBOL程式語言開發等事宜，故相關技術需由其自行撰寫下載轉檔程式或使用其他廠商之工具軟體來解決。
3.原告最終仍依法向相關廠商購得WSMGR軟體使用授權，並完成舊資料之轉換，取得WSMGR軟體使用授權過程之延宕，完全因為原告專案管理之缺失，原告將作業不順歸咎於被告實屬不當。
本案軟體功能需求確認係以「系統設計規格書」通過審查為確認時間點：
1.原告亦肯定為符合被告需求，必須在確實經被告審查通過「設計規格書」後，原告始能進入「系統程式設計」階段。
另依系爭契約軟體經費分三期給付，第一期款項7,716,590元（含稅），按照建議書徵求須知（RFP）第13頁載「第1年（97）費用承包廠商完成整體系統分析與系統設計，並交付系統分析及系統設計相關文件，經確認核可後，依合約支付第1年之軟體開發費用。」
即原告所提「設計規格書」經被告審查通過後，被告始支付上開第一期款，故依系爭契約意旨，「軟體需求分析」階段係於「設計規格書」經確認後才告完成，原告才能請領第一期款，準此，益證明判斷新增、變更功能之時間點，是以「設計規格書」經審查通過當時為標準，並非以「需求規格書」確認通過當時為標準。
2.原告專案時程表清楚列出，「程式規格」開立係「程式設計」階段的工作事項，作業時程從98年1月1日展開，與「系統需求規格書」應交付的期限97年9月30日，有長達3個月的時程落差，此該3個月乃「系統設計」時程，故原告所稱「需求確認完畢後，即必須進行程式開立之作業」顯不足採，亦即程式設計根本不可能只根據「需求規格書」來進行，實際上程式設計的依據為「設計規格書」（圖14之「初步設計」），既然「設計規格書」審查尚未通過，又豈有所謂的新增或變更之情事。
又該專案時程表清楚表列，將軟體開發分成「需求分析」（A）、「軟體設計」（B）（即「系統設計」，本階段包含「雛形設計」）與「程式設計」（C）（含測試）三個階段，軟體之開發必須歷經此三個階段，此三階段環環相扣，須按部就班依序完成。
按系統設計（B）係包括系統架構、畫面雛形、資料結構、檔案（或稱資料表）之設計等等，程式設計（C）的任務係在將系統設計（B）的結果作具體的呈現。
原告稱「不得以『程式設計規格書』仍進行審查，即遽稱此階段並無新增、變更之情事」，恐將系統設計（B）與程式設計（C）二者混為一談。
被告於98年2月審查的是「設計規格書」並非「程式設計規格書」，且「系統設計」（B）該階段仍未完成，尚未進入「程式設計」（Ｃ）階段，自然沒有在「程式設計」（Ｃ）階段新增或變更需求之可能。
3.依經濟部工業局「軟體技術文件指引手冊」指出：「確認與驗證是確定軟體遵循它的規格並符合客戶的需求。
在軟體流程的各個階段中，系統應使用前一階段所產生出來的文件來做確認與驗證。
因此，確認與驗證應從需求審查開始，並且經過設計審查與程式碼審查，一直持續到產品測試為止」；
復依據同文件「圖14、確認與驗證程序」，在「需求規格」之後，必須進行「雛形架構」及「初步設計」二項程序（即「系統設計」）之後，才是「確認後之規格」，此與原告專案時程表之程序完全一致。
該文件明確指出軟體「確認規格」係在「初步設計」（即系統設計）之後，被告亦只主張「系統設計」階段完成前，並無任何功能新增或變更之問題，並未陳述至產品測試階段仍可新增、變更需求（而不算新增或變更功能）。
4.每一契約均為獨立的個案，本案並未明文規定需求新增或變更以「系統需求規格書」通過審查時點為判斷標準，其他個案契約之規定，並無引申適用本案之餘地。
況即使以更證1他案之契約而言，該契約條款的重要精神為「雙方共同決定何者屬新增或變更，且合意訂定應該展延的時程」。
查本案原告在「系統設計規格書」第90頁中指出：「上列系統功能清單為目前分析階段與各系統使用者歸納之成果，日後在程式設計階段尚或有增修，如需增修功能，則依據本專案契約書有關功能新增之規定辦理。」
由該段文字清楚可知，功能需求之確認時間點為「系統設計」階段，當進入「程式設計」階段才有功能是否屬增修之問題。
原告自97年9月30日「系統需求規格書」交付截止日至98年9月30日「程式設計」應完成日，期間長達1年，從未正式提出（包括專案管理會議或函文）哪些功能係屬新增或變更需求，因而必須展延時程的要求，及至無法如期於98年9月30日交付「程式設計」的軟體產品，才匆忙於「同日」函文要求展延時程。
5.查「需求規格書」係利用訪談來得知業者初步需求，而雛形展示是廠商依照「系統需求規格書」之業者初步需求建立「靜態」畫面，看業者所要表示的是否像畫面顯示一樣，因訪談通常係以對話方式為之，因表達意涵是否清楚、聽者是否了解表達者意思、抑或有些事難以用言語表示等問題，雛形展示與業者真正想要者一定有落差，業者就會提出修正意見，廠商彙整意見後，再據以製作「設計規格書」，可知「需求規格書」審查並非業者全部需求之確認。
原告於建議書所提專案時程亦是「系統需求規格書」審定過後，有「系統雛形展示及設計」階段，之後是「設計規格書交付」。
原告準備㈡狀第6頁「二、招標機關未能於雛形階段提出明確之需求內容」，亦招認在「系統需求規格書」審定後之雛形展示階段被告可提出需求內容，益證需求、功能規格並非以「系統需求規格書」審查後就確認。
既然雛形展示僅係靜態畫面，在系統設計規格書審查時，才能看許多細部內容，如雛形展示未設計部分，畫面點連接部分，其他動態資料如日期時間繼續性顯示部分等方面，業者始能提出意見，則原告主張被告在雛形展示階段未提出明確需求，影響原告廠商履約，自不足採。
且原告對此在履約過程均未表達異議，待解約後才提出，實為卸責之詞。
原告所提本審卷第143-144頁之附表六亦無加以審酌必要，一併敘明。
6.系統需求規格書並非在完成所有訪談作業之後撰寫，例如：報表訪談在98年4月方始進行，原告並於訪談注意事項3註明：「本次討論完畢，依據討論結果，或需修改資料模型、結構或雛形，分析小組將儘速整理檢討後，告知程式設計團隊。
若有需要，再行安排下一次訪談時程。」
可知，實際上系統需求訪談尚未結束，該「需求規格書」之所以能通過審查，係因「原告認為部分功能在需求規格書審查結束後再進行訪談即可，原告承諾會安排後續之需求訪談，故被告同意通過該審查」，並不代表所有功能已完成需求確認。
依契約規定原告應於98年9月30日完成所有子系統之程式設計（共9個），惟原告逾期未完成應用系統軟體交貨，至99年1月12日交付4個子系統，其功能僅佔全部之16.2％：1.本件全部子系統共9個，總功能數807個，契約規定原告應於98年9月30日完成所有子系統之程式設計，99年1月13日解除契約時，依據該日之前第25次專案會議報告，截至99年1月6日為止，原告自稱完成並交付者僅有「系統管理」、「資訊預算管理」、「供水系統成本」及「普通會計」等4個子系統，所佔功能數僅131個，其功能之比率只佔所有子系統807個之16.2％，對被告而言，必須全部完成，才能進行整合測試，程式設計之進度嚴重落後，至為明顯，遑論之後仍須辦理「整合測試」、「轉檔驗證」及「系統建置」等工作項目。
2.依據98年9月17日第18次專案會議紀錄之結論㈤原告歷次專案報告所列已完成設計與單元測試之程式功能數量，經被告連線至原告之主機檢視，許多功能並未確實完成，故原告實際上真正完成功能數之百分比，應較專案報告數字為低。
原告雖主張其延遲比例僅19.23％，未達20％，被告依政府採購法第101條第1項第12款登載政府採購公報，亦應受延遲達20％之限制，並提出臺北高等行政法院100年度訴字第697號判決為據等語，惟查，政府採購法第101條第1項第10款、第12款係不同刊登政府採購公報事由，有各自規範目的，應個別審查，同法施行細則第111條規定重大乃指履約進度落達20％以上者，亦僅限第10款事由，故第12款事由自不受拘束。
且由該判決所載「雖經被告限期催告而未履行，然徵諸比例原則，仍肇因於被告招標文件不明、審標不嚴，契約範疇有疑，原告無從評估契約風險所致，尚雖以終止契約，而認原告具有政府採購法第101條第1項第12款規範目的所指之足以彰顯其為不良廠商之可歸責性」等語，即其並非考量履約遲延有無達20％而論之，況且，本案被告亦無上述情事，兩案實難相提並論。
硬體部分：
1.依契約原告應交付配置SEU2之HP rx8640伺服器始符合「內建72GB(含)以上之硬碟機6顆(含)以上」規定：
⑴依系爭契約所載「第二條契約文件及效力（一）契約包括下列文件：1.招標文件及其變更或補充。
2.投標文件及其變更或補充。
3.決標文件及其變更或補充。
4.契約本文、附件及變更或補充。……」原告於投標時所提出之建議書
屬於兩造契約範圍內，合先敘明。
⑵就系爭契約「伺服器」標的物為伺服主機一（資料庫伺服器）、伺服主機二（報表伺服器）、及磁碟陣列主機各一
台，依RFP中「軟硬體需求規格表」明載之「五、資料庫伺服器……3.硬碟機容量（1）提供內建72GB(含)以上之硬碟機6顆(含)以上。」
【簡稱RFP五-3(1)】、「六、報表伺服器…3.硬碟機容量（1）提供內建72GB(含)以上之硬碟機6顆(含)以上。」
【簡稱RFP六-3(1)】亦即二台伺服主機均須「提供『內建』72GB(含)以上之硬碟機6顆(含)以上。」。而原告投標建議書第一冊「廠商規劃軟硬體
規格較RFP規定優良表」中，明列「提供內建72GB硬碟機6顆。」
且而依建議書第二冊附錄第E-3-2頁所附HP Integrity rx8640 Server的型錄規格，明白記載rx8640原則上內建4顆硬碟，於配置SEU2最大內建硬碟始可達8顆（Maximum capacities when configured with the Server Expan sion Unit 2（SEU-2）:‧Eight internal hot plugLVD SCSI disks），原告在前揭英文左邊空白處標記「3⑴⑵」、「3⑴⑵」表達配置SEU2後之rx8640符合上開RFP之第五-3⑴⑵及3⑴⑵項「提供內建72GB(含)以上之硬碟機6顆(含)以上」需求規格。
被告評選委員因此審查配置SEU2之HP rx8640規格符合RFP所載須提供「內建」72GB (含)以上之硬碟機6顆(含)以上之規格。
原告服務建議書「本文」所列設備的規格，不能自證符合RFP規範，當然必須檢視「附錄」之規格，才能證明是否確實符合，而
原廠的規格說明，就是原告用以證明符合規範之用，況且
原廠並不會在文件上標註符合本案規範之哪些項目，故該
些標示配置SEU2之HP rx8640規格符合上開RFP之「3⑴⑵」、「3⑴⑵」，是原告用以證明符合規格，豈能因
其置於附錄而稱其無作用。
故原告自應交付配置SEU2之HPrx8640始符合契約約定。
2.內建硬碟機因安裝在主機之內，故至少有下列特徵：①硬碟機位在伺服器主機內部，而非機架（或稱機櫃）之內。
②硬碟機的訊號線直接與伺服器主機的主機板相連，而非透過外接訊號線路。
③硬碟機使用伺服器主機內部的電源。
被告驗收之作業，係參酌電腦原廠之原始設計規格，並根據上開特徵判定，故只須其中任何一項特徵不符，即屬規格不符合，被告之驗收標準始終如一。
3.「內建」硬碟機之電源來自電腦機盒之主要電源，須並非置於電腦系統機盒之外，反面言之，硬碟機之電源如在電腦系統機盒之外，即屬「外接」硬碟機：
⑴就此爭議，臺灣科技大學之鑑定報告，載「⑴根據http://www.yourdictionary.com/對internaldrive(內建硬碟)之定義：…A hard disk drive that fits inside a drive bay in the computer cabinet.It derives its power from the main power supply.只要硬碟機是放在電腦機盒（或機櫃）之內的適當隔間【按：應譯為：只要硬碟
機是放在電腦機盒（computer cabinet）內之硬碟機插槽(drive bay)】，且其電源來自電腦之主電源（不利用電腦機盒之外的電源）即為『內建』硬碟機。」
、「⑶http://www.webopedia.com/TERM/d/disk_drive.html在diskdrive的定義內提及：Disk drives can be either internal (housed within the computer) or external（housed in a separate box that connects to the computer）亦即，內建硬碟機是在電腦機盒內的硬碟機。」、「⑷
http://www.wordreference.com/對external drive(外接硬碟)之定義為：A drive with its own power supplyand fan mounted outside the computer system enclosure and connected to the computer by a cable.只要硬碟機是放在電腦機盒（或機櫃）之內【按：『或機櫃』
應刪除】，且其電源或風扇並非置於電腦系統機盒之外，
即為『內建』硬碟機。」
⑵上開段落某些中文翻譯與英文原告有落差：如「drive bay」應譯為磁碟機插槽」而非「適當隔間」。
「computercabinet」應翻譯成「電腦機盒」，所指為電腦主機之「機殼」，上開中文翻譯成「機盒」（或機櫃）」，但英文
原文並無「或機櫃」之附註說明，應刪除之。則依英文原
意，「內建」硬碟機係指該硬碟機是置放於電腦機盒之磁
碟機插槽內，且其電源係來自電腦機盒之主電源。
⑶縱依鑑定報告中文「只要硬碟機是放在電腦機盒（或機櫃）之內的適當隔間，且其電源來自電腦之主電源（不利用
電腦機盒之外的電源）即為『內建』硬碟機。」、「只要
硬碟機是放在電腦機盒（或機櫃）之內，且其電源或風扇
並非置於電腦系統機盒之外，即為『內建』硬碟機。」等
予以認定，「內建硬碟機」之電源係來自電腦機盒之主電
源（不利用電腦機盒之外的電源），須並非置於電腦系統
機盒之外。
4.臺中地院民事庭法官99年11月19日到被告機房勘驗，勘驗結果：「⒈兩部rx8640伺服器主機各含二台硬碟機，伺服器主機上方同一機櫃內另設置四組2120磁碟機（每組二台）。
⒉這四組磁碟機組所使用之電源為機櫃後方內之插座，插座電源不是來自兩部rx8640伺服器主機電源。」
有民事案件被證16相片與HP rx8640伺服器主機兩台、HP Disk System 2120磁碟機組四台，與其等電源線等相片共6張供參酌；
亦即原告交付之2120組件之4顆磁碟機位於主機之外（上方），而訊號線與電源線係透過外接之方式與伺服器主機相連，原告意圖將機櫃（架）與主機畫上等號，顯有不當，且2120組件之4顆硬碟機係透過PCI擴充介面及連接線與伺服主機連接，且此4顆硬碟機並非使用來自伺服器主機之主電源，而係使用外部的電源，準此，並非「內建磁碟機」而係「外接硬碟機」，與RFP規範「內建6顆」不符，被告自不能予以驗收合格。
5.就長榮大學101年10月9日補充鑑定報告書內容，表達下列意見：
⑴依契約第2條㈢2規定：「招標文件之內容優於投標文件之內容。但投標文件之內容經機關審定優於招標文件之內容
者，不在此限。」原告提出所謂硬體設備優良表，載「本
公司提供HP rx8640伺服器……3.硬碟機容量（1）提供內建72GB硬碟機6顆」，並沒有優於招標建議書RFP「伺服器…提供內建72GB（含）以上之硬碟機6顆以上」規格，自無上開條款但書之適用。此鑑定補充報告書以硬體設備優
良表所載內容無SEU2來認定原告無給付SEU2義務，被告亦可以視原告所交付硬體是否符合「招標建議書RFP」甚至「硬體設備優良表」內容，來認定是否符合契約、有無收
受義務。
⑵依HP原廠文件資料及補充鑑定報告書鑑定結果（三），rx8640伺服器僅能內建4顆硬碟，且原廠文件資料顯示2120組件為外接裝置，而原告卻在硬體設備優良表中記載「本
公司提供HP rx8640伺服器……3.硬碟機容量（1）提供內建72GB硬碟機6顆。」
先在投標時以此不實內容來蒙蔽被告。
現在原告所交付為rx8640伺服器二台與2120磁碟機四組（每台二組），原告主張rx8640伺服器加上2120磁碟機符合「提供內建72GB硬碟機6顆」此規格，姑不論內建或外接標準為何，這2120組件不僅係招標建議書RFP規格無此組件，亦不存在於原告投標所提硬體設備優良表內，原
告提出此2120組件不符合契約，被告自可拒收，準此，依RFP及原告硬體設備優良表規劃，原告交付rx8640伺服器主機僅能內建4顆硬碟，不符合「提供內建72GB硬碟機6顆」規格甚明。
⑶依RFP與原告硬體設備優良表內容，均無「機櫃」此組件，顯不符合契約，被告可拒絕收受；排除機櫃，回到契約
，單以原告所交付rx8640而言，僅能內建4顆硬碟，不符合「提供內建72GB硬碟機6顆」規格。
⑷依RFP與原告硬體設備優良表所載，伺服器僅有rx8640主機即可符合「提供內建72GB硬碟機6顆」規格，然對照原告現所交付除rx8640主機外，還另加上契約所無之2120磁碟機及機櫃，原告才稱符合「提供內建72GB硬碟機6顆」規格（按：被告認為rx8640主機外硬碟機組均為外接），這當然違反契約，怎能驗收通過？
6.不論交付SEU2是否屬於原告義務，均不影響被告解除契約函所載違約之事實：
⑴被告於99年1月13日發函解除系爭契約係以：①本案硬體部分，原告所提供伺服器兩台主機內建73GB硬碟均僅2顆、另4顆在伺服器外，不符RFP所定「伺服器硬碟機容量：提供內建72GB以上之硬碟機6顆以上」規格，經三次驗收均不予改善，依契約條款第11條之㈥規定解除契約。
②本案軟體部分，原告未能依約於98年9月30日前完成程式設計，被告於98年10月27日進行第2次催告，原告仍未交貨，依系爭契約第16條之㈠規定解除契約。
⑵原告起訴狀亦載「依據被告驗收報告之記載：『目視內建73GB硬碟僅2顆，另外4顆在伺服器外』，並未以原告所交付之設備缺少SEU2作為驗收不合格項目」，足證其明白所交付伺服器驗收不通過，重點在於不符合內建6顆硬碟此
一規格，並非SEU2。
⑶系爭專案名稱為「會計管理資訊系統改版委外資訊服務案」，專案目標為「於開放架構下開發全新會計管理資訊系
統，並整合現有人事差勤系統、薪資系統……、責任中心
系統與統計系統等關連系統介面，新增各相關作業功能，
以配合決策資訊與責任會計之需求，減少各項人力及成本
，縮短作業時程，提升行政效能。」加以此標案分類屬「
勞務類」並非「財物類」，有招標更正公告可稽，故本契
約主要重於軟體系統之開發，硬體設備僅係配合軟體系統
所為之建置，換言之，原告軟體系統違約未交付，硬體設
備就毫無用武之地，軟體部分、硬體部分需一併處理，不
可分割對待。
⑷綜上，不論交付SEU2是否原告義務，均不影響被告解約函所載交付伺服器兩台不符RFP所定「伺服器硬碟機容量：提供內建72GB以上之硬碟機6顆以上」規格，並經三次驗收均不予改善；軟體即程式設計逾期未給付，經2次催告
仍未交貨等違約之事實。稽此，原告稱被告以原告所交付
之硬體設備無SEU2之設備進而以驗收不合格為由，遽然終止契約云云，與事實不符，而不足採。
依前述本件專案名稱及專案目標，本契約主要重於軟體系統之開發，硬體設備僅係配合軟體系統所為之建置。
軟體系統違約未交付，硬體設備就毫無用武之地，故軟體部分、硬體部分需一併處理，不可分割對待。
依最高法院99年度台上字第170號判決要旨「按稱『製造物供給契約』……自以依當事人之意思而為解釋，以資定之。
如當事人之意思，重在工作之完成（勞務之給付），適用承攬之規定；
側重於財產權之移轉者，適用買賣之規定，兩者無所偏重或輕重不分時，則認為承攬與買賣之混合契約，關於工作之完成，適用承攬之規定，關於財產權之移轉，即適用買賣之規定。」
系爭契約應適用承攬之規定，無適用民法第359條有關買賣瑕疵擔保規定餘地，臺中地方法院以98年度重訴字第573號民事判決即採斯旨等語，資為抗辯，並聲明求為判決駁回原告之訴。
五、兩造之爭點：
㈠軟體設備部分，原告主張被告新增及變更需求項目各4項，致其無法如期履約，是否有理？
㈡原告提出之硬體設備，是否符合本件契約約定？
六、經查：
㈠按「機關辦理採購，發現廠商有下列情形之一，應將其事實及理由通知廠商，並附記如未提出異議者，將刊登政府採購公報：．．．因可歸責於廠商之事由，致解除或終止契約者。」為政府採購法第101條第1項第12款所明定。
㈡本件被告因原告交付之硬體經2次限期改善後仍有不符之情事，且原告已無作第3次改善之意願；
軟體部分，亦未能依契約規定時限於98年9月30日前完成所有子系統之程式設計，並經函催2次後仍未交貨，故於99年1月13日以台水會字第1747號函通知原告，依契約第11條及第16條規定解除全部契約，並於同日以台水會字第1745號函通知原告有政府採購法第101條第1項第12款規定之情形，將刊登政府採購公報。
原告不服，以99年1月27日聲明異議書向被告提出異議，經被告於99年2月6日以台水會字第0990003854號函復異議處理結果，仍維持原決定。
原告不服，循序提起本件訴訟，並為如事實欄所載之主張。
㈢關於軟體設備部分：
原告主張被告新增及變更需求項目各4項，及被告未盡協力義務，致其無法如期履約，其履約期限應予展延。
而查新增及變更需求項目之判斷時點，究應以原告主張之「需求規格書」交付日或被告主張之「設計規格書」審查完成時為準？按RFP所約定之專案時程「需求規格書」之原訂交付日為97年8月31日，然原告雖於97年9月30日交付，惟歷經三次審查，始於第三次97年11月28日交付，並於97年12月5日通過（前審卷第72頁）。
而「設計規格書」（含雛形展示及資訊安全規劃書）原訂交付日為97年12月31日，原告雖於97年12月31日交付，在歷經四次審查作業後，方於98年6月1日通過。
（見臺中地院98年度重訴字第573號民事判決，第32頁）復按RFP第232頁約定「專案進度及時程規劃：㈠專案細部時程規劃：本公司預計本專案自97年3月10日啟動。
本專案細部時程規劃至平行作業結束止（即99年12月31日），詳見於後。」
其細部時程規劃「⒊軟體開發：3.1需求訪談階段：3.1.1.1總管理處需求訪談、3.1.1.2區管理處需求訪談、3.1.1.3給水廠需求訪談、3.1.1.4營運所需求訪談、3.1.1.5服務所需求訪談、3.1.1.6北中南工程處需求訪談、3.1.1.7工務所需求訪談、3.1.1.8南北區水表修理場需求訪談、3.1.1.9員工訓練所需求訪談、3.1.2訪談內容整理及確認。
（註：3.1之時程為4月1日至6月30日）3.2軟體需求分析階段：3.2.1現況分析、3.2.2需求分析、3.2.3軟體需求分析產品分析、3.2.3.1系統需求規格書。
（註：3.2之時程為7月1日至8月29日）3.3軟體設計階段：……、3.3.3系統雛形設計、3.3.3.1系統雛形設計、3.3.3.2系統雛形展示及設計……3.3.5.1系統設計規格書交付、3.3.5.2資訊安全規劃書交付（註：3.3之時程為9月1日至12月31日）」。
即透過3.1需求訪談階段及3.2軟體需求分析階段，以「需求規格書」確認被告實際所需事項，使原告得以進入3.3軟體設計階段，且在雛形設計、展示、再設計階段，供被告再次確認是否符合其需求，最後進入撰寫設計規格書及交付。
故是否新增及變更原本所無之事項，應以「設計規格書」、「資訊安全規劃書」之「交付時」為判斷基礎，始為合理，因倘於契約規定、需求訪談階段及雛形展示階段皆未提出之需求，反於設計規格書交付後才提出，即須重新修改設計，均會影響履約時程，而被告於系統設計規格書之審查，主要係確認其設計規格書是否符合契約規定、需求規格書及嗣後就雛形展示時所提修正之需求。
倘若於設計規格書交付後，於審查階段始提出之新需求或變更，即屬新增或變更事項。
至於該項需求或變更需求，究竟係何時提出，此為事實認定問題，應由兩造舉證證明。
茲就兩造所爭執之新增及變更需求項目各項說明如下：
⒈新增項目：
⑴新增「總分支會計子系統」、「工程會計子系統」產生報表檔供查詢及列印之功能：
原告主張被告於98年9月30日之專案會議（前審卷第47頁）始新增「總分支會計子系統」、「工程會計子系統」產
生報表檔供查詢及列印之功能，額外增加原告3.31個月之工期云云。然查，總分支及工程會計子系統均為系爭採購
RFP附錄一「台灣省自來水公司會計管理資訊系統功能規範書」、「二、會計管理資訊系統架構圖」中所明列；另
同一附錄中「三、功能需求」「8.報表作業」之「8.2結算報表（經日結、月結及年結產生的報表之查詢及列印）
」、「8.3報表列印：所有報表皆可由使用者自行列印，並可轉檔為EXCEL或PDF格式。」
並於該附錄最後一頁明示：「（註）以上功能規範內容詳細設計依本公司實際需求
為準。」依系爭採購案之性質，前揭規定核屬合理，被告
既已於該兩系統部分報表檔查詢及列印功能為RFP所規定，難謂構成新增需求之情事。原告此一主張，自不足採。
⑵被告備援機制須達到異地備援機制及e-mail通知：①依RFP「肆、安全需求：㈠須有完整之系統安全規劃，如資料安全及資料備份等……資料備份需包含資料備
援、資料回復作業及當機時之處理功能。㈧資訊安全控
管：……⒉廠商於契約期間應遵循本公司頒行之資訊安
全相關法令及要點作業，並遵守本公司有關資訊安全的
規範與要求，本公司對商執行前揭資訊安全及控管有稽
核權。」是資料備份是契約規定之安全需求，但未明確
規定須以「異地」備援方式，此亦為兩造所不爭執。惟
兩造爭執點在於「異地」備援是何人提出？原告主張其
於資訊安全規劃書所記載之「異地備援」是應被告要求
之資訊安全標準所製作，且須另行開發軟體，而被告則
稱「異地」備援是原告於資訊安全規劃書自行提出，非
被告要求。
②然據上揭㈧資訊安全控管之規定，原告須遵守被告公司
有關資訊安全的規範與要求（兩造均未提出被告之資訊
安全相關規範），原告101年4月19日準備㈡狀第3頁亦載「資訊安全規劃書所記載之內容（指異地備援）仍係
依據被告所要求之資訊安全標準所製作之文件……本項
需求之提出乃係被告於本案需求規格書確認後，於系統
規格書審查時提出」（本審卷第127頁），且資訊安全
規劃書3.0版也確實記載「異地備援」（本審卷第85頁）而設計規格書5.0版第683頁亦載明「2.0版台水補充說明：⒈本項是指在短時間內（例如：硬體設備嚴重毀
損，修復嚴重毀損，修復零件恰巧短缺，必須等待國外
進口），無法恢復作業的情況下，應該在什麼條件下，
『於另一個平台，甚至另一個地點』，讓系統能暫時恢
復運作，以免原系統平台修復前，整個系統陷入長時間
停擺的狀況。」（本審卷第146頁背面），故論理上及
經驗法則而言，異地備援應是被告所要求，而原告為符
合其需求所規劃。
③然如上所述原告認為「資訊安全規劃書所記載之內容（
指異地備援）仍係依據被告所要求之資訊安全標準所製
作之文件……本項需求之提出乃係被告於本案需求規格
書確認後，於系統規格書審查時提出」，亦即「異地備
援」應該係被告之資訊安全標準已有相關規定，只是被
告卻於設計規格書審查時始提出，則依上揭RFP雖無明
確表示資料備份之定義，是否須異議，而被告「頒行之
資訊安全相關法令及要點作業」已有異地備援之概念，
則依上揭㈧資訊安全控管之規定，原告亦應要求被告提
出其有關資訊安全的規範與要求，縱使被告嗣後發現無
此功能而後才提出，該項需求應仍屬原RFP規範之內，
而非新增之需求。
④原告於歷次書狀並未提及e-mail部分。
⑶被告要求提供數位學習並嵌入會計系統中：
原告主張依RFP「伍、三、㈧：可提供線上學習方案。」
記載「提供線上學習功能」，並非嵌入式數位學習功能，
但被告要求每一系統功能須嵌入數位學習功能，要求者乃
於操作系統介面時必須同時顯示學習功能，必須在系統設
計時一併將學習功能納入系統作業中，影響專案開發時程
乙節。
經查：依前揭RFP規定提供線上學習方案為契約所定，然並未詳細規定該線上學習方案，係究應設計於獨立
一個系統，或是嵌入會計系統中。惟原告倘認為是獨立一
個系統，而非以嵌入會計系統中，應提出其已依契約提出
「線上學習方案」，而遭被告指示或拒絕之證據，然而原
告直至系統設計規劃書5.0版時，審查意見第862頁仍載明：「交付文件內容：⒈無數位學習畫面。⒉無文件（使用
【或操作】手冊、系統使用問答集【Ｑ＆Ａ】…等等）查
詢或下載的畫面。」
（本審卷第213頁）是原告主張被告要求提供數位學習並嵌入會計系統中，應屬新增事項，即
無可採。
⑷被告要求安全機制與擴張契約解釋：
原告爭執有二：①使用者分類RFP僅規定4種，被告嗣後要求至6種，且增加該6種使用者之權限內容。
②被告從未提供任何資安規定之文件，卻於審查階段始提出各項資安之
要求。惟查，原告所指「資安要求」為何，並未詳細說明
，被告指其要求原告進行轉檔時依規定填報「資通安全保
密切結書」等文書為「資安要求」，惟此原為RFP「肆、三、安全需求：㈦得標廠商於本公司進行轉檔、測試、並
行作業、保固、維護等相關作業時，均須遵照本公司資安
規定辦理。」所規定，為契約範圍內。至於使用者分類乙
節，說明如下：
①依RFP附錄一「三、功能需求說明：1.2.1系統管理員、1.2.2會計管制員、1.2.3帳號管理員、1.2.4一般使用者。」
使用者分類僅有4種，惟系統設計規格書5.0版，就使用者存取管理項下，被告審查意見提出應修正內容
「請詳列各種角色（系統管理者、監控人員、會計負責
人、會計人員、一般人員、委外廠商人員……）之權限
（完全控制、修改、讀取及執行、寫入、執行、特殊權
限），並填報台水公司『系統角色存取權限表』及『系
統人員職掌對照表』」（本審卷第148頁）等，亦即被
告之需求為使用者分類須有6類以上，且其權限須與該
公司「系統角色存取權限表」（本審卷第246頁）所列
而區分6種權限，則就使用者分類及其權限而言，確實
與RFP原規定不同。
②被告究係何時提出增加使用者分類，及何時提出台水公
司「系統角色存取權限表」及「系統人員職掌對照表」
？以釐清此項需求是否為新增項目。就此原告主張被告
係於程式設計階段始提出該項要求，核屬新增需求，然
被告僅抗辯「系統角色存取權限表」（本審卷第246頁
）係制式文件，於會計系統僅需填列「系統管理員」及
「一般使用者」二種角色；以本開發案而言，只需再增
加「會計管制員」及「帳號管理員」二種角色（即RFP
所定4種角色分類），被告自始至終並未要求變更使用
權限分類，僅需在將來系統上線後，依據系統已有的權
限設定功能，「授予」每一個使用者如前揭RFP所載4種其中之一使用權限，又抗辯原告僅屬資訊安全之規劃，
並未程式設計等語，並未舉證說明其於訪談階段或雛形
展示階段是否即已提出該公司「系統角色存取權限表」
及「系統人員職掌對照表」供原告參考，以變更RFP原
規定4種使用者分類及權限，就舉證責任而言，應認本
項需求為新增事項。
⒉變更項目：
⑴專案計畫結構修改部分：
①原告主張被告於98年5月13日告知專案計畫須由二階層 改為以三階層規劃，分別為主計畫、子計畫、孫計畫
三階層，而此項變更非需求訪談時「需求規格書」之
內容，嚴重影響資料庫結構之設計、程式開發、操作
介面模式設計及報表資料之統計彙整等作業程序，因
此原告需修改已完成開立的程式規格約50支及需修改
已完成撰寫的程式約15支程式等語。
②兩造就此爭執之專案計畫，應為系爭契約中就「工程
預算子系統」項下之「專案計畫」。就此計畫兩造於
97年4月30日之訪談紀錄紀載（需求規格書附錄第176- 181頁）「一、工程預算編製：……⒉預算編製階層：
⑴專案計畫（繼續/新興）→計畫→六大科目→工程（
由廠所編製）。⑵一般建築及設備計畫（分年性/一次
性）→六大科目→子目→細目→工程。⑶專案計畫金
額大、階層少。一般建築及設備計畫階層細又多、金
額小。」97年5月7日訪談紀錄載明「⒉編列預算調整
：⑴專案計畫：區處以上調整子目、廠所調整各工程
。⑵一般建築及設備計畫：區處以上調整細目，廠所
調整細目下各工程預算。⑶專案計畫下多一層子目，
有些計畫可能無子目（編號方式再與台水公司確認）
。」可知，專案計畫須有子目階層（有些計畫可能無
子目），係97年5月7日訪談時所增加。
③原告主張被告於98年5月13日第10次專案會議（本審卷 第152頁）中始提出三層計畫結構之需求，即「專案計
畫有子計畫，子計畫有孫計畫，此做法需修改工程會
計的架構」，顯然構成變更需求之情事乙節，惟查，
原告所謂之「子計畫、孫計畫」為何，並未詳細說明
，是否指前揭二次訪談紀錄所載「⑴專案計畫（繼續/
新興）→計畫→六大科目→工程（由廠所編製）。」
為子計畫，而「⑶專案計畫下多一層子目」為孫計畫
？
④就此被告主張「專案計畫」係指例如「降低漏水率實
施計畫」（計畫代號145），而「子目」係指其下再細
分「WZ、WV計畫」（計畫代號同樣為145），而「子目 」多數專案計畫並沒有，惟嗣因舊系統中「專案型計
畫」及「非專案型計畫」分別獨立存在於「工程會計
」及「非計畫型會計」二個子系統中（本審卷第220頁
），而新系統必須將二者合併成一個子系統（本審卷
第221頁），故工程計畫必須分成「專案型」及「非專
案型」二類，因而原告在98年5月13日該次會議中提出 之第10次專案會議報告，將被告一開始的「專案計畫
」名詞（例如：「145降低漏水率實施計畫」，改名為
「子計畫」，以便「專案型計畫」能與「非專案型計
畫」做區隔，因而被告所稱的「子目」就變成原告所
說的「孫計畫」。而被告之參與訪談的會計人員，已
於97年系統訪談時提出相關專案計畫需求，並已納入
原告97年12月31日交付的系統設計規格書SD1.0中「 專案計畫：⒉降低漏水率實施計畫（WZ、WV）」，此
有97年7月23日被告交付原告文件簽收表關於「購建固 定資產增減變動表、按全公司、區處分」之文件、及
系統設計規格書下冊1.0所載可稽（前審卷第164、165 頁）。故「專案計畫項下降低漏水率實施計畫（WZ、
WV）」原為二層結構，然因被告確實於98年5月13日第 10次專案會議報告時，即「設計規格書」交付日97年
12月31日後，始增加將「非專案型」計畫與「專案型
」計畫合併成一個子系統之需求，使「專案型」計畫
原為二層，因合併「非專案型」計畫後而改為三層，
則相關規格設計皆須因此而變更，亦為新增需求。
⑵新增單位裁併及整併需求：
①原告主張被告於98年5月14日提出單位裁併及整併需求 ，因單位組織為系統最基礎且重要之架構，全系統皆
因此做修改之程式109支乙節：經查，是否為新增事項
應以「設計規格書」交付日97年12月31日為判斷時點 ，如前所述，則被告就單位裁併及整併之需求究竟於
何時提出？被告稱其早已提出該項需求，惟原告未納
入設計規格書1.0版中，乃於98年2月10日第1次設計規 格書審查會議中即提出審查意見，嗣於3月25日、4月
29日審查3.0、4.0版本時再次提出（前審卷第169-176 頁），則雖原告主張被告98年5月14日始提出並不可採 ，然被告亦無法舉證證明，其於設計規格書交付日97
年12月31日前已提出該項需求。則被告提出單位裁併
及整併需求，自屬新增項目。
②至於被告主張提出設計規格書4.0版第90頁已經載明「 另外『單位裁併或整併』之作業程序確定後，再進行
該項維護作業之設計（不屬新增範圍）。」（本審卷
第211頁）故單位裁併及整併之需求不屬新增範圍云云
，惟依該文義之解釋，似乎是被告之單位裁併及整併
直至4.0版時，仍未確定，惟嗣後待確定後之維護作業
則不屬新增範圍而已，似非指「單位裁併及整併」之
需求非屬新增項目。
⑶報表查詢之功能變更：
原告主張依RFP附錄一「三、功能需求說明8.3：所有報 表皆可由使用者自行列印，並可轉檔為EXCEL或PDF格式 。」
惟被告於98年9月30日提出產製後之報表可修改其欄 位及其值再行列印乙節，惟查，依據兩造98年9月30日第 19次專案會議紀錄係記載「台水再次強調已數次訪談過
程中提出總分支及工程會計的月報表（含季報、半年、
年報）需產生報表檔供查詢之用。」（本審卷第95頁）
並未提及該報表檔須達可修改欄位及其值再行列印之功
能，故原告上開主張亦無可採。而總分支及工程會計的
月報表（含季報、半年、年報）需產生報表檔供查詢之
用，係屬RFP規定範圍內，已如前所述，均非變更之項目 。
⑷「web services」之交換方式：
按RFP附錄一「功能需求說明：9.資料轉換作業：現有 會計資料檔案，全部轉換至開放式資料庫。⒑建立標準
介面：與其他應用系統間，透過web services之服務導 向架構（SOA），達到資訊交換、整合之即時性與透通性 。」
是關於資料之轉換，契約原規定以web services之 方式為之。惟有關外部系統資訊交換方式之變更，因經
與外部系統訪談後，部分應用系統因其本身的需求採其
他交換方式，即可達到資料交換之目的，惟因與契約規
定未符，兩造乃於98年9月17日第18次專案會議取得共識 ，合意辦理契約變更，當日原告李總經理、專案經理及
工程師均在場，並作成會議結論「㈥原合約規定與其他
應用系統間，透過web services之服務導向架構（SOA） ，經與外部系統訪談後，部分應用系統因其本身的需求
採其他交換方式，如中介表格及檔案方式，即可達到資
料交換之目的，故不影響時程及價金。因與合約之功能
需求說明10規定有異，台水公司將正式行文通知衛展公
司辦理變更契約」，此有第18次專案會議紀錄附卷可稽
（前審卷第154、155頁）。
兩造於第18次專案會議中， 既已合意有關外部系統資訊交換方式之變更，不影響時
程及價金，則原告事後以此為由，要求額外增加3.75個 月工期，實有違誠信原則。
至被告於98年12月1日發函通 知原告辦理契約變更一事，僅係履行98年9月17日第18次 專案會議之決議，並不影響原訂履約時程。原告主張被
告變更外部系統資訊交換方式，額外增加原告3.75個月 之工期，且被告係於98年12月1日始行文通知辦理契約變 更，原告豈可能於98年9月30日完成程式設計云云，尚非 可採。
⒊綜上說明，原告主張被告新增需求4項、變更需求4項部分 ，有關「使用權限變更」及「單位裁併、整併需求」，因
被告無法證明其於設計規格書交付前，已提出此項需求，
應認為屬新增或變更事項，而「專案計畫結構修改部分」
係被告98年5月13日始提出，亦屬新增需求，其餘5項均非 屬新增或變更需求項目。
原告主張被告至98年2月10日始提 出審查意見，且當時僅提出47項審查意見，卻於原告修正 完成後，於98年3月25日將審查意見擴張至216項，後於98 年4月29日更將審查意見擴張至266項，此等審查意見之急 遽擴張，更造成原告於第一次審查意見所為之修正完全白
費，實已嚴重遲延原告之履約時程與功效乙節，即堪以採
信。
又原告97年12月31日交付之「設計規格書」，被告以 98年1月6日台水會字第0980000129號函復「有關系統設計 規格書之審查因適逢元旦（4天)、農曆春節（9天）連續假 期，加上98年1月間本公司正辦理97年度決算，時值會計及 資訊處最忙碌期間，實難以撥出時間審查貴公司交付之『
設計規格書』，業以簽奉核准將『設計規格書』審查延期
於98年2月13日前完成，正式審查日期將俟確認後再另行通 知。」
（前審卷第231頁）則98年1月1日至2月13日前之期 間，既經被告核准而未予審查，即無須由原告申請延期，
該期間應予扣除，始為合理。
原告雖復於98年9月30日申請 展期，惟經被告於98年10月15日以台水會字第0980035060 號函（前審卷第149頁），以不符系爭契約第7條第3項第1款第7目之約定，而不同意展延履約期限等情，實屬濫用權 利，也不符公平原則。
況被告於98年12月1日以台水會字第 0980042682號函通知原告辦理系爭契約之變更（前審卷第7 6頁），則被告既已同意辦理契約變更，應認為被告已經同 意展延，自應給予合理期間展延。另系統程式設計原訂交
付日期為98年9月30日，如扣除被告98年1月1日至2月13日 無法審查之期間，延期至98年11月13日，則被告以98年10 月6日台水會字第0980035211號函為第一次催告，並於98年 10月27日以台中雙十路郵局第209號存證信函進行第二次催 告，催告原告依照原契約所訂期間履行即不合乎債之本旨
，則被告解除契約亦不合法，契約應認仍為存在。
㈣硬體設備部分：
⒈查兩造於97年4月3日簽訂系爭採購契約（前審卷第52頁），合約總金額3,917萬9,700元（含營業稅），系爭採購案招標公告之RFP中「軟硬體需求規格表」記載：「資料庫伺服器……⒊硬碟機容量⑴提供內建72GB(含)以上之硬碟機6顆(含)以上。」
、「報表伺服器……⒊硬碟機容量⑴提供內建72GB(含)以上之硬碟機6顆(含)以上。」
亦即2台伺服主機均須「提供『內建』72GB(含)以上之硬碟機6顆(含)以上。
」次查，原告於98年4月交付之2台HP rx8640伺服器主機，係於「內建硬碟插槽」安裝2顆硬碟機，其餘4顆硬碟機則安裝於伺服器主機上方之同一機櫃內，透過PCI擴充介面及連接線與伺服器主機連接，而該4顆硬碟機所使用之電源並非來自伺服器主機之電源，係使用機櫃後方另行安裝之延長線插座，亦即該4顆硬碟機係使用外部加裝之電源等情，有臺中地院勘驗筆錄及照片附卷可稽（前審卷第205至208、298至300頁），並為兩造所不爭。
⒉依照兩造所簽訂之系爭契約，原告所交付之2台HP rx8640伺服器在未裝置SEU-2之情況下，是否符合內建6個硬碟機之規格？查內建硬碟機之定義，根據網路資料所示，有⑴只要硬碟機是放在電腦機盒（或機櫃）之內的適當隔間，且其電源來自電腦之主要電源（不利用電腦機盒之外的電源），即為內建硬碟機；
⑵與前述相同，但增加了敘述內建硬碟機為了與電腦的motherboard互傳資料，會與電腦的hard drivecontroller相連接；
⑶內建硬碟機是在電腦機盒內的硬碟機；
⑷只要硬碟機是放在電腦機盒(或機櫃)之內，且其電源或風扇並非置於電腦系統機盒之外，即為內建硬碟機等4種；
而系爭伺服器有內建4個硬碟機。
若內建寬鬆解讀成「在機櫃內安置有」，則符合內建6個硬碟機之規格。
未裝置SEU-2的系爭伺服器有4個內建硬碟機插槽。
較嚴謹的看待是其規格不符合兩造所簽訂之勞務採購契約條款；
較寬鬆則符合。
其功能與效用應與內建6個硬碟機接近或符合，國立臺灣科技大學鑑定亦同此看法，有該大學鑑定報告書（下稱系爭鑑定報告）附卷可憑（前審卷第224-227頁）。
而被告之招標須知（RFP）內僅單純記載內建硬碟，而未對於該「內建硬碟」有任何定義，則兩造對之有爭議，其文字不明確之不利益應歸由被告承擔，亦即符合上揭寬鬆內建硬碟定義即可。
依據臺中地院之勘驗筆錄及照片與被告所提出照片可知，原告所交付之硬碟機係置於電腦機櫃內，顯然符合系爭鑑定報告對於較寬鬆內建硬碟定義⑶之判斷標準，屬內建硬碟，且其功能與效用亦符合，有上開鑑定報告足憑。
被告主張原告所交付之硬碟機，不符合內建6個硬碟機之規定云云，委無足採。
⒊系爭契約第2條載明：「契約文件及效力㈠契約包括下列文件：1.招標文件及其變更或補充。
2.投標文件及其變更或補充。
3.決標文件及其變更或補充。
4.契約本文、附件及變更或補充。
……」，故被告招標文件與原告投標時所提出之建議書均屬於兩造契約範圍。
被告固主張系爭採購案招標公告RFP之「軟硬體需求規格表」明定，二台伺服主機均須提供「內建」72GB（含）以上之硬碟機6顆（含）以上；
又原告之投標建議書第二冊附錄E第E-3-2頁，特別標示配置SEU-2之HP rx8640規格符合上開RFP之第五-3⑴⑵及六-3⑴⑵項規格，原告應配置SEU-2之HPrx8640規格符合RFP所載須提供「內建」72GB（含）以上之硬碟機6顆（含）以上之規格，故應交付配置SEU-2之HP rx8640伺服器主機云云，查系爭鑑定報告原認為原告有義務交付裝置SEU-2之伺服器（系爭鑑定報告第5頁），無非依服務建議書第二冊所載為據，然原告主張認為其僅為伺服器RX8640之產品型錄說明，其中有關SEU-2之記載僅係介紹RX8640日後可擴充之功能範圍，不得以此作為認定原告應交付SEU-2之義務等語；
經臺中高分院將服務建議書第二冊送請長榮大學補充鑑定（按原承辦鑑定人轉至長榮大學服務），請其指明原告應交付之憑據，惟補充鑑定報告書明確認定原告並無交付SEU-2之義務，有補充鑑定報告在卷可稽（本審卷第261-264頁），是系爭鑑定報告此部分即不足取。
被告上開主張原告有交付SEU-2之義務，核不足採。
⒋依上說明，原告所交付之硬體設備，以上開較寬鬆內建硬碟之判斷標準，伺服器主機屬內建硬碟，且其功能與效用亦符合內建6個硬碟機，符合兩造所訂契約之規定，被告就原告所提出之硬體設備卻拒絕驗收，並予解除契約，即有未合，自不發生解約之效力。
㈤綜上所述，被告以原告參與被告所辦理「會計管理資訊系統改版委外資訊服務案」採購案，認原告所交付之硬體設備與契約規範不符且拒絕改正，另軟體部分未照契約規定時限交貨，而予解除契約。
被告於99年1月13日以台水會字第1745號函通知其有政府採購法第101條第1項第12款規定之情事，將刊登政府採購公報，揆諸上開說明，於法有違，異議處理結果及申訴審議判斷未予糾正，予以維持，亦有未合。
原告訴請確認原處分、異議處理結果及申訴審議判斷違法，為有理由，應予准許。
兩造其餘之主張和舉證，於本件判決之結果並無影響，爰不逐一論述，附此敘明。
七、據上論結，本件原告之訴為有理由，依行政訴訟法第98條第1項前段，判決如主文。
中 華 民 國 102 年 6 月 20 日
臺中高等行政法院第二庭
審判長法 官 王 茂 修
法 官 劉 錫 賢
法 官 林 秋 華
以上正本證明與原本無異。
如不服本判決，應於送達後20日內，向本院提出上訴狀，其未表明上訴理由者，應於提出上訴後20日內向本院補提理由書（均須按他造人數附繕本）；
如於本判決宣示或公告後送達前提起上訴者，應於判決送達後20日內補提上訴理由書（須附繕本）。
未表明上訴理由者，逕以裁定駁回。
上訴時應委任律師為訴訟代理人，並提出委任書，但符合下列情形者，得例外不委任律師為訴訟代理人：
┌─────────┬────────────────┐
│得不委任律師為訴訟│         所  需  要  件         │
│代理人之情形      │                                │
├─────────┼────────────────┤
│（一）符合右列情形│1.上訴人或其法定代理人具備律師資│
│      之一者，得不│  格或為教育部審定合格之大學或獨│
│      委任律師為訴│  立學院公法學教授、副教授者。  │
│      訟代理人    │2.稅務行政事件，上訴人或其法定代│
│                  │  理人具備會計師資格者。        │
│                  │3.專利行政事件，上訴人或其法定代│
│                  │  理人具備專利師資格或依法得為專│
│                  │  利代理人者。                  │
├─────────┼────────────────┤
│（二）非律師具有右│1.上訴人之配偶、三親等內之血親、│
│      列情形之一，│  二親等內之姻親具備律師資格者。│
│      經最高行政法│2.稅務行政事件，具備會計師資格者│
│      院認為適當者│  。                            │
│      ，亦得為上訴│3.專利行政事件，具備專利師資格或│
│      審訴訟代理人│  依法得為專利代理人者。        │
│                  │4.上訴人為公法人、中央或地方機關│
│                  │  、公法上之非法人團體時，其所屬│
│                  │  專任人員辦理法制、法務、訴願業│
│                  │  務或與訴訟事件相關業務者。    │
├─────────┴────────────────┤
│是否符合（一）、（二）之情形，而得為強制律師代理之例│
│外，上訴人應於提起上訴或委任時釋明之，並提出（二）所│
│示關係之釋明文書影本及委任書。                      │
└──────────────────────────┘

中 華 民 國 102 年 6 月 28 日
書記官 李 孟 純