引文:

我認為，可以當成發展SOW的基礎或依據，與"等於"或"就是"SOW是兩回事。我自始至終的意思均是：2167A、498及其他的軍規、手冊等，"可以當成發展SOW的基礎或依據"，但它們"不等於"SOW。否則，MIL-HDBK-245D即無存在的意義。我在這個討論串裡貼的SOW範例(本討論串3樓中的例子)，即來自於MIL-HDBK-245D的附錄。先不談MIL-STD-498，從該範例中的工作條款描述，就可以知道，那些絕對不是直接抄自MIL-STD-499B。因為根本找不到相對的東西。而是在系統工程的過程context中，結合了預期專案的進展、與其他各別專案進程的搭配、以及計畫目標的達成等等而產生的計畫/專案特定的SOW。

以下取材自MIL-HDBK-245D 3.6.4節SOW的do's and dont's
a. Do's：
• 選擇適任的團隊，並由經驗豐富者帶領。
• 排除 “how to” 需求，因為投標者應在合約下，以最具成本效益的方式提供交付項目下交派工作。
• 使用本手冊第3.8.1節中討論的計畫工作產出分解結構(WBS)，勾勒必要的工作投入。
• 如果可以，設定SOW目標以支持獲取計畫(Acquisition Plan, AP)。
• 明白地定義所有列舉之標準及規格的裁適後界限。
• 排除設計控制或硬體效能參數，因為此等需要應在規格中涵蓋。
• 就獲取(案)順暢，對人員實施教育。(DFARS 211.002 – 70 合約條款)。
• 當商用項目滿足軍方需求時，對商用項目超越規格項目設定優先權。
• 對商業常規做為獲取的手段設定優先權 (DFARS 212 商用項目獲取 – 通則)。
b. Dont's：
• 指示、描述、或討論合約資料需求清單(CDRL)資料。
• 援用、列舉、或討論資料項目說明(Data Item Description, DID)。雖然SOW本文不包含資料格式及內容調製指示及/或資料交付需求，列於CDRL之資料項目說明編號可以交叉參照至SOW。
• 規定技術建議書準則或評估因子。
• 建立交付時程。(就澄清目的，可以納入重大里程碑)。
• 規定設計控制參數或硬體的效能，因為這些項目應該涵蓋在規格中。
• 在合約商格式可被接受時，強行合約商使用政府部門的格式。
• 過度規定。僅規定所需要的事項，並讓合約商建立履行需求的最佳方法。
• 援用內部管理指示。
• 使用SOW以建立或修定規格。
• 援用手冊、軍種規定、技術命令、或所有其他未根據DoD標準具體寫作的文件。(排除非政府部門文件)

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