需求管理
 |
需求管理(Requirements Management, REQM)的目的，在於管理專案產品及產品組件的需求，並界定這些需求與專案計畫及工作產品間的差異。
簡介[编辑]
「需求管理流程」管理專案所發展或收受的技術性、非技術性需求，以及組織加在專案的需求。尤其是如果組織實施「需求發展」流程領域，它的流程所產生的產品及產品組件需求，也要納入需求管理流程的管理。在所有的流程領域中，當使用產品及產品組件這個專門名詞時，也意指包含服務及其組件的意思。當組織實施需求發展、需求管理及技術解決方案等流程領域，它們相關的流程將會緊密聯繫並同步執行。
專案採行適當的步驟，確保議定的需求是受管理的，以支援專案規劃和執行的需要。當專案從已核定的需求提供者收受需求時，應與其一起審查，以便在需求納入專案計畫前，先行解決有關議題並避免誤解。一旦需求提供與接受的雙方達成協議，須再取得專案成員對需求的承諾。當需求漸進發展時，專案須管理需求的變更，並界定計畫、工作產品，以及需求間可能產生的差異。
需求管理也須記錄需求變更及其理由，並維護原始需求與所有產品和產品組件需求之間的雙向追溯性。(「雙向追溯性」的定義，請參考詞彙。)
所有發展專案都有需求。以專注於維護活動的專案來看，產品或產品組件的變更是基於現有需求、設計及開發的變更。如有需求變更，可能是記錄在客戶或使用者的變更請求上，也可能是從需求發展流程中所產生的新需求。不論來源或形式，因需求變更所引起的維護活動，應依此原則管理。
相關流程領域[编辑]
- 有關將關鍵人員之需要轉成產品需求，以及決定如何將需求配置於產品組件，請參考需求發展流程領域，以獲得更多資訊。
- 有關將需求轉為技術解決方案，請參考技術解決方案流程領域，以獲得更多資訊。
- 有關專案計畫如何反映需求，以及專案計畫如何因需求變更而修訂，請參考專案規劃流程領域，以獲得更多資訊。
- 有關基準和如何管制需求的建構文件的變更，請參考建構管理流程領域，以獲得更多資訊。
- 有關以需求為基礎的專案活動和工作產品之追蹤與控制，以及採取適當的矯正措施，請參考專案監控流程領域，以獲得更多資訊。
- 有關與需求有關的風險界定與處理，請參考風險管理流程領域，以獲得更多的資訊。
特定目標及執行方法摘要[编辑]
SG 1 管理需求
SP 1.1 瞭解需求
SP 1.2 取得需求承諾
SP 1.3 管理需求變更
SP 1.4 維護需求的雙向追溯性
SP 1.5 界定專案工作與需求間的差異
各目標的特定執行方法[编辑]
SG1 管理需求
管理需求，並界定需求與專案計畫及工作產品間之差異。
本執行方法藉由進行下列活動，使專案能全程維護一組最新及已核定的需求：
· 管理所有的需求變更
· 維護需求、專案計畫及工作產品間的關係
· 界定需求、專案計畫及工作產品間的差異
· 採取矯正措施
有關決定需求的可行性，請參考技術解決方案流程領域，以獲得更多資訊。
有關確保需求能反映客戶的需要和期望，請參考需求發展流程領域，以獲得更多資訊。
有關採取矯正措施，請參考專案監控流程領域，以獲得更多資訊。
SP1.1 瞭解需求
與需求提供者一起瞭解需求之意義。
當專案成熟且需求已衍生後，全部的專案活動或專業領域將收受需求。要避免需求不知不覺的到來，須建立準則，以指定需求收受的適當管道和正式的來源。執行需求收受活動時，須與需求提供者一起分析需求，以確保對需求的意義能達成共識。此分析和對話的結果，才是被議定的需求。
典型的工作產品
1. 區別適當需求提供者的準則清單
2. 需求評估和接受準則
3. 依準則進行分析的結果
4. 經議定的需求
細部執行方法
1. 建立區別適當需求提供者的準則清單。
2. 建立客觀的需求評估及接受準則。
缺乏評估及接受準則常常導致需求確認不夠充分、昂貴的重做成本，或客戶退件。
- ┌───────────────────────┐
- │需求評估及接受準則，舉例如下： │
- │● 清晰而適當地表達 │
- │● 完整 │
- │● 相互的一致性 │
- │● 可個別界定 │
- │● 可適當地實作 │
- │● 可驗證（可測試） │
- │● 可追溯 │
- └───────────────────────┘
3. 分析需求，以確保其符合已建立之準則的要求。
4. 與需求提供者達成需求共識，使專案成員可對需求承諾。
SP 1.2 取得對需求的承諾
取得專案成員對需求的承諾。
有關承諾的監督，請參考專案監控流程領域，以獲得更多資訊。
┌─────────────────────────────────┐
│IPPD補充 │
│組成整合團隊(integrated teams)時，專案成員就 │
│是整合團隊和其成員。對其他整合團隊的互動也 │
│是一項需求，對此需求的承諾，其重要性一如對 │
│產品及其他專案需求的承諾一般。 │
└─────────────────────────────────┘
上一個特定執行方法用於處理如何與需求提供者達成需求的瞭解，本特定執行方法則處理如何取得專案成員的承諾和同意，這些專案成員是負責執行需求之必要活動的人員。在專案進行期間，需求將漸進發展，尤其是在需求發展流程領域和技術解決方案流程領域之特定執行方法的說明中。在需求逐漸發展的情況下，本特定執行方法確保專案成員對當時已核可需求的承諾，以及對專案計畫、活動及工作產品所造成之變更的承諾。
典型的工作產品
1. 需求影響評量(Requirements impact assessments)
2. 需求和需求變更承諾的紀錄
細部執行方法
1. 評量需求對現有承諾的影響。
需求變更或新需求發生時，評估其對專案成員的影響。
2. 協商並記錄承諾。
在專案成員對需求或需求改變承諾之前，對現有承諾的改變，應先協商。
SP 1.3 管理需求變更
當需求於專案執行期間漸進發展時，管理需求的變更。
有關維護和控制需求基準，並使需求及其變更資料能為專案運用，請參考建構管理流程領域，以獲得更多資訊。
在專案執行期間，造成需求變更的原因甚多。當需要改變或工作進行中衍生新需求時，就可能需要變更現有的需求。如何有效率和有效果地管理這些新增需求或變更需求是很重要的。要有效分析變更所造成的影響，必須知道每一需求項目的來源，並記錄變更的原因。然而，專案經理或許要追蹤需求變更程度的適當度量，以決定是否要實施新的或修訂現有的控制方式。
典型的工作產品
1. 需求狀況表
2. 需求資料庫
3. 需求決策資料庫
細部執行方法
1. 記錄所有的需求和需求變更，不論是專案本身產生的或外界的要求。
2. 維護需求變更紀錄，以及每次變更的理由。
維護變更的歷史紀錄，有助於追蹤需求變更的狀況。
3. 從相關關鍵人員的觀點，評估需求變更的影響。
4. 確保專案人員能取得需求和變更的資料。
SP 1.4 維護需求的雙向追溯性
維護需求與工作產品間的雙向追溯性。
本特定執行方法的目的，在於維護每一階產品組件需求的雙向追溯性。(「雙向追溯性」的定義，請參考詞彙。)當有效地管理需求，就可建立從原始需求至低階需求的追溯性，亦可建立由低階需求至原始需求的追溯性。如此一來，雙向追溯性可協助確定已處理所有原始需求，以及所有低階需求皆可追溯至有效的來源。需求追溯性也可以涵蓋與其他實體的關係，例如：中間和最終產品、設計文件的變更、測試計畫及工作項目。追溯性應包括水平及垂直關係，例如：跨介面。在進行需求變更對專案計畫、活動及工作產品的影響評量時，特別需要追溯性。
典型的工作產品
1. 需求追溯表
2. 需求追蹤系統
細部執行方法
1. 維護需求追溯性，確保已記錄低階(或衍生)需求的來源。
2. 維護需求追溯性，從需求到衍生需求，以及需求配置到功能、介面、物件、人員、流程及工作產品。
3. 製作需求追溯表。
SP 1.5 界定專案工作與需求間的差異
界定需求與專案計畫及工作產品間的差異。
有關監控專案計畫及工作產品與需求是否一致，以及視需要採取矯正措施，請參考專案監控流程領域，以獲得更多資訊。
本特定執行方法用以找出需求與專案計畫及工作產品間的差異，並啟動修正的矯正措施。
典型的工作產品
1. 差異紀錄，包括差異來源、條件及理由
2. 矯正措施(corrective actions)
細部執行方法
1. 審查專案計畫、活動及工作產品，是否與需求及需求變更相符。
2. 界定差異來源及其理由。
3. 當需求基準有變動時，界定有關計畫及工作產品所需的變更。
4. 啟動矯正措施。