就中國目前很多軟件開發團隊的實際情況來看，從某種程度上來說，錯誤的使用和依賴兩個軟件來管理項目是項目失敗的一個重要理由。這兩個軟件就是Microsoft Project和Microsoft Word。 就像釘釘子，總是用一把斧子。
工程項目 vs 軟件項目
Microsoft Project本身是一個不錯的項目管理工具，能夠做任務分配，Petri-NET, Gannt圖，資源使用分析等等。但是，Project是用來管理工程項目的，如造房子，修大橋等等。這些工程類的項目一般使用以任務驅動的管理方法。而軟件項目和傳統的工程項目有本質的差別，那就是任務的不確定性。舉個例子，目前房地產很火，造什么樣的房子，只要資金到位，都能保質保量的造好。造10層樓，1層用多少人天，每天做什么，很容易計劃，分配任務，人力資源。而且需求是不會變的。沒見過造房子，蓋了3層之后改主意了，拆了重新蓋。
而軟件就大大不同了，需求的變化是不可避免的，而且凡是做過項目的人都知道，需求的變化實際上還挺頻繁。這樣一來，很容易造成計劃趕不上變化，用Project定義任務，計劃工期通常要耗費項目經理大量的時間，而且沒有意義。
有人問，為什么需求不能固定下來呢？定下來就不許變。通常工程師會問這樣的問題。如果他變成了客戶，他可能就不會問這個問題了。需求總是會變的。第一：出錢的總是有更多的話語權（當然改需求是要應該付費的）；第二：市場的情況在變，比如競爭對手突然發布了一個新的產品功能， 那我們也必須做出應對，這就要變更需求；第三：寫需求的不是神仙，人都或犯錯誤的，犯錯誤允許改正（但犯錯誤要有懲罰，就是需求變更是要付費的）。 因此傳統的純瀑布式的開發方式已經成為歷史了，愈來愈多的開發團隊采用極限編程，迭代的開發，來應付需求的變更。
那么軟件項目的這種特點，需要與之相應的項目管理工具。用斧子釘釘子的做法就有點不合時宜了。
和傳統項目還有一個很大的不同，當工程項目拖后了工期，可以多加人手，把工期趕回來。而軟件就不這么簡單了，新來的人要熟悉項目的內容就要花時間，工期很難完全趕上。很多IT的老總們體會不到這個問題，總以為多加人手，加班就能搞定。真正的有效的項目管理是要靠一個有效的管理體系來支撐的。
需求的描述
軟件項目有很多不同類型。目前我們所說的軟件項目，多數指的是應用類(Application)的軟件項目，而不是系統類(System)的項目，如數據庫，文件系統，開發工具。系統類的軟件項目和應用類的項目有很大的不同。系統類的項目花很長時間研究體系架構（Architecture），設計系統的框架，模塊之間的關系等等。而應用類的軟件基本上會用現成的框架，如J2EE, 或Microsoft的平臺等等，主要精力放在需求的實現上。中國目前的應用系統多數是為客戶做定制開發的項目，比如各大企業、政府、機構、國防等做的系統，也有一些做產品的，如中小企業的財務系統，通用辦公軟件等等。 針對應用類的項目，我們看看使用Word寫這類的需求有什么問題，為什么有問題。
一般用Word來寫需要，隱含了一個想法，就是一上來把需求都寫好，定下來，然后給開發部門去實現。一般Word文檔寫的需求很龐大。 而對于應用系統的開發, 我建議使用迭代的方法開發。上面提到了，瀑布式的開發已經成為了歷史。需求一次性寫好，很難。軟件是慢慢成長起來的（見Microsoft Secrets），一個milestone一個milestone的發展。象小孩子長大一樣，中間可能會走彎路、錯路，需要我們不短的調整、指引，最后他/她才能成才。你很難一開始就給他/她描繪一個一生的所有的詳細場景，讓他/她按照你的藍圖走（工程項目才能做到這樣）。
我們建議先想好我們會有幾個milestone，每個milestone發布哪些功能。然后描述需求，最框架性的需求要最先確定好, 然后先寫最近要實現的功能的需求說明。后面的需求 和開發就可以并行了。這樣我們的產品可以比較快的面世，客戶會及時的給出反饋。從而減小項目的風險。這里建議寫需求的時候，用UI Prototype，User Scenario方法，讓用戶越早看到實際使用界面和使用方法越好。
目前我們很多項目的需求是用Microsoft Word寫的，動輒幾十頁，上百頁。這樣的大文檔，除了上面講到的項目管理方法上的問題，還存在下面的問題：
１、規模巨大，不方便查閱。一個中小型應用系統的需求文檔可多達數百頁甚至更多。即使使用分卷也不方便查閱.
２、不利于更新。需求文檔是一個活的文檔，不斷的增長，更新是難免的。在Word中做了更新，即使用修訂模式，也不容易看出更改的部分。這樣導致開發和功能設計兩個環節溝通不暢。通常就變成需求只有第一個版本，以后的變更就發個郵件或口頭說一下了。
３、不利于多人同時、協同修改。
４、需求沒有條目化，Word文檔中通常只是描述功能，但實際上我們還要把需求分成一項一項，設置每個需求的優先級，難易程度，功能點（function point），在哪個發布中應該做完，需求來源等等。這種類似數據庫的特性，在Word難以體現。
５、不利于建立需求與其它開發控制元素的關系。這可能對寫需求的業務人員體會不到，但對于項目經理，實現這些需求的人員來說是非常重要的。在開發過程中用戶需求與軟件需求的關系、軟件需求與開發任務的關系、測試用例與需求之間的關系等，對于需求變更控制、質量控制都是非常重要的參考信息。一體化的需求文檔（如MS Word）很難做到這一點。
以需求驅動的項目管理(RDPM)
針對應用軟件的項目，漢星天公司提出與傳統的基于任務的項目管理方法不同的，以需求為中心的軟件項目管理方法。在管理中，Microsoft Project和Word的使用處于次要地位。
用戶的需求是軟件開發的源泉和歸宿。需求代表了用戶期待解決的問題，而軟件項目開發的所有活動都是為此目標服務的。在眾多的軟件開發實施案例中，當項目一 旦開始，對于用戶而言項目就像進入了隧道的列車：他們再難看到自己需求的實現狀況，雖然有眾多的形形色色的項目進展報表，卻很難回答一個很簡單的問題：我的那些需求究竟實現的怎樣？ RDPM(Requirement Driven Project Management)的核心就在于需求，而不是任務。
需求的開發
首先要需求條目化。而不是放在一個大Word文檔中。條目化之后，我們就可以給每個需求設置屬性，通過這些屬性來決定需求實現的順序，工期，查看當前的狀態等等。包括里程碑的制定，都要針對具體的需求項。 同時為了處理變更，我們還要記錄需求之間的依賴關系以及追蹤需求與后續的開發工件（如計劃、任務、測試用例、實現代碼等）的關系。這些關系又稱之為“需求 追蹤矩陣”。 一旦需求發生變化，影響面很廣，要評估與實施需求變更，首先要確認需求變化帶來的沖擊面。這個工作就要依賴于“需求追蹤矩陣”體系。這也是我們為什么要把需求條目化的一個重要原因。
條目化的需求，用MS Word難以管理，一般需要存放在數據庫中。
但條目化不能解決一個古老的問題，即如何能把需求描述清楚。需求必須要寫的清晰明確，完整，確保開發人員不需要為一個模糊的需求做決定，尤其是不要自行發揮。我推薦使用wiki來描述需求的細節，加上UI prototype，形象的描述需求。wiki最大的好處在于協同修改很方便。
另外一些實踐能夠幫助需求開發工程師提高需求編寫質量：
１、記錄每條需求的原因。有研究成果表明，通過記錄每條需求的原因（即為什么要實現這個功能），可以刪除多達半數的所謂“需求”。雖然在記錄工作上投入了一定的工作量，但是有效地避免了為那些不必要的需求所要完成的后續工作，可以顯著地降低系統規模、縮短系統開發周期，正所謂“事半功倍”。
２、盡可能考慮采用適當形式化的方法。由于自然語言存在歧義，一個二義性的描述因此可能導致對于同一個需求的不同解釋，而采用形式化表示方法編寫需求能夠更加準確地在用戶和開發團隊間進行溝通。常用的形式化需求表示方法包括：實體關系圖、數據字典、數據流程圖、USE CASE等。當然還是 UI prototype最直接，簡單，有效。
３、使用專業的工具編寫需求，管理需求。這類工具由于沒有成熟的理論指導，客戶的要求各有不同，市場上相應的工具不多。漢星天公司一直致力于這方面的研究，推出了相應的需求描述，需求變更管理的解決方案；并在中國上百家大企業得到非常好的效果。
用戶需求 vs軟件需求
需求，誰來寫呢？我們先看看兩個定義需求的名詞：
用戶需求 - 用戶對于其需要解決的問題以及期待的軟件能力的描述。通常以用戶的語言描述，用作開發團隊與用戶就系統如何解決問題進行溝通的橋梁。
軟件需求 - 建立在用戶需求之上，以開發團隊所能理解的方式描述系統所應具有的功能，是開發團隊進行設計和實現的依據。
文章來源于領測軟件測試網 http://www.kjueaiud.com/