需求管理活動的積累材料
變更控制過程變更控制過程能夠減少因無休止、失控的需求變更引起的混亂。它明確了一種方法來提出、協商、評估一個新的需求或在已有需求上的一項變更。變更控制通常需要問題跟蹤工具的支持，但請銘記工具并不能替代過程。
變更控制委員會過程變更控制委員會(CCB)是由風險承擔者的主要成員組成的，對提出的需求變更決定執行哪一項，拒絕哪一項，以及在各產品發行版本中包括哪些變更。CCB過程描述了變更控制委員會的組成及操作過程。CCB的主要活動是對提出的變更進行影響分析，為每項變更作出決定，并且告知那些將受到影響的人。 需求變更影響分析清單和模板估計提出的需求變更的成本費用和影響是決定是否執行變更的重要步驟。影響分析能幫助CCB作出正確的決定。影響分析清單包括許多自問自答型的問題，如：要考慮到可能的任務、邊界影響、實施所確定的變更引起的相關的潛在風險。一張參與人員工作表可以作為估計任務工作量的簡單方法，從這里就能明白確認變更的復雜性。
需求狀態跟蹤過程需求管理包括監控和報告每項功能需求的狀態和狀態改變的條件。你需要一個數據庫或一種商業需求管理工具來跟蹤一個復雜系統中大量的需求狀態。此過程也描述了當你隨時查看收集到的需求狀態時輸出的報告格式。
需求跟蹤能力矩陣模板需求跟蹤能力矩陣列出了SRS中的所有功能需求及相應的設計模塊，源文件和實施需求的過程，還有驗證需求實施正確性的測試用例。跟蹤能力矩陣應該也可以指出對應的上一層用戶需求或系統需求。
需求分析可分為：問題獲�。╡licitation）、分析(analysis)、編寫規格說明（specification）和驗證（verification）四個階段（Thayer and Dorfman 1997）。這些子項包括軟件類產品中需求收集、評價、編寫文檔等所有活動。需求開發活動包括以下幾個方面：
1、確定產品所期望的用戶類。
2、獲取每個用戶類的需求。
3、了解實際用戶任務和目標以及這些任務所支持的業務需求。
4、分析源于用戶的信息以區別用戶任務需求、功能需求、業務規則、質量屬性、建議解決方法和附加信息。
5、將系統級的需求分為幾個子系統，并將需求中的一部份分配給軟件組件。
6、了解相關質量屬性的重要性。
7、商討實施優先級的劃分。
8、將所收集的用戶需求編寫成規格說明和模型。
9、評審需求規格說明，確保對用戶需求達到共同的理解與認識，并在整個開發小組接受說明之前將問題都弄清楚。 需求開發過程的積累材料
1) 項目視圖與范圍模板項目的視圖與范圍文檔明確了項目的概念性功能，并提供了確定需求優先級和變更的參考。需求視圖與范圍文檔是簡明扼要的、高度概括的新項目業務需求說明。用統一的方式編寫項目視圖與范圍文檔能確保在項目進行過程中作決定時能考慮到所有應考慮的情況。
2) 需求開發過程該過程介紹了怎樣確定客戶及從客戶那里獲取需求的技術。也描述了項目。需要創建的各種需求文檔和分析模型。這個過程還指明了每項需求包含的信息種類，比如：優先級、預計的穩定性或計劃發行版本號。同時還應指明需求分析及需求文檔檢驗需要執行的步驟以及確認軟件需求規格說明和建立需求基線的步驟。 3) 需求分配過程把高層的產品需求分成若干特定子系統是非常重要的，尤其是當開發的系統既含有軟件又含有硬件或是包括多個子系統的軟件產品時尤為重要（Nelsen 1990）。需求分配是在系統級需求完成和系統體系結構確定后才進行的，這個過程包含的信息是怎樣執行分配以確保功能分配到合適的系統組件中，同時也說明分配的需求怎樣才能追溯回它們的上兩級系統需求以及在其它子系統中的相關需求。
4) 使用實例模板使用實例模板提供了一種把每項用戶希望使用軟件系統完成的任務編寫成文檔的標準方法。使用實例定義包括一個簡要的任務介紹，必須處理的異常情況的說明和描述用戶任務特點的附加信息。使用實例可作為軟件需求規格說明中一條獨立的功能需求。另外，你也可將使用實例與SRS模板合并為一個文檔，既包括產品的使用實例，又包括軟件功能需求。
5) 軟件需求規格說明模板軟件需求規格說明模板提供了一種組織功能需求和非功能需求的結構化方法。采用標準的SRS模板將有助于創建統一且高質量的需求文檔�？赡芤捎枚鄠�模板以適應組織承擔的不同類型和規模的項目。這樣可減少因一種“萬能”模板并不適合你的項目所帶來的障礙。 6) 需求優先級確定過程，此時為滿足進度時限要求，計劃的功能不得不放棄掉。我們需要知道哪些性能、使用實例或功能需求的優先級最低，以便在任何階段，我們都可適當縮減范圍。
7) SRS和使用實例審查清單對需求文檔的正式審查是保證軟件質量的一項重要措施。審查清單指出在需求文檔中發現的一些錯誤。在審查會議的準備中運用清單將使你的注意力集中到通常存在問題的地方。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
