WBS的定義：(from MIL-HDBK-881A, 2005年8月)
※ 產品導向族系(product-oriented family tree)，是由硬體、軟體、服務、資料及設施所組成。該族系是在國防裝備項目獲取期間，系統工程努力的成果。
※ WBS呈現及定義出將要產製的產品或一組產品。它把將完成之工作產出(work)的元素關聯至其他的元素或是最終產品上。換句話說，WBS是一種組織的方法，在將產品細分為較低層級的子產品。
※ WBS可以向下展至任何有益的階層。一般來說，最上面三層即已足夠，除非已識別的項目的成本或風險很高。那麼，WBS定義到較低的層級就顯得重要了。

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

計畫WBS在提供用以規定計畫目標的框架。它以階層式關聯、產品導向元素的角度定義計畫，並納入 “其他政府部門”元素(亦即，計畫辦公室作業、人力、政府提供裝備(GEF)、政府部門測試)。每一項元素均提供作為評鑑技術完成度、支持必要之基於事件的技術審查，及測量成本與時程績效的邏輯摘要層級。

合約WBS乃是就計畫報告之目的，由政府部門核定的WBS，包括所有的產品元件(硬體、軟體、資料、或服務)，這些都是合約商的職責。它包含合約商依據政府部門指示及合約工作條款(SOW)任意到達較低層級的延伸。

※獲取組織的專案經理，應發展計畫WBS(PWBS)及初步的WBS字典，然後依據計畫WBS發展初步的合約WBS(CWBS)；提出RFP時，其中應納入合約WBS及初步的WBS字典。投標廠商拿到RFP後，要擴展合約WBS至適當層級，並據之擴充WBS字典。在提交建議書時，投標廠商應一併提交擴展後的合約WBS及WBS字典。而建議書的內容應與合約WBS及WBS字典內容相互關聯。

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

WBS以數種方式支持計畫生命週期：
a.把獲取計畫的項目(items)切割成數個組成部件，釐清部件間的關係、釐清將完成之工作的關係--對彼此間及對最終產品。
b.促進有效的規劃及管理與技術職責的指派。
c.輔助技術投入、風險、資源分配、經費、以及成本/時程/技術績效的狀態追蹤。
d.幫助確保合約商不會困在項目需求的滿足(constrained in meeting item requirements)中。
e.為實獲值管理系統(Earned Value Management System, EVMS)及整合式主時程(Integrated Master Schedule, IMS)提供共通線索，使得計畫成本與時程績效的理解具有一致性。合約WBS包含成為足以接受分析與評價之小型個體的工作產出分解。做為EVMS的部件，合約WBS元素提供了成本評價績效(cost assessing performance)蒐集的結構。IMS是以時間分段的(time-phased)時程，其做為以時間劃分工作產出(time phasing work)及評價技術績效(assessing technical performance)的工具。IMS中的排程活動可以追蹤至EVMS中所使用的合約WBS元素上，讓成本、時程、技術績效、及相關風險的整合式計畫評鑑具有共通性(commonality)。

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

WBS字典應表列並定義WBS元素。最初的版本是由發包單位的計畫/專案管理人所調製，合約商在合約WBS發展的時候，要擴展該字典。

該字典要顯示元素的階層關係，並描述每個WBS元素及產生該元素所需要的資源與過程。其亦提供對詳細技術定義文件的連結。WBS字典應在計畫的生命期內定期修正，以納入各項變更，並應反映計畫/專案的最新狀態。CWBS字典。應含資料項目：

1. CWBS識別碼。
2. CWBS元素。輸入與同階層相同元素的元素名稱。
3. CWBS定義。輸入每一個CWBS元素之技術與成本內容的完整描述。對於由獲取者描述的CWBS初版，對於元素的定義，將描述該元素的意義，外觀、功能、將執行的任務，應有的能力等等。投標者拿到後，除了增加的較低層級CWBS元素外，對於包含獲取者原始提供的項目，應該儘可能描述有關合約商想納入該元素(服務、產品/子產品)的投入、工作、測試、組件...等等。

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

