工作條款(Statement of Work, SOW)應以明確、可以理解的用語，規定發展、生產將交付的物品、或將由合約商履行之服務等期間將完成的工作。

為能寫作有效之SOW，獲取者要具備對滿足特殊需求所需要之物品或服務的理解，同時也要具有以特定、績效為基礎、量化的用語，定義所需事項的能力。(目前政府部門獲取者，在這兩方面的能力仍有許多進步的空間，或者可以外包給具系統工程能力的廠商協助規劃工作)

以明確用語編寫的SOW，會使投標者清楚地理解業主(尤其是政府部門)的需要。如此將有助於回應之建議書的準備，以及所需物品或服務的交付。寫作良好的SOW亦能對業主，在選商期間及決標後的合約行政管理上提供協助。

SOW 以直接或參考其他文件方式，定義合約商要執行的所有工作(屬於非規格)的績效需求。有關於定性與定量的設計與效能需求，並不會出現在SOW中，而是納在規格文件中。此類規格通常會在SOW中參引，但是特定的定性或定量技術需求，不應在SOW中詳列(數據、值等)。以可靠度及可維護度為例，在SOW中，應是要求合約商要建立、實作及控制一份可靠度與可維護度計畫，而不是以可以量化的平均失效時間(MTBF)及平均修護時間(MTTR)，直接引用可靠度與可維護度。

在選商及決標後，合約SOW會成為度量合約商績效的標準。因此，負責SOW寫作者，在寫作時，必須考量到SOW在合約與法律上的意含。外包的工作進行當中，政府部門與合約商將會引用SOW，以判斷其相對的權利與義務。因而，SOW定義合約，並遵循合約法律的解讀。SOW必須清楚地定義將履行的工作，因為該詳細描述合約商工作投入的文字，可能與工作範圍的法律問題有關。在發生績效、權利、或義務的爭議時，若有清楚定義的需求，將能強化SOW的法律強制性，其在徵詢文件與合約中具有高度優先等級。

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

一般而言，SOW的寫作，儘管最後會有一位執筆者，但卻是一個集體的創作。負責SOW撰寫的團隊，要懂得將要獲取的產品與服務，同時也需要知道如何定義這些產品、服務的技術需求、以及合約商在履行合約期間的管理績效需求。

SOW的擬訂，會使用到計畫的WBS(PWBS)，而PWBS源自於系統工程活動，至少會運用到OCD(營運概念文件)，由營運構想與情境(User needs 或 customer requirements)，translate為產品需求(系統功能性與非功能性需求)、產品項目，變成WBS元素，再加上與計畫管理、致能(enabling)產品的WBS項目。有了WBS，會使SOW下筆變得容易，因為WBS讓計畫變得具象。SOW制定的系統作法如下圖所示：


如果，政府部門要讓委外專案變得明確而容易管理其績效，WBS與在其協助下完成之SOW是不可少的，但是更根本的是，WBS需要系統工程的能力。許多的政府部門業務單位不具備這些能力，卻要執行委外專案，或許不容易，但可以協請具備相關能力的單位協助或者將規劃的工作外包。當然，若要將規劃的工作外包慎選廠商很重要，但是要注意的是，不要被廠商具有的認證(例如，CMMI、ISO 9001、或者「我的人員都有PMP的證照」，就算CMMI顧問或相關業務的人員，亦不見得真的具備這方面的能力)所迷惑，最好要求廠商把實績拿出來，尤其是一些過往專案(近期或類似的專案)的artifacts，一一審視，從這些artifacts審視是否具備實質的能力。這雖然有些難，但是，是可以請求具有相關能力的評審與政府專業單位協助的。

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

SOW採三段式格式：第1節 範圍，第2節 適用文件，第3節需求。

第1節 範圍，應描述SOW所涵蓋事物的簡要聲明。其主要定義專案即將完成之工作的幅度與時限。在本段中，所有資訊之提供，應著重於讓投標者熟悉專案基本需求為何。在第一節裡，應該要排除的資訊有：對得標商工作履行的指導、資料需求規格(例如，需求規格書的內容、使用者手冊的形式與內容等)、對於交付產品的描述等。

第2節 適用文件，在完成第3節所列需求，會使用到的標準、規定、技術資料文件等，可以使用參引的方式，但應該要指明參引的版本，包括日期及/或是版本序號。所列適用文件的專案內使用範圍，要在第3節中定出範圍，若沒有在第3節中定出範圍，意指第2節中所列的適用文件，在專案中要全部被符合。

