工具之功能

本工具發展的目的，是為了要與本研究所提出的方法論加以搭配，來支援方 法論不足之處。本方法論希望持續收集到公司外部使用者的需求，也就是需要一 套溝通工具讓外部使用者能將其需求讓企業內部的人員知悉，而企業內人員亦可 與外部使用者溝通需求。換句話說，也就是支援本方法中 R_Step 2 使用者提出

服務要求的階段。然而，問題在於，有需要開發一套全新開發的工具？抑或是採 用一般既有的溝通工具？

根據調查顯示，利害相關者並不希望特別去學習全新的溝通工具，而希望採 用平時慣用的溝通工具來溝通需求（Shinha et al., 2006）。但是，既有的溝通工具 並非是專為需求的溝通而設計。尤其對於不斷演化與維護的系統來說，新需求會 不斷地發生，而系統的設計會不斷地吸納需求並日趨複雜，這使得新需求與現有 系統設計之間的不一致會更容易發生。所以，溝通工具必須扮演著更主動的角 色，來偵測提議的需求是否與現有的設計抵觸。

本研究選擇了部落格來作為溝通工具，其原因有二，首先，部落格在近年廣 為流行，大多數的網友皆使用過或熟悉部落格的操作，第二，本方法論重視大眾 的集體智慧，而部落格是在web 2.0 風潮中興起的溝通軟體，在設計上是鼓勵並 重視大眾的自我表達意見，所以部落格與本方法論在背後的設計理念上就這部分 來說是相通的。然而，部落格當初的設計並沒有特別著重於對需求的溝通，因此 本研究將部落格套裝軟體加以修改，加上需求溝通方面的功能。

本研究選用了在美國廣為流行的Telligent 公司之 Community Server 這套部 落格軟體，此部落格軟體架設在微軟的Windows XP 平台下，其程式的部分是建 構在.NET 架構上，採用了 C#語言來進行開發，而資料庫的部分是採用微軟的 SQL Server 2005 來儲存資料。此部落格軟體預設的顯示是英文介面，雖然有提 供在地化（localization）的功能來顯示英語之外的他國語言，然而並沒有提供繁 體中文的在地化檔案，所以研究者自行先將重要的介面翻譯成中文。

為了支援本方法論，研究者在部落格軟體中添加了一些新功能，除了修改部 落格程式且添加了一些模組之外，並將知識本體、需求模型、資訊系統的設計模 型、以及衝突狀況等資料添加在部落格的資料庫中。新添加的資料庫實體關係模 型，描繪如下圖。

系統模 型

新需求模

型 包含 主詞 連接 動詞 連接 受詞 包含

概念 知識本體 包含

關係到

對應 對應 對應

衝突 有

圖12 工具之資料庫模型

在工具的資料庫所新增之處，主要涵蓋了三個部分：知識本體、資訊系統設 計、以及新需求。如圖12 中所示，知識本體這部分涵蓋了需求所涉及的領域知 識內之概念，以及將概念間聯繫起來的關係。而更詳細地說，概念可分為兩種，

一種是名詞的概念，一種是動詞的概念。

名詞概念是根據不同的系統來建置，包含了角色、功能、活動、資料、目標、

與假設等類型的概念，而名詞概念的屬性包含領域知識編號（用來分辨不同系統 所屬的相關知識）、概念序號（用來識別各個概念）、概念類型（也就是角色、活 動、資料…等類型）、代表該概念的名稱、以及概念的節點類型（該概念是知識 本體中的是根節點還是子節點）。而名詞概念之間的關係則是以種類（上位關係 與下位關係）、組成（整體-部分關係與部分-整體關係）、以及同義詞關係來描述。

動詞概念是由研究者所設定，則包含了使用、支援、操作、達成、與依循等 類型的概念。其中，使用類的動詞概念包含三種：使用、不可使用、與不需使用；

支援類動詞有：支援、不可支援、與不需支援；操作類動詞包含輸入類、儲存類、

與顯示類等三個子類別，而輸入類動詞有：輸入、不可輸入、與不可支援，儲存

類有：儲存、不可儲存、與不可支援，顯示類有：顯示、不可顯示、不需儲存；

達成類動詞有：達成、不可達成、與不需達成；而依循類動詞有：依循、不可依 循、與不需依循。以上這些動詞中，「不需」與「不可」的意涵不同，不可是帶 有禁止該動作的意味（例如：非會員不可使用結帳功能），而不需是表達沒有必 要（例如：會員不需輸入身份證字號）；而不可與不需開頭的動詞，與其他動詞 間會有反義關係，像是使用和不可使用兩個概念之間就是具備反義關係。動詞概 念的屬性包含了概念序號、代表該概念的名稱、節點類型、以及動詞兩端所連接 的概念類型。動詞兩端所連接的概念類型，正如前述圖 11 的後設模型所示，例 如：「使用」的前端是連接角色類概念，後端是連接功能類概念。

