協助溝通與合作的維護需求整合方法論

行政院國家科學委員會

獎勵人文與社會科學領域博士候選人撰寫博士論文

成果報告

協助溝通與合作的維護需求整合方法論

核 定 編 號 ： NSC 96-2420-H-004-010-DR 獎 勵 期 間 ： 96 年 08 月 01 日至 97 年 07 月 31 日 執 行 單 位 ： 國立政治大學資訊管理研究所 指 導 教 授 ： 楊亨利 博 士 生 ： 劉季綸 公 開 資 訊 ： 本計畫涉及專利或其他智慧財產權，2 年後可公開查詢

中 華 民 國 97 年 09 月 02 日

博士學位論文

指導教授:楊亨利博士

國立政治大學資訊管理研究所

系統功能演化之需求分析方法論

Requirements Analysis Methodology for

System Functional Evolution

研究生：劉季綸

謝詞

七月的天氣，跟當初準備入學時一樣，依然豔陽高照，然而，不同的是，口 袋中已經裝滿了豐富的回憶，正準備踏入人生的另一個階段。 首先，衷心地感謝論文指導教授楊亨利老師的循循善誘，總是不厭其煩地引 領著學生進行獨立思考，在問答之中試圖讓學生自己打開黑箱，使得學生有一定 程度的能力，能將思維的內容細緻清晰地整理並顯露出來。而投稿時，那種鍥而 不捨的精神，令人銘記在心。 再者，相當感謝口試委員們的熱情參與和支持，李允中老師以清晰的思維和 對軟體工程豐富的學養，使得本論文得以進一步地改善。陳英一老師熱心地引見 實驗與訪談的對象，是本論文能順利完成不可或缺的助力。余千智老師與黃世禎 老師對論文的指引，也使論文得以更盡善盡美。 在修課與準備資格考中一起辛勤讀書的同學，實驗室的學長與學弟妹們，也 給予了相當多的鼓勵與協助，使得博士班修業能更為順利且美好地度過並完成。 也相當感謝世新大學傳播研究所的老師，以及修課的同學們，在一同研討原典的 時光中，使得學生對哲學詮釋學與現象學有著初步的認識，並從中獲得不少啟發。 感謝父母一路上始終如一的大力支持，才能在沒有後顧之憂的情況下，順利 地獲得博士學位。最後，非常感謝妻子可凡的平日的陪伴與鼓勵，並且大力協助 尋得實驗合作對象，是論文得以順利完成的幕後推手。 有了大家一路上的相伴，使得博士修業歲月不再漫長，而且更能有動力地面對新 的環境而繼續成長，再次謝謝大家。

摘要

在重視集體智慧、重視服務、且需要因應環境快速變遷的年代，傳統的系統 開發方法論雖然有其不可磨滅的價值，但已經顯露出其不足之處。為了順應時代 的潮流，方法論必須指引企業去聆聽大眾的心聲，以期確保系統提供優質的服 務，方法論也必須指引資訊人員運用有異於以往的手法與步驟，與其他部門和大 眾共同合作，來持續不斷地維護系統，使得系統得以注入新的生命力而不斷演進。 為了提出一套不斷吸納使用者的新需求來規劃系統演進的功能需求分析方 法論，本研究以哲學詮釋學為基礎，並佐以軟體工程相關文獻，將持續吸納新需 求來促進系統演進的抽象概念，化為具體可執行的步驟。本需求分析方法論是針 對使用者提議的需求進行初步分析與確認，可分為兩個主要部分：需求形成流 程、與衝突處理流程。需求形成流程是分析使用者所提出之功能性需求的主要方 式，其中包含了提出新需求、分析新需求在商業活動與科技層次的影響、估計新 需求的成本效益來決定是否實作、排序實作的優先權、並且了解新功能的釋出時 間的期望。而衝突解決流程是為了解決各方人馬的歧見所造成的爭端，衝突解決 的方式包含了自行協商、第三方中間人介入協調、以及高層決策小組的裁決。 為了讓企業外界的大眾提議新需求，本研究發展了一套以部落格為基礎的新 需求提議工具，讓網友可在部落格上提出自己對新功能的想法。此外，為了協助 企業判斷新需求是否會觸發衝突解決流程，本研究根據哲學詮釋學，將使用案例 （Use cases）加以延伸修改，提出一套後設模型，並輔以知識本體，據此來提出 一套規則，讓本工具能自動偵測新需求與系統既有設計之間是否有所抵觸，而規 則亦可進一步應用在新需求間的衝突上。 為了初步瞭解本研究所提之方法論與工具的優缺點，本研究與中時電子報和 民視購物網合作，來試用此方法論與工具。透過試用之後的訪談得知，本方法論 與工具有其價值，而也獲得了不少寶貴的試用意見。最後，本研究根據試用的諸

多意見，對方法論與工具的改善上，提出了具體的改良作法與方向。

關鍵詞：需求工程、系統發展方法、知識本體、後設模型、使用案例、哲學詮釋 學

Requirements Analysis Methodology for System

Functional Evolution

Abstract

Nowadays, companies have to respect collective knowledge and improve service quality for adapt their rapidly changing environment. Traditional systems development methodologies may be still valuable but have shortcomings. To accommodate customer-driven trend, new methodologies must guide enterprises to listen to customers for ensuring high-quality system services. New methodologies also have to guide developers to carry out cross-department and customer-centered collaboration in new ways for maintaining systems cyclically.

This research proposes a user requirements analysis methodology according on philosophical hermeneutics and software engineering literature. The proposed methodology includes requirements formation and conflict resolution. Requirements formation process involves new user requirement proposition, commercial and technical impact analysis, cost benefit estimation, coding prioritization, and new version release scheduling. Conflict resolution process involves negotiation, mediation, and arbitration.

Besides the proposed methodology, this research also develops a blog-based tool for collecting user requirements on Internet. This research extends and modifies use cases diagram and use philosophical hermeneutics as a foundation to propose a meta-model. This research also proposes a set of rules for conflict detection. Base on the proposed meta-model, ontologies, and the proposed rules, the blog-based tool can automatically detect conflicts between new requirements and existing design. These

proposed rules also can apply to detect conflicts among new requirements.

An online newspaper company and an online shopping mall try to use this methodology and the blog-based tool. In the interviews, they confirm this methodology’s and tool’s values and give several suggestions for improving the methodology and the tool. Finally, this research discusses the improvements and future research directions according to these suggestions.

Keywords: Requirements Engineering, Systems Development Methodology, Ontology, Meta-model, Use Cases Diagram, Philosophical Hermeneutics

目錄

謝詞...I 摘要...I Abstract...IV 目錄...VI 圖目錄...IX 表目錄...XI 第一章 研究背景及目的 ...1 第一節 研究問題...1 第二節 研究目的...3 第三節 研究範圍...4 第四節 研究假設...5 第二章 文獻回顧與評述 ...7 第一節 溝通的相關理論...7 第二節 有機式組織與參與式管理...8 第三節 系統維護...9 第四節 系統維護方法論...10 第五節 方法論的假設與隱喻...14 第六節 哲學詮釋學...17 第七節 部落格...19 第八節 本體論...20 第九節 需求工程...22 第三章 研究方法 ...25 第四章 需求分析方法論 ...26

第一節 方法論介紹...26 一、本方法論精神：協助有機體的結構化神經訊號傳遞...26 二、本方法論概觀...28 三、需求形成流程...30 四、衝突解決流程...36 五、造成需求變更的回饋...41 六、詮釋學如何延伸至系統維護...43 七、本方法論如何符合SMmm指導方針...46 八、本方法論如何具備有機體特性...48 第二節 本方法論運作之虛擬劇情（Scenario）...51 一、需求形成流程的開始...52 二、觸發衝突解決流程...54 三、回到需求形成流程...55 四、事後的需求變更...56 第五章 部落格為基礎之工具 ...59 第一節 需求之後設模型與知識本體...59 第二節 工具之功能...62 第三節 衝突偵測規則之完整性討論...88 第六章 方法論之試用 ...91 第一節 試用過程...91 第二節 試用意見與討論...92 一、中時電子報對於方法論的意見...93 二、中時電子報對於工具的意見...95 三、民視購物網對於方法論的意見...98 四、民視購物網對於工具的意見...98 第七章 結論 ...104

圖目錄

