我眼裏的需求版本控制

 

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

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

• 需求文檔的版本

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

• 需求條目的版本

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

• 需求體系的版本

今天，越來越多的公司採用迭代或增量開發模式。爲了降低風險，將開發過程分爲多個增量部分可以加快整個開發過程。那每個階段結束後，是不是要將整個項目的文檔做一個快照呢？通常是需要的，那此時的項目基線也就是我們這裏說的需求體系的版本。需求體系的版本包含自需求而來的多個相關文檔，此時的版本管理不僅應將這些文檔打上統一的基線，並且將該組文檔之間的追蹤關係也進行基線化的管理。對文檔之間的追蹤關係也進行基線化的管理意味着什麼呢？項目的每一個階段，需求文檔會有不同，那需求文檔之間追蹤關係也會有不同。那當我們記錄下項目每個階段的需求文檔及其追蹤關係的版本後，在日後的工作中，我們可以回溯到以前的某個需求版本，並能夠按照當時的項目追蹤關係，追蹤分析當時的分析設計結果，實現對整個需求體系的掌握，能夠更好的理解，利用以至複用已完成的工作成果。