用戶需求 vs. 軟件需求
需求，誰來寫呢？我們先看看兩個定義需求的名詞：
用戶需求 - 用戶對于其需要解決的問題以及期待的軟件能力的描述。通常以用戶的語言描述，用作開發團隊與用戶就系統如何解決問題進行溝通的橋梁。
軟件需求 - 建立在用戶需求之上，以開發團隊所能理解的方式描述系統所應具有的功能，是開發團隊進行設計和實現的依據。
我了解的一般的客戶，寫個word文檔，發封email，或打個電話，就把需求甩給開發團隊了。能寫一個結構完整、內容嚴謹需求的客戶很少。在美國，基本上用戶會寫需求，RFP（Request for Proposal）。國內有時候項目經理或做需求分析的工程師會幫助用戶整理用戶需求。用戶需求比較粗。有了用戶需求之后，再對其細化，寫出軟件需求。對于應用系統來說，軟件需求寫好了，開發的工作就簡單多了。
這兩種需求分別記錄。里程碑一般以用戶需求為目標。用戶需要關聯到多個軟件需求上。
項目規劃和進度監控
將需求作為項目規劃和實施的目標，這是RDPM的核心。一切以需求為中心。
通過小版本發布逐步實現需求
在項目計劃和進度控制方面，我們采用迭代的方法。
將項目目標分解為較小的、易于管理的子目標，這對于減少項目失敗風險很有幫助。項目目標分解可以從各個角度進行，采用小版本發布分階段實現項目需求是目前越來越被認同的一種。尤其是現在流行的敏捷開發方法，更是提倡迭代開發。有個普遍的誤解就是以為敏捷開發方法只適用于小規模的開發團隊，其實對大的團隊一樣適用。大的開發團隊 可以按照實現不同的模塊分成很多小的項目小組，給個項目小組其實就是一個小團隊。一般5、6個人最為合適，團隊合作和溝通成本之間有一個很好的平衡。
小版本發布是針對以前瀑布式開發的缺點而提出的開發方式。在以前的模式中，項目往往經過一個漫長的需求開發、設計、編碼和測試階段后才能夠與客戶見面，而客戶在這個時間段上進入了“盲區”，直到開發團隊“隆重推出”開發成果。而恰恰這個時候是項目風險最大的時候，由于在過程中缺乏交流機會，客戶往往會發現這個產品與他們想象的很不一樣，因此很有可能導致項目拖延或者失敗。
小版本發布則不同，它將系統的實現分解為多個連續的版本，每一個都實現一部分的系統功能。當每個小版本結束后，都會邀請客戶評估這一版本實現的狀況，并且根據用戶反饋制定和調整下一個小版本的目標。這樣做的好處是顯而易見的：客戶越早看到產品，就能越早發現與開發團隊間就用戶需求方面的理解差異， 盡早調整需求，從而避免了在項目后期調整需求帶來的巨額代價。另一個潛在的好處是，這一部分產品功能經過驗收后就有可能投入使用，從而盡早為用戶提供價值。 當然，小版本發布會不可避免地面臨較多的需求變更請求，因此需要仔細的管理需求變更。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