圖1 Shannon 的資訊理論...7 圖2 詮釋循環過程...18 圖3 協助有機體組織的結構化神經訊號傳遞循環...26 圖4 有機體維護組織的特徵...27 圖5 本方法論在 SMmm中的定位...28 圖6 提議的功能更新維護之需求分析流程概觀...29 圖7 需求形成流程...30 圖8 爭論者對衝突解決進行協商...36 圖9 調停者對僵局進行調解...38 圖10 仲裁者對僵局進行裁決...40 圖11 用於表達需求的後設模型...59 圖12 工具之資料庫模型...64 圖13 用於提議新需求的部落格介面...67 圖14 新需求模型製作模組之介面...68 圖15 概念選擇的介面...70 圖16 建立新詞彙的介面...70 圖17 權限與使用對象上之衝突偵測規則...71 圖18 功能所操作資料上之衝突偵測規則...72 圖19 功能所支援活動上的衝突偵測規則...72 圖20 活動所達成目標上的衝突偵測規則...73 圖21 活動所遵守假設上之衝突偵測規則...74 圖22 目標分歧之衝突偵測規則...75 圖23 預防功能在支援活動上可能違反假設之衝突提醒規則...76 圖24 角色可否將功能用於進行活動之衝突偵測規則...77

圖25 角色使用功能可否用於活動之衝突偵測規則...78 圖26 角色可否使用功能來操作資料之衝突偵測規則...79 圖27 角色所用功能可否操作資料之衝突偵測規則...80 圖28 功能可否用於活動來達成目標之衝突偵測規則...81 圖29 功能用於活動可否達成目標之衝突偵測規則...82 圖30 功能可否用於遵循假設的活動之衝突偵測規則...83 圖31 功能用於活動可否遵循假設之衝突偵測規則...84 圖32 功能用於活動所支援之目標分歧之衝突偵測規則...85 圖33 預防功能設計於支援某活動上可能違反假設之衝突提醒規則...86 圖 34 預防功能設計讓角色使用並用於活動時可能違反假設之衝突提醒規 則...87 圖35 民視購物網所放置之工具的橫幅廣告...91 圖36 中時電子報所放置之工具的文字超連結...92

表目錄

表1 系統維護方法論的特色...13 表2 需求衝突之相關研究...24 表3 新功能提議階段之工作表格與範例...31 表4 商業活動塑模階段之工作表格與範例...32 表5 影響性分析階段之工作表格與範例...33 表6 實作優先權排序階段之工作表格與範例...34 表7 釋出時程期望階段之待填表格與範例...35 表8 自行協商流程之待填表格...38 表9 第三方調解流程之待填表格...39 表10 高層裁決流程之待填表格...40 表11 需求變更之待填表格...42 表12 要求形成的各環節中的詮釋循環狀況...43 表13 衝突解決的各環節中的詮釋循環狀況...45 表14 本方法論各階段對 SMmm第二級必要條件的支援狀況...47 表15 本方法論在各階段所呈現出來的有機體特徵...50 表16 本方法論可改善之處...100 表17 本工具可改善之處...101

第一章 研究背景及目的

第一節 研究問題

隨著網際網路的普及，資訊系統比以往更廣泛地應用於各種組織群體的工作 與生活之中（Lucas et al.,2006）。在網際網路上，許多資訊系統的使用者往往是 在系統上線後才自願地來使用，造成系統的需求在一開始往往不甚清楚，只能初 步的分析（唐日新，民92），並在上線後逐漸藉由線上銷售與行銷的方式（Vidgen, 2002）來得知需求以進行改版，而使用者的需求又總是一直在改變的（Nissen et al.,1996），所以，現今資訊系統的開發生命週期，可視為一個將系統不斷改版、 並且不斷地進行功能更新的維護與演化過程。也因此有學者如Ginige（2002）提 出有必要去設計維護流程來支援資訊系統的持續演進與維護。 系統維護在業界一直是相當重要的工作，然而在學界卻相對地受到忽視。系 統 維 護 的 成 本 被 預 估 佔 據 資 訊 部 門 的 總 預 算 的 50% — 80% （ Banker et al.,1991）。雖然，有許多軟體公司都正視了系統維護的重要性，而提供了系統 維護服務（Polo et al.,2002），但在學術界，傳統上大部分的方法論都著重於 資訊系統開發，卻少有著重於系統維護的方法論，這可能是因為傳統上的價值觀 常 會 假 設 新 系 統 的 效 能 會 比 維 護 一 個 舊 系 統 來 得 好 （ Kendall and Kendall,1993），近年來，學界逐漸開始轉而重視系統維護，例如 Basili 等人 （1996）認為有必要去發展專屬於系統維護的方法論。 在系統發展的過程中，需求分析一向是最重要、且最難以處理的部分之一（潘 建一，民 88）。在現實上，對於系統的使用需求，往往存有著多元且不同的觀點， 然而，在傳統上，軟體工程領域卻忽視這樣的多元觀點所造成的問題（Andrade et al.,2004），也就是如何將多元的主觀需求進行整合的問題。而在系統的維護上， 需求也被視為相當重要的部分（April,2005）。

然而，在系統維護的實務上，Dart 等人（1993）發現了五項與維護需求分析 上有關的困難：（1）維護人員與客戶間在需求上難以有效溝通，（2）維護人員與 高階管理階層的溝通困難，（3）沒有提供適當的資源來進行維護活動，（4）缺乏 適當的工具來支援系統維護，（5）難以獲得過去或現在進行的維護專案中所得到 的教訓或專業知識。 而對於維護部門來說，提供系統維護的服務也可說是客戶服務的一種。而傳 統上，總希望客戶服務能減少錯誤與延遲的狀況發生（Lancioni,1995；El Sawy and Bowles,1997），而造成錯誤與延遲可能有四個原因：（1）溝通不良導致誤解 （Lucas,1996），（2）需要處理的問題與要求相當廣泛（Sterne，2000），（3）服 務流程複雜（Hill and Motes,1995），對於沒處理過的多樣化新問題難以完全預先 定義其處理流程（4）有些問題往往需要跨部門合作，但部門間的合作往往有障 礙（Lancioni,1995；El Sawy and Bowles,1997）。

從Shannon 與 Weaver（1949）所提出的資訊理論（Information theory）的角 度來看，噪音是（Noise）造成組織成員之間溝通失敗的一個常見原因（George and Jones,1999;McQuail and Windahl,1993）；噪音的發生往往是因為發言者建構的訊 息的結構不嚴謹且模糊不清，這在正面上來說會造成資訊豐富，但在反面上來說 會造成聽取者在解讀上的不確定高；而重複關鍵的重點詞句可減少訊息在傳播管 道中的噪音（Severin,2001）。 Hooper 與 Hsia（1982）亦指出了需求在處理上有三大重點：（1）需求的辨 認：強調判斷何謂真正的需求以及需求的正確與否，（2）需求的分析：分析需求 的不一致與完整性，以及（3）需求的溝通：使得需求易於了解。 所以，根據上述的討論，本研究所提出的研究問題為： 1. 如何協助企業不斷傾聽網友的需求？ 2. 如何自動偵測新需求與現有設計是否抵觸？ 3. 如何引導企業對新需求的初步專案規劃上，有規律地、妥善地進行分析 與溝通？

第二節 研究目的

針對上述的研究問題，本研究提出了一個維護需求分析方法論。本方法論是 在資訊系統功能更新維護時需求形成階段，協助利害相關者（Stakeholder）能機 動地互相溝通並協同合作，並在發生衝突時以結構化的程序來協助利害相關者對 多元觀點進行整合，並鼓勵調停者或高階主管涉入來協助打破衝突所產生的僵 局。 本研究所提出的方法論本質上呈現了協助有機體的結構化神經訊號傳遞的 精神，能在維護需求形成過程中的各階段來協助相關的利害關係者能以著重不同 的主題、輔以結構化的發言格式來表達需求所指涉的事物與合作意涵，來降低溝 通障礙。此方法論的哲學基礎為詮釋學（Hermeneutics）。選擇詮釋學作為本方法 的哲學基礎的理由是：人們的主觀意識對社會層次與商業層次有著主導力量，而 詮釋學揭露的是個體的主觀意識背後得以整合的共通原則，使得不同主觀意見的 相互理解以及進一步激盪出新的想法得以可能。詮釋學的主要焦點放在多元觀 點、協商、以及演進等概念上（West,1997）。對於資訊系統來說，由於功能更新 維護與社會及商業層次有著密不可分的關係，商業層次的變動又經常牽涉到使用 者需求，使用者需求又往往牽涉到多元觀點的衝突進而需要協商並演進而達成共 識，因此，詮釋學適合作為本研究之基礎思維，來延伸成維護需求分析方法論。

