忽視需求分析的重要性,便不容易收集、分析到更接近客戶真實的需求。一旦在開發過程朝著偏離真實需求面的方向來進行,到了開發中期或後期階段才來導正,只會付出更沉重的代價。

因此,重視需求的收集及分析,是建立對需求正確認識的成功第一步。不過,需求分析也的確是一件困難的工作。這需要客戶端人員及開發團隊成員協同合作,才能發揮最大的效果。而在從事需求分析時,不僅是開發團隊成員會面臨到一些困難,對同樣扮演舉足輕重角色的客戶端人員而言,同樣需要克服一些障礙。在我們討論他們所會遭遇到的困難之前,讓我們依序介紹進行需求分析時各個階段的工作。

在開發專案開始之前,勢必會先定義出專案的最終目標及願景。基本上,專案的目標及願景,是以專案的業主或是負責規畫產品的產品經理所主導,再由需求分析人員協助確定。而所有的需求,便是在這個最終目標及欲達成的願景之下,去逐一展開。所有的需求,都是為了支持達到最終目標及實現願景而存在的。

在定義最終目標及專案的範圍之後,需求分析人員接著便可以以這為基礎,決定需求的提供者。正如前文所提及的,需求的提供者,可能是了解重要需求資訊的人,或者是有權利及責任決定需求規格為何的人。

開始著手進行需求訪談
當決定需求的提供者之後,需求分析人員便可以安排需求訪談的會議,逐一訪談需求資訊的提供者。當然,你可以想像,在完成第一輪的需求訪談會議之後,需求分析人員可能會想增加額外的需求提供者,或者針對已訪談過的需求提供者,做進一步的訪談。因為在第一輪的需求訪談之後,需求分析人員對於實際需求的細節面貌,可能已經有了更深一層的了解,這使得他更有能力找出潛在而且重要的需求提供者,同時判定更需要進一步釐清或確認的需求資訊。

需求的「訪談」,對需求分析人員而言,並不全然是一種接近被動的活動。也就是說,它並不是片面的由需求資訊的提供者,漫無目的、全無章法的將需求資訊傾倒給需求分析人員。需求分析人員在需求訪談會議開始之前,必須針對訪談的範圍,建立訪談的綱要及計畫,才能更有效率地收集到有用的需求資訊。

確認需求本身的性質
一般會將需求分為兩大類,一類是所謂「功能性」的需求,而另一類則為「非功能性」的需求。

功能性需求指的是系統應該具備的能力或是特色,而通常描述功能性需求的方式,便是描述系統與環境互動的方式。這邊所指的環境,可能是操作系統的使用者,也可能是其他的外部系統。也有人將功能性需求稱為「情節(scenario)」,因為在表達功能性需求時,時常會描述一連串環境和系統互動的過程,以及最終系統會有什麼表現。例如,需求的提供者,時常會描述使用者在操作介面上,做了什麼樣一連串的操作,而系統應該要有什麼相對的反應。

而所謂非功能性需求,指的就是功能性以外的需要。例如,可用性(usability)、效能、穩定性、可靠度、等等。這一類的需求時常會被需求提供者所忽略,因為他們通常會將關注的焦點放在系統能夠為他們達成什麼事情,而遺忘了除了功能性的需求之外,非功能性的需求也同樣的重要。

例如,系統的某個功能,應該在同時使用者數到達一個標準時,仍有足夠快的回應時間。此類的非功能性需求,時常在需求分析階段被忽略,但是一旦等到系統進入測試階段或者是上線後,這些非功能性需求的重要性就會浮現,而且被重視。但是,很多時候,到了開發後期甚至是上線之後,才在既有的架構及系統實作之下,試著滿足這些非功能性需求,所需要付出的成本就會多出很多了。

所以,如果只是單方面的接收來自於需求提供者的資訊,往往會流於片面,而且不夠完整。因為他們時常只會將焦點擺在他們最關心的事情上面,而忽略其他同樣重要,或者甚至更為重要的事情。所以說,需求分析者必須扮演更主動的角色,提示、引導需求提供者跳出本身的思路陷阱,進而提供更完整、更全面的需求資訊。有人稱這樣的活動為「誘導需求」。

對需求提供者顯而易見的需求,是比較顯性的需求,透過收集的手段容易得到。但是對於需求提供者來說較於隱性的那些需求,就要倚賴誘導需求的手段了。倘若需求分析者具備足夠的經驗或知識,那麼,對於需求提供者容易忽略的面向,便比較能夠掌握,也易於針對這些部份進行提示。

不論是收集需求或是誘導需求,其目的都是為了要「瞭解需求」。在CMMI ML 2中的需求管理(REQM)流程領域中,針對需求管理提出了幾個實踐準則,其中就包括了「瞭解需求」。

將需求分析的結果轉換為文件內容
在充份瞭解需求之後,需求分析者的工作就是「文件化」所得到、並分析完成的需求。文件化的最大目的是為了溝通,而溝通的對象有二,也就是有權責確認需求的人員及開發團隊內部的成員。

文件化是透過既定格式的文字或是圖示方式,來呈現所分析得到的需求規格。不同的分析方法,會以不同的文件化方式來呈現。

好的文件化方法,可以讓欲溝通的對象更易於了解所表達的內容,而且不容易產生誤解。文件化的方式可以很簡化、也可以更複雜。其中最簡單的方式,可能像極限編程(eXtreme Programming)中利用使用者情節(User Story)的方式來描述。而複雜的方式,可能涉及到完備的文字描述、圖示,甚至是模型的建立。但無論如何,其目的都是要讓閱讀的對象了解需求規格為何。

在文件化動作完成之後,接著便是確認需求的工作。透過具體成型的需求規格文件,便可以讓有權責確認需求的人員進行確認。確認下來的需求,意謂著開發團隊及客戶對即將開發的系統,達成一定的共識,並訂下承諾。有時在需求確認的過程中,會找出需求規格撰寫不正確或不完備的地方,此時,便會重新收集、分析,再度調整文件內容。

在這個階段時常看到一個問題,也就是開發團隊迫不及待地要確認需求。因為對他們來說,一旦客戶確認需求,就等於畫押了。開發團隊的責任僅止於此,超出確認後規格的,便不在責任範圍內。

這種心態時常也會影響到之前的需求收集工作。開發團隊為了縮小開發的範圍,盡可能地想要縮減客戶所提出的需求,所以,針對那些其實是必要、客戶卻沒有提出的需求,也就本著「不告不理」的原則,不予以提醒,更別提要做到誘導需求了。

即使客戶願意確認一份其實不完整的需求規格,但是,到了開發後期或上線、產品化階段,因為這一份需求不夠完整而衍生出來的麻煩及問題,一樣會面臨到。而開發團隊都有責任協助客戶解決。

無論開發團隊是否額外收費與否,客戶為了讓系統可用,勢必補足所缺或不正確的部份。在這樣的情況下,勢必也產生諸多的需求變更請求。而這往往是開發團隊所最不願意見到的。

開發團隊和客戶是協同合作的夥伴關係,客戶得到一個可用的好系統,才是開發團隊的真正勝利。在需求分析的工作中,協助客戶得到一份真正可用的需求規格,會比盡可能降低開發團隊的開發範圍,來得有意義多了。

 

 

作者簡介


Advertisement

更多 iThome相關內容