9月21日，我作為外部的專家參加了乙個客戶的測試用例評審會議，該測試用例文件在開此評審會議之前曾經在測試組進行了內部評審。與會的評審專家包括了：2個專案的需求與開發人員，3個測試人員，2名qa人員，1名外部的諮詢顧問。
會議開始，由作者對照測試用例文件開始講解每個測試用例，會議的專家對這些用例進行評判。每當作者解釋完乙個用例後，我就會問乙個問題，此用例對應的是哪個需求？然後作者會再投影出對應的需求給我看，於是我建議作者以需求文件的順序來講解測試用例，即對照每個需求，然後講解對應這個需求設計了哪些用例，按照此方式評審測試用例時，作者本人很快就發現有的需求沒有對應的測試用例，漏設計了測試用例，而需求開發人員很快發現有的需求是不需要測試的，是其他的系統實現的，雖然在需求文件中描述了，但是不是本系統的範圍內。對每個需求評審完成以後，作者還提出有些用例還沒有被評審，為什麼呢？因為有些需求在需求文件中並沒有明確描述，但是根據經驗，這些功能是必須的，所以測試人員在測試時也設計了一些測試用例。這些需求是需要需求分析人員在需求文件中補充完善的。
此評審會議進行了2個半小時，累計發現了45個問題。
如果建立了需求跟蹤矩陣，我們對照需求跟蹤矩陣的進行測試用例的評審，則會更加方便，如果建立了需求跟蹤矩陣，作者本人很容易在評審之前就會很容易發現未被測試用例覆蓋的需求。
需求跟蹤矩陣的作用有兩個:一是檢查需求是否被實現了，是否被測試了，執行需求的驗證，進行功能審計；二是在發生需求變更時，通過檢索需求跟蹤矩陣發現需要修改的需求、設計及測試用例等。本例即證明了需求跟蹤矩陣的第乙個作用。
基於上例，以此類推，在我們進行設計評審時，也要對照需求跟蹤矩陣逐一檢查每個需求是否都設計了以及設計的正確性、合理性等。
關於需求跟蹤矩陣
x朋友問 做了幾年需求跟蹤，最開始用exl表，後來用工具，但是，感覺需求跟蹤和需求編寫質量 粒度等有很大關係。想請問各位，是否有跟蹤矩陣做得好的，真正用上了的。我知道哪個矩陣是有用的，但是維護和使用中容易做不下去，想看看各位都是怎麼用好它的。有什麼經驗？乙個朋友推薦 也許解決方案應該是，在詳細設計之...
需求分解與需求跟蹤矩陣
需求分解是將需求分解成乙個個的功能點。先寫出大的模組，然後子模組，然後細分成各個功能點，模組的個數名稱，子模組的層數，名稱，功能點均可維護。同時每個功能點後面還有開發人員和維護人員的記錄。開發人員和維護人員可以根據不同時期疊加。模組名稱 子模組名稱1 子模組名稱2 功能點開發人員 維護人員 備註 需...
需求分解與需求跟蹤矩陣
需求分解是將需求分解成乙個個的功能點。先寫出大的模組，然後子模組，然後細分成各個功能點，模組的個數名稱，子模組的層數，名稱，功能點均可維護。同時每個功能點後面還有開發人員和維護人員的記錄。開發人員和維護人員可以根據不同時期疊加。模組名稱 子模組名稱1 子模組名稱2 功能點 開發人員 維護人員 備註 ...