本研究也參考了軟體維護成熟度模型（Software maintenance maturity model, SMmm）的指導方針（April et al.,2005），將其作為本研究所提議的方法論的互補 品。SMmm基於系統維護的實務經驗與豐富的相關文獻來提出一個泛用的系統維 護流程模型，並針對維護需求管理提供了一組詳細的指導方針。所以，SMmm可 以輔助本方法論來更周全地考慮系統維護的實務狀況。 此外，由於在不斷傾聽網友需求時，需求數量會持續不斷地增加，而且現有 系統設計上會隨著吸納更多的需求而使得設計上更為複雜，因此，本研究針對需 求的提議，實作了一個工具來支援本方法論，其中加入能易於選用與呈現關鍵詞

的機制，背後並搭配後設模型與知識本體，讓需求提議者能製作出需求的概念模 型，並自動偵測新需求是否與現有設計是否有不一致之處。 總結來說，本研究有三個主要目的： （1） 提出需求分析方法論：根據詮釋學的精神，塑造系統功能的需求分析方法 論之概念模型，引導利害關係者針對新需求，有條理並有系統地對相關重 點來進行分析與討論。 （2） 實作支援方法論之工具雛形：讓需求提議者用知識本體中的詞彙來填入後 設模型，來表達需求模型，並將之加入現有的部落格系統中，使得系統得 以自動判斷新需求是否與現有設計不一致，視情況需要而進入衝突解決程 序。 （3） 方法論的初步評估：讓企業試用本方法論與工具，來初步了解本方法論與 工具是否有助於實務上需求的分析，並收集試用後意見，以期未來改善本 方法論與工具。

第三節 研究範圍

本研究在各層次所適用的範圍如下： z 軟體類別：本研究所針對的軟體是與企業管理與組織有密切關係、而且不斷 需要對系統改版的「資訊系統」。 z 維護類型：本研究採用 Chapin 等人（2001）對系統維護的詳盡分類，針對 其中的「功能更新維護」。 z 維護過程的階段：根據 April 等人（2005）提出的維護過程，本研究所發展 的方法論是針對其中的「維護要求形成」階段，也就是對維護需求進行分析 與整合的階段。 z 組織型態：本方法論適用於需要面對多變環境而需要不斷演進的「組織有機 體」。 z 商業需求類型：本研究針對的是「主觀多元、且常隨著時間而改變的使用者

需求」。

第四節 研究假設

一 個 好 的 方 法 論 必 須 能 有 著 合 乎 實 務 狀 況 的 合 理 假 設 （Avison and Fitzgerald,2003），所以，本研究考慮了網路資訊系統維護的狀況來做出一些假 設，雖然本研究並沒有對這些假設已經成立的條件進行證明，然而，也試圖列出 理由或可行的做法，來說明這些假設是可以達到或是合理的。 z 組織內部的重要使用者已選出：對於組織內部的使用者，可將組織中各群組 中具代表性的重要使用者事先挑選出，來確保在需求整合時起碼有掌握到各 群組關鍵人物的意見。這裡可採用社會網絡分析（Social network analysis） 測量人與人之間的關係，來事先找出群組中具有關鍵中心地位的使用者（唐 日新，民92）。 z 維護對象的現況已知：必須先行儲存欲維護對象的相關現況資料，這包含了 部分的網站結構與部分的商業現況。可在維護進行前，將與維護目標相關的 部分網站結構與部分商業現況加以查訪。 z 使用者了解本身需求：在眾多的使用者中，會有使用者能夠根據自身經驗來 了解該族群之新的使用需求，並有能力藉由言語表達出來。這也是一般方法 論都會有的假設。 z 維護者了解資訊系統與維護案件狀況：維護者了解使用需求所涉及的資訊系 統相關需要更新的部分以及正在處理的其他維護案的狀況。一般的方法論也 會有這樣的假設。可根據網站結構現況來告知維護者可能需要了解哪些部 分，並讓資深的維護者審視，來提醒維護者去了解資訊系統與手上維護案的 相關狀況。 z 願意主動發言：利害相關者能願意主動發言揭露所知道的需求與所了解到的 狀況。對於企業外部的使用者，可透過線上的行銷或銷售活動，提供獎品來 鼓勵使用者提出需求，而對於企業內部的使用者，則可透過績效評估的方式

來讓員工有意願來發言。 z 了解組織所共享的一組關鍵詞的意義：涉入維護案的利害相關者能了解這些 由組織所認可而共同分享的標準詞彙，例如某網站名稱、某維護階段等。可 以提供相關詞彙的說明文件與 FAQ 機制，讓關鍵詞的意義與作用令人容易 了解。 z 了解使用者的各種需求是資訊系統成功的關鍵：了解各族群的使用需求是資 訊系統成功的必要條件。在以消費者為導向、或說以市場為導向的潮流下， 這是人們所常秉持的信念。 z 認可標準化流程的價值：工程導向的結構化維護流程比藝術導向的非結構化 手工維護更好，結構化的方法使得需求的處理更為穩定，這也是一般方法論 所秉持的信念。

第二章 文獻回顧與評述

由於需求分析涉及不同角色之間的多元觀點的溝通，所以先從傳播與管理的 相關理論開始回顧，並對系統維護工作的類型以及方法加以討論，而哲學詮釋學 是本方法的理論基礎，故介紹其歷久彌新的基本觀念，而對於本研究所設計的衝 突偵測工具是用部落格加以延伸修改而成，故對於部落格與知識本體有所討論， 最後並對於需求工程的相關進展作一說明。

第一節 溝通的相關理論

資訊理論（Information theory）的概念在傳播學域中已經廣為應用，資訊理 論的模式（如圖1）中，在人與人的傳播上來說，資料來源就是大腦，訊號也就 是語言，傳送器是指說話者的發聲器官或撰寫文字的肢體，而傳送與接收之間的 通道則是指空氣、紙張或網際網路等傳播媒介，將信號傳送出去。接收器的作用 則與傳送器相反，它將通道傳輸過來的信號解讀還原為訊息，目的地則是訊息所 想傳達的對象，而噪音則是會干擾資訊來源的訊息。資訊理論揭露了當所傳送出 的訊息的結構不嚴謹且模糊時，模糊不清的發言就是一種噪音，這會造成接收者 對訊息的不確定感覺就越高。而重複發言中的關鍵字詞，可確保訊息在充滿噪音 的通道中還可以被聽者接收到，使得噪音得以減低（Severin,2001）。 圖1 Shannon 的資訊理論 （資料來源：Shannon 與 Weaver,1949）

而在管理學域中，資訊理論也常被用來解釋組織成員之間溝通的情形。組織 溝通上噪音產生的主因之一往往是不當過濾與資訊曲解，不當過濾是指發訊者不 適當地保留部分訊息，而資訊曲解是指接收者接收到的訊息在意義上已經有所改 變（George and Jones,1999）。而 Defleur 在 Shannon 的資訊理論加入了回饋 （Feedback）的概念，這使得來源可能去有效地修正其原本的溝通方式，使得來 源與目的之間所持的意義更有可能相通（McQuail and Windahl,1993）。

資訊豐富理論（Information richness theory）指出了人們會根據任務的需要， 而依照媒介的豐富度來選擇媒介（Daft and Lengel,1986）。而 Hollingshead 等人 （1993）的研究指出，產生想法與計畫的任務僅需豐富度低的媒介，而協商彼此 衝突的任務則需要媒體豐富度高的媒介。

資訊過量（Information overload）這樣的現象，肇因於近年來資訊科技的發 達。雖然人們比以往藉由網際網路等資訊科技獲得更多的資訊，然而，接收過多 資訊的後果，則會讓組織成員可能耗費過多心力在讀取不必要的資訊上，甚至可 能導致收訊者忽視真正重要的訊息（George and Jones,1999）。

對於維護需求的分析來說，上述與溝通相關的理論都指出了一些在需求溝通 過程中可能會發生的問題，而本方法論以及支援工具在設計上則參考的這些理 論，來協助利害相關者的互相溝通。

第二節 有機式組織與參與式管理

相對於機械式組織來說，有機式組織（Organic organization）是一種鬆散、 即興的組織型態，其權力下放到組織基層，對意外事件能迅速集結來團隊合作 （Kinicki and Williams,2006）。而機械式組織（Mechanistic organization）的權力 是集中在高層的，有著明確的規章，適合於穩定的環境下運作。本研究所提的方 法論，是機動地隨維護案的特性與該階段的狀況來鼓勵不同的特定相關人員進行 對話與集體決策，進而協助維護需求得以整合，因此符合有機式組織的精神。

而落實有機式組織，也就是讓基層人員也參與管理的工作，也就是與參與式 管理（Participative management）的概念相符。參與式管理是增加生產力的技術 之一。參與式管理也就是讓各階層的員工一起處理資訊、進行決策、或去解決問 題 （Wagner ，1994）。而參與式管理的施行會使得員工的工作滿意度提升 （Kim,2002）。因此，參與式管理被認為可提振士氣、鼓勵創新及提高績效（Kinicki and Williams,2006）。而本研究所提出的方法論是讓利害相關者一同參與功能更新 維護需求的整合過程，來互相溝通並共同決策來解決問題，所以本方法論是在系 統維護中落實參與式管理的精神。

