需求的描述
軟件項目有很多不同類型。目前我們所說的軟件項目，多數指的是應用類(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）很難做到這一點。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
