建立具體而微的需求模型

在前文中介紹了一些將需求文件化的方式。將需求文件化的基本目的有二：一個是記錄需求、而另一個便是得以進行溝通。因為需求分析人員收集需求資訊並進行分析之後，除了以特定形式記錄做為開發活動的基礎之外，也有助於和有權責確認需求規格的客戶端人員進行確認。

在過去，「文件化」時常會被視為是一種在形式上意義較大的工作。也就是說，開發團隊往往把它當做是一件在開發工作之外的額外負擔，而文件本身對於開發工作沒有太大的幫助，即使需求分析工作的產物——需求規格文件本身可以做為客戶確認規格之用。

近來幾年，對於需求分析工作本身，以及其產物，開始有人給了另一種稱呼，叫做需求建模（Requirement Modeling）。從字面上不難理解，這個稱呼的意思，就是建立需求模型。

我一直很喜歡開發軟體的人們利用「建模（modeling）」，來描述他們在開發系統時所做的分析及設計工作。

分析及設計通常是系統開發各個階段中，先於實作階段的前期工作。為什麼需要這兩個階段的工作？是因為它們可以為即將實作出來的系統，提供具體而微的模型。

將需求轉換為具體形式的另一方法
人們喜歡用建造建築物來比喻建構軟體的過程，這是很好的比喻。

在現實生活中，人們在利用鋼筋、水泥等材料建造一棟大樓之前，總是會先完成繪製設計圖、建立大樓模型的相關工作。這使得人們在真正開始動工建造大樓之前，可以先嘗試了解到即將完成的大樓的外觀及主要特性。

建立模型的作用，就是幫助我們透過一個比較小規模的工程投入，捕捉到系統的主要特性，協助我們評估想像中的系統真正實現之後，究竟可能會是什麼模樣。所建立出來的模型，不僅對工程團隊能夠提供助益，對於客戶檢視未來即將得到的成果，也很有幫助。

有了模型之後，即使模型和真正的成品之間還是有著很大的分別，但是因為模型乃是嘗試著捕捉主要、關鍵的元素，透過更具體的方式來呈現這些元素，使工程團隊和客戶端人員得以將原先只存在腦海中的抽象描述，轉化成為更為具體的形式。

你可以想像一個情境，就是當你打算為自己新家做裝潢設計時，對於日後完成的設計以及施工後的結果，究竟需要滿足那些生活上的需求，一定有著諸般的想法。
所以你會和設計師討論，告訴他需求，以及希望他幫你解決的問題。設計師收集了一條又一條來自於你的需求及想法之後，經過整理、消化、並且分析之後，可能會做出對應的設計，來解決你所提出的問題，同時滿足你的需求。但是，在施工之前，總要讓你確認他所做出來的設計，的確能夠如你想像的那樣解決問題、達成需求，如此得以進行真正的施工。

除了單純的文字之外，要怎麼呈現他所做的設計呢？正如我們所知道的，設計師都會繪製相關的設計圖，讓客戶檢視他所做出來的設計。而有了視覺化的產物之後，客戶自然能夠更輕易的理解，同時，也就可以利用這做為基礎，來進一步的溝通、討論及修正。

我們可以說，室內設計師透過繪製相關的設計圖，等於是一個建模的過程，而設計圖就是他所建立出來的模型。雖然繪製出來的設計圖，距離實際施工完成的成品，還有天差地遠的工程差別，但是，設計圖中已經描繪了主要的設計精神，也讓客戶得以從較為高階、抽象的觀點，來察看未來施工後的結果，究竟長相可能為何，這就是建立模型的重要性以及用處。

一個概念的表達可以有多種方式
另一方面，在建立模型的過程中，透過各種建立模型的不同方法，也引導模型建立者從客戶描述的需求片段中擷取資訊，更有系統性的加以組織，使其得以成為建構系統的元素。例如，室內設計師可能會繪製2D平面配置圖及3D立體設計圖，來描述他所做的設計在平面上的配置方式，以及從立體的方式來看整個室內的情況。

設計師可能一邊考量著客戶的需求，一邊繪製設計配置的圖面，然後同時不斷進行修改及調整，最終得到一個自認是客戶心中想得到的結果。不論是2D平面配置或3D立體設計，其實都是一種建模的方式，它們各自引導設計師，從2D及3D的角度，思考客戶的需求最終可能呈現出來的樣貌。

從室內設計的這個例子我們還可以明白一件事，也就是說，我們可能同時會運用不同的建模方式、從不同的觀察方式，來表達同一個概念。之所以需要利用不同的觀察方式來表達同一個概念，是因為每一種觀察／表達方式下，可以看到／表達的面貌不同，而且，通常也很少有任何一種觀察／表達方式足以獨立地看到／表達完整的面貌。所以，我們需要綜合多種不同的觀察／表達方式，以求表達出更完整的結果。

建模的方式
在軟體的領域之外，其實許多類型的工程，都已經廣泛的運用建模的方式，來表達工程後的產物。建模不僅幫助溝通、記錄、也讓建模人員得以遵循一個既定的模式及方法，來理解、組織客戶的需求。而建立需求模型的方法，同樣可以提供類似的協助。

例如著名的UML，便是一套專門用來建立模型的符號及規則，你也可以運用它來建立使用者需求的模型。需求分析人員可以基於使用者所提出的需求資訊，利用UML中的各種圖示方式，從不同的觀點來描繪系統的長相。例如，你可以運用「使用者案例圖」來表達系統的使用者以及它對系統所做的動作，也可以使用「活動圖」來描述使用者與系統（或其部份）所執行之活動間的流程，還可以使用「順序圖」來表示使用者與系統（或其部份）之間的互動順序、……。

在UML中，不同的建模符號及規則，便是從不同的觀點出發的系統描述方式。針對使用者的需求，我們可以綜合多種UML中的不同圖示方式，來協助我們從不同的面向來理解系統。

透過建模過程來協助分析
對需求分析人員而言，不同的建模方式其實也是現成的分析方法，協助他們從客戶提供的片段資訊中，逐漸的拼湊、建立出一個完整的系統。

例如，建立「使用者案例圖」時，分析人員會思考使用者有那些、存在那些操作的情境、他們又會進行什麼樣的操作。在建立「活動圖」時，又會轉換角度，從流程的方式來進行思考。而在建立「順序圖」時，則又能讓分析人員思考使用者和系統互動的順序性。

換言之，使用者提供的需求資訊是未經整理的素材，而這些建模的方式，則是引導分析人員如何基於這些素材建立出系統。

由此可見，建立需求模型的方法，不僅得以讓需求分析人員運用所建立的模型來做溝通和討論，同時在建立的過程中，也能協助分析人員進行分析。如果你的開發團隊，嘗試著運用這些建模的語言及圖示方法來表示需求，卻只是讓它們淪為形式上的文件，而沒有充份利用建構提供的分析輔助，以及具體化呈現系統面貌的作用，那就實在太可惜了。