電子數(shù)據(jù)庫？使用商業(yè)性的缺陷與變更跟蹤工具（如 IBM Rational ClearQuest），允許在Web上提交變更請求，不需要本地軟件安裝，并且允許 CCB 進行查詢以篩選變更請求并確定接受哪些，從而極大地簡化了變更請求的管理。
然后項目團隊需要決定 CCB 多久應碰一次面來檢查變更請求，并且要決定在確定應該實現(xiàn)哪一個時所使用的標準。
技巧2：在加強已建立的變更請求過程中學會說"No"
作為開發(fā)人員，您在成功建立變更請求過程中扮演了關鍵角色。越是沒有讓 CCB 評估它們就接受和實施來自典型來源（如，銷售人員、客戶和高級經(jīng)理等）的特別變更請求，項目團隊就越感覺變更無窮無盡。同樣，這只會增加直接奔您而來的特別請求的數(shù)量，因為請求者知道您是他們實現(xiàn)希望的特性所可以依賴的人。
為了幫助控制影響您項目團隊的持續(xù)不斷的變更，您必須學會向請求者說"不"，并且將他們引導到您已建立的變更控制過程。這看上去可能很容易，但是這通常會導致高壓情形。比如，最成功的銷售人員可能很有影響力和說服力，并且通常是很多特別請求的煽動者。銷售人員通過說這樣的話來施加壓力，"如果您添加那個特性我就用不著 XYZ 賬戶了"或者"我最近從競爭對手那里丟掉了很多生意，因為我們沒有 ABC 特性"。不管他的論據(jù)看上去多么充分，您和開發(fā)團隊都必須表現(xiàn)出堅定的原則，并禮貌地將這些請求者引導到您已建立的變更控制過程中。這些請求者的行為不可能一夜之間改變，但是假以時日，一定會有所改觀。
技巧3：建立和參與需求規(guī)格說明書檢查
需求規(guī)格說明書檢查是確認是否理解需求的簡單有效的方法。作為開發(fā)人員，您知道不管何時收到一組需求您都會有很多問題，因為有些規(guī)格說明書不清楚或者是含糊的。與其猜測規(guī)格說明書的意圖，從而增加不能交付客戶期望的軟件的風險并導致返工，不如為項目計劃分配時間進行定期的需求規(guī)格說明書檢查。這些檢查不需要很正式，相反它們應該是一個開放的論壇，需求規(guī)格說明書的特定部分都可以拿來與指定的開發(fā)人員公開討論，以保證人們清楚地理解了這些需求。
作為開發(fā)人員，應該主動參與這些檢查會議，并且應該在對需求的解釋的基礎上準備一個初步的設計或者概念。該過程本質上是高度迭代的，因為在開發(fā)團隊能夠對需求有一個清楚的理解并且開始設計之前通常需要多次會議。同樣，通過這些迭代，保證所有變更被正確捕獲和記錄就是分析人員的責任了。在您以及其他開發(fā)人員開始設計之前，整個項目團隊必須對所有需求有一致的理解。
此外，需求規(guī)格說明書檢查的迭代本性為項目團隊提供了一種自我檢查機制，保證了軟件需求和初步設計的質量。通過保持這兩個工件的同步，項目團隊會保持同步前進，并增加交付成功解決方案的機會。因此，在實際階段應該分配時間進行需求規(guī)格說明書檢查。經(jīng)常在設計階段，很多開發(fā)人員在需求規(guī)格說明書檢查中發(fā)現(xiàn)更多的含糊性需要澄清。這里再一次需要需求規(guī)格說明書檢查。
技巧4：需要一個術語表
術語表是消除需求規(guī)格說明書中模糊性并避免誤解的簡單卻強有力的手段，應該由分析人員擁有、開發(fā)和維護。由于時間的限制，項目團隊成員可能不知道他們對同一需求有著不同的解釋。術語表不需要列出需求規(guī)格說明書中用過的每一個詞匯，但是它必須包含可能有歧義的詞匯。術語表通過給出需求規(guī)格說明書中關鍵詞匯的定義，消除了模糊性。如果術語表中的詞匯有具體和重要的關系（比如，在構建財務應用中，客戶可能只有一定數(shù)目的賬戶，并且同一賬戶不能被兩個以上的人擁有），您可能希望用一個域模型來補充術語表。該域模型可視化地描述了客戶與賬戶之間的一致關系，因為開發(fā)軟件時需要考慮這些關系。
&nb