些過程可能在多個項目中都有用，因為他們反映每個項目所應(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）也并不提倡制作過多的文檔?？刂坪媚愕挠媱潱怪m合你的項目。需求分析人員應(yīng)該專注于需求的獲取和分析，而不是寫出漂亮的文檔。當(dāng)然，如果用戶有這方面的要求的話，你是應(yīng)當(dāng)重視的。
需求管理活動的積累材料
變更控制過程變更控制過程能夠減少因無休止、失控的需求變更引起的混亂。它明確了一種方法來提出、協(xié)商、評估一個新的需求或在已有需求上的一項變更。變更控制通常需要問題跟蹤工具的支持，但請銘記工具并不能替代過程。
變更控制委員會過程變更控制委員會(CCB)是由風(fēng)險承擔(dān)者的主要成員組成的，對提出的需求變更決定執(zhí)行哪一項，拒絕哪一項，以及在各產(chǎn)品發(fā)行版本中包括哪些變更。CCB過程描述了變更控制委員會的組成及操作過程。CCB的主要活動是對提出的變更進行影響分析，為每項變更作出決定，并且告知那些將受到影響的人。 需求變更影響分析清單和模板估計提出的需求變更的成本費用和影響是決定是否執(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)需求。
需求分析
需求分析可分為：問題獲?。╡licitation）、分析(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、將所收集的