sp;
有時(shí)使用非常正式的 RM 實(shí)踐可能是小題大做。比如，如果您的項(xiàng)目團(tuán)隊(duì)任務(wù)是構(gòu)建一個(gè)視頻游戲，那么擴(kuò)展請求和需求變更就可能頻繁出現(xiàn)，以至于隨后如果使用傳統(tǒng)變更控制過程（需要變更控制委員會的批準(zhǔn)）實(shí)際上可能妨礙項(xiàng)目成功。這種情況下，變更控制過程實(shí)際上限制了開發(fā)人員的創(chuàng)新，并且成為軟件交付的瓶頸。然而，即使在這種情況下，項(xiàng)目團(tuán)隊(duì)仍可以使用諸如故事板或原型這樣的RM技術(shù)在開發(fā)和交付之前驗(yàn)證游戲創(chuàng)意，并從中獲益。
在另一個(gè)極端上，也有極其需要使用非常正式的 RM 實(shí)踐的時(shí)候。比如，如果項(xiàng)目團(tuán)隊(duì)的任務(wù)是開發(fā)一個(gè)運(yùn)行醫(yī)療設(shè)備的軟件，它能根據(jù)情況自動管理病人的精確的、正確的用藥量，那么項(xiàng)目團(tuán)隊(duì)就應(yīng)該采用高度正式的 RM 過程來保證開發(fā)出正確的系統(tǒng)。這種情況下需求錯誤的風(fēng)險(xiǎn)可能危及人的生命安全。
那么 RM 如何影響像您這樣的開發(fā)人員呢？諸如 Standish Group 報(bào)告（見參考文獻(xiàn)）這樣的研究表明，需求錯誤是修復(fù)成本最高的錯誤，因?yàn)樗鼈兂鲥e的時(shí)間越長，影響就越大。隨著軟件開發(fā)生命周期的進(jìn)展，這些錯誤越來越難以糾正，這實(shí)際上產(chǎn)生了雪球效應(yīng)。如果您從一個(gè)錯誤的需求或者需求變更開始，那么您的設(shè)計(jì)就是無效的，這最終會導(dǎo)致進(jìn)行代價(jià)昂貴的構(gòu)架返工。確認(rèn)測試也是錯誤的，用戶文檔也不精確，等等。最終，這將導(dǎo)致花費(fèi)更多的時(shí)間來修復(fù)問題，而這些是完全可以避免的。
但您是開發(fā)人員，而不是分析人員。RM 不是僅用于分析人員的嗎？可以肯定的是，您項(xiàng)目團(tuán)隊(duì)中代表客戶的那些人涉入 RM 最深。分析人員通常負(fù)責(zé)創(chuàng)建需求。然而，需求的質(zhì)量不僅僅落在分析人員的肩上。記住，整個(gè)項(xiàng)目團(tuán)隊(duì)對需求有一個(gè)完整清楚的理解是至關(guān)重要的。為了實(shí)現(xiàn)這種質(zhì)量，開發(fā)人員必須盡早參與，以幫助澄清最初需求版本中的模糊性。開發(fā)人員提供了一種實(shí)現(xiàn)視角，能夠提高已編寫需求的質(zhì)量，并且能夠增加開發(fā)解決方案的成功率。與開發(fā)人員的合作是"如魚得水"；開發(fā)人員負(fù)責(zé)將概念轉(zhuǎn)化為現(xiàn)實(shí)。因此，開發(fā)人員越早參與需求的澄清，項(xiàng)目成功交付正確的軟件解決方案的機(jī)會就越大。
開發(fā)人員還應(yīng)該關(guān)心適當(dāng)?shù)?RM，因?yàn)樗梢院喕麄兊墓ぷ?。?dāng)從高質(zhì)量的需求而不是很差勁的需求（這樣的需求總需要團(tuán)隊(duì)成員查找測試內(nèi)容，并且用各種問題打斷開發(fā)人員）開始工作時(shí)，質(zhì)量保證（QA）或質(zhì)量工程（QE）和文檔編輯團(tuán)隊(duì)的工作就更有效率。另外，維護(hù)活動可以減少到只專注于系統(tǒng)中真正的實(shí)施缺陷，而不是由不清楚和不完整的原始需求導(dǎo)致的缺陷。更高質(zhì)量的需求最終能夠保證軟件的質(zhì)量更高，這使得開發(fā)人員可以集中精力思考如何對系統(tǒng)作出改進(jìn)。
與拙劣的需求管理相關(guān)的軟件問題
讓我們看一下可能面對的問題，將它們與拙劣的 RM 實(shí)踐中的根本原因掛鉤，并為每個(gè)問題提出解決辦法。
問題1：持續(xù)變更
市場或銷售人員每隔多久會要求您在代碼中加入客戶請求的變更？通常變更看上去都是很小，并且看上去是合理的。當(dāng)然您希望能夠成功地完成代碼編寫，所以您非常愿意滿足他們的請求，并且加班加點(diǎn)地在代碼中加入變更。這些持續(xù)性的中斷影響您設(shè)計(jì)和交付優(yōu)質(zhì)軟件的效率。您很難集中精力。但是更大的破壞是接受這些隨意的請求對項(xiàng)目計(jì)劃和總體軟件質(zhì)量造成的影響。像這樣持續(xù)的中斷使項(xiàng)目計(jì)劃超出了最初的范圍，這就是通常所說的"范圍蔓延"。這些打斷分散了項(xiàng)目團(tuán)隊(duì)的思路，使他們無法按照最初目標(biāo)交付軟件，從而導(dǎo)致所交付的軟件不能滿足客戶期望。
該需求問題的根源在于，項(xiàng)目團(tuán)隊(duì)在接受變更或擴(kuò)展請求之前不能正確評估它們的影響。
讓開發(fā)人員對這些直接請求作出響應(yīng)，可能導(dǎo)致項(xiàng)目團(tuán)隊(duì)不能正確評估接受變更的整體影響。結(jié)果，如果開發(fā)人員接受這些乍一看很小的請求