我眼里的需求版本控制

關鍵字：需求     當開發人員做了一個已經被取消的功能，你能想想他有多沮喪；當測試人員按照老的測試案例去測試新的需求規格的開發結果時，他可能要抓狂。出現了這些情況，都是因為需求的版本控制出現了問題。

        說到需求的版本管理，是不是就是需求文檔放到配置庫就可以了呢？答案是——不僅僅如此。因為需求有它的特殊性，有它分析和管理的特殊要求，所以在實際的工作中的需求版本我們考慮更多層次：

需求文檔的版本

        對整個文檔進行版本的管理是最基礎的。當談及最新版本時，項目團隊的成員“應該”都知道它指的是哪個版本的文檔，比如說2.1版。應該上面加引號是有用意的，因為實際的情況是每個人往往都是指向自己的機器上的文檔版本，以為是最新版本。

需求條目的版本

        需求條目的版本是什么意思呢？需求條目的版本表示了對每個需求對象進行更細粒度的控制。需求文檔里面有若干條需求組成，兩個需求我嫩大版本之間可能是幾個需求項發生了變化，有時候我們需要更清楚的知道某條關鍵的需求，何人何時創建，何人何時做出何種修改，并且能夠知道修改的開始和結束的狀態，并且顯示出其中的差異，最好能可以自動的回退到某個歷史狀態。這些工作中的需求，實際上都體現了對需求條目層次上版本管理的要求。

需求體系的版本

        今天，越來越多的公司采用迭代或增量開發模式。為了降低風險，將開發過程分為多個增量部分可以加快整個開發過程。那每個階段結束后，是不是要將整個項目的文檔做一個快照呢？通常是需要的，那此時的項目基線也就是我們這里說的需求體系的版本。需求體系的版本包含自需求而來的多個相關文檔，此時的版本管理不僅應將這些文檔打上統一的基線，并且將該組文檔之間的追蹤關系也進行基線化的管理。

        對文檔之間的追蹤關系也進行基線化的管理意味著什么呢？項目的每一個階段，需求文檔會有不同，那需求文檔之間追蹤關系也會有不同。那當我們記錄下項目每個階段的需求文檔及其追蹤關系的版本后，在日后的工作中，我們可以回溯到以前的某個需求版本，并能夠按照當時的項目追蹤關系，追蹤分析當時的分析設計結果，實現對整個需求體系的掌握，能夠更好的理解，利用以至復用已完成的工作成果。

原文轉自：http://www.anti-gravitydesign.com