1.需求跟蹤
需求跟蹤包括編制每個需求同系統元素之間的聯絡文件。這些元素包括別的需求、體系結構、其他設計部件、源**模組、測試、幫助檔案、文件等。跟蹤能力資訊使變更影響分析十分便利，有利於確認和評估實現某個建議的需求變更所必須的工作。
2.需求跟蹤目的
需求跟蹤提供了乙個表明與合同或說明一致的方法，需求跟蹤可以改善產品質量，降低維護成本，而且很容易實現重用。需求跟蹤是個要求手工操作且勞動強度很大的任務，要求組織提供支援。隨著系統開發的進行和維護的執行，要保持關聯鏈資訊與實際一致。跟蹤能力資訊一旦過時，可能再也不會重建它了。由於這些原因，應該正確使用需求跟蹤能力。下面是在專案中使用需求跟蹤能力的一些好處：
（1）審核跟蹤能力資訊可以幫助審核確保所有需求被應用。
（2）變更影響分析跟蹤能力資訊在增、刪、改需求時可以確保不忽略每個受到影響的系統元素。
（3）維護可靠的跟蹤能力資訊使得維護時能正確、完整地實施變更，從而提高生產率。要是一下子不能為整個系統建立跟蹤能力資訊，一次可以只建立一部分，再逐漸增加。從系統的一部分著手建立，先列表需求，然後記錄跟蹤能力鏈，再逐漸拓展。
（4）專案跟蹤在開發中，認真記錄跟蹤能力資料，就可以獲得計畫功能當前實現狀態的記錄。還未出現的聯絡鏈意味著沒有相應的產品部件。
（5）再設計（重新建造）
你可以列出傳統系統中將要替換的功能，記錄它們在新系統的需求和軟體元件中的位置。通過定義跟蹤能力資訊鏈提供一種方法收集從乙個現成系統的反向工程中所學到的方法。
（6）重複利用跟蹤資訊可以幫助你在新系統中對相同的功能利用舊系統相關資源。例如：功能設計、相關需求、**、測試等。
（7）減小風險使部件互連關係文件化可減少由於一名關鍵成員離開專案帶來的風險。
（8）測試測試模組、需求、**段之間的聯絡鏈可以在測試出錯時指出最可能有問題的**段。
以上所述許多是長期利益，減少了整個產品生存期費用，但同時要注意到由於積累和管理跟蹤能力資訊增加了開發成本。這個問題應該這樣來看，把增加的費用當作一項投資，這筆投資可以使你發布令人滿意同時更容易維護的產品。儘管很難計算，但這筆投資在每一次修改、擴充套件或代替產品時都會有所體現。如果在開發工程中收集資訊，定義跟蹤能力聯絡鏈一點也不難，但要在整個系統完成後再實施代價確實很大。
cmmi要求具備需求跟蹤能力。軟體產品工程活動的關鍵過程域有關於它的陳述，「在軟體工作產品之間，維護一致性。工作產品包括軟體計畫，過程描述，分配需求，軟體需求，軟體設計，**，測試計畫，以及測試過程。」需求跟蹤過程中還定義了一些關於乙個組織如何處理需求跟蹤能力的期望。
3.需求跟蹤的內容
跟蹤能力（聯絡）鏈使你能跟蹤乙個需求使用期限的全過程，即從需求源到實現的前後生存期。跟蹤能力是優秀需求規格說明書的乙個特徵。為了實現可跟蹤能力，必須統一地標識出每乙個需求，以便能明確地進行查閱。
圖說明了四類需求跟蹤能力鏈。客戶需求可向前追溯到需求，這樣就能區分出開發過程中或開發結束後由於需求變更受到影響的需求。這也確保了需求規格說明書包括所有客戶需求。同樣，可以從需求回溯相應的客戶需求，確認每個軟體需求的源頭。如果用使用例項的形式
來描述客戶需求，圖上半部分就是使用實 例和功能性需求之間的跟蹤情況。圖的下半部分指出：由於開發過程中系統需求轉變為軟體
需求、設計、編寫等，所以通過定義單個需求和特定的產品元素之間的（聯絡）鏈可從需求向前追溯。這種聯絡鏈使你知道每個需求對應的產品部件，從而確保產品部件滿足每個需求。第四類聯絡鏈是從產品部件回溯到需求，使你知道每個部件存在的原因。絕大多數專案不包括與使用者需求直接相關的**，但對於開發者卻要知道為什麼寫這一行**。如果不能把設計元素、**段
或測試回溯到乙個需求，你可能有乙個「畫蛇添
足的程式」。然而，若這些孤立的元素表明了乙個正當的功能，則說明需求規格說明書漏掉了一項需求。
跟蹤能力聯絡鏈記錄了單個需求之間的父層、互連、依賴的關係。當某個需求變更（被刪除或修改）後，這種資訊能夠確保正確的變更傳播，並將相應的任務作出正確的調整。乙個專案不必擁有所有種類的跟蹤能力聯絡鏈，要根據具體的情況調整。
4.四類需求跟蹤能力鏈
（1）從專案目標追溯到需求。從專案目標可追溯到需求,這樣就能區分出開發過程中或開發結束後由於需求變更受到影晌的需求。這也確保了需求規格說明書包括所有專案目標。
（2）從需求回溯專案目標。從需求回溯相應的專案目標,確認每個軟體需求的源頭。如果用使用例項的形式來描述專案目標,就是使用例項和功能性需求之間的跟蹤情況。
（3）從需求追溯產品。由於開發過程中系統需求轉變為軟體需求、設計、**等,所以通過定義單個需求和特定的產品元素之間的聯絡鏈可從需求向前追溯.這種聯絡鏈使你知道每個需求對應的產品部件,從而確保產品部件滿足每個需求。
（4）從產品回溯到需求。從產品部件回溯到需求,使你知道每個部件存在的原因。
絕大多數專案不包括與使用者需求直接相關的**,但對於開發者卻要知道為什麼寫這一行**。如果不能把設計元素、**段或測試回溯到乙個需求,你可能有乙個「畫蛇添足的程式」。
然而,若這些孤立的元素表明了乙個正當的功能,則說明需求規格說明書漏掉了一項需求。
5.需求跟蹤矩陣
需求跟蹤矩陣是把產品需求從其**連線到能滿足需求的可交付成果的一種**。使用需求跟蹤矩陣，可以把每個需求與業務目標或專案目標聯絡起來，有助於確保每個需求都具有商業價值。需求跟蹤矩陣提供了在整個專案生命週期中跟蹤需求的一種方法，有助於確保需求檔案中被批准的每項需求在專案結束的時候都能交付。最後，需求跟蹤矩陣還為管理產品範圍變更提供了框架。
需求跟蹤包括（但不限於）跟蹤以下內容：業務需要、機會、目的和目標；專案目標；專案範圍/
wbs可交付成果；產品設計；產品開發；測試策略和測試場景；高層級需求到詳細需求。
應在需求跟蹤矩陣中記錄每個需求的相關屬性。這些屬性有助於明確每個需求的關鍵資訊。需求跟蹤矩陣中記錄的典型屬性包括唯一標識、需求的文字描述、收錄該需求的理由、所有者、**、優先級別、版本、當前狀態（如活躍中、已取消、已推遲、新增加、已批准、被分配和已完成）和狀態日期。為確保干係人滿意，可能需要增加一些補充屬性，如穩定性、複雜性和驗收標準。
需求跟蹤矩陣連線了需求與需求源，用於在整個專案生命週期中對需求進行跟蹤。需求跟蹤矩陣有助於發現任何變更或對範圍基準的任何偏離給專案目標所造成的影響。
更多知識點請在應用寶找簡練，專案忙還想過軟考，您需要簡練！
簡練網軟考知識點整理 專案基線
1.基線 基線是軟體工程活動從乙個環節轉入另外乙個環節時對階段產品或元件的標識。因為軟體規模的膨脹和分工的細化，軟體開發過程變得越來越複雜，每個階段可能由不同型別的角色和人員來完成，因此有必要清晰標識上一階段完成的成果和下階段開始工作的基礎。這種標識活動就是建立基線。根據同行評審或階段評審的結果建立...
簡練網軟考知識點整理 需求管理及需求工程
需求，是由專案接受的或專案產生的產品和產品構件需求，包括由組織徵集的對專案的需求。需求管理，目的是用以確保各方對需求的理解一致 管理和控制需求變更，以及從需求到最終產品的雙向跟蹤。主要活動包括 變更管理 版本控制 需求跟蹤 需求狀態。需求工程，把所有與需求直接相關的活動統稱為需求工程。分為需求開發和...
簡練網軟考知識點整理 專案管理會議
在專案管理中，會議 是乙個非常重要的工具與技術，專案管理中的八種會議包括 專案啟動會議 專案開踢會議 焦點小組會議 引導式研討會 規劃會議與分析 狀態審查會 經驗總結會。1 專案啟動會議 會議召開前已經對干係人進行了識別，已經有了干係人登記冊與干係人管理策略。此時應當讓各方干係人進行認識和會面，讓客...