上一節簡介了一在 Web 上支援軟體再利用的 Broker 系統的系統架構，及使 用者使用此 Broker 系統之流程。然而，不同的軟體再利用層次對於其 Broker 系 統之設計及使用者之使用流程也會有所不同，本小節便先對使用者使用支援需求 規格再利用之 Broker 系統進行軟體需求分析的流程做一探討。
3.2.1 Web 上進行需求規格再利用之流程
當分析師接獲客戶的委託欲開發一軟體系統時，首先必須對客戶欲解決的問 題進行了解，才有辦法與客戶進行進一步的溝通，此時分析師可能會遇到下列兩 種情形：
l 分析師對於該軟體系統所屬領域不熟悉
由於在廣域再利用的情況下，再利用的系統所屬的應用領域不限於 以往開發過應用領域，因此第一種情形可能發生在分析師以往沒有開發 過與客戶的問題相關的應用領域的軟體系統，對於該領域的專業知識並 不熟悉，若直接與客戶進行訪談，可能不易了解客戶真正的問題與需求。
因此分析師必須先收集並學習與系統所屬領域相關的知識，然後才有能 力了解客戶的問題，並與客戶再針對系統的需求進行進一步的溝通。
此時，分析師可透過下列步驟透過 Broker 進行應用領域知識再利用：
(1) 分析師進入 Broker 網站，透過瀏覽的方式尋找與客戶的問題相近的 應用領域
(2) 檢視各個應用領域的基本描述，判斷是否可能是相近的應用領域，
或是可參考應用領域下包含之軟體系統之系統概述，了解該應用領 域下所包含之系統類型，以增加對應用領域之判斷能力
(3) 選取一與客戶問題最接近之應用領域，可以從中找到欲了解該應用 領域需要參考之書籍、文獻資料索引
(4) 在學習相關之領域知識後，分析師便有與客戶溝通系統需求的能力 l 分析師對於該軟體系統所屬領域很熟
第二種情形可能是分析師對於開發與客戶問題類似的系統已經具有
問題及其需求時應是從其原本做事之方式及流程思考。此時分析師之工 Broker 系統進行需求再利用：
(1) 分析師到 Broker 中與客戶問題相近之應用領域下，瀏覽應用領域下
(3) 由 Broker 挑選出一到數個基本需求接近之系統，檢視候選系統所提 供之系統功能，並對客戶之前未想到之功能進行討論
(4) 分析師檢視與客戶需求較接近之候選系統的基本資訊以決定是否購 買更詳細之系統需求文件
當系統需求談清楚以後，分析師則會依據客戶的服務需求一一制定系統所需 提供的服務，此時，若系統的範圍太大或太複雜，以致不易明確訂出系統所有的 服務，則分析師可將系統分解成數個較小之子系統進行分析，針對每個子系統分 別定出其系統的目的及所需提供之功能，然後再針對各個功能制定規格及針對各 系統及子系統分別制定其系統規格。此外，分析師可到 Broker 中尋找是否已存 在可以滿足客戶需求的系統，若存在則分析師便不須重新制定新系統之規格文 件，可考慮直接購買現成之系統規格文件進行再利用，其再利用之步驟如下：
(1) 從之前的應用領域知識再利用及需求再利用階段，分析師可在 Broker 中 找到與客戶問題相近之應用領域
(2) 瀏覽應用領域下，系統可能提供之功能，利用 Broker 提供之工具記錄符 合客戶需求之系統功能
(3) 搜尋 Broker 中是否有可滿足客戶需求之現成的系統，由 Broker 挑選出候 選系統
(4) 分析師檢視候選系統之基本資訊，及系統功能描述，若是現有系統與客 戶需求之系統很接近，則可購買現成之系統規格而不需重新制定新的系 統規格文件
以上便是利用支援需求規格再利用之 Broker 系統進行需求分析之流程，由 於軟體系統需求分析是一個反覆的過程，因此上述的步驟會一直反覆進行直到客 戶認可所制定完成之規格文件為止。
然後我們可以根據 User 使用 Broker 之流程及需求規格再利用單元 所包含的內容設計 Broker 系統中需求規格再利用單元之分類方式。
l 軟體需求規格再利用單元之搜尋、檢視及擷取機制
再依據再利用單元之分類架構、再利用單元包含的內容及 User 進行 需求分析之流程與習慣設計 Broker 之搜尋工具，其中包括搜尋之機制及 相似度計算的公式。然後再依搜尋可得知結果及元件所包含的內容設計 元件檢視工具。
l Broker 系統儲存庫之設計
最後我們必須再研究設計一可儲存需求規格元件之元件儲存庫。