些過程可能在多個項目中都有用，因為他們反映每個項目所應(yīng)遵循的公共功能。
需求控制的工具有很多，你可以使用專業(yè)的Rational公司的RequisistPro，也可以使用一些可視化的數(shù)據(jù)庫管理工具，甚至你可以只是使用目錄結(jié)構(gòu)。用什么樣的工具并不是特別重要，關(guān)鍵還是在于人。上面已經(jīng)說過，需求的管理最重要的（關(guān)鍵過程域）就是版本控制和變更管理。這兩個方面是密切相關(guān)的。需要版本控制的一個重要因素就是需求在不斷的變化。
文檔的海洋
雖然到現(xiàn)在還沒有提到任何的具體文檔，但是需求過程的產(chǎn)品中大都是文檔。文檔的產(chǎn)生目的是為了項目能夠被控制。如果為了實現(xiàn)控制項目的目的，而文檔卻陷入了不可控制的境地，那就是一條歧途了。想象起來是很可笑，但是這個錯誤是確實存在的。往往有一些狂熱的技術(shù)分子，為了追求完美的實施項目管理，實施了過多的文檔，可是這個項目本身并沒有想象的那么龐大。到了最后，是由于文檔的失控導(dǎo)致了項目的失控。即便是以完善著稱的RUP（Rational Unifined Process）也并不提倡制作過多的文檔。控制好你的計劃，使之適合你的項目。需求分析人員應(yīng)該專注于需求的獲取和分析，而不是寫出漂亮的文檔。當(dāng)然，如果用戶有這方面的要求的話，你是應(yīng)當(dāng)重視的。
需求管理活動的積累材料
變更控制過程變更控制過程能夠減少因無休止、失控的需求變更引起的混亂。它明確了一種方法來提出、協(xié)商、評估一個新的需求或在已有需求上的一項變更。變更控制通常需要問題跟蹤工具的支持，但請銘記工具并不能替代過程。
變更控制委員會過程變更控制委員會(CCB)是由風(fēng)險承擔(dān)者的主要成員組成的，對提出的需求變更決定執(zhí)行哪一項，拒絕哪一項，以及在各產(chǎn)品發(fā)行版本中包括哪些變更。CCB過程描述了變更控制委員會的組成及操作過程。CCB的主要活動是對提出的變更進(jìn)行影響分析，為每項變更作出決定，并且告知那些將受到影響的人。 需求變更影響分析清單和模板估計提出的需求變更的成本費(fèi)用和影響是決定是否執(zhí)行變更的重要步驟。影響分析能幫助CCB作出正確的決定。影響分析清單包括許多自問自答型的問題，如：要考慮到可能的任務(wù)、邊界影響、實施所確定的變更引起的相關(guān)的潛在風(fēng)險。一張參與人員工作表可以作為估計任務(wù)工作量的簡單方法，從這里就能明白確認(rèn)變更的復(fù)雜性。
需求狀態(tài)跟蹤過程需求管理包括監(jiān)控和報告每項功能需求的狀態(tài)和狀態(tài)改變的條件。你需要一個數(shù)據(jù)庫或一種商業(yè)需求管理工具來跟蹤一個復(fù)雜系統(tǒng)中大量的需求狀態(tài)。此過程也描述了當(dāng)你隨時查看收集到的需求狀態(tài)時輸出的報告格式。
需求跟蹤能力矩陣模板需求跟蹤能力矩陣列出了SRS中的所有功能需求及相應(yīng)的設(shè)計模塊，源文件和實施需求的過程，還有驗證需求實施正確性的測試用例。跟蹤能力矩陣應(yīng)該也可以指出對應(yīng)的上一層用戶需求或系統(tǒng)需求。
需求分析
需求分析可分為：問題獲取（elicitation）、分析(analysis)、編寫規(guī)格說明（specification）和驗證（verification）四個階段（Thayer and Dorfman 1997）。這些子項包括軟件類產(chǎn)品中需求收集、評價、編寫文檔等所有活動。需求開發(fā)活動包括以下幾個方面：
1、確定產(chǎn)品所期望的用戶類。
2、獲取每個用戶類的需求。
3、了解實際用戶任務(wù)和目標(biāo)以及這些任務(wù)所支持的業(yè)務(wù)需求。
4、分析源于用戶的信息以區(qū)別用戶任務(wù)需求、功能需求、業(yè)務(wù)規(guī)則、質(zhì)量屬性、建議解決方法和附加信息。
5、將系統(tǒng)級的需求分為幾個子系統(tǒng)，并將需求中的一部份分配給軟件組件。
6、了解相關(guān)質(zhì)量屬性的重要性。
7、商討實施優(yōu)先級的劃分。
8、將所收集的