當(dāng)開發(fā)人員做了一個(gè)已經(jīng)被取消的功能，你能想想他有多沮喪;當(dāng)測(cè)試人員按照老的測(cè)試案例去測(cè)試新的需求規(guī)格的開發(fā)結(jié)果時(shí)，他可能要抓狂。出現(xiàn)了這些情況，都是因?yàn)樾枨蟮陌姹究刂瞥霈F(xiàn)了問題。
說到需求的版本管理，是不是就是需求文檔放到配置庫就可以了呢?答案是——不僅僅如此。因?yàn)樾枨笥兴奶厥庑?，有它分析和管理的特殊要求，所以在?shí)際的工作中的需求版本我們考慮更多層次：
需求文檔的版本
對(duì)整個(gè)文檔進(jìn)行版本的管理是最基礎(chǔ)的。當(dāng)談及最新版本時(shí)，項(xiàng)目團(tuán)隊(duì)的成員“應(yīng)該”都知道它指的是哪個(gè)版本的文檔，比如說2.1版。應(yīng)該上面加引號(hào)是有用意的，因?yàn)閷?shí)際的情況是每個(gè)人往往都是指向自己的機(jī)器上的文檔版本，以為是最新版本。
需求條目的版本
需求條目的版本是什么意思呢?需求條目的版本表示了對(duì)每個(gè)需求對(duì)象進(jìn)行更細(xì)粒度的控制。需求文檔里面有若干條需求組成，兩個(gè)需求我嫩大版本之間可能是幾個(gè)需求項(xiàng)發(fā)生了變化，有時(shí)候我們需要更清楚的知道某條關(guān)鍵的需求，何人何時(shí)創(chuàng)建，何人何時(shí)做出何種修改，并且能夠知道修改的開始和結(jié)束的狀態(tài)，并且顯示出其中的差異，最好能可以自動(dòng)的回退到某個(gè)歷史狀態(tài)。這些工作中的需求，實(shí)際上都體現(xiàn)了對(duì)需求條目層次上版本管理的要求。
需求體系的版本
今天，越來越多的公司采用迭代或增量開發(fā)模式。為了降低風(fēng)險(xiǎn)，將開發(fā)過程分為多個(gè)增量部分可以加快整個(gè)開發(fā)過程。那每個(gè)階段結(jié)束后，是不是要將整個(gè)項(xiàng)目的文檔做一個(gè)快照呢?通常是需要的，那此時(shí)的項(xiàng)目基線也就是我們這里說的需求體系的版本。需求體系的版本包含自需求而來的多個(gè)相關(guān)文檔，此時(shí)的版本管理不僅應(yīng)將這些文檔打上統(tǒng)一的基線，并且將該組文檔之間的追蹤關(guān)系也進(jìn)行基線化的管理。
對(duì)文檔之間的追蹤關(guān)系也進(jìn)行基線化的管理意味著什么呢?項(xiàng)目的每一個(gè)階段，需求文檔會(huì)有不同，那需求文檔之間追蹤關(guān)系也會(huì)有不同。那當(dāng)我們記錄下項(xiàng)目每個(gè)階段的需求文檔及其追蹤關(guān)系的版本后，在日后的工作中，我們可以回溯到以前的某個(gè)需求版本，并能夠按照當(dāng)時(shí)的項(xiàng)目追蹤關(guān)系，追蹤分析當(dāng)時(shí)的分析設(shè)計(jì)結(jié)果，實(shí)現(xiàn)對(duì)整個(gè)需求體系的掌握，能夠更好的理解，利用以至復(fù)用已完成的工作成果。