這篇博文的標題是一個疑問句。在回答這個問題之前，首先應該想到的是：提出這個問題，實際上已經先認定了
需求管理工具是必要的。那么，需求管理工具是否真的必要呢？
這里的“需求”不是個抽象概念，它指的是需求分析文檔、需求規格說明文檔這樣的需求分析成果；需求管理就是對這些成果（包括中間成果）的管理。從這個角度來看，需求管理工具是必要的，至少在絕大多數情況下是這樣。根據經驗，我至少能夠列出以下兩個理由：
1、在絕大多數情況下，需求是復雜的。
2、在絕大多數情況下，需求是變化的。
需求分析過程往往是這樣的：從用戶關于系統的一些模糊的、頂層的概念和想法出發，不斷地進行明確和分解，形成數量眾多的需求條目，直到最終成為可以指導開發的用例。隨著這一過程的進行，當程序員因為需求越來越清晰而備受鼓舞時，不幸的項目經理卻很可能陷入苦惱中：這么多條需求，誰知道是否有遺漏呢？誰知道這些條目之間是否有很緊密的關聯呢？如果需求條目比較少，或許項目經理還能夠在腦子里把這些問題理清楚；但是如果條目很多，誰又能保證不出錯呢？
需求的變化有多種來源：有可能用戶的想法發生了改變；有可能用戶的想法并沒有變，但一開始他沒有說清楚，或者我們的理解有誤；實際上，需求分解本身就意味著我們對需求的認識在不斷地深入和細化。
所以我們可以借助工具管理好需求，以結構化的形式（例如樹形圖、表格等）來組織需求條目，讓項目經理能夠比較方便地查看、追蹤、回溯需求分解，理解需求條目之間的關系。
所以我們可以借助工具管理好需求，不但要能夠很方便地進行“增刪查改”，最好還能像代碼版本控制那樣，對需求分析的成果也能進行版本控制。
事實上，在行為驅動開發（Behavior Driven Development, BDD）或者驗收
測試驅動開發（Acceptance Test Driven Development, ATDD）中，需求與驗收測試代碼最終合二為一，即所謂specification by example。所以對需求進行管理，就像對代碼進行管理一樣，是非常自然的事情。
那么，什么樣的需求應該被工具管理起來呢？
我們可以把需求分為三類：
1、功能需求：即系統應當提供哪些功能，例如“支持在用戶登錄時進行用戶身份認證”；
2、性能需求：即性能方面的指標，例如“當用戶登錄請求并發數不大于200時，身份認證處理時延不大于3秒”；
3、特性：對某項功能實現的方式、界面、操作步驟、外觀、接口等進行規定的需求，例如“服務器與客戶端之間的消息傳輸采用HTTP協議”。
性能需求會對系統技術路線的選擇、架構設計等產生直接的影響，但是通常不易被分解為更細的條目；特性往往會體現在某項功能的實現方式或呈現形式上，通常我們都是把功能需求進行分解，并且在分解時注意把相應的特性包括進去。因此，實際上需求管理工具首先應該管理的是功能需求。
所以，為了較好地支持BDD或者ATDD，我覺得需求管理工具至少應該具有以下功能：
一、能夠以樹形圖或表格的方式瀏覽所有需求條目。以下以樹形圖為例進行說明：
1、樹形圖具有唯一的根節點，就是“系統功能需求”，根節點以下可以有任意多層分支節點；
2、每個節點是一個需求條目，具有編號、名稱、說明3項內容；
3、采用多級編號，編號能夠體現需求條目之間的邏輯關系；
4、如果系統包括多個子系統（例如多個軟件），那么第1層分支節點是系統功能，從第2層分支節點開始是子系統功能，即第1層分支節點只把系統功能需求進行分解，不按子系統分解；從第2層分支節點開始，按子系統進行分解，第2層分支節點應注明是“客戶端xxx功能”還是“服務器xxx功能”；
5、最末端的分支節點（即葉子節點）采用BDD驗收測試代碼的feature文件的形式（例如cucumber的feature文件）；
6、每個節點可以展開（顯示子節點）和收攏（不顯示子節點）。
樹形圖如下圖所示：
系統功能需求--+--1.用戶登錄--+--CLIT.1.1客戶端登錄界面 + + + +--SERV.1.1服務器身份認證 + + + +--SERV.1.2服務器維護用戶登錄會話狀態 + +--2.XXXX--+--CLIT.2.1XXXX--+--CLIT2.1.1XXXX + + + + +--CLIT.2.2XXXX +--CLIT2.1.2XXXX + + + +--SERV.2.1XXXX + + + +--SERV.2.2XXXX--+--SERV2.2.1XXXX--+--SERV2.2.1.1XXXX + + + + +--SERV2.2.2XXXX +--SERV2.2.1.2XXXX + + + +--SERV2.2.3XXXX +--3.XXXX |
二、對每個節點可以進行以下操作：
1、通常的操作有：編輯、添加下級分支節點、添加葉子節點、改變上級節點（從而可以改變節點之間的邏輯關系）；
2、如果已經是葉子節點，則不能再添加下級。
三、能夠把所有葉子節點導出為feature文件，這些feature文件可以直接在測試代碼中使用。
1、每個葉子節點是一個單獨的feature文件；
2、feature文件分目錄存放，目錄結構與樹形圖的分層結構一致。
四、能夠把所有節點導出為一個文本文件，文本文件的章節結構與樹形圖的分層結構一致。