需求管理計劃所包含的資訊,其他計劃可以涵蓋其中或大或小的範圍。
請參閱工作成果:需求管理計劃,調整,以取得調整指引。
如白皮書:在需求管理中套用使用案例所說明,對於確保專案的成功而言,需求管理非常重要。最常被提及的專案失敗原因包括:
需求錯誤也可能是最常見的錯誤類別,而且修正的成本也最高。
與關係人有正確的關係,有助於解決這些問題。關係人是定義需求及瞭解需求優先順序時的重要輸入來源。不過,許多關係人對於所要求的特性在成本和排程上的影響,都缺乏深入瞭解,因此,開發組織必須管理關係人的預期。
建立關係人關係包括定義下列各項:
-
關係人的責任:有人員在場接受咨詢嗎?或在預先安排好的時間?
-
專案工作成果中的關係人可見度:所有工作成果都能見到關係人嗎?或只在排定的里程碑能夠見到?
請說明可追蹤項目並定義好它們的命名、標示和編號方式。請參閱概念:需求類型和概念:可追蹤性。
最重要的可追蹤項目列在作業:開發需求管理計劃中。
典型的可追蹤性有一組有限的基本工作成果,請參閱作業:開發需求管理計劃,以取得相關說明。
除了識別可追蹤性鏈結之外,您還應該指定鏈結的基數。以下是部分一般限制:
-
每項已核准的產品特性都必須鏈結到一或多項增補需求,或一或多個使用案例,或同時包括這兩者。
-
每項增補需求及每個使用案例區段都必須鏈結到一或多個測試案例。
請參閱白皮書利用使用案例管理需求的可追蹤性策略,以取得可追蹤性更詳細的討論。
以下是一些您可能想從中選取的範例屬性,它們是利用作業:開發需求管理計劃中所指出的需求類型來組織的。
關係人需求
來源:產生需求的關係人。(這也可實作成「關係人」可追蹤性項目的一項可追蹤性。)
要素項:指出專案所處理的整體商機或問題的要素問題。百分比(0 至 100%)。所有要素項的總和不應該超出 100%。以下是範例柏拉圖,顯示各項關係人需求的要素項。
特性、增補需求及使用案例
狀態:指出「正式通道」是否已檢視和接受需求。範例值如下:已提出、已拒絕、已核准。
這可能是一項合約狀態,或能夠進行連結決策的工作群組所設定的狀態。
好處:呈現關係人見解下的重要性。
-
關鍵(或主要)。這些與系統的主要作業、基本功能以及開發所針對的功能相關。如果遺漏它們,系統便無法實現它的主要任務。它們驅動架構設計,往往是最常用的使用案例。
-
重要(或次要)。這些與支援系統功能相關,如編譯統計資料、產生報告、進行監督,以及測試功能。如果遺漏它們,系統仍能實現基本任務(一會兒),但服務品質欠佳。在建模時,較低的重要性會附加到它們,而不是關鍵的使用案例。
-
有用(有比較好)。這些都是「舒適的」特性,並不鏈結到系統的主要任務,但有助於使用和打進巿場。
工作:實作需求的估計工作天數。
比方說,這可能是「低」、「中」、「高」之類的種類。例如,低 = < 1 天,中 = 1-20 天、高 = >20 天。
在定義工作時,應該清楚指出,將哪些額外負荷(管理工作、測試工作、需求工作等)併入預估中。
大小:預估的無備註程式碼行 (SLOC),不包括任何測試程式碼。
您可能會想區分新的和重複使用的 SLOC,以便更準確計算預估的成本。
風險:需求的實作會遇到重大不當事件(例如排程移動、成本超限,或取消)的 % 可能性。
比方說,這可能是「低」、「中」、「高」之類的種類。例如,低 = <10%,中 = 10-50%,高 = >50%。
另一個風險選項是個別追蹤技術風險 - 在實作需求時,因對領域沒經驗和/或欠缺必要技術,而遇到嚴重困難的 %
可能性。之後,就可以基於其他屬性(包括大小、工作、穩定性、技術風險、架構影響及組織複雜度),將整體風險當作一項加權總計來計算。
組織複雜度:在開發要求時,對於組織之控制的分類。
-
內部:單一場所室內開發
-
地理:分佈各地理區的小組
-
外部:公司內的外部組織
-
供應商:轉包或採購外部開發的軟體。
架構影響:指出這項需求將如何影響軟體架構。
-
無:不影響現有的架構。
-
延伸:需要延伸現有的架構。
-
修改:必須變更現有的架構來配合需求。
穩定性:這項需求變更的可能性,或開發小組理解需求將變更的可能性。(>50% = 高、10..50% = 中、<10% = 低)
目標版次:預期將符合需求的產品版次。(版次 1、版次 1.1、版次 2...)
危險層次/嚴重性:影響健康、福利或經濟結果的能力,通常是因為軟體無法依照需要執行所造成的結果。
-
可忽略:不會造成重大人員傷害或設備損壞。
-
不重要:可控制,不會造成人員傷害或主要系統損壞。
-
嚴重:可能造成人員傷害或主要系統損壞,或需要立即採取更正動作,人員或系統才能倖存。
-
災難性:可能造成嚴重傷害或死亡,或系統徹底失敗。
危險也可以識別成個別需求類型,鏈結到相關聯的使用案例。另外,您也可能想要追蹤危險的可能性、更正動作和/或預防措施。
解釋:在某些需求會形成正式合約的情況中,需求用語的變更可能很困難,成本很高。當開發組織更深入瞭解一項需求之後,可能需要附加解釋文字,而不只是變更需求的正式用語。
使用案例
除了以上所述,追蹤下列使用案例屬性也很有幫助:
% 詳細程度:使用案例已詳述的程度:
-
10%:提供基本說明。
-
50%:建立主要流程文件。
-
80%:已完成而尚未檢視。已完整指定所有前置條件和後置條件。
-
100%:已檢視和核准。
測試案例
狀態:追蹤測試開發期間的進度。
-
無活動:在這個測試案例的開發中,未完成任何工作。
-
手動:已建立手動 Script,且證明它能夠驗證相關的需求。
-
自動:已建立自動化的 Script,且證明它能夠驗證相關的需求。
一般屬性
另外,還有些一般都會適用的其他需求屬性:
屬性用來追蹤可追蹤性項目的相關資訊,通常是用在狀態和產生報告等用途。每個組織都需要組織專用的特定追蹤資訊。在指派屬性之前,您應該考量:
-
誰提供這項資訊?
-
誰會使用這項資訊?它為什麼有用?
-
追蹤這項資訊所花費的成本值得嗎?
所要追蹤的基本屬性包括風險、好處、工作、穩定性和架構影響,以便能夠設定需求優先順序來進行範圍管理,以及將需要指派給反覆。開始時,應該能夠針對特性來追蹤這些項目,稍後則是針對所有使用案例和增補需求來追蹤。
考量衍生資訊
除了直接使用需求屬性之外,您也可能會想從這些需求屬性中,透過其他需求類型的追蹤性來衍生資訊。以下是衍生的一般型樣:
-
向下衍生 - 在取得上述的可追蹤性之後,假設「產品特性」有一項「目標版次」屬性。您可以衍生出在指定的「目標版次」或在它之前,也必須能夠使用這個「產品特性」所追蹤至的每個「使用案例區段」。
-
向上衍生 -
在取得上述的可追蹤性之後,假設「使用案例區段」有一項「預估工作」屬性。您可以總計追蹤所至之「使用案例區段」的「預估工作」來預估「產品特性」。您在使用時,要非常小心,因為許多「產品特性」都可能對映到相同的「使用案例區段」。
因此,如果要將需求屬性指派給需求類型,您應該考慮:
-
我們希望從這個屬性產生哪些衍生資訊/報告。
-
我們應該在可追蹤性階層中的哪個層次追蹤這個屬性?
屬性相依性
有些屬性可能只適用於特定開發層次。例如,在設計中充分呈現使用案例之後,設計元素的工作預估可能會取代使用案例的預估工作屬性。
以下是與需求相關的報告和測量的範例。在針對報告選取一組必要的/所要的報告和測量之後,您便可以衍生需求管理計劃的必要屬性。
報告/測量說明
|
用途
|
使用案例的開發優先順序(依風險、好處、工作、穩定性和架構影響來排序的使用案例清單)。
|
這可以是個別排序的清單,也可以是依這些屬性的加權組合來排序的單一清單。這用在作業:設定使用案例優先順序上。
|
每個狀態種類中的特性百分比。
|
在專案基準線定義期間追蹤進度。
|
- 依目標版次分類
|
- 追蹤個別版次的進度
|
- 依工作加權
|
- 提供更精確的進度測量。
|
依風險排列的特性
|
- 識別風險特性。可用來進行範圍管理,以及將特性指派給反覆。
|
- 依目標版次分類,針對每個目標版次總計開發風險
|
- 可用來評量風險特性是排定在專案中的初期或後期。
|
依穩定性來排序的使用案例區段
|
- 用來決定必須穩定哪些使用案例區段。
|
- 依影響架構來加權或排序
|
- 可用來設定需要優先穩定的含架構重要性之使用案例和/或高工作量之使用案例的優先順序。
|
含未定義屬性的需求
|
當最初提出需求時,您可能並未立即指派所有屬性(例如,使用預設的「未定義」值)。核對清單:軟體需求規格利用這份報告來檢查這些未定義的屬性。
|
含有不完整可追蹤性鏈結的可追蹤性項目
|
核對清單:軟體需求規格會用到不正確或不完整可追蹤性鏈結的報告。
|
變更必然發生,應該事先規劃。變更發生的原因如下:
-
要解決的問題有了改變。可能是因為新的規章、經濟壓力、技術變更等。
-
關於系統要執行什麼,關係人的心意或觀點改變了。可能的原因有許多,其中包括負責人員有了變動或問題的瞭解加深了。
-
當定義原始需求時,關係人未全部參與,或未詢問所有正確的問題。
管理需求變更的策略包括:
-
設定需求的基礎線
-
建立控制變更的單一通道
-
維護變更歷程
設定需求的基準線
在詳述階段接近結束時,系統分析師應該設定所有已知需求的基準線。 執行方式通常都是確定需求工作成果有版本控制,再識別形成基準線的工作成果集以及它們之版本。
基準線的目的並不是要凍結需求。相反地,它是為了能夠識別、溝通、評估和控制新的需求及修改過的需求。
另請參閱工具監視:設定 Rational RequisitePro 專案的基準線。
建立控制變更的單一通道
關係人希望改變,不見得就是正式變更預算和排程。一般而言,必須先起始協議或預算協調流程,才能核准變更。各個變更通常必須互相平衡。
每項變更都要通過單一通道「變更控制板」(CCB),以判斷它對系統的影響和接受正式核准,這一點很重要。提出變更的機制會送出一項變更要求,再由 CCB 來檢視這項要求。
如需相關資訊,請參閱作業:建立變更控制處理流程。
維護變更歷程
維護個別需求的變更審核追蹤是有益的。這個變更歷程可讓您檢視先前的所有需求變更和屬性值的變更,以及變更的基本理由。在評量實際的需求穩定性及識別變更控制流程可能無法運作的情況(例如,識別未適當檢視及核准的需求變更)時,這可能很有幫助。
|