理解開發人員在 RM 中的重要性，有助于反映 RM 的目的。RM 的目的是在客戶和軟件組之間建立共識，其內容包括查找、文檔化、組織并跟蹤不斷變化的需求。與客戶達成共識是計劃和管理項目的基礎。如果項目團隊不能有效管理需求，那么他們達到關鍵里程碑的能力就會受到損害，進而影響項目計劃的精確度和效用。這通常導致開發和測試資源被浪費在錯誤方面。開發人員在 RM 上扮演了重要角色，不僅因為他們根據需求構建軟件，而且因為他們能夠防止項目團隊一開始就使用不完整或者模糊需求。最大化需求的完整性和清晰度是保證整個項目成功的轉折點，可以確保包括測試人員和文檔編寫人員在內的整修團隊能夠在最短的時間內構建質量合格的系統。
RM 的正式程度因項目和項目團隊而異，并且與您的項目團隊在不能交付正確的軟件解決方案方面愿意冒多大的風險直接相關。RM 過程的正式程度越差，項目團隊不能向客戶交付令他們滿意的軟件的風險就越大。幸運的是，項目中 RM 的松散程度是權衡 RM 形式的優缺點之后所作的一個簡明的決定。關于采用松散 RM 過程的最常見的論據包括：它可以使的開發速度更快，可以更好地適應不斷變化的市場，并且不需要正式的需求文檔來了解我們應該創建什么系統。不幸的是，這些論據是項目團隊很難實際把握的，并且需要仔細分析項目成功所需的 RM 正式程度。從根本上說，RM 實踐應該產生：1）所有項目團隊成員都能夠清楚理解的需求，2）對不斷變化的需求的控制，以保證項目團隊能夠跟蹤正確解決方案的交付，3）有效的溝通，以保證整個項目團隊協調一致。
有時使用非常正式的 RM 實踐可能是小題大做。比如，如果您的項目團隊任務是構建一個視頻游戲，那么擴展請求和需求變更就可能頻繁出現，以至于隨后如果使用傳統變更控制過程（需要變更控制委員會的批準）實際上可能妨礙項目成功。這種情況下，變更控制過程實際上限制了開發人員的創新，并且成為軟件交付的瓶頸。然而，即使在這種情況下，項目團隊仍可以使用諸如故事板或原型這樣的RM技術在開發和交付之前驗證游戲創意，并從中獲益。
在另一個極端上，也有極其需要使用非常正式的 RM 實踐的時候。比如，如果項目團隊的任務是開發一個運行醫療設備的軟件，它能根據情況自動管理病人的精確的、正確的用藥量，那么項目團隊就應該采用高度正式的 RM 過程來保證開發出正確的系統。這種情況下需求錯誤的風險可能危及人的生命安全。
那么 RM 如何影響像您這樣的開發人員呢？諸如 Standish Group 報告這樣的研究表明，需求錯誤是修復成本最高的錯誤，因為它們出錯的時間越長，影響就越大。隨著軟件開發生命周期的進展，這些錯誤越來越難以糾正，這實際上產生了雪球效應。如果您從一個錯誤的需求或者需求變更開始，那么您的設計就是無效的，這最終會導致進行代價昂貴的構架返工。確認測試也是錯誤的，用戶文檔也不精確，等等。最終，這將導致花費更多的時間來修復問題，而這些是完全可以避免的。
但您是開發人員，而不是分析人員。RM 不是僅用于分析人員的嗎？可以肯定的是，您項目團隊中代表客戶的那些人涉入 RM 最深。分析人員通常負責創建需求。然而，需求的質量不僅僅落在分析人員的肩上。記住，整個項目團隊對需求有一個完整清楚的理解是至關重要的。為了實現這種質量，開發人員必須盡早參與，以幫助澄清最初需求版本中的模糊性。開發人員提供了一種實現視角，能夠提高已編寫需求的質量，并且能夠增加開發解決方案的成功率。與開發人員的合作是"如魚得水"；開發人員負責將概念轉化為現實。因此，開發人員越早參與需求的澄清，項目成功交付正確的軟件解決方案的機會就越大。
開發人員還應該關心適當的 RM，因為它可以簡化他們的工作。當從高質量的需求而不是很差勁的需求（這樣的需求總需要團隊成員查找測試內容，并且用各種問題打斷開發人員）開始工作時，質量保證（QA）或質量工程（QE）和文檔編輯團隊的工作就更有效率。另外，維護活動可以減少到只專注于系統中真正的實施缺陷，而不是由不清楚和不完整的原始需求導致的缺陷。更高質量的需求最終能夠保證軟件的質量更高，這使得開發人員可以集中精力思考如何對系統作出改進。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
