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