如何記錄需求，看清系統真實面貌

有些時候，在需求分析時，客戶端的人員會有試著加入更多需求的傾向。有些客戶總是覺得系統功能愈多愈好、系統設計愈彈性愈好，但完全沒有考慮到，這些多出來的功能以及彈性，是不是使用者真正需要的。

不是真正需要的功能和彈性，對系統而言，就不是真正的需求。相反的，至於開發團隊，在需求分析階段，則時常有試著削減需求的情況。因為，需求愈少，需要投入在開發的努力也就愈少。但是，倘若把的確需要的需求從規格中予以削減，那麼所得到的需求也不是真正的需求。

對一份需求規格而言，不論是額外多了、或者少掉了必要的東西，都不能算是真正的需求。倘若開發額外且實際上不需要的需求，那麼等於浪費開發成本，也讓系統變得更複雜（可能意謂著更容易出錯、更不易維護以及效能較慢）。

倘若真能在開發階段，說服或誘導客戶削減其實是必要的需求，以減少開發的成本，但在準備上線或上線之後，客戶仍然會發現或感受到真正的需要。此時，若不是發出需求變更的請求，要求開發團隊進行修改，就是不能百分之百發揮這系統的用處，或者甚至無法派上用場。

耗費諸多心力及成本開發出來的系統不能使用，無論對客戶或對開發團隊而言，都不是一件好事。而因應需求變更而衍生出來的修改，所付出的代價，也勢必超出在一開始就將其納入需求規格而開發的情況。

因此，在需求分析階段中，雙方都認同共同的目標是找出真正的需求，是很重要的一件事。客戶多要到了一些不需要的功能，或開發團隊躲掉、閃掉了一些必備的功能，都只會讓雙方距離逼近真正的需求，愈來愈遠。

有了找出真正需求為前提的共識，需求分析的工作，才算是有了良好的基礎。

將收集到的需求轉換成規格文件
在前文中提到，需求分析的前期主要工作，是進行需求的訪談，以及需求資訊的收集。需求分析人員可藉此得到諸多的需求資訊，但是它們通常只是原始、結構性不強的資訊。在得到這些資訊之後，需求分析人員的工作自然是進行分析、整理，以便得到可文件化的需求規格文件。

對需求規格進行文件化的工作是相當重要的，首先，它是需求分析人員和客戶端需求資訊提供者，以及有權責確認需求規格的人員溝通媒介。當需求資訊收集的工作完成後，需求分析人員依據自己的理解以及分析的結果，以書面的方式呈現。那麼，客戶端的人員才有一個基礎，可以檢視需求分析人員的理解及分析的結果，是否和他們的認知相符。之後的討論及修改，便可以立足在這個基礎上去進行。

要如何文件化需求規格呢？有些人可能會以像撰寫合約的方式，來撰寫需求規格。也是說，基本上是把收集來的需求規格資訊經過整理後，以條列式的做法，寫成一份需求清單。通常，在這份需求清單中的每一個條目，都描述系統應該具有的功能或特性。

這樣子來呈現需求資訊的好處是，它是對收集得來之需求資訊的最原始記錄，完全以清單的方式來呈現需求，同時，也可以做為客戶和開發團隊之間的協議，甚至是合約中代表規格的一部份。

這樣子來呈現需求規格，即使很容易在事後檢驗系統是否滿足規格，但是，對於建構系統的工作無法提供太多的幫助。因為，很少有人可以憑藉著閱讀平鋪直述的需求描述來建立起對系統的整體了解。這些需求描述中的每一則，都只是描述系統的一個片段，而一個足夠大的系統，可能是由數以千計的片段所組成的。

在這種情況下，閱讀者必須自行組織，並且嘗試著在腦中利用這些片段及本身的理解，拼湊出所認知的系統全貌。這樣不僅難以理解，而且，更重要的是，為了拼湊出系統全貌，閱讀者所加入自身的理解，往往構成認知上的歧異。

也就是說，同一份清單，可能因為理解的人不同，而衍生出不同的系統樣貌。更重要的是，在遵循同一份需求清單的情況下，彼此所認知的，卻是兩個相異的系統。

透過建立原型系統的方式呈現需求
條列式的需求清單記錄方式，或許是最早的需求規格文件化的方式。然而，人們在察覺到這種方式所會遭遇到的困難及障礙之後，自然會繼續努力開發新的方法，例如利用建立原型（prototype）系統的方法。

而在軟體開發中，所謂的原型系統，便是藉由較小的開發規模，盡可能呈現完整系統中關鍵重要的面貌。

開發團隊依據需求收集所得的資訊，以及對這些資訊的理解，投入些許的時間，開發出原型系統。接著便可以藉由這個原型系統，讓客戶端的人員看到一個具體呈現的系統，檢視雙方對於系統的認知，是否相同或是存在歧異。

建立原型系統的方法，應用於需求分析階段，主要是將系統的主要功能及介面，以視覺化的方式呈現給客戶。

因為客戶最能感受到的，便是具體存在的視覺感受，從使用者介面的角度來著手，客戶可以實際體驗到系統中將會有什麼功能，以及使用者是透過如何的方式來操作各個功能。

現在很多網站的開發者，在需求資訊收集到一個段落後，便會嘗試著建立靜態、但彼此間可串連的HTML頁面做為原型系統，而這便可以做為和客戶溝通的基礎。當客戶實際體驗並操作這原型系統後，便可以了解開發團隊對於需求的理解為何，是否和客戶想像中的系統有所落差。也能夠明白，究竟需要如何修改才能填補這中間的落差。

這就是「眼見為憑」的威力。人們在實際看到一個原型系統後，對於系統全貌立即能有一個清晰又具體的了解。

除了拿來溝通有很好的效果之外，建立原型系統時所得到的使用者介面，也能夠輕易在不修改或稍加修改的情況下沿用到實作階段。只不過，有時候建立原型系統時，因為時效的關係，難免以急就章的方式來處理。若是直接沿用到正式的系統，難免影響到正式系統的品質。

此外，原型系統通常都將焦點放在視覺化的使用者介面上，它可以做為輔助了解系統需求的一個工具，但是無法用來嚴謹的表示需求規格的全貌。因此，仍然必須搭配其他的需求規格表示方式。

其他記錄需求的方法
人們持續發現需求分析及記錄溝通的重要性，因此，也持續研究、開發新的方法。

例如，從1990年代起，開始流行的使用者案例（Use Case）的需求記錄方式。每一則使用者案例，主要是描述外部執行者（例如使用者或外部系統）如何透過和系統的互動（資訊交換），進而完成單一特定的工作。

此外，不同的開發方法可能會搭配不同的需求記錄方式。例如，強調使用者駐點、持續整合的敏捷開發方法，就利用天生的優點，只採使用者腳本（user story）的方式來記錄需求。

搭配所採用的開發方法，適當的選取需求記錄的方式，讓開發團隊及客戶彼此盡可能地降低誤解，提高對系統的認識，有助於更逼近真正的需求，而日後所衍生出來對雙方造成的困擾及負擔，也才能免除。