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