在發展專案的WBS時，可以參考下列原則，排除不屬於WBS元素的項目。
別納入不是產品(亦即，硬體、軟體、服務、資料、以及設施)的元素。電腦軟體組態項目(Computer Software Configuration Items, CSCIs)或軟體組態項目(Software Configuration Items, SCIs)均是WBS元素。而像設計工程、需求分析、測試工程、以及直接成本之類的項目，都不是產品。設計工程、測試工程、及需求分析等，均為工程職能的投入(efforts)；而直接成本是一項會計分類。因此，這些元素沒有一項是適當的WBS元素。

計畫獲取階段(例如，系統發展與展示階段、生產與部署階段)，以及不同階段(例如，研究、發展、測試與評估)中所用資金的型式，均非適當的WBS元素。

重工(rework)、重測、翻修都不是獨立的WBS元素。它們宜被當成受到影響之適當WBS元素的部件。

成本樽節的投入(efforts)，諸如全面品質管理提案、獲取改革(reform)提案、及保固等等，都不屬於WBS的部件。這些投入應包含在受到(成本樽節之投入)影響之項目的成本中，而非個別地捕捉。

別把會議、差旅、電腦支援等等成本，視為獨立的WBS元素。它們會和與之有關的WBS元素一起納入。

同屬用語不適合放在WBS中。WBS元素應清楚地指示實際的系統名稱與產品的專有名詞，以避免語意的混淆。例如，若Level 1系統為人事管理資訊系統，則Level 2項目(主要任務產品)為應用軟體。

工具(tooling)不是WBS元素。工具(例如，特殊測試裝備、自動化測試裝備)如果可能，應含在開發之應用軟體的功能成本(functional cost)中。若工具用在一個以上的組件/次系統上，則使用百分比應適切地分配給組件/次系統上。若工具無法指派給一個已識別的次系統或組件時，應將之納於整合、組裝、測試及檢驗的成本中。

以上原則亦可以當作WBS審查準則。

(軟體密集系統之WBS範例如下)

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

這個範例，是一個軟體密集系統的合約WBS (CWBS)，拆解至Level 5，當然，如果有次系統的下包商，則該次系統下包商，還要以這張圖的Level 4為其所負責之產品之WBS的Level 1、以本圖的Level 5為其產品WBS的Level 2，依次類推。

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

在發展WBS時最常見的問題是，專案經理會直覺地想使用過程、活動、工作當成WBS元素，例如「需求分析」、「軟體設計」。儘管PMBOK告訴讀者：WBS沒有一定的拆解方法。但是，讀者可不能因此而迷失，認為WBS元素怎麼拆都對；所以，什麼都可以當成WBS元素。基本上，WBS除了支持計畫的發展之外，很重要的是會成為後續專案管理的依據。吾人在管理專案的時候，最重要的就是對專案成本、時程、技術績效的掌握與控制。要做到成本、時程、與技術績效的掌控，我們得需要有"具體"的東西，才能估計成本、時程、以及賦予技術績效。也因此，不論是PMBOK或是美國軍方的標準，均特別強調，WBS是產品導向(美國軍方說法)或交付項目導向(PMBOK的說法)(或以之為WBS的定義)。而專案經理在發展WBS時，就必須遵循WBS的定義(產品導向樹狀結構，或交付項目導向樹狀結構)發展WBS結構。

WBS亦為專案及工程管理中許多規劃活工作的基礎：

下圖為另一個與電腦軟體有關的WBS：

在上圖中的WBS裡，依據美國軍方WBS手冊的說法，對於開發上具有高成本或高風險的計畫，應適度地再向下層拆解，亦即可以達到Level 4與Level 5，或者更低。在美國軍方的經驗裡，軟體系統的發展，不論其屬於人事系統或是太空梭的導航軟體，在開發過程中圴屬高風險與高成本的計畫。故而在此其WBS發展的指導手冊裡，發展至Level 4與Level 5。上圖可以與五樓的圖做比較。

