軟件開發項目中的需求變更分析和解決之道[3]

    •一級需求（或變更）是關鍵性的需求，這種需求如果不滿足，意味著整個項目不能正常交付使用，前期工作也會被全部否定。這個級別的需求是必須滿足的，否則就意味著否定自已的項目成員和成員的所有努力，所以定為“Urgent”。 這通常是屬于補救性的debug類型，要救火。 

    •　二級需求（或變更）是后續關鍵性需求，它不影響前面工作內容的交付，但不加以滿足，新的項目內容無法提交或繼續，所以是“Necessary”。一般新模塊關鍵性的基礎組件，屬于這個級別。 

    •三級需求是后續重要的需求，如果不被滿足會令整體項目工作的價值下降，為了體現項目價值，也是開發人員自已的技術價值的證明，所以定為“Needed”。一般性的重大的有價值的全新模塊開發，屬于這個級別。 

    以上三個等級是應該實施的，但時間性上可以作優先級的排列。 

    •四級需求是改良性需求，沒有滿足這類需求并不影響已有功能的使用，但如果實現了則會更好，定級為“Better”。界面和使用方式的需求，一般在這個檔次。 

    •五級需求是可選性需求，更多的是偶是一種設想，以及一種可能，通常只是客戶的的一種個人喜好而已，定級為“Maybe”。 

　　對于四級需求，如果時間和資源條件都允許的話，不妨做下去。對于五級需求，正如對它的描述一樣，做與不做是“Maybe”。 

    2、全生命周期的需求變更管理 

    各種規模和類型的軟件項目的生命周期大致可以分為三個階段，即項目啟動、項目實施、項目收尾。不要以為需求變更的管理和控制只是發生在項目實施階段，而是要貫穿在整個項目生命周期的全過程中。 

    站在全局角度的需求變更管理，需要采用綜合變更控制的方法。 

    （1） 項目啟動階段的變更預防 

    正如前面強調的，對于任何軟件項目，需求變更都無可避免，也無從逃避，無論是項目經理還是開發人員只能積極應對，而這個應對應該是從項目啟動的需求分析階段就開始了。 
    對一個需求分析做得很好的項目來說，基準文件定義的范圍越詳細清晰，用戶跟項目經理提出需求變更的幾率就越小。如果需求沒做好，基準文件里的范圍含糊不清，被客戶發現還有很大的“新需求空間”，這時候項目組往往要付出許多無謂的犧牲。 

原文轉自：http://www.kjueaiud.com