這個是做CMMI的企業(yè)最熟悉的，因為RD過程域里邊正好有著兩樣東西。
這種表述方式適合“產品-項目型”項目，也就是說企業(yè)整體上有一個成型的產品，并通過定制這個產品來銷售給特定的客戶。
簡介：
用戶需求就是用戶需要用我們的軟件來做什么，常常包含很多非軟件功能的描述，比如（銀行軟件）“在開戶時，用戶憑身份證，身份證復印件，開戶申請單（簽字確認）可開戶。”看似很簡單，卻有幾個問題：復印件是一張紙，還是想用聯(lián)機的攝像頭拍攝一個？（航空安檢就是這樣的）開戶申請單，是一張紙還是指屏幕上的一個表單？如果是表單，應該打印出來簽字吧？
產品需求就解答上面的問題的：這個（些）客戶需求需要我們產品具體做什么呢？
幾個明顯地是應該選擇這種需求結構的判定條件：
1. 幾乎每次銷售都需要二次開發(fā)才能完成
2. 幾乎每個客戶都是大客戶（因此才值得做二次開發(fā)）
3. 我能把客戶分類并描述他們的業(yè)務特點，以及為什么購買我的產品
使用這種需求結構應該注意的地方：
1. 要善于讓多個用戶需求復用一個產品需求
2. 要善于從多個重復的用戶需求中提煉并產品化產品需求
常見問題：
1. 這種方法沒有顆粒度的概念，需要自己把握
2. 這種方法沒有條目化的概念，很多企業(yè)理解為只要編寫《用戶需求說明書》《產品需求說明書》即可
更詳細的內部結構：
1. 客戶需求和產品需求可能各自還包含若干個層次
成功要訣：
1. 正確處理對不同級別的需求，典型地（不要生搬硬套）：
若一個需求僅來自于單個客戶，應“輕視”之，只保留簡單文檔并進行簡單測試，但要記錄“有人要了這個需求”以便復用或提煉
若一個需求被提煉為產品需求，應建立基本的需求和設計文檔及適當的測試手段。
若一個需求被列入產品核心模塊（如工作流/信息流/組織結構等可復用內容），則應該建立健全的文檔供5～10年內查閱，并確保自動化測試（每日冒煙測試和版本發(fā)布測試）
即基于功能點分析進行組織，特別適合于需要招標-報價的項目。
簡介：
所謂文件，就是一組用戶可以理解的邏輯數據，比如在“會議管理系統(tǒng)”中，會議/會議室/參加人都是文件。在OA/MIS等數據庫系統(tǒng)眾所，一個文件一般對應若干個物理表。
所謂操作，就是圍繞某個文件展開的操作，比如會議的計劃/通知/召開/總結/上傳附件等；會議室的增加/修改/預訂等；參加人的增加/刪除/通知/統(tǒng)計等。操作必須是“基本過程”，也就是說包含了所有分支/異常等，以最終操作者達成操作意圖為終點。
文件和操作對應若干功能點及造價，文件15（外部）或35點（內部），操作4～5點不等，每點對應1.5人天左右大約1000多元成本。
此方法比較新，已有配套的培訓教程，包括如何利用功能來計算工作量/成本/工期，并有配套免費工具。
以下產品與之匹配：當需要向甲方競標和報價的時候，用次方法可以迅速準確地計算價格，且雙方均可理解。
幾個明顯地是應該選擇這種需求結構的判定條件：
1. 政府行業(yè)
2. 需要向甲方報價
3. 這個系統(tǒng)是一個以數據和操作的數量為主要因素決定產品規(guī)模進而影響報價的（比如類似OA）
使用這種需求結構應該注意的地方：
1. 文件和操作的概念是有判定標準的，不要望文生義
常見問題：
1. 這種表達方式適合表達要做什么，但無法表達“做到什么程度”
更詳細的內部結構：
1. 客戶需求和產品需求可能各自還包含若干個層次
成功要訣：
1. 此方法的目的在于向客戶確認是否“有必要做”成這個樣子，每個功能的增加將帶來造價的增加。
如果用別的方法描述需求，客戶總是希望做得更全更好，但這個方法