第三節 系統維護

系統維護（System maintenance）涵蓋了許多在新系統完工後的各種後續改 善工作。在 IEEE 標準中，系統維護（亦可稱作軟體維護）被定義為：「在系統 交付之後去更改系統或元件，以更正錯誤、改善性能、增加新功能、或去適應不 同的環境」（Thayer and Dorfman,2005）。在系統維護的分類上，最早的時候， Swanson 的研究（1976）指出系統維護可由維護目的來區分為完善性、適應性、 與更正性維護。IEEE 則列舉了四種維護類型：完善性、適應性、更正性、與預 防性。（IEEE,1990;IEEE,1998）。近來，有鑑於過去的系統維護類型之間存有模 糊地帶，在實務上往往不能明確地把維護工作加以分類，故Chapin 等人（2001） 則更進一步地依據實際可得的明確證據把系統維護區分為 12 種類型：教育訓 練、諮詢、評估、文件改良、文件更新、整理、預防、性能、適應、功能縮減、 功能更正、以及功能更新。

功能更新維護（Enhancive maintenance）是 Chapin 所提出的類型中最重要的 類型之一。功能更新維護可說是去取代、增加、或擴展系統功能的活動，而此活 動會導致商業規則的變更（Chapin et al.,2001），換句話說，系統更新維護可說是 去處理商業上的需求和系統功能上複雜的糾葛。由於現在廣泛倚賴資訊系統的企 業往往面對了相當程度的使用者需求之不確定性，所以許多企業組織必須能像是

具備神經系統的有機體來依據不斷變化的需求來不斷地演進，而資訊系統的功能 更新維護則是企業演進重要的一環。 由於使用者的需求隨著時間不斷地改變，其中對系統功能的不斷有新需求是 最重要的部分之一（Chapin et al.,2001），因此，本方法論選擇針對維護需求中的 功能更新維護需求來進行初步分析。 而維護需求的整合工作是進行一個維護案的開端，其所需討論的主題包含了 有：運作問題、服務要求、優先順序、人力資源、以及釋出時程（April et al.,2005）。然而，有必要針對功能更新維護，去進一步地指出這些主題中所涉 及的細節，使得功能更新維護需求的所必須加以討論的主題能更加明確。

第四節 系統維護方法論

雖然已經有數眾多的系統開發方法論問世，相較之下，卻沒有多少個系統維 護方法論。然而，學術界逐漸開始承認系統維護有著不同於系統開發特性 （April et al.,2005;Abran et al.,2004）並且漸漸開始發展系統維護方法論。 在 1990 年代，有著非常稀少的系統維護方法論被提出。舉例而言，Simple reuse model（SRM）（Basili,1990）是一個簡單的模型，把系統維護單純視為軟體 物件的再用。IEEE 1219（IEEE,1998）是一個流程模型，其中包含了問題辨認、 分析、設計、實作、系統測試、接受度測試、和交付等階段。

截至今日，有一些其他的系統維護方法被發展出來。例如，Mantema（Polo et al.,2002）是一個有四階段流程模型的方法論，此四階段包括：維護流程定義、 無法預先規劃的維護（緊急更正）、可預先規劃的維護（非緊急更正、預防、完 善、與適應）、以及遷移與退役。Corrective maintenance maturity model（CM3） （Kajko-Mattsson,2002）是一個針對更正性維護的龐大且非常詳細的模型，CM3 的重點在於問題管理，包含了問題報告、問題分析、與問題解決。Adaptive development and maintenance（ADM）（Pahl,2004）有著以下三個階段：透過劇本 為基礎設計來進行參與式的需求工程、可改寫的架構設計與雛形設計、以及評估

與演進導向的改變與維護。 此外，SMmm（April et al.,2005）設計來與能力成熟度模式（CMMi）互補， 其包含四個流程領域：流程管理、要求管理、演進工程、以及演進工程的支援。 SMmm是一個流程模型並有數種軟體維護的成熟度。SMmm針對要求管理的第二 層級成熟度擬定了六項詳細的規定，此第二級成熟度是SMmm目前所發展出的最 高層級，這六項規定在第六章有所說明。而SMmm流程模型包含了下列七個階段 （如第三章第二節的圖 5），而軟體演進工程階段是要求管理、營運支援、系統 更正、系統演進的集合。 (1) 交付前與轉移：這是指開發者把系統交給維護者之前的時期。 (2) 要求管理：此階段負責去處理系統的日常問題與維護要求。 (3) 營運支援：此階段包含的工作有系統的評估、顧問、以及教育訓練。 (4) 系統更正：此階段的工作是修理系統的故障，使系統能正常運作。 (5) 系統演進：這個階段包含了適應性、完善性、功能更新、與功能減少的活動。 (6) 導入狀況監控：此階段是為了確定維護後的系統在實際運作上是否有窒礙難 行之處。 (7) 系統重生（Rejuvenation）、遷移與退役：此階段的作用包含改善可維護性、 把系統遷移到另一個環境、或拋棄老舊系統。 本研究所提議的方法論選定 SMmm 作為實務性的互補品，其理由有三。第 一，SMmm主要源自於是從實務者的觀點而提出。第二，此模型後來也考慮了多 種系統維護相關的國際標準，例如 ISO/IEC 12207 與 IEEE 1219。第三，SMmm 針對要求管理提出了一組詳細的指導方針。

Enhancive maintenance model（EMM）（Kajko-Mattsson et al.,2006）是從三個 組織所衍生歸納而得，此功能更新維護流程中的開端有四個階段：功能更新提 交、功能更新分析、決策、與簽訂合約。

表1 包含了上述七種系統維護方法論以及本研究所提出的方法論，依照出刊 年份由早到晚排列。在表1 中，這些系統維護方法論依照下列五種特色類型來進

行評估： z 特定維護類型：此特色類型是去說明該方法論是否是針對特定系統維護類 型來設計的。一些方法論是適用於各種各樣的系統維護類型，而一些方法 論則是只針對特定系統維護類型來設計。 z 做法的詳細度：此特色類型是要顯示系統維護方法論是否提供在其所提的流 程中提供了詳細的做法。 z 考量衝突解決：此評估準則是去判斷各方法論是否對多元觀點所發生的衝突 提供了協助解決的步驟。 z 考量需求變更：此評估準則是去判斷各方法論是否提供了根據回饋資訊來修 改既有維護需求的機制。也就是說，在維護需求被正式批准或被採用之 後，在接下來的設計、撰寫程式、與導入階段，都可能發現一些之前沒有 考慮到的阻礙而習得新的教訓，而有時就必須據此去更動維護要求才是良 策。 z 隱喻：方法的背後往往有其哲學的立場，而揭露方法背後的隱喻，可說是揭 露其基本精神的一種方式，這在下一節會專門對此加以說明。 表 1 揭露了關於現存七種系統維護方法論的一些有趣的現象。第一，除了 CM3 問題管理與 EMM 之外，大部分的方法論都不是針對特定維護類型而設計 的。第二，這些沒有針對特定維護類型而設計的方法論，雖然大多都提出了流程 概念的概觀，但是卻往往沒有提出詳細的做法、或具體的步驟。第四，現存的方 法論並沒有考量到多元觀點往往會造成衝突，而沒有設計協助衝突解決的流程。 第五，現存的方法論通常沒有考慮維護需求可以在要求確定後，再根據後續階段 的回饋資訊來進行變更。 上述的現象可說具備下列的意涵。首先，具備詳細做法的單一方法論很難去 顧及所有類型的系統維護或顧及維護流程的所有階段。一個詳細的方法論比起概 略的方法論比較適合容易被想採用方法論的業界人士所接受，所以，比起概略的 方法論，針對特定系統維護類型與特定的維護流程階段來設計詳細的方法論是較

