國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
第四章 籌獲管理使用案例分析
使用案例圖可以用來表示「使用案例(Use Case) 」和「行動者(Actor)」
之間的互動關係。「使用案例(Use Case) 」呈現系統的功能，也可以說是用戶 觀點下的系統需求，「行動者(Actor)」則代表提供資訊給系統或從系統接受資 訊的人或是其他的系統。因此，使用案例圖可以呈現出每一個使用案例是由 哪個行動者所引起的，同時也說明了行動者可以從使用案例中獲得資訊的事 實，本質上，使用案例圖及使用案例描述即在說明系統的需求(Alhir, 1999)。
4.1 籌獲需求發展使用案例分析與說明
依據籌獲需求發展活動圖（圖 3-7），建立籌獲需求發展使用案例圖（圖 4-1）。首先在籌獲規劃階段，由需求規劃人員擬定需求發展計畫，此計畫可 簡單的以人、事、時、地及物的方式，交待需求發展期間需要配合的人、需 求主題、時間、地點及相關使用工具並通知需求承諾人員與需求提供者(代 表)。
在 RFP 準備階段，需求承諾人員需與需求提供者協同合作，共同發展 需求，含客戶需求與契約需求。為有效取得、發展需求，在 CMMI 模式中列 舉了多種誘發需求的方法：問卷與訪談、雛型和模型、觀察現行產品、環境 及工作流程的樣式、腦力激盪、市場調查、由文件、標準或規格等來源中抽 取、使用案例、業務案例分析等方法。而在需求發展的過程中，須建立操作 性概念與劇本，用以協助誘發、分析及確認需求。
‧
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
使用案例名稱(Use Case Name)：建立籌獲需求發展計畫 編號：1.1
－使用者輸入專案代號後，系統自動帶出專案名稱。
－使用者點選或輸入訪談時間、地點、訪談人員、受訪人員、受訪單位及訪談 內容，按「新增」，系統即可此筆資料資新增至畫面的表格中。
－使用者若需「修改」或「刪除」，可直接點選欲修改或刪除的訪談時間，系 統將該筆資料顯示於畫面之欄位內。
－使用者當完成所有需求發展訪談的規劃後，按「規劃完成」，系統將發出電 子郵件信箱，通知計畫主持人進行審查，並直接提供超連結供計畫主持人 點選。
衍生或替代流程（Extensions or Alternatives）：無。
資料來源：本研究整理
相關畫面展示：
表 4-2：「審查後公告籌獲需求發展計畫」使用案例說明
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
使用案例名稱(Use Case Name)：審查後公告籌獲需求發展計畫 編號：1.2 主流程（Main Flow）：
－使用者一進入此畫面，系統將自動帶出審查人員(同登入人員)。
－使用者輸入專案代號後，系統自動帶出專案名稱。
－使用者選擇欲審查的文件，系統自動帶出最新版次。
－使用者點選應公告的對象。
－使用者依系統所提供的審查項目，點選審查結果。
－使用者完成所有審查項目，點選「審查完成」，系統將依彙整審查結果修改 文件狀態為審查通過或審查未通過。若為審查通過，系統自動發送計畫予 公告的對象。
衍生或替代流程（Extensions or Alternatives）：無。
資料來源：本研究整理
相關畫面展示：
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
表 4-3：「上傳客戶/契約需求」使用案例說明
使用案例名稱(Use Case Name)：上傳客戶/契約需求 編號：1.3/1.6 主流程（Main Flow）：
－使用者一進入此畫面，系統將自動帶出承諾人員(同登入人員)。
－使用者輸入專案代號後，系統自動帶出專案名稱。
－使用者點選欲上傳的文件類別。
－使用者將文件狀態由「未完成」修改為「完成」。
－使用者「瀏覽」欲上傳文件的位置。
－使用者「點選」上傳。
衍生或替代流程（Extensions or Alternatives）：無。
資料來源：本研究整理
相關畫面展示：
‧
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
表 4-4：「建立客戶/契約需求分析報告」使用案例說明
使用案例名稱(Use Case Name)：建立客戶/契約需求分析報告 編號：1.4/1.7 主流程（Main Flow）：
－使用者一進入此畫面，系統將自動帶出分析人員(同登入人員)。
－使用者輸入專案代號後，系統自動帶出專案名稱。
－使用者選擇欲分析的文件，系統自動帶出最新版次。
－使用者依系統所提供的文件項目，點選分析結果。
－使用者完成所有分析項目，點選「分析完成」，系統依各分析項目的結果，
將分析結果修改為「待確認」，並將通知需求提供者進行需求確認。
衍生或替代流程（Extensions or Alternatives）：無。
資料來源：本研究整理
相關畫面展示：
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
表 4-5：「確認客戶/契約需求」使用案例說明
使用案例名稱(Use Case Name) 確認客戶/契約需求 編號：1.5/1.8 主流程（Main Flow）：
－使用者一進入此畫面，系統將自動帶出確認人員(同登入人員)。
－使用者輸入專案代號後，系統自動帶出專案名稱。
－使用者選擇欲確認的文件，系統自動帶出最新版次。
－使用者依系統所提供的確認項目，點選確認結果。
－使用者完成所有確認項目，點選「確認完成」，系統將依彙整確認結果，修 改客戶/契約需求文件態為確認通過或確認未通過。
衍生或替代流程（Extensions or Alternatives）：無。
資料來源：本研究整理 相關畫面展示：
確認「客戶需求」畫面：
確認「契約需求」畫面：
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
4.2 籌獲驗證使用案例分析與說明
依據籌獲驗證活動圖（圖 3-8），建立籌獲驗證使用案例圖（圖 4-2）。
首先在籌獲規劃階段，由驗證人員負責撰寫驗證計畫，驗證的項目以甲方重 要的工作產品為主，且須經由獨立的品保小組審查，以確立其公正性。
雖然驗證的活動是貫穿完整籌獲生命週期，但考量「甲方」的重要工作 產品多發生在「RFP 準備」階段，如招標文件、契約書等。所以在該階段以 品保小組獨立、客觀的特性，建立所須的驗證環境、程序與準則後，再經驗 證人員審查無誤後，據以執行。而「同仁審查」是驗證的一種形式，在驗證 計畫中須界定採用同仁審查的工作產品。
至於其他階段，多為乙方的工作產出，不論是乙方的驗證活動或同仁審 查的項目、方法、紀錄等，應在契約內規範，要求乙方提報，再由甲方進行 審查。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 4-2：籌獲驗證使用案例圖 資料來源：本研究整理
依籌獲驗證使用案例圖（圖 4-2），發展出各個使用案例（表 4-6、表 4-7、
表 4-8 及表 4-9），另「上傳驗證計畫」、「上傳驗證報告」（使用案例編號：2.1 與 2.4）與「上傳客戶/契約需求」使用案例說明（表 4-3）相似度頗高，故不 再描述。
隨同「上傳驗證計畫」、「上傳驗證報告」使用案例說明，提供驗證/確 認計畫與報告之建議大綱如下：
驗證/確認計畫建議大綱
‧
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
表 4-6：「審查驗證計畫」使用案例說明
使用案例名稱(Use Case Name)：審查驗證計畫 編號：2.2 主流程（Main Flow）：
－使用者一進入此畫面，系統將自動帶出審查人員(同登入人員)。
－使用者輸入專案代號後，系統自動帶出專案名稱。
－使用者選擇欲確認的文件，系統自動帶出最新版次。
－使用者依系統所提供的審查項目，點選審查結果。
－使用者完成所有審查項目，點選「審查完成」。系統將依彙整審查結果修改 驗證計畫文件狀態為審查通過或審查未通過。
衍生或替代流程（Extensions or Alternatives）：無。
資料來源：本研究整理 相關畫面展示：
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
表 4-7：「審查驗證環境」使用案例說明
使用案例名稱(Use Case Name)：審查驗證環境 編號：2.3 主流程（Main Flow）：
－使用者一進入此畫面，系統將自動帶出審查人員(同登入人員)。
－使用者輸入專案代號後，系統自動帶出專案名稱。
－使用者選擇審查驗證環境之依據，系統自動帶出最新版次。
－使用者依系統所提供的審查項目，點選審查結果。
－使用者完成所有審查項目，點選「審查完成」。系統將依彙整審查結果修改 驗證環境之文件狀態為審查通過或審查不通過。
衍生或替代流程（Extensions or Alternatives）：無。
資料來源：本研究整理 相關畫面展示：
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
表 4-8：「同仁審查」使用案例說明
使用案例名稱(Use Case Name)：同仁審查 編號：2.5 主流程（Main Flow）：
－使用者一進入此畫面，系統將自動帶出審查人員(同登入人員)。
－使用者輸入專案代號後，系統自動帶出專案名稱。
－使用者選擇欲進行同仁審查之項目，系統自動帶出最新版次、規模。
－使用者選擇欲進行同仁審查之型態。
－同仁審查項目若有缺失應於缺失處與說明欄位描述。
－使用者點選「審查完成」時，若無缺失描述，系統將視同審查通過，若有缺 失描述則視為審查不通過。
衍生或替代流程（Extensions or Alternatives）：無。
資料來源：本研究整理 相關畫面展示：
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
表 4-9：「分析整體驗證」使用案例說明
使用案例名稱(Use Case Name)：分析整體驗證 編號：2.6 主流程（Main Flow）：
－使用者一進入此畫面，系統將自動帶出分析人員(同登入人員)。
－使用者輸入專案代號後，系統自動帶出專案名稱。
－使用者依系統所提供的分析項目，進行分析，並點選其分析結果。
－使用者完成分析後，點選「分析完成」。系統將依彙整分析結果修改整體驗 證之狀態為驗證通過或驗證不通過。
衍生或替代流程（Extensions or Alternatives）：無。
資料來源：本研究整理 相關畫面展示：
4.3 籌獲確認使用案例分析與說明
依據籌獲確認活動圖（圖 3-9），建立籌獲確認使用案例圖（圖 4-3）。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
首先在籌獲規劃階段，在籌獲需求發展流程領域之配置契約需求活動中須事 先將乙方需配合的確認活動詳訂於契約內。
在「管理與監控」階段的開始，由乙方的計畫撰寫人撰擬專案確認計畫，
連同其內部的審查紀錄交由甲方審查。審查無誤後，由乙方進行環境的建立 與確認活動。完成的報告再交給甲方，而其後的「驗收」與「移轉」階段則 重覆執行確認活動直到上線與保固完成。
在籌獲的過程中，開發方（乙方）在約定的時間點將會交付相關重要的 產出，為確保其品質，於專案監控流程中，應確實監控廠商工作與產品的進 度，更進一步實際審查其工作與產品以確保其品質，才不致於在確認活動時 勉強接受不良率過高的產品。
圖 4-3：籌獲確認使用案例圖 資料來源：本研究整理
依籌獲確認使用案例圖（圖 4-3），發展出各個使用案例（表 4-10、表 4-11 及表 4-12）。因「上傳確認計畫」、「上傳確認報告」（使用案例編號：3.1
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
與 3.4）與「上傳客戶/契約需求」使用案例說明（表 4-3）相似度頗高，故不 再描述。
隨同「上傳確認計畫」、「上傳確認報告」使用案例說明，提供之確認計 畫與報告之建議大綱與驗證計畫與報告雷同，已於 4.2 描述。
隨同「上傳確認計畫」、「上傳確認報告」使用案例說明，提供之確認計 畫與報告之建議大綱與驗證計畫與報告雷同，已於 4.2 描述。