產(chǎn)生影響，但一旦產(chǎn)生影響，處理起來就很麻煩，這也是為什么大家都提倡在需求階段把需求做充分，在設(shè)計階段把架構(gòu)設(shè)計靈活。前者可以預(yù)防問題發(fā)生，后者則可以盡量降低問題發(fā)生后對設(shè)計的影響。
(三) 測試階段的需求變更
在這個階段需求變更發(fā)生較少，但也會出現(xiàn)，有可能是用戶突然又增加新的內(nèi)容，而更多情況是測試人員發(fā)現(xiàn)的BUG是由需求的誤差引發(fā)的。這也是為什么現(xiàn)在的軟件測試從需求分析階段就開始，而不是等到階段性編碼結(jié)束再開始。把問題盡量消滅在開始階段總比在問題出現(xiàn)后再補救更合理。
(四) 實施階段的需求變更
這個階段出現(xiàn)的需求變更就更少，即使出現(xiàn)也不是功能方面的問題，可能是和實施相關(guān)的軟硬件或網(wǎng)絡(luò)問題。若要避免，則只能在設(shè)計時就考慮多種實施方案，以防萬一。凡事預(yù)則立，不預(yù)則廢。
(五) 系統(tǒng)維護(hù)階段的需求變更
借用80/20原則，80%的需求變更產(chǎn)生于這個階段，剩余的20%則產(chǎn)生于其他幾個階段。系統(tǒng)上線后，用戶在使用起來肯定和原來的想法會有很大的出入，這就是理想與現(xiàn)實的差距。這個階段的變更無法預(yù)料，只好認(rèn)真的管理。
上面分析了各個階段的需求變更，那么對于變更控制也就有了清晰的解決思路。國內(nèi)講需求變更管理，大多提到加強溝通、區(qū)分對待、合同約束等問題，這種功利化的處理方式無可厚非，但是卻沒有講到重點上。對于需求變更控制，我覺得仍要沿用需求分析的處理方式，先分主次，再具體分析。這個過程中就需要標(biāo)明是哪個階段的需求變更，還要估計變更對程序帶來的影響，而不是泛泛的記錄變更的內(nèi)容。很多軟件在系統(tǒng)維護(hù)階段變得異常的被動，主要還是沒有把需求變更帶來的影響分析準(zhǔn)確。
把方法再明確一下，就是需求變更需要有專門的人員記錄，這個人最好是項目組內(nèi)部的人員，記錄內(nèi)容包括需求變更具體內(nèi)容、發(fā)生于哪個階段、以及由誰提出的等內(nèi)容。項目經(jīng)理需要每天關(guān)注需求變更記錄，每周必須對需求變更產(chǎn)生的影響進(jìn)行預(yù)估，并將預(yù)估結(jié)果記入到需求變更記錄當(dāng)中，以便于確定今后的工作計劃。