為可行的也較容易實施。第二，系統維護往往會與商業活動互相影響，而商業活 動的變更往往影響了多個員工甚至多個部門。然而，傳統的系統維護方法論卻沒 有考慮到多元觀點可能造成需求難以整合的問題，因而也沒有提出協助衝突解決 的做法。第三，雖然在確定維護需求之後才在事後進行變更，其成本相當高，但 是這也是常常難以避免的事情，所以方法論需考量根據回饋資訊來進行變更的狀 況。 表1 系統維護方法論的特色 特色類型 方法論 維護類型 做法詳細度 考量衝突解決 考慮需求變更 隱喻 SRM 泛用 概略 否 否 機器 IEEE 1219 泛用 概略 否 否 遊戲 Mantema 泛用 概略 否 否 有機體 CM3_{問題管理 更正性 詳細 否 否 機器} ADM 泛用 概略 否 否 旅程 SMmm _{泛用 大 體 上 概 略 但 是 要} 求管理部分詳細 否 否 有機體 EMM 功能更新 詳細的工作要點 否 否 社會 本研究所提出 的方法論 功 能 更 新 的 維 護 需 求整合 詳細的流程、以及溝 通與合作方式 提 出 協 助 解 決 衝突的流程 有 回 饋 機 制 來 處理需求變更 有機體 （資料來源：本研究）

第五節 方法論的假設與隱喻

任何的方法論都會有一組假設，而這組假設可以解釋為何該方法論可以正常 地運作（Avison and Fitzgerald,2003）。舉例來說，在系統開發方法論方面，可假 設世界是有秩序的或衝突的，並可假設事物是客觀存在的或主觀存在，而這些假 設可把諸多系統開發方法論區分為四種典範（Hirschheim et al,1995），而ETHICS 系統開發方法論落實了新人文主義（Neohumanism）這個典範，ETHICS 的假設 包含了解放主義以及參與的理念、主觀、與衝突（Hirschheim et al,1994）。然而， 方 法 論 的 作 者 本 身 常 常 沒 有 把 方 法 論 背 後 的 假 設 說 明 清 楚 （Avison, Fitzgerald,2003），而之後才仰賴他人對其背後假設進行更進一步的釐清。 隱喻（Metaphor）是一個強而有力的工具讓方法論的採用者比較容易去瞭解 該方法論的主要精神與背後的假設。Kendall 與 Kendall（1993）列出了九種隱喻 來揭露系統開發方法的主要精神與假設，以及每種隱喻其相關連、相對應的系統 開發方法。此外，並針對每種隱喻所可能相關連的系統維護方法來進行討論。 z 遊戲：可以把系統開發視為是一個進行運動遊戲的競賽團隊。這樣的遊戲隱 喻裡面暗示了系統開發是有目標的、困難的、存在已知的風險、有趣的、需 要團隊合作的、而且需要領導統御。在系統開發方法論中，SDLC 具體呈現 了遊戲的主要精神（Kendall and Kendall,1993）。而在系統維護方法論中， IEEE 1219 在其提出的流程中針對每一階段強調了有秩序的輸入、處理、控 制、輸出、與度量做法，所以似乎具體呈現了遊戲的精神。

z 機器：發展系統可以像是機器一般運作。機器有其用途與目的，並且其效能 是可預見的。結構化方法論（像是Jackson systems development）和 CASE 工具是落實機器這樣的隱喻的系統開發方法論（Kendall and Kendall,1993）。 在系統維護方法論方面，SRM 倡導了維護者應該對於物件有條理地再用， 而 CM3問題管理則是提出有秩序的方式協助維護者去處理軟體需要更正的 問題，所以，這兩種方法論應該也可說是具備了機器的精神。

z 旅程：系統開發也許可以被看做是一場旅程，例如進行一趟航海之旅。既然 是旅程，那就必須包含領隊、機組人員、團隊成員、不可預見的風險或危機、 以及冒險。由於雛形法主要著重於不斷與使用者互動，所以其未來是不可預 知 的 ， 故 雛 形 法 讓 系 統 開 發 的 過 程 像 是 一 趟 旅 程 （Kendall and Kendall,1993）。而 ADM 將雛形法視為系統維護的一種手段，所以此方法論 的主要精神也是旅程。 z 叢林：開發系統可以像是組織成員去逃出叢林，而在逃出叢林的過程中，需 要嚮導讓組織成員避免危險。在行銷與管理的文獻中有提到的 Project Champion 觀念，其指出必須選出使用者中的出類拔萃人物來作為專案的嚮 導 ， 此 關 鍵 人 物 的 責 任 是 去 引 導 大 家 去 接 受 新 科 技 （Kendall and Kendall,1993）。 z 家庭：此隱喻的特色是讓成員在一起分享友誼，儘管成員間有著不同的目 標，但允許目標共同存在。所以，組織這樣的大家庭中常常會進行政治協商， 而ETHICS 方法論是家庭隱喻的一個例子（Kendall and Kendall,1993）。 z 動物園：系統開發可以比擬成一個動物園，組織成員被不合理地歸類為一群

一群不同的群組，就像動物在動物園中歸類為不同的種類來圈養。而組織成 員就像動物園裡面的動物一樣安全地生活著，而沒有天敵或掠食者。而在系 統開發方法中，軟系統方法論（Software system methodology）把動物園的 精神具體呈現出來（Kendall and Kendall,1993）。

z 社會：此社會隱喻的觀點來看組織，是去強調組織對於未來的籌畫有多種方 案或選項可供選擇。社會需要政治層次的互動，並且社會的運作必須遵守其 本身的規則與條例。Multiview 系統開發方法論符合此社會隱喻的精神 （Kendall and Kendall,1993）。而在系統維護方法論方面，EMM 有秩序地考 量了科技與商業的價值、規則、與條例，而且EMM 使用了數個決策活動來 從對於未來規劃上的多種可行方案進行選擇，因此EMM 的主要精神符合了 此社會隱喻。

z 戰爭：戰爭需要最好的領袖與軍隊、戰略、以及物資去與敵軍作戰並贏得勝 利，而戰場上瞬息萬變，是難以預測的並且充滿危機，並由將軍負責發號施 令。然而，由戰爭隱喻的觀點去看待對組織是不太好的，因為這可能造成使 用者與開發者的衝突對立，而有必要去避免（Kendall and Kendall,1993）。 z 有機體：一個活生生的組織有機體，有其結構和運作的秩序，但又可因為外

部不可被控制的力量所影響而繼續成長。組織有機體必須適應惡劣的環境並 生存下來。此有機體隱喻假設了面對未來有時必須去追求單一目標、而有時 必須面對多樣化的選擇，環境與有機體內部有時是井然有序、而有時是混亂 的，而領導者有時候必須扮演主動創新者的角色，有時卻只要從旁扮演培育 者的角色即可（Kendall and Kendall,1993）。在系統維護方法方面，Mantema 包含了軟體演進與退役（死亡）的概念，所以應該部分符合了有機體的精神。 此外， SMmm包含了許多關於有機體的觀念，像是軟體演進，回春、與退 役（死亡），因此 SMmm可能也隱含有機體的部分精神。而本研究所提出的 方法論，其主要精神在於協助有機體神經訊號以結構化的形式來傳遞，這在 第六章有所討論說明。 在Kendal 與 Kendal（1993）的研究中，並沒有發現符合有機體精神的系統 開發方法，而其研究指出了發展具備有機體精神的系統開發方法論的困難有二。 第一的困難在於，此種方法論必須具備靈活而有彈性並且具備適應性。第二，有 機體隱喻讓人們必須正視系統成熟、老化、甚至死亡等人們平時不善於面對的問 題。這些困難可能可以解釋為何具備有機體精神的系統開發方法沒有被設計出 來。 總而言之，有必要明確揭露方法論背後的假設，讓方法論的採用者所知悉這 些假設來瞭解方法論的適用情境。而依據這些假設，系統維護者可以視系統維護 的實際狀況來更容易地選擇適合用於該情況的方法論。此外，系統維護者可以有 目的性地選擇適當的方法論在維護過程的各階段去試圖影響系統維護者與使用 者，去引導他們進行改變，使其扮演適當的角色。

此外，雖然Kendal 與 Kendal（1993）的研究中所提出的有機體特徵雖指出 了利害相關者應適情況來採用適當的方式來溝通並合作，但需要進一步將此概念 延伸，來揭露維護需求整合中各階段的基本特徵。

第六節 哲學詮釋學

哲學詮釋學（Philosophical hermeneutics）的開創者為高美達（Gadamer）， 是現象學的一支，而現象學（Phenomenology）是二十世紀歐洲哲學路線的重要 成就，是一種純粹意識自身的先驗超越科學（Moran,2000）。另一方面，詮釋學 亦可說是社會主觀主義典範的一支，在這個典範下，意義是在主體間交流時才得 以被造創出來（Meaning is inter-subjectively created）（Berthon et al.,2002）。近年 來，在資管領域中，詮釋學已經受到越來越廣泛的矚目，並已經被用在下列五個 方面：

z 系統開發方法：ETHICS 方法論（Hirschheim et al.,1994）有使用到詮釋學去 達到解放主義的理想。

