問題，即如何能把需求描述清楚。需求必須要寫的清晰明確，完整，確保開發(fā)人員不需要為一個(gè)模糊的需求做決定，尤其是不要自行發(fā)揮。我推薦使用wiki來描述需求的細(xì)節(jié)，加上UI prototype，形象的描述需求。wiki最大的好處在于協(xié)同修改很方便。
另外一些實(shí)踐能夠幫助需求開發(fā)工程師提高需求編寫質(zhì)量：
１、記錄每條需求的原因。有研究成果表明，通過記錄每條需求的原因（即為什么要實(shí)現(xiàn)這個(gè)功能），可以刪除多達(dá)半數(shù)的所謂“需求”。雖然在記錄工作上投入了一定的工作量，但是有效地避免了為那些不必要的需求所要完成的后續(xù)工作，可以顯著地降低系統(tǒng)規(guī)模、縮短系統(tǒng)開發(fā)周期，正所謂“事半功倍”。
２、盡可能考慮采用適當(dāng)形式化的方法。由于自然語言存在歧義，一個(gè)二義性的描述因此可能導(dǎo)致對(duì)于同一個(gè)需求的不同解釋，而采用形式化表示方法編寫需求能夠更加準(zhǔn)確地在用戶和開發(fā)團(tuán)隊(duì)間進(jìn)行溝通。常用的形式化需求表示方法包括：實(shí)體關(guān)系圖、數(shù)據(jù)字典、數(shù)據(jù)流程圖、USE CASE等。當(dāng)然還是 UI prototype最直接，簡(jiǎn)單，有效。
３、使用專業(yè)的工具編寫需求，管理需求。這類工具由于沒有成熟的理論指導(dǎo)，客戶的要求各有不同，市場(chǎng)上相應(yīng)的工具不多。漢星天公司一直致力于這方面的研究，推出了相應(yīng)的需求描述，需求變更管理的解決方案；并在中國(guó)上百家大企業(yè)得到非常好的效果。
用戶需求 vs軟件需求
需求，誰來寫呢？我們先看看兩個(gè)定義需求的名詞：
用戶需求 - 用戶對(duì)于其需要解決的問題以及期待的軟件能力的描述。通常以用戶的語言描述，用作開發(fā)團(tuán)隊(duì)與用戶就系統(tǒng)如何解決問題進(jìn)行溝通的橋梁。
軟件需求 - 建立在用戶需求之上，以開發(fā)團(tuán)隊(duì)所能理解的方式描述系統(tǒng)所應(yīng)具有的功能，是開發(fā)團(tuán)隊(duì)進(jìn)行設(shè)計(jì)和實(shí)現(xiàn)的依據(jù)。
我了解的一般的客戶，寫個(gè)word文檔，發(fā)封email，或打個(gè)電話，就把需求甩給開發(fā)團(tuán)隊(duì)了。能寫一個(gè)結(jié)構(gòu)完整、內(nèi)容嚴(yán)謹(jǐn)需求的客戶很少。在美國(guó)，基本上用戶會(huì)寫需求，RFP（Request for Proposal）。國(guó)內(nèi)有時(shí)候項(xiàng)目經(jīng)理或做需求分析的工程師會(huì)幫助用戶整理用戶需求。用戶需求比較粗。有了用戶需求之后，再對(duì)其細(xì)化，寫出軟件需求。對(duì)于應(yīng)用系統(tǒng)來說，軟件需求寫好了，開發(fā)的工作就簡(jiǎn)單多了。
這兩種需求分別記錄。里程碑一般以用戶需求為目標(biāo)。用戶需要關(guān)聯(lián)到多個(gè)軟件需求上。
項(xiàng)目規(guī)劃和進(jìn)度監(jiān)控
將需求作為項(xiàng)目規(guī)劃和實(shí)施的目標(biāo)，這是RDPM的核心。一切以需求為中心。
通過小版本發(fā)布逐步實(shí)現(xiàn)需求
在項(xiàng)目計(jì)劃和進(jìn)度控制方面，我們采用迭代的方法。
將項(xiàng)目目標(biāo)分解為較小的、易于管理的子目標(biāo)，這對(duì)于減少項(xiàng)目失敗風(fēng)險(xiǎn)很有幫助。項(xiàng)目目標(biāo)分解可以從各個(gè)角度進(jìn)行，采用小版本發(fā)布分階段實(shí)現(xiàn)項(xiàng)目需求是目前越來越被認(rèn)同的一種。尤其是現(xiàn)在流行的敏捷開發(fā)方法，更是提倡迭代開發(fā)。有個(gè)普遍的誤解就是以為敏捷開發(fā)方法只適用于小規(guī)模的開發(fā)團(tuán)隊(duì)，其實(shí)對(duì)大的團(tuán)隊(duì)一樣適用。大的開發(fā)團(tuán)隊(duì) 可以按照實(shí)現(xiàn)不同的模塊分成很多小的項(xiàng)目小組，給個(gè)項(xiàng)目小組其實(shí)就是一個(gè)小團(tuán)隊(duì)。一般5、6個(gè)人最為合適，團(tuán)隊(duì)合作和溝通成本之間有一個(gè)很好的平衡。
小版本發(fā)布是針對(duì)以前瀑布式開發(fā)的缺點(diǎn)而提出的開發(fā)方式。在以前的模式中，項(xiàng)目往往經(jīng)過一個(gè)漫長(zhǎng)的需求開發(fā)、設(shè)計(jì)、編碼和測(cè)試階段后才能夠與客戶見面，而客戶在這個(gè)時(shí)間段上進(jìn)入了“盲區(qū)”，直到開發(fā)團(tuán)隊(duì)“隆重推出”開發(fā)成果。而恰恰這個(gè)時(shí)候是項(xiàng)目風(fēng)險(xiǎn)最大的時(shí)候，由于在過程中缺乏交流機(jī)會(huì)，客戶往往會(huì)發(fā)現(xiàn)這個(gè)產(chǎn)品與他們想象的很不一樣，因此很有可能導(dǎo)致項(xiàng)目拖延或者失敗。
小版本發(fā)布則不同，它將系統(tǒng)的實(shí)現(xiàn)分解為多個(gè)連續(xù)的版本，每一個(gè)都實(shí)現(xiàn)一部分的