發表者

討論內容

冷日
(冷日)

發表時間：2008/3/14 8:45

Webmaster

註冊日: 2008/2/19
來自:
發表數: 15771

[轉貼]需求怎麼管理？？: 需求怎麼管理？？
需求管理是專案能夠順利完成的基礎，關於這點，我想大概沒有人會反對的。而根據統計，專案失敗的因素中，需求問題引起的爭議往往也是最大宗的（實際數據在不同的統計案例下都不盡相同，因此不予列出，台灣政府資訊委外部分數據可以參考行政院研考會的資料）。

需求接受標準
為了能夠明確的掌握需求的處理狀況以及立即反應專案即時的狀態，需求管理需要在一個能夠被度量的基礎上進行。因此，需求必須在訪談完成之後，逐項條列，並且加以編號識別。在提取需求時，需要遵循組織本身制訂的需求接受準則，需求本身需要符合該準則的標準後，才被允許建立。反之，若是任一需求無法符合該準則的標準，則需要重新分析。
在CMMI Level 2的需求管理流程領域中，提供了以下的需求接受參考準則：

清晰而適當的表達
完整
相互的一致性
可個別界定
可適當的實做
可驗證（可測試）
可追溯

而在筆者之前的淺談 Use Cases - 找出Use Case的四個基本流程一文中，也曾談到需求提取的標準可參考EBP 企業基本流程準則的精神。每個組織對於需求提取都有其定義與要求，真正的重點在於一致性。也就是說必須確保所有的需求都是遵循一致的標準來提取的，不會因負責的人員不同有所差異。在這個前提下建立的需求就有了度量的基礎，每個需求的實做工作量差異性會被限制在一定的範圍內。
若是能夠遵循上述的原則來建立需求識別，那麼我們就可以有科學根據的來量化需求衍生的工時，每個需求的基礎相同，工時的評估就是
需求的數量 X 基本需求需要的工時
在這個基礎上，我們可以做到最基本的進度監控。在某個時間點花費掉的工時與已經完成的需求是否符合一定的比例原則。如果沒有，那麼我們可以大概知道專案的進行是有問題的，而不用等到專案快要收尾了才發現時間不夠。

雙向追溯性
此外，每項需求都已經完成條列之後，我們可以有根據的為每項需求填寫與追蹤會產出的工作成品，包括文件以及程式碼。
相對的，我們也能夠從任何工作產品反向追蹤回所屬的需求。這樣的觀念稱之為需求的雙向追溯性。那麼，在任何的需求做變動時，我們都可以在有根據的情況下評估影響的範圍有多大。
遵循上述的原則建立的文件稱為需求追溯表，若是允許的話，使用軟體工具來達到這樣的目的，才不會耗費太多時間成本在管理這樣的文件上。

需求變更
在需求逐項被識別，以及建立需求追?表之後，我們在需求變更的管理上就較為簡單了。我們可以在需求發生變動時，進行影響層面的評估，然後依照牽涉的範圍來決定接受與否，以及需要耗費的成本。
此外，需求一旦確定要進行變更，變更的紀錄務必保留。由於需求有逐項建立識別，變更的次數也詳實記錄，那麼在專案進行的任何時間點，我們都可以即時監控需求變更的成長曲線，若是變更的頻率過高，可以即時評估專案是否有需要重新評估，並且調整專案時程，避免專案的運作變得無法掌握，造成重大的損失。

因地制宜
每個組織都有其特殊的文化，也都身處於不同的專業領域，因此需求的管理並沒有一定的標準，但是建立可供度量與監控的需求管理是不變的基本原則。此外，需求是恆變的。這大概是所有專案人員不得不承認的事實，因此，如何讓需求的變動在控制的範圍內是很重要的課題。
建立需求變動的標準流程，不要讓需求變動過於容易，獲得客戶對於需求的承諾，文件化所有需求的內容，都是需求管理的方法。但實際的運作，還是要依靠有經驗的專案經理來運籌帷幄，而非照本宣科而已。

回覆

主題一覽的下方

討論串

前一個主題 | 下一個主題 | 頁首 |

| |

發表新主題

軟工藝術 : [轉貼]需求怎麼管理？？