試用意見與討論

中時電子報的資訊部門主管在接受訪問時，對於方法論以及工具，提出了下 列意見。而本研究並針對每個意見，來進行討論，除了比較希望藉此來改善本方 法論與工具的設計。

一、中時電子報對於方法論的意見

1. 有採用本方法使得需求的處理流程能標準且一致。

中時電子報的資訊部門主管提到了其實在他們以往對新需求的處理上，已經 有實行部分與本方法論相似的手法，然而，跟沒有採用本方法相比較，採用本方 法論好處在於，能使得新需求在處理流程上能更有紀律。

2. 需求在初步過濾、並經過成本與利益的的估算後，如果成本高的需求，應該 在需求形成流程的最後，送交給上級進行核准。

此意見對於本方法論的意涵在於，因應不同的規模的需求，應該可以採用不 同的方式來權變地進行處理，規模較大的需求可能需要利用本方法論來進行詳細 地分析，然而如果是規模相當小而修改系統成本低廉的需求，則可以考慮來另外 設計一個簡便的方式來進行快速地分析處理。

3. 在實務上，使用者的需求提議與偏好調查活動，需要提供誘因，才能使得大 量的使用者樂於參與。

在本方法論的設計上，應該提醒公司提供適當的誘因讓利害關係者樂於提出 新需求並討論。確實，在本工具的試用時，沒有提供誘因確實難以吸引大量的利 害關係者來提出需求。然而，對於特定的族群，怎樣的誘因（例如：某種獎品或 獎金）才適合讓對的利害關係者來提出新需求，則有待進一步的探討與驗證。

4. 需求放在部落格上討論，需要安排人員妥善地管理，避免對手言語攻擊。

本方法論在設計上，應該提醒企業在使用本方法時，要加強管理部落格上惡 意的發言。

5. 為了保障品質，較大範圍的維護應接受完整測試後，一般都會選擇「定期釋 出」。

本方法在釋出方式上，應該建議方法的採用者應該以定期釋出為預設值，而 在特殊情況下，再考慮採取不定期之相依性釋出與緊急釋出。

6. 衝突解決流程中，自行協調時的討論內容應該被上級所知悉，以免衝突的人 馬間勾結或粉飾太平，反而使得公司的利益受損。

在方法論的設計上，應該提醒企業在衝突解決過程的自行協商過程，應該請 上級參與此過程，但不涉入爭端，或事後留存協商的會議紀錄。

7. 有衝突對公司是好的，能打破既有成規的意見，可能對公司有益處。

由於衝突有其好處，因此，在設計獎勵的誘因上，應該考量將廣受支持、或 受到重要人士支持的衝突需求，給予較多的誘因（例如：較多的中獎機率、或給 予額外的獎品），如此一來才能對公司有好處。

8. 系統所支援的活動有其欲達成的目標，然而，企業花費成本去開發一個系統 功能，也應該有其目標，也就是維護案件本身應該有其想獲得的企業利益。

本方法雖然有將新需求的目標考慮在後設模型的備選（optional）選項內，然 而，到底新功能能夠對該目標有多少幫助，也就是新功能對公司有多少好處，應 該要列為必須討論的項目，也就是在本方法的影響性分析階段，應該除了對所花 費資源的成本的估算外，亦要衡量其效益，如此才能提供較為完整的資訊，供決 策小組來決定是否實作該需求。

9. 應該在需求經過分析其成本效益後才送交決策小組進行批准，而非再一開始 尚未分析前，就決定是否接受或拒絕此需求。

依據此意見，本方法論應該在一開始僅是將需求做一篩選，將沒有意義或明 顯不適宜的需求文章去除掉，由於影響性分析階段會得到成本效益評估，所以應 該將決策小組進行批准的動作，移至緊接著影響性分析階段之後來進行。

二、中時電子報對於工具的意見

1. 部落格工具的採用，能幫助企業易於蒐集公司外部網站使用者的需求。

中時電子報原本是由各部門提出需求，然後採用線上問卷的方式來瞭解需求 對網友的重要性。而研究的工具，提供了一種新的方式，來協助企業直接跟外界 網友互動，來取得第一手的需求資訊。

2. 使用者常無法說明其確切的需求，只會說出模糊的問題點。

目前部落格工具僅設計來用主詞、動詞、受詞來組成需求模型，但是利害相 關者在提議模糊的需求時，可能僅指出某個地方有問題，所以工具可以增加一個 指出問題點的功能，讓利害相關者能僅選定某個地方有問題（例如：「列印功能」

有問題），而再由系統分析師協助來完整地選擇出主詞、動詞、受詞所組成的需 求模型。

