在軟件項目處理進(jìn)程中,，項目經(jīng)理常常面對用戶的需求改動。假定不能有用處理這些需求改動,，團(tuán)購軟件,，項目方案會再三調(diào)整，軟件交給日期再三推遲,，項目研制人員的士氣將越來越丟失,，將直接致使項目本錢添加、下降及項目交給日期推后,。這選擇了項目組有-具有需求處理戰(zhàn)略,。

   一、需求處理復(fù)雜性剖析

   軟件需求是全部軟件開發(fā)項意圖關(guān)鍵的一個輸入,，和傳統(tǒng)的出產(chǎn)公司相比較,，軟件的需求具有迷惑性、不確定性,、易改變性和主觀性的特色,，他不像出產(chǎn)汽車、電腦等硬件的需求,，是有形的,、客觀的、可描繪的,、可查看的,，軟件需求是軟件項目難把握的疑問，他的易改變性體現(xiàn)在以下方面：

   1,、項目需求的描繪疑問,。短少正式的無缺的需求文檔浪費(fèi)了許多的人力物力，可是有了需求文檔又出現(xiàn)了新的疑問,。在用戶方進(jìn)行的需求評審會完全是走形式,，因為用戶根柢不去聽他讀那上百頁的需求文檔。紛歧樣層次的客戶用戶關(guān)心的疑問是紛歧樣的,，想要每個客戶都變成需求是不現(xiàn)實的,。

   2、需求的齊備程度疑問,。需求怎樣做到?jīng)]有丟失,？怎樣準(zhǔn)確劃定體系的方案？這確實是一個兩難疑問，略微大一點的體系要想窮舉需求幾乎是不或許的,，每次開需求評審會時,，總會冒出新的需求，以至于體系沒有一個準(zhǔn)確的方案界定,。即使是這么,，體系仍是要開發(fā)，沒辦法,，體系的方案還要硬性的劃定一個，然后建立一個基線,。

   3,、需求的詳盡程度疑問。需求究竟描繪到多細(xì),，才算能夠完畢了,？仁者見仁，智者見智,，并沒有結(jié)論,，假定時刻容許，要想細(xì)-夠細(xì)下去的,。

   4,、需求開發(fā)的工期疑問。在需求上花費(fèi)了許多的時刻,，客戶,、軟件公司是不是能夠忍耐？為了-需求的正確性,，齊備性,，項目經(jīng)理通常堅持要在需求期間花費(fèi)許多的時刻，可是客戶與公司的高層---卻會為項目遲遲看不到實習(xí)可作業(yè)的軟件擔(dān)憂不已,！

   5,、需求的改動疑問。在軟件開發(fā)進(jìn)程中假定只需一條真理的話,，那必定是：需求的改動是耐久的,，團(tuán)購---，需求不或許是齊備的,。

     以前我們接受過的思想是立項后先要需求-,、分析，-后出各種-報告及需求說明書,，需求搞定后,，再進(jìn)行概要設(shè)計ue設(shè)計、ui設(shè)計、交互設(shè)計,、數(shù)據(jù)庫設(shè)計,、框架設(shè)計，概要設(shè)計完成后再進(jìn)行詳細(xì)設(shè)計這樣一個周期下來,，耗費(fèi)太長,，當(dāng)進(jìn)度進(jìn)入下一階段，當(dāng)上一階段有問題時,，會影響到整個項目流程的各個階段,。  而敏捷方法是會將大的系統(tǒng)拆分成一個個子項目，再把子系統(tǒng)拆分成子模塊,，盡量減少模塊間的耦合性,、增加其內(nèi)聚性，定制團(tuán)購軟件,，這樣我們可以把團(tuán)隊分成多個小組,，各組可以同時作業(yè)。另外,，當(dāng)一個模塊需求發(fā)生變化時,，對其它模塊的影響也不會太大，以實現(xiàn)降低開發(fā)難度的目的,。