z 系統設計：一個路徑模型使用了詮釋學來進行網頁的推薦（Chalmers,2004）。 z 系 統 導 入 ： 一 個 理 論 架 構 用 了 辯 證 詮 釋 學 來 促 進 資 訊 系 統 的 導 入

（Myers,1994）。

z 系 統 使 用 評 估 ： 許 多 研 究 （ Lee,1994;Sarker and Lee,2006;Trauth and Jessup,2000）使用了詮釋學來評估系統的使用。

z 研究方法：一些研究（Lacity and Janson,1994；Mingers,2001）認為詮釋學是 研究資訊系統使用很重要的方法論。 當需要重視多元觀點的時候，詮釋學可以是協助組織協商與演進的基礎。然 而，詮釋學似乎還沒有用在系統維護方法的設計上。這可能有兩個理由，首先， 詮釋學大體上在社會科學中被比較廣泛地使用，但在設計科學領域則少為人知。 第二，詮釋學的知識，由於涉及的是人類複雜意識背後的本質，故其呈現方式往 往相當抽象並且不太結構化。

為了把詮釋學應用在系統維護方法論的設計上，這邊嘗試根據詮釋學的重要 經典–高美達的「真理與方法」一書（Gadamer,1989）–以較為結構化的概念來 簡約地解釋何謂詮釋學。詮釋學所想要回答的問題是：「理解如何可能？」 （Gadamer,1989），而在回答這個問題的論述當中，詮釋循環（Interpretive Circle） 是一個相當重要的概念。圖1 以結構化的方式來說明詮釋循環的過程，而詮釋循 環可被視為觀點整合過程，包含了三個步驟： 1. 個人去了解公眾意見：以個人原有的知識為基礎，才能對新接觸的其他 公眾意見進行了解。而在接觸其他人意見之後，有機會去拓展使得原本 狹窄的視野。 2. 公眾意見影響了個人：個人可憑藉品味與理性，選擇性地吸收有趣的公 眾意見。而個人的知識體系可能會受到公眾意見的左右，來新增或修改 一些概念與關係。 3. 個人公開表達意見：基於吸收了一些公眾意見之後的個人知識，個人可 以在公共領域中表達自己的見解。而其他人可去理解此見解，而重複詮 釋循環的這三個步驟。 1. 了解 可演進的個人知識 不斷累積與改變的公眾意見 2. 影響 3. 表達 圖2 詮釋循環過程

由於詮釋學關注於多元觀點的整合，而功能更新維護除了技術層次外又涉及 了組織的社會層次與政治層次，而這些非技術層次往往深受多元的主觀意識所左 右，所以詮釋學對於功能更新維護的需求分析可以是相當重要的哲學基礎。如果 在功能更新維護之使用者需求分析活動中去重視多元觀點，顯然衝突會常發生。 而有研究認為詮釋學對於衝突解決來說是一個有用的基礎（Väyrynen,2005）。 雖然詮釋學指出了在一般生活中人們整合多元觀點的過程，然而，在維護需 求的觀點整合中，卻需要進一步回答下列問題：該如何引導利害相關者以合乎詮 釋學所提的詮釋循環方式中來進行觀點整合？針對哪些主題進行討論與意見整 合？每一主題中，哪些利害相關者需要共同參與？而必須產生的結果與決定為 何？換句話說，在需求分析流程與工作表格的設計上，將哲學詮釋學所揭露利於 個人與公眾間意見交流並促進知識演進的方式考量進來，應會使得需求的溝通能 有助於系統功能的演進。

第七節 部落格

部 落 格 （ Blog ） 是 一 個 主 流 的 新 型 態 個 人 通 訊 與 協 同 工 具 （Rosenbloom,2004;Young and Terrence,2003），而部落格也是一種新的出版平台 或媒體（Rosenbloom,2004）。更具體地說，部落格是一種網站，在網站上所定期 發佈的文章會按照日期而有固定格式地排列。原本部落格是為了個人撰寫日記而 設計的，而人們可以使用部落格在網路上撰寫個人日誌來向網友展現自己。部落 格提供了一種機制，稱為匯集（Syndication），可以讓部落格文章連結在一起 （Lindahl and Blount,2003）。此外，人們可以瀏覽、搜尋、和以多媒體的形式來 發 表 文 章 在 部 落 格 上 ， 並 且 可 以 對 部 落 格 上 的 文 章 進 行 評 論 （Moor and Efimova,2004）。

從 技 術 觀 點 來 看 ， 部 落 格 系 統 都 具 備 有 五 個 共 通 特 點 （Lindahl and Blount,2003）：（1）把內容從呈現外觀中分離：部落格系統透過工作流管理機制 來進行內容管理，而不影響到部落格上的網頁外觀。（2）樣版：針對內容提供更

換外觀樣版的機制，讓使用者可以輕易而有彈性地改變功能與視覺外觀。（3）部 落格API：部落格的客戶端軟體可以透過應用程式介面（Application Programming Interface, 簡稱 API）來編輯部落格的文章內容。而許多客戶端軟體讓使用者可 以一次在數個部落格上同時張貼文章。（4）資訊管理：部落格系統提供許多資訊 管理的功能，像是備份與復原的機制、自動化地為文章編製索引、搜尋功能、以 及指定各角色擁有的權限。（5）匯集：人們可以使用 RSS （Really simple syndication）去訂閱特定部落格的文章。此外，TrackBack 是另一種匯集的方式， 這讓使用者在自己的部落格上張貼文章時，可以去引用其他部落格上的文章，並 且通知該部落格其文章已經被自己引用了。所以使用者可藉此來追蹤一串討論文 章中的前後文關係，並使得不同的部落格間可以點對點地連接起來。 然 而 ， 部 落 格 除 了 可 供 個 人 使 用 之 外 ， 也 可 以 應 用 在 組 織 上 （Bulkeley,2005;Treese,2004）。在商業上，部落格可以促進分散在各地的人們進 行對話（Moor and Efimova,2004），而且可能變成人們在線上互動的主要方式之 一（Tepper,2003）。企業可以很容易地在部落格上放置吸引人的文章並得到客戶 的回應。目前，企業已經開始把部落格應用在商業領域中，例如通用汽車的 FastLane 部落格（http://fastlane.gmblogs.com/）和日產汽車的 TIIDA 部落格 （http://blog.nissan.co.jp/TIIDA/）。 對於需求工程的支援工具來說，已經有研究顯示在需求溝通時，不應該去發 展一個特殊的溝通系統，而是應該選擇使用者日常生活中已經習慣的溝通系統， 再加以進一步改進（Sinha et al., 2006）。雖然廣受網友歡迎的部落格可以直接用 作使用者與資訊部門間的需求溝通工具，然而，部落格上文章內容所包含的概念 與關係並沒有讓利害相關者能很容易地加以自訂、選用以及呈現，故現有的部落 格有改良的空間。

第八節 本體論

在哲學上，本體論（Ontology，又譯為知識本體及存有論）是對存在的種種

事物之研究，在本體論的觀點上是可把世界從其接縫處切開（Chandrasekaran et al.,1999），進一步來說，本體論可以被具體定義為：「研究現實上各種領域中關 於是甚麼、種類、物件結構、屬性、事件、過程、以及關係的科學」（Smith,2003）。 而在電腦科學中，計算本體論則可被定義為：「具備正式且明確規格之形式化概 念（Conceptualization）」（Gruber,1993）。而哲學本體論和計算本體論的差異在於， 哲學的本體論所包含的內容是沒有邊際且沒有範圍的，而相較之下，計算本體論 所論及的內容則是根據其用途與目的而只在限定在一定的範圍內（Kishore et al.,2004a）。 雖然以比較窄的定義來說，本體論只是一組詞彙，然而，以比較廣泛的定義 來說，本體論可以是一種概念系統（Guarino and Giaretta,1995），這樣的概念模 型可由下列三個元素所組成（Kishore et al.,2004b）： z 概念（Concepts）：概念可說是從特定的一些實例中導出或推論出的抽象或 總稱的構想，而概念中通常會顯示一些屬性。在本體論中，概念可以用兩種 方式加以組織起來，第一種方式是分類，也就是概念與概念之間是以is-a 的 關係連結起來，來表達出一個概念是繼承自其他概念的情況；而第二種方式 是組合，這就是說該概念可以分割成許多小概念，而這些小概念與該概念通 常沒有繼承關係。 z 關係（Relationship）：概念通常會透過關係或函數（Function）來與本體論 中的其他元素有所關連。

z 限制與公理（Constraints & Axioms）：限制是指範圍或約束，一般包含結構 上、空間上、以及時間上的限制。而公理也是一種限制，是指該命題假設為 真且不需證明，限制與公理常會使用第一階與第二階邏輯（First and second logic）。

