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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

作者簡介


Advertisement

更多 iThome相關內容