工作成果: 變更需求
這些構件用來記錄及追蹤對產品的變更要求。這提供了關於決策的記錄,並利用適當的評量流程,確保考量到該要求的變更影響。
目的
  • 若要公式化及追蹤變更及問題
關係
角色負責: 修改者:
輸入至強制:
選用: 外部:
輸出來源
說明
概略輪廓

範例變更要求表單

  1. 識別

  • 專案:
  • 變更要求號碼:
  • 變更要求類型:(問題或加強功能)
  • 標題:
  • 送出日期:
  • 創始者:
  • 變更要求優先順序:
  1. 現行問題

  • 現行問題說明:
  • 嚴重失敗:
  • 危害:
  • 加強功能:
  • 新需求:
  • 發生問題的狀況:
  • 現行環境:硬體
  • 作業系統編譯器:
  • 現行問題的來源:
  • 現行問題成本或節省影響:
  1. 建議的變更(創始者)

  • 建議的變更說明:
  • 實作建議的變更之預估成本:
  1. 建議的變更(變更審查團隊)

  • 動作:
  • 核准:
  • 不核准:
  • 延遲:
  • 建議的變更說明:
  • 受影響的配置項目:
  • 種類:
  • 錯誤修正:
  • 加強功能:
  • 新特性:
  • 其他:

  1. 解決方案

  • 實作建議的變更之預估成本:
  • 實作者:
  • 實作變更的實際時間:
  • 分析:
  • 實作:
  • 測試:
  • 文件:
  • 受影響的程式碼行數:
  1. 評估

  • 測試方法
  • 檢驗
  • 分析
  • 示範
  • 測試
  • 測試平台
  • 測試案例
  1. 變更審查團隊佈署

  • 核准及接受變更
主要說明

變更的必要性是在開發軟體系統中是固有的,在起始建立時逐步形成,且在實際環境中透過日常運作進行後續使用和維護。「變更要求」提供了決策記錄,並利用適當的評量流程,確保考量到其變更影響。

 變更要求有許多不同名稱,例如 CR、問題、錯誤、事件、加強功能要求。適當地擷取及管理這些要求能確保對系統的變更是以受管制的方式進行的,所以對系統的影響是可預期的。部份變更要求的匯入類型包括了:

加強功能要求由不同的關係人所使用,以便要求在產品中包含他們所希望的未來特性。這些為一種關係人需求類型,可以擷取並表達對關係人需求的理解。

問題是對已交付的工作成果中的異常現象或失敗狀況所作的報告。問題包括了例如在生命週期早期階段中所發現的遺漏和缺點,或軟體中需要進行隔離及更正的錯誤(失敗)徵兆。問題可能也包括了偏離可合理預期的軟體行為(例如使用性問題)。

問題的目的是為了對發生的問題之詳細資料進行溝通,讓更正動作、解決方案,以及追蹤能開始進行。下列人員會使用 CR:

  • 角色集:分析師使用 CR 來定義對高階需求的重要變更,並判斷需求來源,尤其是來自被識別為「加強功能要求」的 CR。
  • 角色集:管理人員使用 CE 來管理並控制工作分派。
  • 角色集:測試人員使用 CR 來說明軟體測試期間所發現的失敗(問題)、遺漏及品質問題。
  • 角色:開發人員使用問題 CR 分析失敗,並尋找基本錯誤及失敗原因,以解決 CR。
  • 角色:測試分析師使用 CR 來計劃驗證已解決的 CR 之測試,並藉由分析問題集,以測量軟體品質以及軟體工程流程的趨勢,來評估測試成效。
內容
選用
規劃Yes
調整
表示法選項

實際欄位及精確識別、說明,並追蹤問題必要的資料,依照實作的標準、準則,以及變更控制系統會有所不同。

一般來說,將變更要求儲存於資料庫或變更要求管理系統較有效率,這樣,可以更容易地管理變更要求(例如,依優先順序排序、追蹤指派以及完成狀態)。 在小型專案中,可能試算表就足以使用。

在小型專案中,您可以簡易的清單來管理問題。您也可以使用試算表,每個變更要求屬性都有個別的直欄。 這只能管理小型系統。當涉及的人員及問題的數量成長到超過某個數量時,您就需要使用更具彈性的問題追蹤系統。



詳細資訊