1 / 18

CMMI Level2 REQM: Requirement Management Process Area

CMMI Level2 REQM: Requirement Management Process Area. Page82~93 William Hou 2004/3/11. 了解需求管理在 CMMI 模式中的位置與關連 (p.58). Purpose. 目的在於管理專案產品需求與產品組件需求 ( 由需求發展流程中產生 ) ，並判定需求與專案計畫及工作產品的差異 (p.82) 使產品與組件能夠持續符合需求 有效控制需求變更所帶來專案的變動，以節省變動的成本. Introductory notes. (p.82) 需求指的是產品與組件之需求 ( 詳見需求發展 )

carsyn
Download Presentation

CMMI Level2 REQM: Requirement Management Process Area

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CMMI Level2 REQM:Requirement Management Process Area Page82~93 William Hou 2004/3/11

  2. 了解需求管理在CMMI模式中的位置與關連(p.58)

  3. Purpose • 目的在於管理專案產品需求與產品組件需求(由需求發展流程中產生)，並判定需求與專案計畫及工作產品的差異(p.82) • 使產品與組件能夠持續符合需求 • 有效控制需求變更所帶來專案的變動，以節省變動的成本

  4. Introductory notes • (p.82) • 需求指的是產品與組件之需求(詳見需求發展) • 可以是技術性與非技術性 • 所維護管理的需求將於其他相關流程領域所參考使用 • 收受需求時須與提供者一起審查需求達成共識 • 確保獲同意之需求受到妥善管理並支援專案的規劃 • 與執行同意之後取得實作需求人員的承諾 • 管理需求之變更並界定計畫本身或工作產品與所收受需求間的差異，載明變更與其理由，以維持原始需求與所有產品與產品組件需求的相互可追溯性 • 與RD及TS兩個流程領域緊密相關。

  5. Related PAs (p.83) • 需求發展(RD):將關鍵人士需求轉為產品需求，並決定如何配置到產品組件 • 技術解決(TS):將需求轉為技術解決方案 • 專案計畫(PP):有關於專案計畫如何反應需求或因應需求而變動 • 組態建構管理(CM):有關與需求相關之文件控管部分 • 專案控管(PM):有關需求之各項專案活動與工作產品之追蹤控管

  6. 需求管理流程領域目標(p.84) • SG1 管理需求(具體作法範例) • SP1.1 了解需求 • SP1.2 取得需求承諾 • SP1.3 管理需求變更 • SP1.4 維護需求的互相追溯性 • SP1.5 界定專案與工作產品與需求間的差異 • GG2 制度化已管理之流程 執行承諾 • GP2.1 建立組織政策 執行能力 • GP2.2 規劃流程 GP2.3 提供資源 • GP2.4 責任分配 GP2.5 人員訓練 督導執行 • GP2.6 管理組態建構 • GP2.7 界定並納入相關人員 • GP2.8 監控流程 驗證執行 • GP2.9 客觀評估流程遵循程度 GP2.10 與上層管理者審查

  7. SG1 管理需求(p.84) • 管理需求並界定需求與專案計畫及工作產品間之差異 • 維護現有已核可的需求並在專案全程中達到以下工作: • 管理需求變更 • 維護需求及專案計畫及工作產品間之關係 • 界定需求與專案計畫及工作產品間之差異 • 根據差異促發矯正措施(corrective actions) • 有關需求可行性分析可參考TS，有關確保需求真正反應客戶需要可參考RD • 在軟工領域中需求可以是產品需求的全部或僅其中一部份

  8. SP1.1 了解需求(p.85) • 與需求提出者一同了解需求 • 當需求被發展完後，為要避免Creep，應該 • 建立準則區別需求提供者 • 建立準則檢驗需求的適當性 • 確保對需求內涵之共識，方成為核可知需求 • 典型工作產品 • 適當需求提供者的區別準則 • 需求評估與可接受的準則 • 根據準則之分析結果 • 最後核可之需求 • 細部執行方法 • 建立區別適當需求提供者的準則 • 建立接受需求的客觀評估準則 • 分析需求已確定符合評估準則 • 與需求提供者達成共識，而能使專案參與人員對需求給予承諾

  9. 需求評估與可接受的準則範例(p.85) • 需求評估與可接受的準則 • 清晰而適當地表達:為求明確性，所說明之每一項需求項目應僅有一種解釋，且以單一名詞加以描述，若某名詞在文內有多種涵義則應明確說明 • 完整:必須涵蓋所有主要的需求，包含功能效益、資料庫、介面需求、設計限制等，且需界定該軟體在各種情況下對所有可能輸入資料的反應 • ㄧ致性:每一需求不互相衝突(衝突:如:不同需求對同一事務特性描述矛盾) • 能被個別界定:每一需求項目能被各別區分且只說明一項需求 • 能被適當實施:需求在現有技術或人力上是可行的 • 可驗證:每一需求均可用有效的方法測試驗證 • 可追溯:每個需求來源均明確

  10. SP1.2 取得需求承諾(p.86) • 自專案參與人員取得需求執行承諾 • 取得專案執行人員的承諾 • 在需求發展與技術解決流程領域中需求逐漸發展 • 所有關鍵人員需維護當時已核可之需求及所可能造成對專案計畫與工作產品之變動的執行承諾 • 典型工作產品 • 需求影響之評估 • 針對需求與其變更之書面承諾 • 細部執行方法 • 評估需求現存承諾的影響(針對新需求或需求變更時對專案之影響) • 協調並紀錄承諾(現有承諾若有變動須先經過協調)

  11. SP1.3 管理需求變更(p.87) • 在專案進行過程中管理所有需求之變更 • 需求變更之原因很多，當有改變或引發新需求時便要變更 • 需有效率且有效能地管理變更 • 有效分析變更影響須知道每個需求項目的需求來源 • 留下為何變更之文件紀錄 • 專案經理可追蹤變更之程度以判定是否修改或實施新的需求控制方式 • 典型工作產品 • 需求狀況表 • 需求資料庫 • 需求決策資料庫 • 細部執行方法 • 紀錄所有需求或需求變更(專案本身產生或外部要求均要記錄) • 維護需求變更紀錄與變更之理由紀錄(有助於追蹤變更) • 由人員角度評估需求變更之影響 • 確保人員能查閱需求與需求變更之資料

  12. SP1.4 維持需求之雙向追溯性(p.88) • 維持需求及專案計畫與工作產品間的雙向追溯性 • 原始需求與低階層級需求可相互追溯 • 需求間的追溯性也可延伸涵蓋至其他實體，如產品、設計、文件與測試計畫等 • 追溯性分為垂直(原始需求至各層級需求)與水平追溯(在同一需求層級下各功能間的水平追溯) • 分析變更影響時特別需要追溯能力 • 典型工作產品 • 需求追溯表 • 需求追溯系統 • 細部執行方法 • 維護需求追溯性以確保低階需求來源被掌握 • 維護需求追溯性，包含由依需求到其衍生需求及所配置到之功能、物件、人員或流程 • 維護功能與介面之水平追溯性 • 製作需求追溯表

  13. SP1.5 界定專案工作與需求間之差異(p.88) • 界定 專案計畫及工作產品 與 需求 間的差異 • 找出需求與 專案計畫及工作產品間之差異 • 啟動矯正措施 • 典型工作產品 • 差異紀錄(包含來源、條件與理由) • 矯正措施 • 細部執行方法 • 檢查專案計畫、活動與工作產品是否與需求變更相符合 • 界定差異來源與理由 • 需求變更時界定有關計劃與工作產品之因應變更 • 啟動矯正措施

  14. GG2 制度化已管理之流程(p.89~90) • 將流程制度化為已管理之流程 • GP2.1建立組織政策(CO1) • 建立組織政策以規劃並執行需求管理流程 • 本政策建立組織期望以管理需求並界定差異 • GP2.2規劃流程(AB1) • 建立並維護執行需求管理流程的需求、目標與計畫 • 這些規劃將說明於專案規劃流程領域之專案計畫中 • GP2.3提供資源(AB2) • 提供足夠資源以執行需求管理流程、發展工作產品及提供流程服務 • 這些資源如需求追溯工具或追溯工具 • GP2.4責任分配(AB3) • 指定需求管理流程的相關責任與授權以執行流程 • GP2.5人員訓練(AB4) • 依據需要，訓練人員以執行需求管理流程 • 訓練內容可有 • 專業領域知識、 • 需求定義分析審核管理技巧 • 需求管理工具使用 • 組態管理 • 協調及衝突解決

  15. GG2 制度化已管理之流程(p.91~93) • GP2.6 管理組態(DI1) • 將指定的需求管理流程工作產品納入適當層級的組態管理 • 如:需求、需求追溯表等 • GP2.7 界定並納入相關人員(DI1) • 依據計劃界定並納入需求管理流程相關之關鍵人員 • 人員通常包含客戶、使用者、發展人員、製作人員、測試人員、供應商、行銷業務、維護人員、報廢處理人員以及其他相關人士 • 這些人員參與的活動有解決需求了解的議題、評估變更影響、溝通雙向追溯性、界定需求與專案間的差異等 • GP2.8監控流程(DI3) • 依據計劃監控需求管理流程，並採取相對之矯正措施 • 監控指標如需求變更比率 • GP2.9客觀評估遵循程度(VE1) • 客觀評估需求管理流程、工作產品與服務在適當需求目標與標準下的遵循程度，並說明不符合的情形 • 列入評估的活動有需求管理活動、界定差異的活動 • 列入評估之工作產品如:需求與需求追溯表 • GP2.10與高層共同審查狀況(VE2) • 與高層共同審查需求管理流程活動、狀況與結果並解決問題 • 提出之承諾變更若延伸與組織相關須經高層認可

  16. GG3 制度化已定義的流程(p.93) Level3需要) • GP3.1建立並維護一個以定義的需求管理流程 • GP3.2收集可改進的資訊，如工作產品、量測結果、需求管理規劃中所衍生的改進資訊等

  17. 需求管理流程規劃 • 需求管理規劃程序 • 需求變更追溯管理程序 • 相關人員:執行人員、發展人員、專案經理、組態管理人員、客戶等等

  18. 需求管理注意事項 • 堅持流程規定，避免流於形式 • 定期統計分析需求變更情形 • 結合需求管理工具 • 常見的錯誤 • 未將需求統一登錄管理 • 需求文件不完整 • 對需求承諾共識不足

More Related