這項作業的功能是審查已提出的變更要求。這個狀態起因於 1) 提出新的 CR、2) 更新現有的 CR,或 3) 針對新的發行週期考量已延後的 CR。CR 會放在 CCB
審查佇列中。這個動作不會指派任何擁有者。
CCB 審查會議中會對 CR 的內容進行初審,以決定是否為有效的要求。通過初審後,再根據優先順序、排程、資源、工作等級、風險、嚴重性及小組訂定的其他任何相關準則,判斷這項變更是否超出現行版本的範圍。
如果 CR 確定為有效,但對現行版本而言「超出範圍」,它就會進入已延後狀態,它將保留下來,等未來的版本再重新考量它。您可以指派一個目標版本,以指示可以提出 CR 來重新進入 CCB
審查佇列的時間範圍。
如果您相信某 CR 與另一個已提出的 CR 重複,您應該將它指派給 CCB 審查管理或被指派解決它的小組成員。當 CR 進入重複狀態時,會將重複的 CR 號碼記錄下來(在 ClearQuest
的「附件」標籤上)。在提出 CR 之前,提出者應該先在 CR 資料庫中查詢是否有重複的 CR。這樣可以省去許多審查步驟,節省許多時間。重複 CR 的提出者應該加入原始 CR 的通知清單中,以便日後提供解決的通知。
有時 CCB 審查會議或指派的小組成員會判斷 CR 是無效要求,或要求提出者必須提供詳細資訊。如果已獲指派(已開啟),便會從解決佇列中移除這項 CR,並重新審查。這時會指派一位 CCB
授權代表來進行確認。除非必要,否則提出者不須對此狀態的變更需求採取任何動作,但如果需要提出者介入,CR 狀態則將變成進一步資訊。CCB 審查會議會重新審查這個 CR,探討任何新的資訊。如果已確認無效,CCB
將結束這個 CR,提出者也會接獲通知。
當 CR 已確定是在現行版本的「範圍內」,它會被指派已開啟狀態,並等待解決。這時它已列入下一個目標里程碑之前必須解決的名單內。它會被定義為在「指派佇列」中。只有會議成員才有權將 CR
送入解決佇列中。如果發現優先順序 2 以上的 CR,QE 或專案管理人員須立刻處理該變更需求。這時,他們可決定召開緊急的 CCB 審查會議,或只是立即開啟 CR 並送入解決佇列中。
專案管理人員必須負責根據 CR 的類型,為已開啟的 CR 指派工作,並依照需要來更新排程。
變更要求管理中會顯示變更要求可能經歷的一般狀態。
|