需求之後設模型與知識本體

為了能結構化地表示需求模型，使得自動偵測衝突得以可能，就必須提出一 套需求的後設模型（meta-model）。後設模型可視為一個有很多空格的框架，而 各類型的概念可以被塞進這個框架中。根據哲學詮釋學所揭示的人類世界本質，

人類所處的世界是一種工具的世界，人在世上總是會使用工具來進行活動，所以 引伸到需求上來說，可說是人所扮演的某種角色，總是會使用系統的某種功能來 協助某個活動的進行。而人的歷史經驗存在記憶中，總會發揮指引和限制的效 用，而影響人們對於未來的籌劃（Gadamer，1989）。

另一方面，統一塑模語言（Unified Modeling Language，UML）的使用案例 圖（Use Case Diagram）也不謀而合地揭露了各種角色都會與涉及某些系統的使 用案例，然而由於使用案例圖的表達仍不夠詳細，因此本研究根據哲學詮釋學與 使用案例圖來加以延伸，而提出了一個用於表達需求的後設模型，如圖11 所示。

圖 11 用於表達需求的後設模型

發展本後設模型的理由，是因為本需求模型是用於一般使用者與開發者之間 的溝通。雖然 UML 中的使用案例圖已經可以用於一般使用者與開發者間的溝

通，然而該模型又過度簡易，用橢圓型內的文字就概略描述了系統的功能。然而 使用UML 其他幾種圖形，對於一般非專業使用者又是相當困難的。所以，有需 要將系統功能的描述進一步分解為更詳細的小部分。此外，使用案例圖並沒有去 解釋系統功能之所以需要存在其背後的理由，也就是系統功能所需達到的目的。

而使用案例圖也沒有揭露系統功能之所以如此設計其背後所依循的假設。根據上 述三個理由，使得本研究根據了使用案例圖，以及哲學詮釋學對工具世界的看 法，來進一步地將使用者需求的表達加以細緻化並延伸。

這個後設模型主要有兩大部分，功能區和背景區，用來呈現資訊系統的需 求。功能區包含了角色、功能、活動、資料等四種概念，以及使用、支援、與操 作等三類型的關係，也就是說，功能區主要是去表達何種角色使用了某個功能來 支援某項活動並操作某些資料。在概念方面，角色就是指使用案例圖裡的行動者

（actor），功能是哲學詮釋學中所說的工具，也就是軟體系統或子系統。而活動 與資料通常組成了使用案例圖中的橢圓形之使用案例名稱，活動可說是功能所用 以支援的任務，而資料是指系統功能所輸出與輸入的訊息。在關係方面，使用、

支援、與操作等三種關係將上述四種概念聯繫起來形成一個對需求的敘述，這種 關係也就是類似E-R 模型中的 Relationship 的觀念，或說是句子中主詞與受詞之 間的動詞的觀念，例如：會員使用結帳功能。值得注意的是，限制意味的需求常 常隱藏在需求與系統的設計中，這些需求則是用關係的反義詞（不可使用、不可 支援、及不可操作）來進行有效地描述，例如：非會員不可使用結帳功能。

背景區包含了目標與假設兩種概念，以及達成與遵循兩種關係，來描述功能 區的背景脈絡。在UML 中已經指出，活動通常有其能進行的先決條件或背景脈 絡（Fowler 與 Scott，2003），而更進一步地闡釋，背景可分為目標與假設兩個部 分。一個活動之所以存在，是因為背後往往有其想達成的目的，例如：信用卡線 上付款活動存在的目的，是在於便於收付款之目的。而一個活動的進行方式，往 往也受到背後的假設所左右，例如：銷售活動之所以要包含印製發票的任務，是 為了要符合政府稅法的假設。達成與遵循等兩種關係則將活動與其背後的目標與

假設聯繫起來，而此兩種關係的反義詞，像是不可達成與不可遵循，也可用來描 述需求，例如：網站的使用不可達成營利目的。

知識本體可用來提供一組結構化的分享的詞彙與關係來描述需求或資訊系 統的設計，而這些詞彙可用來塞進後設模型這樣的框架中，需求模型裡的詞彙皆 可對應到知識本體中的概念。也就是說，利害相關者可以從知識本體中選出適當 的詞彙來填入需求模型，如果找不到適當的詞彙，亦可自行輸入新的詞彙，而新 的詞彙需由管理者來加入知識本體中。知識本體包含如下六種概念，而知識本體 中概念間的關係則包含了種類（is a）、部分（part of）、以及同義詞的關係。

1. 角色知識本體：在商業環境中，角色是涵蓋各種不同階層與不同專長的組織 單元，例如：公司可能會包含部門與專案小組等群組，而群組是由不同的職 位所組成。又例如：網站使用者可能包含了會員與非會員兩種類型。而對於 同一種角色，也許會有不同的名稱去指稱之，而存在有指向同一角色的多個 同義詞。

2. 功能知識本體：這個知識本體是去描述軟體是由哪些功能所組成。一般而 言，軟體系統是由多種類型的組件所組成，像是子系統、模組、網站的商業 邏輯、元件、類別等，舉例來說，線上購物網站通常包含了商品型錄管理、

會員管理、以及交易管理等功能。除此之外，而這些組件之間可有著繼承的 關係，或稱為種類的關係，像是某類別繼承自其母類別。

3. 活動知識本體：此知識本體描述了系統的利害相關者其所從事的重要活動。

一個活動常常包含了數個小活動，例如購物活動包含了瀏覽商品、更新購物 車、以及付款活動。此外，在活動概念與功能概念之間的關係方面，而一個 活動往往會由一個或多個功能所支援，反過來說，一個功能也可去支援一個 或多個活動。

4. 資料知識本體：在資訊系統中，功能總是涉及了對資料的操作。功能與資料 之間的操作關係上，可分為輸入、儲存、與輸出等三種關係。而資料的知識 本體中資料概念之間的關係，可分為組成與類型關係，例如，送貨資料是由

收貨人姓名、電話、以及住址所組成，而個人資料可分為公開個人資料與非 公開資料兩種。

5. 目標知識本體：一個活動之所以存在，往往是因為背後有其欲達成的目標。

而目標知識本體就是用來儲存目標、並標示出大大小小目標之間的關連性。

不同的人往往有著不同的目標，舉例來說，一間公司通常會有幾個全公司都 認同的大目標，像是獲利與增加營業額。但是該公司的各部門則除了認同此 大目標外，主要還是要去達成該群組所認同之大目標底下的各項小目標，像 是系統開發小組需要邁向系統成功的目標。而在群組底下，則分工更為細 緻，各種職位有其各自所要發揮的特長與其應達成的目標，例如業務員需衝 業績，而業務主管則主要責任在於管控並設計制度激勵業務員。

6. 假設知識本體：活動的背後除了有其欲達成的目標之外，往往有許多不言自 明的假設去引導著或限制著活動的進行方式假設，也就是一種被人們所信奉 的價值觀或習以為常的觀念，像是組織文化、市場潮流、政府政策、法規、

組織策略、組織管控規範、標準作業程序等。而系統功能在設計上也必須符 合假設，才能有效地支援活動。

藉由上述所提議的後設模型與知識本體，需求模型變得能以結構化的方式呈 現，而對於需求模型中所指涉的諸多概念，其概念間的關係也能夠非常清楚。之 所以做了後設模型和知識本體的準備工作，就是為了要使智慧型工具能夠自動地 偵測需求模型與現有設計之間的衝突。下一節中，就要繼續闡述所發展工具之相 關功能、與衝突偵測運作的方式。