基于市場的創新是IPD的核心思想之一，集中體現為客戶需求驅動產品開發。具體實現方式是劃分出一個個產品包（Offering），并根據客戶需求（包括外部客戶和內部客戶）定義產品包需求（OR，Offering?Requirements），再將產品包需求轉化為設計需求（DR，Design?Requirements），然而通過產品開發實現需求。那么，產品包需求（OR）與設計需求（DR）有何區別呢？下表列出了兩者的定義和主要不同：

?

產品包需求的例子：

揚聲器需要110dB低頻聲音輸出

提供簡易方便的查看和打印分公司經營數據的功能

減輕臂架自重，載荷能力提高20%

每站平均升級時間30分鐘
設計需求的例子：

將廣播的輸出在20～50HZ的范圍內放大到115W
??在查詢功能模塊中，設置查看分公司經營數據的功能，可以選擇按分公司名稱、區域、月份、年份查詢，查詢結果按表格和圖形方式顯示，并能即時打印

臂架采用三角型支撐結構，支撐臂從圓形改為工字型，采用高韌性輕型鋼

每次可以同時升級10個機站，加載準備時間60分鐘完成，同步升級20分鐘內完成，40分鐘完成測試確認

漢捷咨詢發現很多企業在產品開發過程中往往把產品包需求和設計需求混為一談，獲得客戶需求（通常客戶需求還不充分，也不明確）后就一古腦編制產品需求說明書和規格書，然后匆匆忙忙進入開發階段。這是一種典型的欲速則不達的開發方式，往往造成以下突出的問題：

沒有理解真正的需求。缺乏從客戶角度對需求進行研究和分析，沒有了解客戶真正的需求，尤其是潛在的需求。很多新產品推向市場后雖然也能使用，但無法讓客戶滿意甚至驚喜，就與此問題直接相關。如過去每款新手機都有短信功能，都能使用，但直到iPhone推出對話式短信格式才使消費者有了很好的用戶體驗。

需求出現偏差。由于前面的客戶需求不充分、不清晰，開發人員在進度的壓力下，從開發者的角度去定義需求，與實際的客戶需求相距甚遠。如漢捷與某公司交流時了解到他們剛推出一款高端灶具，設計師增加了一個罩，認為灶具不用時可以用罩防灰塵，利于清理，殊不知罩本身的清洗更為麻煩。再如某應用軟件系統開發了一個對工廠發貨數據進行多維度分析的模塊，系統在使用過程中該模塊從來沒有用過，因為工作人員只需要了解每月、每類產品的發貨統計信息并進行缺貨、及時率、趨勢等簡要分析就可以了。

需求不全面。開發團隊關注從技術實現的角度定義需求，主要考慮的是功能及性能需求，而可制造性、可服務性、可測試性、可靠性、可安裝性等方面的需求缺乏考慮，導致需求定義不全面。

產品創新性不足。在定義和實現需求的分析過程中，缺乏探索不同或更好的產品概念及技術方案，往往只是沿用過去的設計方案，失去了提升產品創新性和競爭力的機會。如手機要帶物理鍵盤，這是開發人員習以為常的做法，消費者也使用習慣了。而蘋果開發iPhone時基于客戶需求探索新的技術實現方式，首次采用了通過觸摸屏的軟鍵盤方案。

導致返工。開發團隊不僅致力于快速形成產品需求說明書，而且希望盡快明確硬件、軟件、結構等各部分的需求，于是相關專業領域的人員按照自己的理解定義各子系統及模塊的需求。且不說整個產品/系統的需求是否存在問題，各自為戰的方式導致彼此理解不一致，各部分的銜接和接口考慮很不充分，代價就是后面頻繁的返工和修改。