而本研究將本體論視為一種概念模型的表達方式，而本體論可包含兩種類型 的知識，一是針對特定領域與用途的有用概念以及其屬性、關係以靜態的方式來 加以表達知識，另一種是針對限制與公理以規則（Rule）來表達此種動態的知識，

使得系統可搜尋這些規則來進行推論。

第九節 需求工程

在軟體工程領域中，需求工程（Requirements engineering）是相當重要的一 環。需求工程是一組結構化的活動，來協助參與系統發展的利害相關者與工程師 來了解並記錄系統規格（Sommerville, 2005）。需求工程可視為一個不斷演進的 過程，其不斷循環的流程包含了擷取（Elicitation）、分析（Analysis）、驗證 （Validation）、協調（Negotiation）、紀錄（Documentation）、以及管理（Management） （Sommerville, 2005）。 而使用案例（Use-case）近年來越來越常用於需求工程上，因為可用於使用 需求的擷取、分析、並記錄需求（Jacobson, 1992;J. Rumbaugh, 1994）。使用案例 雖然對於角色用系統來從事何種活動的描述上，是相當簡易而容易使用的，然而 對於因為基於何種背後的原因而形塑出哪些使用案例，卻是欠缺的。故 Lee 與 Xue（1999）指出了在使用案例上延伸加入目標的概念，可以使得各種使用案例 所欲達到之目的更為清楚。 由 於 需 求 工 程 中 往 往 需 要 面 對 多 元 觀 點 ， 所 以 ， 需 求 間 的 相 互 關 係 （Interaction）一直是需求工程領域中令人感興趣的問題。Robinson 等人（2003） 將需求的互動關係分為四種（1）正面關係：滿足需求 R1，有助於滿足需求 R2， （2）負面關係：滿足需求 R1 會導致不滿足需求 R2，（3）未定關係：改變對於 需求 R1 的滿足程度，會對需求 R2 造成未知的影響。（4）無關係：無論怎麼改 變需求R1 的滿足程度，對需求 R2 的滿足程度不會有影響。從目標的觀點來看， 正面關係可說是指出了R1 與 R2 應是朝向同一目標，而負面關係則是指出了 R1 與R2 在各自目標的達成上有抵觸衝突。而從需求衝突的觀點來看，需求間具備 負面關係和未定關係，都可能造成需求抵觸與衝突的發生。

而Lee and Xue（1999）以及薛念林（1999）則指出了使用案例所欲達成目 標，具備了三種互動關係。（1）合作關係：可細分為正向和負向關係，正向關係

就是說目標G1 的滿足程度提升會連帶讓目標 G2 的滿足程度提升，而負向關係 是目標G1 的滿足程度下降，會連帶讓目標 G2 的滿足程度下降。（2）衝突關係： 提升對於目標G1 的滿足程度，會使得 G2 的滿足程度下降。（3）不相關：兩者 獨立。所以，從語意的觀點來看，所謂的兩目標有合作關係，可以解釋成兩目標 之間有母子關係，而衝突關係，可解釋為目標間是為兄弟姊妹關係而造成分歧， 而不相關，則可解釋為兩目標間並無共同的母概念。 在需求觀點整合方面，Andrade 等人（2004）提出了一個流程來處理多元觀 點，首先對某人或某個群組所提出的單一觀點進行塑模，然後對多元觀點的不一 致之處進行偵測，接著解決需求不一致的問題，最後將多元觀點整合起來。然而 這個流程有需要對於需求的內容（例如上述提及的目標、使用案例中的角色與系 統用途）進行進一步地說明。 在衝突的自動偵測上，Gervasi 與 Zowghi（2005）認為所謂的需求衝突可具 體定義為邏輯上的抵觸（Logical Contradiction），也就是相反的事實（α與﹁α） 同時存在於同一個規格中。 而在知識本體在需求工程的發展上，Kaiya 與 Saeki（2006）提出了應用知 識本體用於領域知識描述來藉此進行需求擷取的方式。其包含了一個知識本體的 後設模型，並且認為需求文件所涉及的項目（也就是需求文句中的各個詞彙）必 須要能與知識本體中的概念有著對應關係（Mapping），如此應該有助於分析人 員改善需求文件的完整性與一致性。 Sommerville（2005）認為需求工程在 20 世紀，是去假定在系統開發前已經 有一份完整的規格存在，但是，這樣的想法已經不合時宜。在21 世紀的趨勢中， 需求工程是需要面對快速的環境變化，這使得需求規格是必須不斷持續改變的。 所以，需要有新的手法，來迅速面對新的機會與挑戰。進一步地說，21 世紀的 軟體工程必須思考下列四個趨勢：（1）利用組態（configuration）的方式來迅速 發展系統（2）因為商業快速變遷而需要將軟體快速釋出（3）新需求日趨增多（4） 新舊系統能一同工作來改善投資報酬率。

這裡將針對需求衝突的相關研究，以及對衝突的相關研究與啟發，整理如下 表。 表 2 需求衝突之相關研究 作者 研究重點 Robinson 等人（2003） 衝突發生於需求間有負面關係（滿足需求R1 會導致不滿足需求R2）時，或衝突可能發生 於需求間有未知關係時

Lee and Xue（1999）以及薛念林 （1999） 指出了衝突的發生是肇因於目標間的關係， 也就是需求在滿足某一目標的同時，會使得 另一目標不滿足 Andrade 等人（2004） 提出了工作流程來解決不一致多元需求的整 合問題 Kaiya 與 Saeki（2006） 指出了以知識本體並搭配規則，可自動偵測 需求不一致的研究方向 Gervasi 與 Zowghi（2005） 提出了可自動偵測需求內容中邏輯上的抵觸 （α與﹁α）之機制

第三章 研究方法

為了提出一套可行的、用於系統維護之需求分析方法論，本研究採取了三個 階段來進行。首先，根據相關文獻，先將維護需求的流程、以及流程中所涉及的 相關概念與關係塑造出來，來呈現出方法論。然後，依據方法論，並鎖定需求之 衝突抵觸偵測為主要目的，建立工具的系統架構，並改良現有的部落格系統，將 工具的雛形實作出來。最後，採用實地實驗法，讓企業試用這套系統雛形，來對 本方法論與工具進行評估並提出改良建議。以下對這三個階段來更進一步說明： （一）概念模型塑造（Conceptual modeling）：在方法論的概念模型的塑造過程 中，是以詮釋學為基礎來塑造需求的溝通討論流程，並參考SMmm所揭露 的需求演化所涉及的概念，來塑造溝通過程中討論的對象。此外，在工具 的系統雛形上，則是針對衝突自動偵測的用途，根據所提方法論、現有部 落格的系統特性、以及知識本體和後設模型，來提出系統的架構模型。 （二）系統實作（Implementation）：本研究選擇一套開放源碼的部落格系統來進 行修改，並自行發展可用於表達需求的後設模型（Meta-model），而且設 計能存放知識本體的資料庫模型，來實作出支援需求溝通與偵測衝突之雛 形（Prototype）。 （三）實驗評估：在系統完成後，本研究預計採用實地實驗法，尋找適當的企業 來試用本方法論與工具，透過深度訪談，來了解本系統與工具是否可行， 並且透過實務人士的觀點，來了解對本系統與工具在現在或未來可改善之 處。

第四章 需求分析方法論

第一節 方法論介紹

一、本方法論精神：協助有機體的結構化神經訊號傳遞

本研究所提議的維護需求分析方法論，其主要的精神是：協助有機體的結構 化神經訊號傳遞。這個概念是指有機體某部位的神經訊號（發言）能遵循既定流 程，在特定步驟時著重於特定主題來加以發出，使得其他部位（群組）能易於理 解該發言的內容，並據此進行各自解讀，來發表不同的意見。

溝通步驟

維護處境

（1）選擇 （2）引導 利害關係者 （3）思考、行動 （4）發言

溝通步驟

維護處境

（1）選擇 （1）選擇 （2）引導 （2）引導 利害關係者 （3）思考、行動 （4）發言 圖3 協助有機體組織的結構化神經訊號傳遞循環 圖 3 描繪了在維護需求整合時，有機體組織的訊號傳遞過程，圖中左邊的人 型是指維護案中負責思考並且協同地合作與行動的使用者或維護人員，而右上方 的方塊是指已經預先設計好的維護需求溝通步驟，右下方的方塊是指資訊系統的 功能更新維護之相關實際處境，除了發言內容外，也包含了商業、網站、與維護 案等相關事物。而這樣的有機體的訊號傳遞是一個不斷循環的過程，此過程可依 序分為四個階段來加以說明： 1. 選擇：根據維護處境的現況以及既定的流程，來選擇出下一個適當的溝通步