在資料庫中，對資訊系統現況進行描述的系統模型以及由利害相關者提議的 新需求模型的兩個部分，其所包含資料在結構上大致是相同的，兩者皆包含主 詞、動詞、與受詞，本研究用這樣的結構來來描述現有系統設計或新需求。新需 求實體中的每則新需求、系統設計中的每條系統設計的描述、以及主詞、動詞、

受詞實體中的各個詞彙，都有其獨特的識別碼，然而主詞、受詞、與動詞實體中 的每筆資料，原則上都會對應到知識本體中的某個概念，但是，如果在描述新需 求時，主詞和受詞中有知識本體之外的新詞彙，則會需要後台的管理者來將新詞 彙納入知識本體中。

由於本工具在設計上是將新需求模型附加在部落格的文章中，所以新需求模 型的實體必須與部落格原有的文章實體間建立外來鍵來進行聯繫，也就是說，在 新需求模型實體中必須有一個部落格文章編號的屬性。而如果新需求與現有設計 上有偵測到衝突的狀況，則記錄在衝突實體中，衝突實體和新需求模型實體間亦 有關係來聯繫。

為了偵測需求與現有設計間的衝突，研究者在部落格軟體工具中添加了知識 本體管理、系統模型管理、新需求模型製作、以及衝突自動偵測等四個模組。管 理者可使用「知識本體管理模組」來對知識本體中的概念與關係進行新增、修改、

刪除等動作，一般的製作方式是先選擇欲建立的概念類型（例如：角色），再輸

入代表概念的詞彙名稱（例如：非會員），並指定該概念為根節點或子節點（例 如：子節點），來將概念建立起來；然後，選定欲建立兩者間關係的概念（例如：

網友與非會員這兩個概念），再指定關係類型為種類或組成關係（例如：非會員 是網友的一種），如此一來，新增的概念就被加入了知識本體中，並與既有的概 念聯繫起來。

在知識本體的建立工作告一段落後，即可根據現有的系統狀況，利用「系統 模型管理模組」來將系統模型建立起來。至於建立系統模型的方式，首先，需先 選定主詞（例如：角色知識本體之中的非會員），然後選擇受詞（例如：功能知 識本體之中的結帳功能），最後再選擇連接角色與功能之間的動詞（例如：不可 使用），因此，描述系統模型的一則敘述（非會員不可使用結帳功能）就存入了 資料庫的系統模型資料表中。將知識本體與系統模型這兩部分的資料建置完成 後，此系統即可讓利害相關者來提議新需求，並可對新需求與現有設計之間的抵 觸與衝突之處進行自動偵測。

在「新需求模型製作模組」方面，是將其結合至部落格的評論模組中，也就 是利害相關者在提議需求時，不止是將知識本體中的概念視為選項，來選出組成 新需求模型的主詞、動詞、受詞，而且在此同時，也應該將模型之外對新需求的 其他描述，以一般文章的形式，自由地來進行新需求的補充描述。採取這樣的做 法的理由，已經在哲學詮釋學中揭露，因為模型雖然是一種著簡潔有力的表達方 式，反過來說，卻不是一種完整的表達方式（Gadamer, 1989），因此模型無法全 然取代其他形式的文章。而在實務上，Fowler 與 Scott（2003）在從其建立資訊 系統模型的經驗中，也提到模型之存在目的在於促進溝通，所以不應該將對系統 的所有細節描述都建立在模型中。從目前軟體工程的相關研究發展中，亦可發現 除了概念模型的建立之外，像是情節（Scenario）這種以說故事的手法在文章中 自然地來描述需求，也是很重要的表達需求方式。上述的說法，都肯定了結構化 的模型與非結構化的自然語言描述，對於需求的表達都是相當重要的。

利害相關者提出新需求的過程中，包含了登入系統、製作模型、以及補充說

明等三個步驟，其介面如下圖所示。首先，如果利害相關者尚未加入會員，則必 須使用部落格之加入社群功能，輸入基本的電子郵件信箱和密碼等資料，來建立 其社群會員資料，如果已經加入部落格，則直接使用部落格的登入功能來登入系 統。

提議新需求的第二步驟是製作模型，也就是利害相關者可按下圖的「用功能 提議」按鈕，接著選用任一模版，從中選擇主詞、動詞、與受詞，如此一來即可 利用選項來組成簡潔的模型來顯示需求的重點。接著，用部落格的評論功能，輸 入需求模型之外的補充說明。最後，再按下送出按鈕，如果模型和補充說明文字 皆有輸入，即可成功提出新需求，如果模型或補充文字說明沒有輸入，則系統會

提議新需求的第二步驟是製作模型，也就是利害相關者可按下圖的「用功能 提議」按鈕，接著選用任一模版，從中選擇主詞、動詞、與受詞，如此一來即可 利用選項來組成簡潔的模型來顯示需求的重點。接著，用部落格的評論功能，輸 入需求模型之外的補充說明。最後，再按下送出按鈕，如果模型和補充說明文字 皆有輸入，即可成功提出新需求，如果模型或補充文字說明沒有輸入，則系統會