在軟體專案中常見如下的現象：
使用者提出了需求變更，市場人員答應了，開發人員認為工作量太大，不好實現；
軟體專案簽訂了合同，規定了**，在後期的開發過程中，需求變更很多，變更的成本都是乙方承擔，專案結束後發現專案做虧了；
使用者提出了需求的變更，開發人員直接修改軟體，沒有通知相關人員；
使用者張三提出了需求變更，開發人員修改了軟體後，張三又認為不妥當，需要修改回去；
使用者張三提出了需求的變更，開發人員修改了軟體，使用者李四看到了，認為需求不妥，需要修改回去，張三與李四的意見沒有統一；
使用者提出了需求變更後，軟體開發人員只是做了區域性的修改，有的功能漏改了；
等等，上述的現象可以羅列出很多。
這些現象的原因都是由於缺少乙個決策的機構對需求進行管理。在敏捷方法中是通過現場客戶或product owner來實現需求的控制作用，但是這樣的角色需要滿足如下的要求：
collaborative:易於協作
representative:具有代表性
authorized:得到了充分有授權
committed:盡職盡責
knowledgeable:熟悉需求
這種crack型客戶是可遇不可求的，通常情況下，需要乙個團隊來實現上述的要求,這個團隊一般稱為需求控制組。需求控制組是需求決策的機構，他負責對需求進行拍板，確定需求做還是不做，做到什麼程度，開發的順序等。需求控制組可以有哪些人構成呢，可以參見下圖：
成立需求控制組，再定義需求變更的管理流程，則可以實現了對需求變更管理的制度化建設。需求變更管理的目的不是為了不讓需求變更，而是希望需求能夠有序地、一致地變更。
Docker核心技術 控制組
控制組cgroups是 linux 核心的乙個特性，主要用來對共享資源進行隔離 限制 審計等。只有能控制分配到容器的資源，才能避免當多個容器同時執行時的對系統資源的競爭。控制組可以提供對容器到記憶體 cpu 磁碟io等資源進行限制和計費管理 控制組到設計目標是為不同的應用情況提供統一的介面，從控制單...
我眼裡的需求版本控制
當開發人員做了乙個已經被取消的功能，你能想想他有多沮喪 當測試人員按照老的測試案例去測試新的需求規格的開發結果時，他可能要抓狂。出現了這些情況，都是因為需求的版本控制出現了問題。說到需求的版本管理，是不是就是需求文件放到配置庫就可以了呢？答案是 不僅僅如此。因為需求有它的特殊性，有它分析和管理的特殊...
我眼裡的需求版本控制
當開發人員做了乙個已經被取消的功能，你能想想他有多沮喪 當測試人員按照老的測試案例去測試新的需求規格的開發結果時，他可能要抓狂。出現了這些情況，都是因為需求的版本控制出現了問題。需求文件的版本 對整個文件進行版本的管理是最基礎的。當談及最新版本時，專案團隊的成員 應該 都知道它指的是哪個版本的文件，...