的細致性問題
在文章的開頭就說明了軟件需求在整個軟件系統(tǒng)開發(fā)中的重要性，正是由于它的重要性，一般來說，需求描述越詳細越好。項目的開發(fā)方與用戶在各種問題上的要求都是基本輪廓達到一致即可，具體的細節(jié)可以以后再填充，這是一種非常危險的思想。不管需求分析做的多么細致，以后對需求的變更都是必然的。另一方面，在需求分析階段，開發(fā)人員希望再多投人一些時間，但是用戶卻不這么認為，因為需求階段是軟件系統(tǒng)開發(fā)首先要進人的階段，離最終開發(fā)出可用的系統(tǒng)還有很長一段距離，這導致了雙方的不一致。但如果在需求階段投人很多時間，時間越長，可能的變化就越多，對設計的限制越嚴格，因此在需求描述的問題上，沒有統(tǒng)一的界定，需要開發(fā)人員學會適當?shù)陌盐铡?
3.2需求描述的正確性
軟件開發(fā)是一種專業(yè)行為，一般的業(yè)主難以理解軟件開發(fā)人員的開發(fā)理念。所以在和業(yè)主交流時，他們講述的需求在實際中利用現(xiàn)有的技術是實現(xiàn)不了的，用戶以為自己很清楚自己的需求了，但實際上他們只是依據當時的工作需求提出的。隨著開發(fā)工作的不斷進展，用戶可能想到更多的功能和特色，進而對以前的需求進行改動，導致需求的不一致。
另外一種情況就是開發(fā)人員和業(yè)主交流時，由于業(yè)主本身對需求的描述不清晰，導致開發(fā)人員誤解或曲解了業(yè)主最初的要求，最后開發(fā)出來的系統(tǒng)不是不能滿足用戶，就是一個發(fā)生需求錯誤的系統(tǒng)。事實上這種錯誤在需求階段也會經常發(fā)生。更可怕的是，對于需求階段出現(xiàn)的錯誤，如果在軟件項目進行到后期的時候才發(fā)現(xiàn)，修復費用是非常可怕的，甚至會超出項目本身的費用。因此做好需求管理、減少需求錯誤的出現(xiàn)對于降低軟件項目的成本是必要的，也是至關重要的。
3. 3需求描述的完備性
系統(tǒng)的需求是層出不窮的，我們不可能做到把所有的需求都一一列舉出來，并且隨著時間的推進，用戶的需求也會越來越多，要窮舉需求是不可能做到的。另外，并不是用戶提出的所有需求都要滿足，在項目的最后，改變一個需求對整個項目的影響或損失很可能會超過需求本身給用戶帶來的益處。
3. 4需求的變更
需求的變化問題是每個開發(fā)人員、每個項目經理都遇到的問題，也是最頭痛的問題，一旦發(fā)生了需求變化，你不得不來修改你的設計、重寫你的代碼、修改你的測試用例、調整你的項目計劃等等，需求的變化好比是萬惡之源，為項目的正常的進展帶來不盡的麻煩，怎么辦?管理它!使需求在受控的狀態(tài)下發(fā)生變化，而不是隨意變化，需求管理就是要按照標準的流程來控制需求的變化。難題隨之而來，需求中的變化一般不是突發(fā)的革命性的變化，最常見的是項目需求的漸變(Project Scope Creep)問題，這種漸變很可能是客戶與開發(fā)方都沒有意識到的，當達到一定程度時，雙方才驀然回首，發(fā)現(xiàn)已經物是人非，換了一番天地。
4解決問題的策略
4. 1對需求文檔版本控制
客戶簽收的所有過程文檔都要作為基線確定下來，做好相關文檔的管理工作。需求的基線是指是否容許需求變更的分界線，需求分析人員在充分與客戶用戶進行溝通的基礎上形成第一個版本的需求文檔，這個需求文檔在通過需求評審后即可以建立第一個需求基線。此后每次需求變更并經過需求評審后，都要重新確定新的需求基線，以免將來用戶需求發(fā)生變更時，原來的需求無法查找。為有效進行需求變更控制，必然要做的工作就是保存好各個版本的需求基線，維護需求基線文檔，以備不時之需。
4. 2正確認識需求變更
在軟件開發(fā)過程中有這樣一條真理:需求的變化是永恒的，需求不可能是完備的。軟件開發(fā)的過程實際上是一個變化的過程，需求的變更不一定是壞事，也有可能是好事。
變更的需求之所以變