通知嗎？通常開發(fā)人員都依據(jù)過時的需求工作，因為有些人忘了將影響他們工作的變更通知給他們。
即使在實際中，QE/QA 和文檔化通常比開發(fā)人員更處于盲區(qū)之中，經(jīng)常出現(xiàn)這種情況：沒有及時將間接影響開發(fā)人員工作的變更通知開發(fā)人員。團隊中的分析人員可能與另一位開發(fā)人員討論，衡量變更的影響，但是卻沒有意識到它可能對開發(fā)人員工作的影響。
解決辦法：需求變更通知
好的 RM 實踐確保在影響您工作的變更發(fā)生時，您能夠得到通知。同時通知您應該與哪些人取得聯(lián)系，以保證您使用的是最新的需求。
如何知道需求變更何時會影響您的工作？除非您團隊中的某個人對需求與實現(xiàn)這些需求的設計要素之間的關系進行跟蹤，否則很難快速評估需求變更對設計的影響。好的RM都對需求和設計工件之間的依賴關系做了跟蹤，以便在需求發(fā)生變更時您能查明設計的哪一部分受到影響。
由于需求是不斷變化的目標，所以RM的一個主要利益是能跟蹤需求是否被實現(xiàn)。這就是所謂的可跟蹤性。存在各種級別的可跟蹤性，但不幸的是，同時也有許多方法在濫用可跟蹤性?？筛櫺缘娜蝿帐潜ＷC您為客戶許諾的功能能夠真正實現(xiàn)（由開發(fā)人員來完成），并且按照指定的要求工作（由測試人員確認）。為了保證能夠?qū)崿F(xiàn)需求，并評估需求變更對設計的影響，需求應該被跟蹤到設計元素。為了保證需求發(fā)生變更時能夠得到驗證同時測試驗證也得到更新，需求應該被跟蹤到測試工件（通常為測試用例）。
從需求跟蹤到源代碼會如何呢？雖然乍一看很有吸引力（比如，如果我變更一個需求，我知道哪些代碼必須更新），但實際上代碼在本質(zhì)上比需求更具動態(tài)性。您可以從一個設計開始，然后優(yōu)化該設計。新設計可能會導致代碼變更，但是它仍與需求一致。維護可跟蹤性鏈接需要花費時間，但是軟件團隊永遠也沒有足夠的時間。所以您應該明智地使用可跟蹤性。可跟蹤性的真正價值在于將需求跟蹤到設計和測試。編寫代碼實施規(guī)格說明書的方法有很多種，但是最終用戶不會關心您編寫的代碼是什么，只要它滿足需要就可以了（需求是清楚無誤地向整個軟件團隊表達這些需要的媒介）。這種情況的一個例外是如果您工作的系統(tǒng)經(jīng)過了標準實體（如 FDA）的審計，該標準實體托管了從需求到代碼（有時甚至幾行代碼）的可跟蹤性。即使這種情況，您在構(gòu)建軟件時仍不應該將需求跟蹤到代碼。您只需要報告最終產(chǎn)品需求跟蹤到了代碼，并且每段代碼都實現(xiàn)了一個需求。管理需求和源代碼之間的可跟蹤性鏈接可能是一個沒有多少實效的耗時工作。
問題3：根據(jù)不完整的需求規(guī)格說明書編寫代碼
需求文檔的最初版本中總是存在模糊性，這是您的團隊面臨的主要RM挑戰(zhàn)之一。上一次讀需求文檔并感覺您確切理解了構(gòu)建目標是什么時候？大部分需求文檔不包含開發(fā)人員設計系統(tǒng)所需的足夠信息，而是留下了讓他們"解釋"用戶需要的余地。
盡管分析人員通過RM會議、聯(lián)合應用開發(fā)（JAD）會議、會見或者專題組收集和文檔化需求下了不少功夫，但是開發(fā)人員在第一次讀完需求之后還是有很多疑問。不管分析人員多么專業(yè)，都會出現(xiàn)這種情況。通常，開發(fā)人員只提供了一個可能被分析人員忽略的不同的視角。比如，開發(fā)人員通常會提出系統(tǒng)用戶可能遇到而分析人員卻沒有意識到的異常情況。因此，開發(fā)人員和分析人員必須緊密合作，在開始設計之前精化原始的需求規(guī)格說明書。開發(fā)人員應該無拘束地向分析人員提出有關需求規(guī)格說明書的問題，而分析人員則應該提供答案，必要時甚至可以直接與客戶聯(lián)系。
解決辦法：詳細且無歧義的需求規(guī)格說明書
好的RM實踐認識到需求規(guī)格說明書的初版需要項目團隊的檢查，并且還需要開發(fā)人員關于該規(guī)格說明書的提問。因此，必須給予開發(fā)人員足夠的時間來