驟。 2. 引導：被選出的溝通步驟，可引導利害關係者接收到重要的處境資訊。 3. 思考、行動：利害關係者收到重要處境資訊後，會進行思考甚至實際行動， 且在個人心智中形塑出自己的想法； 4. 發言：將想法以語言的形式呈現，進而改變維護處境。 井然 有序 混亂 組 織 功 能 運 作 使用者 維護者 決策責任 未來計畫 單一 目標 多種 選擇 井然 有序 混亂 組 織 功 能 運 作 井然 有序 混亂 組 織 功 能 運 作 使用者 維護者 決策責任 使用者 維護者 決策責任 未來計畫 單一 目標 多種 選擇 未來計畫 單一 目標 多種 選擇 圖4 有機體維護組織的特徵 （Kendall and Kendall,1993）

圖 4 則是說明了在不同的時候，有機體會在當時呈現出不同的特徵。也就是 說，維護需求整合過程中某一階段的有機體特徵，可能是圖中八個方塊的其中一 個。此圖是參考 Kendall 與 Kendall 的研究（1993）所繪製而成，圖中有三個維 度，而每個維度則有兩種項目，在功能運作上，可能是井然有序或混亂的，在維 護者的立場上則可能是站在負責創新的立場或從旁協助的顧問立場，而對未來的 計畫，則可能是已經有了單一的明確目標，也可能是模糊而有多種選擇有待去釐 清與決定。 圖5 描繪了本研究所提出的方法論在 SMmm中的定位。本方法論是SMmm中 要求管理階段的其中一部份。SMmm可說是一個可廣泛用於各種維護工作的流程 模型，本方法論則是適用於SMmm中的要求管理上，也就是需求管理，並針對功 能更新維護而設計的。本方法論可處理系統功能無法符合商業需求的問題，並解

決商業層次衝突來漸進地形成完整的維護需求。 交付前與轉移 要求管理 . . . 營運支援 系統更正 系統回春、遷_移與退役 維護需求整合方 法論 SMmm 軟體演進工程 圖5 本方法論在 SMmm中的定位

二、本方法論概觀

本研究所提出的方法論（如圖6 所示）包含三個環節：需求形成流程、衝突 解決流程、與回饋。 z 需求形成流程：這是為了確認功能更新方面的維護問題，並形塑出對維護要 求所分析出之詳細內容。 z 衝突解決流程：此流程是為了輔助需求形成流程去整合有衝突發生的多元觀 點，其中提供了協商、調解、與裁決等三階段的衝突解決方式。 z 回饋：來自於系統演進與導入狀況監控的回饋資訊，則可能對改善原始維護 要求的原本規劃提供了新契機或揭露了新的限制。

衝突解決流程 爭論者對衝突解決 進行協商 需求形成流程 仲裁者對僵 局進行裁決 維護需求分析方法論 新功能設計、實作、或導 入時需求變更的產生 調停者對僵 局進行調解 回饋 輔助流程 主要流程 圖6 提議的功能更新維護之需求分析流程概觀 在本方法論中，參與維護的成員共有下列八種角色： z 利害關係者：根據 Pouloudi（1997）的定義，利害關係者指維護涉入維護過 程的參與者，也就是任何被系統維護所影響或想去影響系統維護的個人、群 組、或組織，並且是直接或間接地去使用被維護的系統。利害關係者可分為 使用者及維護者。 z 使用者：是指直接或間接去使用被維護系統因而參與系統維護過程的人。 z 維護者：指從開發者把系統承接過來而負責維護系統的人，因而需參與維護 過程，亦可稱為維護人員。 z 爭議者：爭議者是指參與維護過程而與他人意見相左的人。 z 群組領袖：一個組織可以根據部門別與階層別來將之劃分成一個一個的群 組。一個群組領袖可能指的是一個群組成員中公認的意見領袖，或經由投票 來決定之。 z 群組成員：指處於同一群組中的人。

z 調停者：指中立的第三方，其扮演調解的角色來協助衝突解決。 z 仲裁者：指一個人或機構，其負有負責去對衝突進行裁決來解除僵局。

三、需求形成流程

需求形成流程的主要目標是去產生詳細的維護要求內容，對下列主題來進行 溝通與確認：提議新功能需求、分析被影響的商業與軟體部分、安排人力資源、 規劃實作的優先順序、以及規劃新功能的釋出時間。此流程包含了五個階段（如 圖 7），而五個階段中各自有一些步驟，說明如下，並且提出各階段工作上所需 填寫的表格。 需求形成流程 新功能提議 (R_Step 1-3) 影響層面評估 (R_Step 6) 實作優先權排序 (R_Step 7-8) 商業活動分析 (R_Step 4-5) 釋出時程期望 (R_Step 9-10) 圖 7 需求形成流程 R_Step 1. 利害關係者確認問題：利害關係者也就是使用者或維護者，可在此階段 提出關於系統更新維護方面的問題，並應該指定一獨特的識別碼給此維 護問題。系統更新維護問題的成因可能有二種，第一，由於外力造成商 業規則改變，而使此種問題發生；第二，利害關係者主動提出新的需求， 表達其不滿意現有的某些系統功能而產生問題，而想要解決此種問題， 可能會造成現有商業規則改變。接下來，在利害關係者提出問題後，利 害關係人都有權利去對此問題進行評論，可從一己的觀點來評價該維護 問題是有價值抑或是不重要的。如果沒有人認為此問題不重要，則此問 題成立。如果有人認為此問題不重要，則會觸發衝突解決流程，來進一 步去決定問題是否成立，而原問題則必須根據衝突解決後達成的共識來

更新。此外，此問題可在成立後根據回饋資訊來更新，而再次請利害關 係人對新版問題進行評論。 R_Step 2. 使用者提出服務要求：在此階段，使用者或使用者群組可針對前一階段 所點出的問題，提出概略的功能更新維護要求。此維護要求應該以初步 且概念性的方式來提出問題的解決方案，而該維護要求也應該被編上獨 特的代碼以便在後續工作時對其加以識別。此外，要求可以根據評論、 或來自於系統演進或導入狀況監控階段所回饋的資訊來進行修改。 R_Step 3. 利害關係者採納服務要求：在使用者或一群使用者提出服務要求後，其 他的利害關係者可以提出各自的見解。提出要求的使用者可以選擇去接 受或拒絕這些見解。如果有利害關係人不同意去接受此服務要求，則需 要進入衝突解決流程，以決定此服務要求是否該被採納、拒絕、或需要 擱置此要求來進行更深入的分析。表3 以表格的形式來表達子階段 1 到 3 所需填寫的內容，並以電子報為主題舉例說明。 表 3 新功能提議階段之工作表格與範例 編號 新需求自由描述 新需求模型 採納者 拒絕者 1 希望不是電子報會員 的人，也能對文章表達 評論意見，使得迴響功 能能更多人使用 非會員使用迴響功能 廣告部門 資訊部門 行銷部門 2 … … … … （資料來源：本研究） R_Step 4. 維護者考察商業活動：由於系統更新維護的主要焦點在於系統功能的修 改，因此維護者應該對受到功能修改所影響的商業活動進行考察，並根

據維護要求提出詳細的新商業活動設計。維護者必須環顧既有的商業活 動狀況，並從效率與效果的角度針對新的商業流程或任務來建立周詳的 計畫。 R_Step 5. 利害關係者採納新規劃的商業活動：在此階段，除了考慮效率與效果之 外，利害關係者應去考量新商業活動設計對於政治與社會層次的影響， 來評估新的商業活動設計是否適當。當利害相關者對商業活動設計提出 修改意見，維護者可以根據該共識來修改商業活動設計，讓利害關係者 再對此進行評估。如果利害關係者都接受該設計，則繼續需求形成流程 的下一階段；如果有意見分歧，則接下來需要進入衝突處理流程。表 4 以表格的形式來表達子階段4 到 5 所需填寫的內容，並舉例說明。 表 4 商業活動塑模階段之工作表格與範例 編號 新需求自由描述 商業活動模型 採納者 拒絕者 非會員使用迴響功能 廣告部門 … 迴響功能支援發表意 見活動 … … 1 希望不是電子報會員 的人，也能對文章表達 評論意見，使得迴響功 能能更多人使用 發表意見活動達成可 匿名自由表達之目標 … … 2 … … … … （資料來源：本研究） R_Step 6. 維護者進行影響性分析：影響性分析是去判定軟體系統的改變範圍，並 預估為了完成這樣的改變而需要的資源（Thayer and Dorfman,2005）。在 此階段中，首先會指派一個維護者來初步判定改變範圍，而另一資深的 維護者去檢查其判定是否正確。根據這樣的判定結果，維護者接著去評