需求以自然語言進行描述，應該以某種標識方案進行編號。
幾種常見的需求標識和分類的技術：
最靈活和不容易出錯的方法是利用資料庫生成唯一識別符號的方法。這是因為資料庫系統支援在併發的情況下對每個新資料記錄生成唯一的識別符號。有些資料庫還可以通過版本號擴充套件唯一識別符號的方式來支援對相同記錄的多個版本的維護。包括需求在內的資料庫能夠維護建模人工製品之間的索引完整性關係，因而能夠對需求變更管理和需求跟蹤提供必要的支援。
需求可以按照父子關係建立層次化結構。父需求由子需求構成，子需求是父需求的有效子需求。
層次關係引入了另乙個層次的需求分類，這個層次可以直接反映也可以不直接反映在識別符號中，如4.1
4.14.
1是44
4的子需求。
需求的層次可以定義在不同抽象層次上，當需求向較低抽象層次遷移時，這與系統地細化模型的整體建模原則是一致的。最後的結果是，高層模型可以構造成父需求，而底層模型可以被鏈結到子需求上。
需求是變更的，在開發生命週期的任何階段，需求都可能變更，可能刪除、修改或增加新的需求。變更本身不會導致困難，但沒有管理的變更會帶來麻煩。
隨著開發的推進，需求變更的代價不斷增大，這種增加甚至是指數級的。
變更可能與人為錯誤相關，但常常是由於內部政策變化或外部因素而引起的，如競爭力、全球市場或技術進步。無論什麼原因，需要強有力的管理政策來建立變更請求的文件，估計變更的影響，並實現變更。
因為需求變更的開銷很大，所以每個變更請求必須建立起乙個規範化的業務用例。乙個以前沒有處理過的有效的變更請求需要從技術可行性、對專案剩餘部分的影響、開銷的方面來進行估計。需求變更一旦被批准，就會被結合到相關的模型中，並在軟體中實現。
需求變更管理涉及大量的、跨度較大的、相互關聯的資訊，需要好的case工具的支援。
需求跟蹤屬於需求管理的重要部分。需求的可跟蹤性是保持跟蹤關係來跟蹤貫穿整個開發周期的需求變更。
如果所有元素的跟蹤關係存在，則任何元素的變化會使關係開放以重新接受討論，即此跟蹤是可疑的。
在連續的生命週期階段，可跟蹤關係能跨越許多模型，只有相鄰的可跟蹤聯絡能被直接修改。
《需求工程》閱讀筆記之需求工程
需求工程活動分為需求獲取和需求分析 需求規格說明 需求驗證 需求管理。需求獲取是從人 文件或環境中獲取需求的過程，需求工程師必須要利用各種方法和技術來 發現 需求。需求開發的過程包含有學習和認知的過程，而學習和認知的過程是遞進的，因此需求獲取和分析是交織在一起的，需求工程師需要獲取一些資訊，隨即進行...
需求工程之需求基線
什麼是需求基線？需求基線就是把固定的需求都劃一根 線 說明這些需求已經確定下來，新增新的需求或修改原有的需求都必須通過需求變更流程來操作 建立需求基線的目的 防止需求的變化給程式架構造成重大影響。需求基線定義 已經通過正式評審和批准的規格說明或產品，可作為進一步開發的基礎，而且只有通過正式的變更控制...
需求工程之需求跟蹤
需求跟蹤 是需求管理的一項重要內容。指跟蹤乙個需求使用期限的全過程，需求跟蹤包括編制每個需求同系統元素之間的聯絡文件，這些元素包括 需求跟蹤的主要意義 在於獲得需求目前的實現狀態，確保使用者所有的需求都得到滿足。需求跟蹤的主要目標 維護軟體工作產品間的一致性。需求跟蹤分為 後向跟蹤 指需求在被定義到...