我建議使用迭代的方法開發(fā)。上面提到了，瀑布式的開發(fā)已經(jīng)成為了歷史。需求一次性寫好，很難。軟件是慢慢成長起來的（見Microsoft Secrets），一個milestone一個milestone的發(fā)展。象小孩子長大一樣，中間可能會走彎路、錯路，需要我們不短的調(diào)整、指引，最后他/她才能成才。你很難一開始就給他/她描繪一個一生的所有的詳細(xì)場景，讓他/她按照你的藍圖走（工程項目才能做到這樣）。

　　我們建議先想好我們會有幾個milestone，每個milestone發(fā)布哪些功能。然后描述需求，最框架性的需求要最先確定好, 然后先寫最近要實現(xiàn)的功能的需求說明。后面的需求 和開發(fā)就可以并行了。這樣我們的產(chǎn)品可以比較快的面世，客戶會及時的給出反饋。從而減小項目的風(fēng)險。這里建議寫需求的時候，用UI Prototype，User Scenario方法，讓用戶越早看到實際使用界面和使用方法越好。 

　　目前我們很多項目的需求是用Microsoft Word寫的，動輒幾十頁，上百頁。這樣的大文檔，除了上面講到的項目管理方法上的問題，還存在下面的問題： 

　　１、規(guī)模巨大，不方便查閱。一個中小型應(yīng)用系統(tǒng)的需求文檔可多達數(shù)百頁甚至更多。即使使用分卷也不方便查閱. 

　?。?、不利于更新。需求文檔是一個活的文檔，不斷的增長，更新是難免的。在Word中做了更新，即使用修訂模式，也不容易看出更改的部分。這樣導(dǎo)致開發(fā)和功能設(shè)計兩個環(huán)節(jié)溝通不暢。通常就變成需求只有第一個版本，以后的變更就發(fā)個郵件或口頭說一下了。 


　?。场⒉焕诙嗳送瑫r、協(xié)同修改。 
　?。础⑿枨鬀]有條目化，Word文檔中通常只是描述功能，但實際上我們還要把需求分成一項一項，設(shè)置每個需求的優(yōu)先級，難易程度，功能點（function point），在哪個發(fā)布中應(yīng)該做完，需求來源等等。這種類似數(shù)據(jù)庫的特性，在Word難以體現(xiàn)。 

　?。?、不利于建立需求與其它開發(fā)控制元素的關(guān)系。這可能對寫需求的業(yè)務(wù)人員體會不到，但對于項目經(jīng)理，實現(xiàn)這些需求的人員來說是非常重要的。在開發(fā)過程中用戶需求與軟件需求的關(guān)系、軟件需求與開發(fā)任務(wù)的關(guān)系、測試用例與需求之間的關(guān)系等，對于需求變更控制、質(zhì)量控制都是非常重要的參考信息。一體化的需求文檔（如MS Word）很難做到這一點。 

　　以需求驅(qū)動的項目管理(RDPM)

　　針對應(yīng)用軟件的項目，漢星天公司提出與傳統(tǒng)的基于任務(wù)的項目管理方法不同的，以需求為中心的軟件項目管理方法。在管理中，Microsoft Project和Word的使用處于次要地位。

　　用戶的需求是軟件開發(fā)的源泉和歸宿。需求代表了用戶期待解決的問題，而軟件項目開發(fā)的所有活動都是為此目標(biāo)服務(wù)的。在眾多的軟件開發(fā)實施案例中，當(dāng)項目一 旦開始，對于用戶而言項目就像進入了隧道的列車：他們再難看到自己需求的實現(xiàn)狀況，雖然有眾多的形形色色的項目進展報表，卻很難回答一個很簡單的問題：我的那些需求究竟實現(xiàn)的怎樣？ RDPM(Requirement Driven Project Management)的核心就在于需求，而不是任務(wù)。 

　　需求的開發(fā)
 
　　首先要需求條目化。而不是放在一個大Word文檔中。條目化之后，我們就可以給每個需求設(shè)置屬性，通過這些屬性來決定需求實現(xiàn)的順序，工期，查看當(dāng)前的狀態(tài)等等。包括里程碑的制定，都要針對具體的需求項。 同時為了處理變更，我們還要記錄需求之間的依賴關(guān)系以及追蹤需求與后續(xù)的開發(fā)工件（如計劃、任務(wù)、

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://m.opto-elec.com.cn/pmqhd/index.html