lestone一個(gè)milestone的發(fā)展。象小孩子長(zhǎng)大一樣，中間可能會(huì)走彎路、錯(cuò)路，需要我們不短的調(diào)整、指引，最后他/她才能成才。你很難一開(kāi)始就給他/她描繪一個(gè)一生的所有的詳細(xì)場(chǎng)景，讓他/她按照你的藍(lán)圖走（工程項(xiàng)目才能做到這樣）。
我們建議先想好我們會(huì)有幾個(gè)milestone，每個(gè)milestone發(fā)布哪些功能。然后描述需求，最框架性的需求要最先確定好, 然后先寫(xiě)最近要實(shí)現(xiàn)的功能的需求說(shuō)明。后面的需求 和開(kāi)發(fā)就可以并行了。這樣我們的產(chǎn)品可以比較快的面世，客戶會(huì)及時(shí)的給出反饋。從而減小項(xiàng)目的風(fēng)險(xiǎn)。這里建議寫(xiě)需求的時(shí)候，用UI Prototype，User Scenario方法，讓用戶越早看到實(shí)際使用界面和使用方法越好。
目前我們很多項(xiàng)目的需求是用Microsoft Word寫(xiě)的，動(dòng)輒幾十頁(yè)，上百頁(yè)。這樣的大文檔，除了上面講到的項(xiàng)目管理方法上的問(wèn)題，還存在下面的問(wèn)題：
１、規(guī)模巨大，不方便查閱。一個(gè)中小型應(yīng)用系統(tǒng)的需求文檔可多達(dá)數(shù)百頁(yè)甚至更多。即使使用分卷也不方便查閱.
２、不利于更新。需求文檔是一個(gè)活的文檔，不斷的增長(zhǎng)，更新是難免的。在Word中做了更新，即使用修訂模式，也不容易看出更改的部分。這樣導(dǎo)致開(kāi)發(fā)和功能設(shè)計(jì)兩個(gè)環(huán)節(jié)溝通不暢。通常就變成需求只有第一個(gè)版本，以后的變更就發(fā)個(gè)郵件或口頭說(shuō)一下了。
３、不利于多人同時(shí)、協(xié)同修改。
４、需求沒(méi)有條目化，Word文檔中通常只是描述功能，但實(shí)際上我們還要把需求分成一項(xiàng)一項(xiàng)，設(shè)置每個(gè)需求的優(yōu)先級(jí)，難易程度，功能點(diǎn)（function point），在哪個(gè)發(fā)布中應(yīng)該做完，需求來(lái)源等等。這種類(lèi)似數(shù)據(jù)庫(kù)的特性，在Word難以體現(xiàn)。
５、不利于建立需求與其它開(kāi)發(fā)控制元素的關(guān)系。這可能對(duì)寫(xiě)需求的業(yè)務(wù)人員體會(huì)不到，但對(duì)于項(xiàng)目經(jīng)理，實(shí)現(xiàn)這些需求的人員來(lái)說(shuō)是非常重要的。在開(kāi)發(fā)過(guò)程中用戶需求與軟件需求的關(guān)系、軟件需求與開(kāi)發(fā)任務(wù)的關(guān)系、測(cè)試用例與需求之間的關(guān)系等，對(duì)于需求變更控制、質(zhì)量控制都是非常重要的參考信息。一體化的需求文檔（如MS Word）很難做到這一點(diǎn)。
以需求驅(qū)動(dòng)的項(xiàng)目管理(RDPM)
針對(duì)應(yīng)用軟件的項(xiàng)目，漢星天公司提出與傳統(tǒng)的基于任務(wù)的項(xiàng)目管理方法不同的，以需求為中心的軟件項(xiàng)目管理方法。在管理中，Microsoft Project和Word的使用處于次要地位。
用戶的需求是軟件開(kāi)發(fā)的源泉和歸宿。需求代表了用戶期待解決的問(wèn)題，而軟件項(xiàng)目開(kāi)發(fā)的所有活動(dòng)都是為此目標(biāo)服務(wù)的。在眾多的軟件開(kāi)發(fā)實(shí)施案例中，當(dāng)項(xiàng)目一 旦開(kāi)始，對(duì)于用戶而言項(xiàng)目就像進(jìn)入了隧道的列車(chē)：他們?cè)匐y看到自己需求的實(shí)現(xiàn)狀況，雖然有眾多的形形色色的項(xiàng)目進(jìn)展報(bào)表，卻很難回答一個(gè)很簡(jiǎn)單的問(wèn)題：我的那些需求究竟實(shí)現(xiàn)的怎樣？ RDPM(Requirement Driven Project Management)的核心就在于需求，而不是任務(wù)。
需求的開(kāi)發(fā)
首先要需求條目化。而不是放在一個(gè)大Word文檔中。條目化之后，我們就可以給每個(gè)需求設(shè)置屬性，通過(guò)這些屬性來(lái)決定需求實(shí)現(xiàn)的順序，工期，查看當(dāng)前的狀態(tài)等等。包括里程碑的制定，都要針對(duì)具體的需求項(xiàng)。 同時(shí)為了處理變更，我們還要記錄需求之間的依賴(lài)關(guān)系以及追蹤需求與后續(xù)的開(kāi)發(fā)工件（如計(jì)劃、任務(wù)、測(cè)試用例、實(shí)現(xiàn)代碼等）的關(guān)系。這些關(guān)系又稱(chēng)之為“需求 追蹤矩陣”。 一旦需求發(fā)生變化，影響面很廣，要評(píng)估與實(shí)施需求變更，首先要確認(rèn)需求變化帶來(lái)的沖擊面。這個(gè)工作就要依賴(lài)于“需求追蹤矩陣”體系。這也是我們?yōu)槭裁匆研枨髼l目化的一個(gè)重要原因。
條目化的需求，用MS Word難以管理，一般需要存放在數(shù)據(jù)庫(kù)中。
但條目化不能解決一個(gè)古老的