第3節 要求。本節所列要求乃是滿足計畫所需要者。寫作本節時，應注意事項如下：

a. 需求應明確地規定，以便相關人員(政府部門與投標者)能夠估算專案的可能成本，以及完成計畫工作所需專業知識的水準、人力及其他資源。
b. 明定廠商的職責，應讓廠商了解專案所需者為何，如何完成所有工作。
c. 僅引述所需之適用規格與標準及適用的限度，亦即明確指出需求所應遵循的標準，其所在章節，適用部分，及應用的程度等等。
d. 避免直接並具體描述工作該如何履行，應僅描述專案工作所需的結果為何。

當產品或服務在本質上涉及範圍愈來愈廣、愈來愈技術，定義所需事物的充分細節，以使合約商能夠獨立產出產品變得愈來愈困難。如果工作職責是一項分析，則工作任務必須精確地描述要分析的是什麼，以及履行分析的準則為何，及所有要考慮的特殊元素要包括在內。若要得出某個結論以作為分析的結果，要精準說出獲取者(買方/甲方)需要得到的是什麼，以作為此分析性工作的結果。如果分析進行的方法或順序是重要的，那就明確地描述出來。需求應明確地規定，不要給合約商有想像的空間。


SOW 章節 範例 (僅列目錄)
1. 範圍
2. 適用文件
2.1 XX部規格
2.2 XX部標準
2.3 國家標準
2.4 國際標準
2.5 其他出版品
3. 需求
3.1 通用需求
3.2 技術目標與目的
3.3 特定需求
3.3.1 廠商提供之服務
3.3.2 整體後勤支援
3.3.3 管理系統需求
3.3.4 第II階段生產規劃
3.3.5 可靠度計畫
3.3.6 可維護度計畫

工作條款在RFP與合約中的位置

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

在SOW中定義工作時常遭遇到的問題乃是非特定字及片語的使用，諸如： “任何(any)”、 “協助(assist)”、 “應要求(as required)”、 “視情況(as applicable)/視需要(as necessary)”、“按指示(as directed)”、"包括但不限於 (including but not limited to)"及 "等等(etc)"。請勿於SOW乃至RFP、合約中使用這些用語。

另外，以下敘述因可有多重解釋，亦避免用於SOW/RFP/合約中。

至承辦人/甲方(專案小組)滿意為止….
依照承辦人/甲方(專案小組)的決定….
符合承辦人/甲方(專案小組)的指示….
依照承辦人/甲方(專案小組)的指導….
根據承辦人/甲方(專案小組)的意見….
根據承辦人/甲方(專案小組)的判斷….
除非承辦人/甲方(專案小組)另有指示….
在承辦人/甲方(專案小組)要求下，提供…..
所有承辦人/甲方(專案小組)的合理要求應予匯集，….
無論何時何地，在承辦人/甲方(專案小組)的指示下均應予照相(存證)，….
嚴格地依照…..
根據最佳作法….
根據最佳的新式標準作法….
根據最佳的工程作法….
應採取最高品質的工藝技術….
應採取最高規格的工藝技術….
精準的工藝技術…
安全/妥適地安裝….
以俐落且熟練的方式安裝….
巧妙地安裝/裝配…
正確地連接….
正確地組裝….
優良的工序…
優良的材料…
根據公佈的適用規範….
信譽良好之製造商的產品….
除非免除否則將實施測試….
材料應有最高規格、沒有缺陷或瑕疵，且經承辦人/甲方(專案小組)所認可….
扭結和彎曲可能導致無法驗收，….
謹慎地履行….
利落地完工….
金屬部件在上漆前應予清潔…
適當地儲放…
光滑的表面…
討喜的線條….
屬於經過核准型式…
屬於標準型式…
所有引用 “甲方的檢核人員”的陳述。

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

