作為開發(fā)人員，您可能認為"我沒有時間進行需求管理"，或者"RM 與我毫無關(guān)系"。如果情況正是這樣，那么項目團隊如何定義您正在構(gòu)建的系統(tǒng)功能呢?實際上，您對于項目交付的職責(zé)是由某位人員決定并定義的。無論這位人員只是在頭腦中計劃著這些需求、在紙上草畫出需求、在正式會議上討論了需求，還是將需求正式記錄在需求文檔中，每個軟件開發(fā)團隊都要涉及某種形式的需求管理。他們可能并沒有意識到，因為他們的 RM 實踐可能極其不規(guī)范。不管怎樣，所有軟件團隊都要進行某種程度的 RM。問題只是您的軟件團隊的 RM 實踐的規(guī)范化程度如何。
理解開發(fā)人員在 RM 中的重要性，有助于反映 RM 的目的。RM 的目的是在客戶和軟件組之間建立共識，其內(nèi)容包括查找、文檔化、組織并跟蹤不斷變化的需求。與客戶達成共識是計劃和管理項目的基礎(chǔ)。如果項目團隊不能有效管理需求，那么他們達到關(guān)鍵里程碑的能力就會受到損害，進而影響項目計劃的精確度和效用。這通常導(dǎo)致開發(fā)和測試資源被浪費在錯誤方面。開發(fā)人員在 RM 上扮演了重要角色，不僅因為他們根據(jù)需求構(gòu)建軟件，而且因為他們能夠防止項目團隊一開始就使用不完整或者模糊需求。最大化需求的完整性和清晰度是保證整個項目成功的轉(zhuǎn)折點，可以確保包括測試人員和文檔編寫人員在內(nèi)的整修團隊能夠在最短的時間內(nèi)構(gòu)建質(zhì)量合格的系統(tǒng)。
RM 的正式程度因項目和項目團隊而異，并且與您的項目團隊在不能交付正確的軟件解決方案方面愿意冒多大的風(fēng)險直接相關(guān)。RM 過程的正式程度越差，項目團隊不能向客戶交付令他們滿意的軟件的風(fēng)險就越大。幸運的是，項目中 RM 的松散程度是權(quán)衡 RM 形式的優(yōu)缺點之后所作的一個簡明的決定。關(guān)于采用松散 RM 過程的最常見的論據(jù)包括：它可以使的開發(fā)速度更快，可以更好地適應(yīng)不斷變化的市場，并且不需要正式的需求文檔來了解我們應(yīng)該創(chuàng)建什么系統(tǒng)。不幸的是，這些論據(jù)是項目團隊很難實際把握的，并且需要仔細分析項目成功所需的 RM 正式程度。從根本上說，RM 實踐應(yīng)該產(chǎn)生：1)所有項目團隊成員都能夠清楚理解的需求，2)對不斷變化的需求的控制，以保證項目團隊能夠跟蹤正確解決方案的交付，3)有效的溝通，以保證整個項目團隊協(xié)調(diào)一致。
有時使用非常正式的 RM 實踐可能是小題大做。比如，如果您的項目團隊任務(wù)是構(gòu)建一個視頻游戲，那么擴展請求和需求變更就可能頻繁出現(xiàn)，以至于隨后如果使用傳統(tǒng)變更控制過程(需要變更控制委員會的批準)實際上可能妨礙項目成功。這種情況下，變更控制過程實際上限制了開發(fā)人員的創(chuàng)新，并且成為軟件交付的瓶頸。然而，即使在這種情況下，項目團隊仍可以使用諸如故事板或原型這樣的RM技術(shù)在開發(fā)和交付之前驗證游戲創(chuàng)意，并從中獲益。
在另一個極端上，也有極其需要使用非常正式的 RM 實踐的時候。比如，如果項目團隊的任務(wù)是開發(fā)一個運行醫(yī)療設(shè)備的軟件，它能根據(jù)情況自動管理病人的精確的、正確的用藥量，那么項目團隊就應(yīng)該采用高度正式的 RM 過程來保證開發(fā)出正確的系統(tǒng)。這種情況下需求錯誤的風(fēng)險可能危及人的生命安全。
那么 RM 如何影響像您這樣的開發(fā)人員呢?諸如 Standish Group 報告這樣的研究表明，需求錯誤是修復(fù)成本最高的錯誤，因為它們出錯的時間越長，影響就越大。隨著軟件開發(fā)生命周期的進展，這些錯誤越來越難以糾正，這實際上產(chǎn)生了雪球效應(yīng)。如果您從一個錯誤的需求或者需求變更開始，那么您的設(shè)計就是無效的，這最終會導(dǎo)致進行代價昂貴的構(gòu)架返工。確認測試也是錯誤的，用戶文檔也不精確，等等。最終，這將導(dǎo)致花費更多的時間來修復(fù)問題，而這些是完全可以避免的。
但您是開發(fā)人員，而不是分析人員。RM 不是僅用于分析人員的嗎?可