Wylie College
需求管理計劃
2.0 版
修訂歷程
日期 |
版本 |
說明 |
作者 |
---|---|---|---|
1999 年 1 月 8 日 |
1.0 |
起始版本 |
Simon Jones |
1999 年 2 月 10 日 |
2.0 |
延伸計劃 |
Simon Jones |
|
|
|
|
|
|
|
|
目錄
需求管理計劃
「需求屬性準則」識別及說明將用於管理在 Wylie College 的所有軟體專案之需求的屬性。此外,本文件還概述在開發期間將保留在專案上的需求可追蹤性。
指派給每一個需求的屬性,將用來管理軟體開發以及設定每一個版本之功能的優先順序。
需求可追蹤性的目標,是要縮減稍後在開發週期中發現的問題數。確定軟體需求中所記錄的所有產品需求、設計及測試案例可以改善產品的品質。
本文件中的屬性和可追蹤性準則適用於所有 Wylie College 軟體專案的產品需求、 軟體需求以及測試需求。
我們使用 Rational Unified Process 及 Rational RequisitePro 說明文件中所定義的術語。
您可以在 Wylie College Software Process 網站上找到下列參考資料。
1、Wylie College 配置管理計劃。
2、Rational Unified Process。
3、Wylie College 開發案例
為個別專案的「軟體開發計劃」所涵蓋。
將使用 Rational RequisitePro 來管理需求屬性和可追蹤性。Wylie College Software Process 網站上包含其他的基礎架構細節。
每一個專案將會識別及管理下列的需求類型:
工作成果
|
需求類型 |
說明 |
---|---|---|
願景 |
產品需求 |
產品功能、限制、品質範圍,以及其他的產品需求。 |
使用案例模型 |
使用案例 |
記載在 Rational Rose 中的使用案例 |
測試計劃 |
測試案例 |
說明我們將如何驗證系統是否如預期般運作的案例。 |
定義於「願景文件」的產品需求將被追蹤至「使用案例規格」以及「增補規格」中的相對應使用案例或增補需求。
每一個產品需求追蹤至 1 或多個使用案例需求及增補需求。
每一個產品需求追蹤至 1 或多個使用案例需求及增補需求。
定義於「使用案例規格」及「增補規格」的使用案例需求將被追蹤至「測試計劃」中指定的相對應測試案例。
每一個使用案例需求追蹤至 1 或多個系統測試案例。
「測試計劃」中指定的測試案例被追溯至產品需求(來自「願景」)以及使用案例需求,其由特定的測試案例驗證。
測試案例可以追溯至 1 或多個產品需求和使用案例需求。在測試案例在驗證衍生的需求或設計的情況下,測試案例可能無法追溯至原始產品需求或使用案例需求。
將使用本節中定義的屬性管理使用案例需求和「增補規格」。這些屬性對於管理開發投入成本、 決定反覆內容,以及建立使用案例與其特定的 Rose 模型的關聯性非常有用。
這是在分析選派使用案例之後設定。追蹤使用案例的開發進度,追蹤期間是從使用案例的起始選派到使用案例的最後驗證。
已提議 |
已識別使用案例,但是尚未經過審查及核準。 |
---|---|
已核准 |
已核准使用案例進行進一步的設計和實作。 |
已檢驗 |
已在系統測試中經過檢驗的使用案例。 |
這是由「專案管理人員」設定。他會依據指定開發資源給使用案例以及監視使用案例開發之進度的重要性,決定使用案例的優先順序。優先順序通常是根據使用者感知到的受益、 規劃的版本、規劃的反覆、使用案例的複雜度(風險),以及實作使用案例的投入成本。
高 |
使用案例的優先順序較高是關於確定已緊密監視使用案例的實作,以及資源是否適當指派給作業。 |
---|---|
中 |
相對於其他使用案例,使用案例為中優先順序。 |
低 |
使用案例的優先順序較低。 實作這個使用案例的重要性較低,可以將它轉遞或重新排程到後續的反覆或版本。 |
這是由開發團隊設定。由於部分使用案例所需的時間和資源比其他使用案例來得多,因此測量複雜度以及設定在給定的時間範圍內可以及無法完成什麼成果之預期的最好方法,舉例而言乃是預估小組或人員週次數、所需的程式碼行或函數點。用於管理範圍及決定開發優先順序。「專案管理人員」使用這些投入成本預估來決定專案排程以及有效地規劃作業的資源取得。
以人力天數(假設一個工作天有 7.5 個小時)計算的投入成本預估。
這是由開發小組依據使用案例將會遇到的不合意事件的可能性來設定,舉例而言,這些事件有投入成本超支、設計瑕疵、問題數過高、品質不良、 效能不佳等等。之所以造成諸如此類的不合意事件的原因,泰半是因為對於環境的瞭解不足或定義不良、 知識不足、缺乏資源、技術過於複雜、新進技術、新進工具或新進設備。
Wylie College 專案會將每一個使用案例的技術風險分類為高、中或低。
高 |
風險的影響加上發生風險的可能性較高。 |
---|---|
中 |
風險影響的嚴重性較低和(或)發生風險的可能性較低。 |
低 |
風險的影響最低,且發生風險的可能性較低。 |
記錄將在其中實作使用案例的開發反覆。預測每一個版本的開發將於專案的「建構階段」期間,在數個開發反覆上執行。
「專案管理人員」利用指派給每一個使用案例的反覆號碼來規劃專案小組的活動。
可能值的格式將會是 <letter>-<iteration number>,其中的 letter 是 I、E、C、T,分別代表初始階段、 詳述階段、建構階段以及轉換階段。例如:
E-1 |
針對詳述階段、反覆 1 排程 |
C-1 |
針對建構階段、反覆 1 排程 |
C-2 |
針對建構階段、反覆 2 排程 |
C-3 |
針對建構階段、反覆 3 排程 |
使用案例被指派給個人或開發小組,進行進一步的分析、設計和實作。簡易的下拉清單將幫助專案小組中的每一個人更加瞭解其職責所在。
識別與使用案例需求相關聯的 Rose 使用案例模型。
這是由「測試領導者」設定。每一個測試案例的追蹤狀態。
未測試 |
未執行測試案例。 |
---|---|
失敗 |
測試已處理,但是失敗。 |
有條件通過 |
測試已完成,但是出現問題。在某些動作已完成的狀況下,會指派「通過」狀態給測試。 |
通過 |
測試已順利完成。 |
記錄系統建置,將在其中驗證特定的測試案例。
被指派執行及驗證測試案例的個人。這個簡易的下拉清單將幫助專案小組中的每一個人更加瞭解其職責所在。
規劃的測試日期或實際的測試日期。
任何與規劃或執行測試相關聯的附註。
TBD
請參閱「Wylie College 配置管理計劃」。
請參閱「Wylie College 開發案例」。
這在每一個專案的「軟體開發計劃」中說明。