管理變更

您可以使用變更要求工作項目來追蹤及控制對產品和支援系統的所有變更。 所有變更要求都會起始為與基準偏差的結果，其中包含已為專案識別的原始需求。 例如，如果與使用者開會後發現新的需求，則應建立變更要求，以提議更新需求基準。 如需 CMMI 的詳細資訊，請參閱 CMMI 的背景。

建立變更要求

當您發現必須變更原始需求時，您可以建立變更要求工作項目，並使用 [影響] 連結類型，將它連結到舊的需求工作項目。 您也應該要建立一個需求工作項目，其中包含新增或變更部分的詳細資訊，並將其連結至變更要求。 所有變更要求都會被廣泛地分析，以找出對使用者、產品和小組的影響。 在這分析期間，也可以將工作分散進行評估。 這些新的工作項目應連結到新的需求工作項目，以提供可追蹤性。 在工作項目表單中的 [實作] 索引標籤上，將工作加入，即可完成此作業。

變更要求和所產生的新工作項目，必須包含所需的所有新工作以及所要移除、修改或排除的所有現有工作的詳細資料。 您可以從 Team Web Access 首頁或從 Team Explorer 中的 [工作] 頁面中，建立變更要求，如開始使用工作項目所述。 您可以指定您在 [標題] 欄位中要求的變更、擁有變更的小組成員，以及要求的其他資訊。

如需如何完成工作項目的詳細資訊，請參閱 CMMI 工作項目和工作流程。

分析變更要求

在分析變更要求之前，應由組態控制部門進行分級。 組態控制部門是負責核准和拒絕變更要求，並確保正確實作變更的一群人。 您可以將工作項目中的 [分級] 欄位設為 [暫止]，以指出該要求必須進行分級。 如需詳細資訊，請參閱變更要求欄位參考 (CMMI)。 分析變更要求可能會造成資源的消耗，而且很重要的是，不要讓變更要求佇列對小組進行過度需求，而影響專案時間表。

應該要將變更要求加以分析，以判斷它對現有和已規劃工作的影響範圍。 必須知道效果為何，才能用它來估計實作變更的工時成本。

分析接受變更的風險。 外部小組是否依賴會變更的程式碼或功能，而他們的排程是否會受到負面影響？ 指派資源給這項變更，是否會對產品的其他重要功能區域或需求產生負面影響？

分析作業也包括徵詢專案關係人的意見，並將該意見加入變更要求工作項目中。 如果該變更需要變更其他規劃文件，請在變更要求中附註這一點，並適當變更這些文件。 這將會維護修訂歷程記錄，並且讓所有人都能查看詳細資料。 這樣可以降低溝通不良的風險，並且為 Standard CMMI Appraisal Method for Process Improvement (SCAMPI) 評價提供重要的證明。

如果已接受變更要求，則將 [狀態] 從 [已提議] (新變更要求的預設值) 變更為 [作用中]。

監視變更要求

當變更要求為作用中，您可以藉由檢視 [開啟需求的變更要求] 查詢來進行監視。 此外，您也可以建立電子郵件警示，提示已建立變更要求。 應在合理的時間長度內處理變更要求。

如果變更要求沒有受到所需的關注，則可建立問題工作項目來提高層級。 將新的問題連結至變更要求，並提高問題層級，讓變更要求能夠影響對追蹤的評量。