將客戶視為合作夥伴的需求分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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