3. 界定模糊需求之後，再去調查大部分使用者所認為該需求的重要性/偏好，工 具應該能進一步夠提供數據，來顯示各種需求被主流使用者所偏愛的程度(例 如：沒有這個功能可能就不想再次繼續使用此網站、或可有可無)，使得公司 能夠有確切的客觀量化數據，去判斷該需求是否應該被實作。

本工具應該進一步在所提議的需求旁增設評分的機制，讓利害關係者除了提 出新需求之外，也可以讓大家一起來對新需求進行評分，使得公司能瞭解該需求 是否代表了多數人的需要。

4. 在衝突解決時，可針對各種可能的選擇，來調查目標使用族群的偏愛程度，

這樣的客觀數據能避免各派人馬各說各話的口水戰這樣的工具會更為有用。

在後續研究中，工具的後台應該能自動產生報表，讓公司掌握各種利害關係 者對新需求的支持或反對程度為何，以作為衝突解決時的參考。

5. 工具應該能顯示哪個功能在哪時候被更新過，來協助資訊部門進行維護工作。

工具應該不止在需求分析階段所利用，而需貫穿整個開發流程，去結合其他 的軟體輔助軟體工程工具，將更新過的功能標示在部落格工具中，才能發揮更好 的效果。

6. 對於需求的偏愛程度之統計，應該僅給公司內部知悉，不應開放給外界知道。

一般部落格文章的評價會公開給大眾，然而針對於新需求的支持度評分之統計數 據，應該改為設計在部落格的後台中，以免競爭對手也利用此種資訊。

7. 對於新聞網站而言，使用者對新聞內容的需求比起功能需求更為重視，所以 部落格工具亦可用來收集使用者對內容之需求。

對於內容網站來說，本來內容就比功能來得重要，所以針對網站資訊系統，

將知識本體延伸到對於內容特性的需求上，對於數位內容產業的企業來說，是很 重要的事情，然而，針對內容需求特性的後設模型以及知識本體的類型，哪部分 跟功能需求比較起來有所不同，而哪些部分又是相同的，值得進行探討並進一步 設計。

8. 需求放在部落格上討論，需要工具來協助管理人員，避免對手言語攻擊。

工具可建立自動偵測不雅詞彙的功能，以及偵測可能具備惡意的會員特徵（例 如：發言的IP 位置是來自敵對陣營），來協助企業來管理部落格的公開言論。

9. 衝突解決流程中，工具應該協助企業在自行協調時充分揭露資訊給予上級。

在工具方面，可以進一步考慮將協商過程以在部落格上討論的方式進行，使 得協商過程有跡可尋，來避免私相授受的疑慮。

10. 需求模型應該要更完整，例如重點新聞的輪播，每則新聞該顯示多久？而輪 播的順序又是如何？該怎麼用本模型表達出來？

這項意見指出了本方法中後設模型的不足之處，也就是本後設模型尚未考慮 到時間順序的概念，也就是活動之間，應該有著上一個或下一個進行的關係。然 而有些過於細節的部分，例如活動進行所花費的時間，可能不要放進模型中較 妥，因為這可能會導致模型過於詳細而沒有重點。

11. 在知識本體的維護上，由於使用者去描述需求或問題的詞彙往往相當龐大且 多樣，資訊部門內部有一套詞彙去描述系統功能上的設計，然而公司內部的 其他部門卻因為其專長與方便性，往往有自己一套的詞彙去描述需求，需花 費不少成本來持續維護龐大的知識本體。

本研究僅假設工具中存有有一套受到認可的知識本體，所以未來可考慮朝向 各部門自行維護一套知識本體，再將多套知識本體之間對應起來，可能會較為符 合實際的狀況，然而多套知識本體比起一套知識本體來說，其成本更高。本研究 目前對於知識本體建置的作法，是先由研究者去觀察網站，並佐以相關資料，來 建立出系統所牽涉到的角色、功能、活動、與資料等概念以及概念間的種類與組 合關係，然而難以在系統中觀察到的部分，也就是目標與假設方面，則仰賴與公 司主管提供這方面的知識，最後將整套知識本體交由公司主管進行驗證。如果之 後遇到新的詞彙與概念，再由利害相關者提出後，由後台管理員將新詞彙加入知 識本體中。

12. 在知識本體呈現功能概念方面，缺乏詳細說明，有些功能不容易讓利害關係

者理解是指向網站的哪個部分。

根據此意見，可考慮讓使用者直接點選擷取畫面來選取某功能，會比較清楚，

但需要較多人力去製作圖片。另一種解決方式是直接讓利害相關者去填寫功能所

但需要較多人力去製作圖片。另一種解決方式是直接讓利害相關者去填寫功能所