對於軟體系統專案的WBS，在PWBS階段裡，主要任務產品不論向下拆幾層，均要注意要拆到有機會個別描述CSCI之外觀、功能、非功能需求。這些所謂的外觀、功能、非功能需求，實務上是描述在WBS字典中的，WBS字典的初版，是由獲取方的專案經理負責撰寫。

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

以下為使用五樓的軟體密集系統WBS架構所作實例。一般而言，軟體系統之計畫WBS提至Level 5，對於廠商擴展時，應依據建議構想及自身公司的固有系統/軟體工程過程實務往下擴展。但應把握一個原則，亦即--WBS是產品導向的譜系

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

小弟在"工作條款(SOW)"討論串中，曾提及：

引文:
在此舉個例子：
數年前有位軟體業的朋友，在閒聊的時候，提到：在行政院下某部會的某局的一個案子，其RFP中有條敘述(此條敘述屬於系統需求規格)，"系統應提供問題回報機制"。這項需求廠商的認知是：就是在該系統中提供幾個頁面，讓使用者於該系統發生問題時可以回報系統問題而已。而甲方在RFP中，對於該項需求亦無進一步說明(當然更不會有PWBS與WBS字典，可以參考)，而也順利發包了，而得標廠商亦依照其所認定的範圍實作系統。問題是當專案進入驗收期的時候，甲方才說，這個"問題回報機制"，範圍並非只在此新建系統內，該是該局內所有系統的問題回報均要透過此系統收容處理，然後，其功能應該還包括.....云云。結果，廠商專案驗收延後了數個月，同時教育訓練的範圍亦因而擴大，也使廠商增加了數個月的成本，還未包括因為專案延遲的罰款。

當然在這個案例當中， "系統應提供問題回報機制"這項需求有可能是抄來的。因為該局所新建的系統，在地方政府相對已經建立，該局的RFP許多需求是抄襲而已(當然，其說法可以是--如此才能與地方政府的相關系統"無縫接軌")，獲取者大概也不會真的(或有時間)逐項去深究這些需求是否恰當，瞭解這些需求對於中央級機關而言，是否充分，或者該有不同的作法。而任何審查RFP的人員，面對龐雜的需求項目，其實也無從理解起，更看不出所謂的適當性，只能依其經驗判斷而已。

如果，在RFP的格式裡，強制性地要求列入專案WBS與WBS字典，並就計畫風險考量，將"主要任務系統"分解至WBS第五層，亦即CSCI層次，那麼，需求描述不充分的問題立刻就會浮上檯面。因為，需求撰寫者或審查者，會發現這個所謂的"機制"，只有一個"標題性"的敘述，而沒有實質詳細的需求。就算撰寫RFP的人員疏漏了，在相關審查人員看到沒有按照規定分解到第五層時，也可以立即指出可能的問題來，再者經由RFP需求、WBS、WBS字典的三方交叉對照，問題很容易就浮上檯面，更何況WBS是一項循著系統工程需求過程的結果，本身就可以協助計畫人員思考問題，及提出計畫需求。對於RFP審查人員而言，看到WBS，很快就能對RFP的範圍有完整的概念，並對獲取產品(要開發之新系統)有一定程度的理解，將該RFP的需求與邏輯有效連接，如此也能降低RFP審查人員的工作負荷。而對於有意的投標廠商而言，也可以經由RFP需求、WBS、WBS字典的三方交叉對照，很快就能發現出沒有詳細說明的部分，立即提出請甲方澄覆，以免誤判專案的期程、品質、與成本。

廠商常常抱怨的是甲方的產品需求(亦即，該產品應具備什麼功能、要達到什麼樣的品質需求)講不清楚、寫不清楚。但是若問題甲方為何產品需求、品質需求講不清楚，有一種說法是：開放讓乙方有開創性的作法。但是環顧所有的標準，包括國家標準、國際標準、IEEE標準、美國軍方標準等，所開放給乙方有開創性作法的，均是開發的方法論、技術，但是規定一定要說清楚的還是最終產品的需求。因為把需求說清楚是"甲方的責任"，也是"專案成功的最重要的第一步"。而WBS的運用，有助甲方將專案產品需求定清楚。

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