可見，在開發流程中，產品包需求定義和設計需求開發要相分離，當然兩者又是緊密聯系的，而其轉化過程就顯得極為重要，其中涉及到產品概念開發、技術方案選擇、操作方式分析、需求映射分析、設計需求合理化等方面的具體操作。?在產品開發流程的概念階段，首先需要從客戶的角度明確、完整地定義產品包需求，接下來的關鍵轉化為設計需求。設計需求既然是技術上如何實現的需求，那么需要先確定技術實現的方法，因為不同的技術實現方式就會有不同的設計需求，如手機輸入的需求如果用物理鍵盤實現，則需要明確按鍵、信號獲取等方面的設計需求，如果用觸摸鍵盤實現，則需要觸摸屏、軟件處理等方面的設計需求。所以，同步要進行產品概念和技術方案的開發，這也是產品開發的一項關鍵活動，一般要探索多個產品概念及技術方案，然后從中選擇最佳且可行的方案。根據產品概念和技術方案，即可以確定產品包內部的及與外部相關的操作方式，然后將產品包需求分解為設計需求。對于每一個產品包需求，根據下面內容對操作方式進行概括。因為分解過程比較復雜，可以借助表格，將相關內容都寫入表格中（見后面附表）。

操作環境及顧客/用戶眼中的操作

顧客/用戶期望的操作

操作限制，在成本、尺寸、重量、電源、冷卻、環境、制造、服務等方面的操作限制。

限制范圍內的實際操作

在以下方面所帶來的結果影響：成本、質量、上市時間、顧客滿意度、兼容性等等

客戶/用戶對操作表示出來的任何吃驚（包括正面的和負面的）
對操作方式進行概括的一個例子：產品包需求是在中國偏遠地區進行緊急呼叫。用戶希望中國偏遠地區進行緊急呼叫而又不掉線。對操作方式進行概括的過程如下（操作概要）：a)???操作環境或上下文，從顧客/用戶角度考慮操作。舉例：呼叫人可能在偏遠山區快速移動，可能在大客車上，車上還有很多人也在打電話；電池可能不足，等等。b)???顧客/用戶對操作的期望。將期望劃分為強制性的、具有競爭力的或者最好的。比如：

強制性的：呼叫人呼叫，在振鈴五次內接通

具有競爭力的：?在振鈴三次內接通

最好的：?一次振鈴便接通
c)???操作在以下方面受到的限制：成本、體積、重量、功率、冷卻、環境、制造、服務等。比如：呼叫人不愿為被提供緊急呼叫的便利而另外付費，也不愿為支持緊急呼叫功能的手機而額外付費，并且希望電池使用時間越長越好。因此，也許必須使基站具有支持緊急呼叫的額外功能。內部限制是，原有基站已經占用所有可用功率，因此在基站上補充新功能要求進行重新設計。d)???在實際系統操作時盡量考慮這些限制因素。要注意考慮對成本、質量、上市時間、客戶滿意度、兼容性等方面的影響。例如：必須對基站重新進行設計來支持增加的功能，這樣一來便會增加成本，要求運營商們（顧客）對現有基站進行升級會增加成本負擔，而他們必須將這些負擔轉移到呼叫人那里。e)???顧客/用戶對操作的任何吃驚反應（正面以及負面的）都要重視。例如：如果需要為此項服務而額外付費（因為運營商產生了追加成本）的話，呼叫人會很不愉快。如果呼叫人在邊遠地區能夠很穩定地進行緊急呼叫的話，他們便會很高興。而運營商對于必須升級他們的基站則會很不愉快。在完成對操作方式的概括后，在附表的幫助下，依據操作方式把產品包需求分解為設計需求，并在下面圖表的幫助下并詳細列出每個設計需求可接受的參數范圍。應當將產品包需求分解為不同種類的設計需求，包括如下各部分：
????????功能
????????環境
????????性能
????????強健性（魯棒性）
????????可靠性
????????可維護性
????????可用性
????????安全性
????????重量
????????電源
????????尺寸大小
????????靈活性
????????其它

為了實現可追溯性，已經在分解層得到表述的分解描述的設計需求應當與特定的產品包需求建立明確的聯系。分解得到的設計需求還需要進行合理化處理，包括對設計需求進行分類、合并、沖突權衡、整合、刪除、修正等，以形成高質量的設計需求，為后續的產品開發工作提供堅實的依據。附表：產品包需求到設計需求的映射

?

?