工作條款範例--產品
1. 範圍。本工作條款(SOW)在定義 XXXX 系統計畫定義與風險降低階段，先進發展模型(ADM)之設計、工程發展、編製、及測試所需投入。其包含相關的計畫管理、人因工程、以及後勤支援規劃需求。
1.1. 背景。 XXXX 計畫已經啟動，以設計、發展、生產、以及部署一 OOOO 精進系統，其將滿足如編號 NNNN 之營運需求所規定的 XXXX 需求。 XXXX 系統將取代XYZ系統，且能明顯地改進 XXXX 能力。ADM的 XXXX 系統規格，已在過去兩年的概念探索階段發展完成。在本計畫定義與風險降低階段期間所發展的ADM完成測試驗收後，就要取得國防部核准本SOW所發展之使用效能規格與計畫規畫，競爭性採購工程發展模型(Engineering Development Models, EDMs)。
2. 適用文件。以下文件適用於本工作條款及附帶之附錄達到本文件所規定的程度上。
2.1. 國防部規格。
　　　　　(視情況提列文件)
2.2. 國防部標準。
　　　　　(視情況提列文件)
2.3. DoD文件之可用性。除非另有說明，上述所列規格、標準與手冊的複本，可以從標準化文件訂購服務台取得，地址：700 Robbins Ave, Bldg 4D, Philadelphia PA 19111-5094。
2.4. 非政府部門標準與其他出版品。
　　　　　(視情況提列文件)
2.5. 非政府部門標準與其他出版品之可用性。複本的申請可郵寄到(來源的名稱與地址)。
3. 需求。
3.1. 通則。本合約所要求的工作，應根據 XXXX 系統規格(編號#)及本工作條款(SOW)履行。
　　合約商應設計、發展、編製、及測試本合約Section C所列先進發展模型(ADM)，以滿足 XXXX 系統規格(編號#)並符合如下第3.2.1節中詳細需求所規定的效能準則。
　　合約商應根據如下第3.2.2節的詳細需求，提供計畫管理、人因工程管理、及後勤支援規劃。
3.2. 詳細工作任務。
3.2.1. 設計、工程、編製與測試。
3.2.1.1. 設計與工程。合約商應利用效能、可靠度、可維護度、可支援度、可生產性、及生命週期成本間的工程折中，設計及發展 XXXX 系統的ADM，以符合 XXXX 系統規格(#)的規格與準則。 XXXX 系統設計應包括裝備效能與物理特性、次系統組件位置、材料、由上而下設計的軟體程式設計元素、基本模組說明、及介面設計。
3.2.1.2. 設計分析。合約商應對選定的設計進行詳細的設計分析。詳細的物理與效能設計特性，應具體地識別，包括以一方法對比另一方法的工程決策過程。設計文件應包括替代方案的討論，各替代方案分別論述、風險評鑑、以及所做的折中。
3.2.1.3. 初步設計審查(PDR)與設計定形。合約商應舉行初步設計審查。非正式設計審查得於政府部門與合約商雙方達成共識的時間舉辦。
依第3.2.1.2小節所舉行之設計分析及第3.2.1.3小節中PDR的結果，合約商應定案並定形以供編製。在合約商獲得進至ADM編製授權前，需要有設計的書面採購活動核准。
3.2.1.4. 編製。合約商應修正及書面化所有發現到之禁制或使得編製成本不必要之高漲之設計特性，但不得改變效能或系統有效性特性。
3.2.1.5. 測試與評估。合約商應舉行ADM環境與效能測試並評估其結果，以展示所有裝備與軟體，完全遵守 XXXX 系統規格(#)。測試應根據合約商所擬定，並由政府部門所核准的發展測試計畫舉行。測試得於合約商設施，或在獨立實驗室，或商用測試設施中舉行。
3.2.1.6. 關鍵設計審查(CDR)。合約商應舉行關鍵設計審查。在CDR上，合約商應正式報告發展測試的結果，說明編製過程期間所做的設計變更，並提出設計變更建議，以作為發展測試，包括折中衝擊的結果。合約商應併入CDR期間所核定的所有設計變更。
3.2.2. 計畫規劃。
3.2.2.1. 計畫管理。合約商應訂定及維護管理作業，該作業應包括下列各領域：
　　(a) 計畫規劃與控制
　　(b) 下包商控制
　　(c) 財務管理
　　(d) 資料管理
　　(e) 政府部門所提供裝備、材料或資訊的管理與歸責性。
　　(f) 風險管理
　　合約商應擬訂及實作管理計畫，其明確定義 XXXX 計畫定義與風險降低專案將如何管理與控制。鑑定工作產出分解結構(WBS)的工作任務矩陣，應充分地發展以識別合約商與下包商的職責。合約商應擬訂並實作管理計畫，其清楚地定義 XXXX 計畫定義與風險降低專案將如何管理與控制。
　　合約商應建立及實作計畫管理辦公室職能，以管理所有技術效能，包括可靠度、可維護度、ILS、成本、時程、及合約的資料交付需求。
3.2.2.2. 人因工程計畫。合約商應擬訂及實作人因工程計畫(HEP)以確保適切的研究被履行，而人因工程準則應用在次系統硬體與電腦軟體設計上。
3.2.2.3. 後勤支援計畫。合約商應實作ILS計畫，以可支援度設計準則與特定，被考慮並併入設計中與折中研究一致，其符合 XXXX 系統規格(#)的營運用可用性需求。ILS計畫應使用後勤支援分析(LSA)，作為設計過程中的主要分析工作。

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

好久沒來，新增加的幾個議題，相當不錯，值得鼓勵！

有關WBS與SOW整合，以下幾點淺見就教

把WBS與SOW作一整合，在像美國這樣的國家的制度下是合宜的，但若搬到我國，則極可能會有問題.....

原因在於我國並不是以WBS向國會要預算及作計畫(含委外的PWBS部份)，這牽涉到會計/主計/審計制度

所以在實務面，可以使用WBS，但要有轉換機制(惟目前我國政府，包括軍方都沒有相關配套，幾乎所有的政府機關，包括軍方，都沒有適合的指導文件或程序)

基本上，我國政府部門在運用WBS上將會是吃力不討好的....

這在1993-95年的某個發包給美國某跨國事業體的案子中已經證實....

在她的履行我國的合約中，承包商應交付給我國政府的CWBS，根本展不出來....(展不出來是承商自己說的，雖然這家公司是一個非常有經驗的美國政府承商，其承包美國政府合約的CWBS根本不會有問題，與承包美國政府合約SOW結合也不是問題)

我國政府若要將WBS與SOW作一整合(或結合)，只有兩種辦法
1.轉換的配套(將主計結構與881的結構整合，能有換算，且要有法源)
2.在現有的主計制度下，自己訂WBS(而不是美軍881的那一套)

惟上述二者其困難度均非常高，若是民間公司的會計制度是可與WBS整合，則或有希望....

按：
WBS在我國政府其實也不是真的那麼難用
十多年前政府執行的某個案子就是運用WBS的精神向立院爭取預算，效果非常地好，由於每一條計價都"有憑有據"，讓立院很難"殺價"(砍預算)，只好簡單過關放行

SOW其實沒有一定的格式，當然，提出一個"樣板"是好的，但不必拘泥於這個"樣板"

以下連結就是一個例子
http://rcb.cancer.gov/rcb-internet/appl/rfp/HHS-NIH-NCI-SBSS-TSB-97040-65/SBSSSOW.pdf

提出SOW的"範例"也是好的....

但就以本討論串題旨言，較偏向的是"軟體"

所以建議舉軟體業的SOW可能較實用

當然，按照12207可以有各種不同面向的軟體合約

若以"委託發展"案言，其實(已經作廢的)DOD-STD-2167A、MIL-STD-498都是最標準的軟體發展合約之SOW範例(只要做好裁適工作)

脫下軍服的民間版498→J-STD-016也是現成的標準SOW範例....

單純使用2167A/498/016，加上適當的Tailoring，其實可以不用WBS就能與我國政府主計/審計制度結合；而承包者亦可在這個標準的SOW上依己的"內帳"計算履約所需投入的efforts和風險

按：
1. 2167A/498/016雖然是與"軟體發展"或"軟體發展過程"等軟體工程密切相關的"軟體工程標準"，然其本質其實是SOW，所以理面全是"合約用語"這在各該標準的開宗明義就已表明，小弟10餘年前在給某些政府部門上課時已在多處場合強調過2167A是SOW，遺憾的是只有極少數人聽進去....
2. 多年前某機構位出版的軟體規範是以1985版的2167為藍本轉成"指引"方式，可能沒有抓到Logicon當年接受美國DoD委製的2167是國防系統軟體發展的"定型化契約SOW"的精神....而且，其實，2167主要針對的是Mission Critical的MCCR並不太適用於Information Processing的IPSC，故以Information Processing為主的我國軟體業界用起來便不太順

引文:

您可能不了解為什麼我貼樣品出來，主要是因為我們都太強調CMMI, PMBOK，而且希望組織去通過評鑑，其成員去拿證照。問題在於CMMI與PMBOK都是美國環境下的東西，基本上在為美國軍方與美國政府服務。既然要學、要用人家的東西，那就該去看看原本的東西是什麼，怎麼做。(貼美國軍方的東西，因為這些作法最早亦源自美國軍方。)否則的話，對於工程與管理上是沒有幫助的。當然，取得認證、評鑑與實務是兩回事，當實務上不可行時，受害的可能則是企業本身或者是政府與人民。

至於是否拘泥於某個樣板，實務上應無此問題存在。因為從管理的角度來看，樣板都是可以裁適的，不論是向上裁適或是向下裁適。但是，如果沒有弄清楚自己的環境，以及管理的目標，專案的目標，明明是丟三落四的東西，卻強辯："這是裁適出來的結果"，那真的令人很無言了。

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

引文:
這樣的倩況，應該是在於我方政府發包機關自己本身沒有把CWBS的初版及WBS字典寫出來吧。另外，該案的SOW應該也是寫得很亂或是沒有章法，才會發生這種問題。

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

引文:

或許您說的對，小弟對CMMI只有"淺嚐"(只讀過其大綱)，PMBOK也只讀過一遍(幾年前為了幫向小弟求救的某人惡補考試)，所以中毒不深。小弟對本議題中SOW或WBS的回應，其思維是沒有CMMI/PMBOK的...

在CMMI(甚至其前身SW-CMM)還沒出現在這個世上時，大大小小案子的合約中早存在各式各樣的SOW....買賣雙方只要談判(裁適)到彼此皆認為可行，且價格可以接受，便很容易成交

要點是雙方彼此要對標的物如何獲得有充分的了解

政府使用標準(定型化契約)的用意之一在於"透明的政策"，讓承商可以在這個透明的政策基礎上作適合的投資，也讓合約更易於"談成"與"順利完成"

但標準化也不能完全盡信之，2167A在實施經年後就被檢討出至少17項極待改善的"罪狀"

498便是為了改善2167A諸多缺點而來，但同時也是為了將軍方色彩的標準SOW"脫下軍服"的政策作準備....
(按：當今世上最先進的戰機F-22其上的航電軟體即採2167A....)

以上都與CMMI/PMBOK關係不大(應該說無關吧？)

引文:

小弟所見應該不是這樣

發包方的PWBS字典應該是完備的，但對承商展CWBS幫助不大

系統工程方面的SOW(要求交付CWBS)是用499A等價品，為承商所熟練

承商的難處純粹是制度不相容/不匹配的問題
再就是議約時雙方都沒注意到WBS不能用在這種案子

按：應該是我方弟一次在合約中動用499A的CWBS條款，承商亦以承接美國政府的習慣理所當然地接受，履約過程才發現不妙，此教訓，也算是一種寶貴的Lessons Learned吧？

我國政府的標案幾採全案一個價，幾無彈性可言，要承商交付符合標準要求的CWBS並納到計畫管制準會把承商整死！

WBS不是這樣用，其實固定價碼的合約用CWBS管承商只會累死雙方，對履約沒有幫助，這個案子當年負責審WBS的官員最後是依小弟建議採"替代方案"的方式CLOSE，能結案，雙方都鬆了一口氣！

此外，澄清一點，發包方的政府是不必出CWBS的....

引文:

或許我們看到的東西不太一樣，至少版本應該是不同的。
發包單位的PMO/計畫管理者要出CBWS初版(其WBS元件挑選自PWBS中的項目)，納入邀標書中，可參考：MIL-HDBK-881A，版本日期2005年7月30日(但這個說法在1998年1月2日發布的MIL-HDBK-881即已存在)。其編製所使用的DID(資料項目說明)編號為DI-MGMT-81334B(核准日期:2005年2月1日)(WBS與WBS字典)，這份文件中以飛彈為例寫作，敘述的寫法應是基於系統工程"作戰需求"而來，因此，可確定是屬計畫管理者的角度。我想這個要求(提CWBS初版)是合理的，這可以顯現出計畫管理管理單位，對於自己要發包的東西到底了不了解。另外，投標者亦可以深入了解發包單位要的是什麼，而使建議書提出的基礎更為具體而堅實。而投標者據此提出的延伸CWBS亦可作為廠商評選的依據之一。

另外，若2167A之類的文件或是498是屬於SOW，那麼何以對SOW的發展，又有軍方手冊MIL-HDBK-245, HANDBOOK FOR PREPARATION OF STATEMENT OF WORK (SOW)(目前使用版本為MIL-HDBK-245D，版本日期1996年4月3日)，而有關於SOW與WBS之間的關係，即敘述於本文件中。而如果這些工程標準(不論是498或499)是屬於SOW，似乎MIL-HDBK-245D應該寫得更簡單或使用DoDI去做指導即可，亦不需要介紹一個所謂SOW發展的過程/程序/步驟了。

再者，若說諸如498或2167A之類標準要與合約文件有關，則其所在位置，應該還是要裁適、修飾或重組之後納入CWBS之才是適當的，這是根據MIL-HDBK-881A中，有關WBS字典的描述指導而來，而各標準亦在其適當的位置均有"不能直接納入合約中"的類似聲明。因為在WBS字典中，除了元素的定義之外，還可以描述廠商要如何完成WBS元素、需要哪些資源、相關配合事項等等，這些可以基於廠商的工程過程、技術、管理常規與可用資源而提出。(不過美國的系統/軟體工程與工程管理過程，現在有CMMI；國內是否能落實工程過程與工程管理，以及真正具備的能力，即使導入了CMMI並通過評鑑，還是令人懷疑的，另外美國國會的GAO有能力盯著美國國防部對廠商的要求，我國的審計部卻沒有能力做這種事)

在美國軍方DAU的輔助教材SE Fundamentals(國防系統管理學院出版)裡提到，WBS分為兩個部分，一個為主要任務產品的部分，另一部分為致能產品的部分，所有與計畫管理、系統工程、設施、教育訓練、資料的部分均屬於致能產品的部分，這些部分要參考軍規及DID，但是主要任務產品則是根據系統工程，需求發展的結果而來，兩者合起來才會是完整的PWBS，而MIL-HDBK-881A的附錄所提只是一般的基礎。MIL-STD-498中附的DID，屬於PWBS中，資料元素的(工程資料)部分來源而已。

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

引文:

週末到了，先回應這一段
2167A和498是以合約SOW用途是基本常識
其文件開宗明義即律定
2167A

1. SCOPE

1.1 Purpose. The purpose of this standard is to establish requirements to be applied during the acquisition, development, or support of software systems.

1.2 Application. The requirements of this standard apply to the development of Computer Software Configuration Items (CSCIs). This standard applies to the extent specified in the contract clauses, the Statement of Work (SOW), and the Contract Data Requirements List (CDRL).

498

1.1 Purpose. The purpose of this standard is to establish uniform requirements for software development and documentation.
1.2 Application. MIL-STD-498 is intended to be applied as follows.
1.2.1 Organizations and agreements. This standard can be applied to contractors, subcontractors, or Government in-house agencies performing software development. For uniformity, the term "acquirer" is used for the organization requiring the technical effort, "developer" for the organization performing the technical effort, "contract" for the agreement between these parties, "Statement of Work" (SOW) for the list of tasks to be performed by the developer, "Contract Data Requirements List" (CDRL) for the list of deliverable software products, and "subcontractor" for any organization tasked by the developer to perform part of the required effort. (以下恕略)

2167A是純發包與承包之合約用，498因為整合1703用法的關係，所以也可以用在同單位不同部門間之委任協議....但本質都是SOW，交付產品的要求就是CDRL或CLIN

例如
2167A的
5.1.2.3 The contractor shall define a preliminary set of engineering requirements for each CSCI. The contractor shall document these requirements in the preliminary Software Requirements Specification (SRS) for each CSCI.

有兩個"shall"s
第一句shall要求工程分析(軟體需求分析)是sow
第二句shall要求SRS(軟體需求規格書)是CDRL

個人竊以為，應該是對於英文敘述解讀不同而造成認知的差異。以下是個人解讀，敬請參考指正：

498中1.2.1目的之一是做用語的統一，其中提到SOW-乃是由發展者所履行之工作的清單。本段開宗明義提到：This standard can be applied to contractors, subcontractors, or Government in-house agencies performing software development. (本標準能適用於履行軟體發展的合約商、下包商、或政府部門內部的機構"...後接用語(term)說明。

而2167A中，1.2提到的是：This standard applies to the extent specified in the contract clauses, the Statement of Work (SOW), and the Contract Data Requirements List (CDRL). (本標準適用在合約條款、工作條款(SOW)、及合約資料需求清單(CDRL)中所規定的範圍內。其意味著，這個標準就如同前段所說：The requirements of this standard apply to the development of Computer Software Configuration Items (CSCIs).(本標準之需求，適用於電腦軟體組態項目(CSCI)的發展上)所以它只是用在那個範疇內容(獲取的軟體上)，而並無使用之以定義該範圍的內容(工作內容)的意涵在。

2167A與498兩者，在其前言都提到：
This standard is not intended to specify or discourage the use of any particular software development method. The developer is responsible for selecting software development methods that support the achievement of contract requirements. (本標準無意規定或阻止任何特殊軟體發展方法的使用。發展者負責能支援合約需求達成之軟體發展方法的選擇。)所以，應該更不可能拿標準去當成SOW，因為這樣會約束了專案的執行彈性。

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