gipi的學習筆記-經營管理、數據思考、終身學習

 

在系統開發中，有個詞彙我們常聽到，那就是需求雙向追溯矩陣，這觀念其實非常的重要，但似乎被提到的多，但真的被應用的少，以下我簡單的提一下這個追溯矩陣的概念。

不管是依循瀑布式或者Agile、RUP等等開發生命週期方法論，系統開發一定都免不了要經過需求收集、分析、設計、Coding、測試等等程序，才能比較準確地完成客戶的需求，但如果我們只單單憑我們收集到的客戶需求就開始下去做SA、SD、Coding等工作，直到最後才讓客戶做驗收，我們有多少的把握我們開發出來的結果是符合客戶期望的？這種交付模式在開發上的風險實在太大了。

為了避免這樣的風險，我們在專案開發過程中通常會持續的去驗證與確認(V&V)我們做出來的東西是不是客戶所需要的，而驗證的方法自然是在各個階段，我們都要反覆的去審視我們的產出(或交付物)與客戶的原始需求是沒有差異的，這一點在專案管理領域中非常講究，我們要確保所有的客戶需求都在我們的系統中被實現，且沒有多做(鍍金)。

而如何確保？我們會在完成客戶需求列表後與客戶確認這些需求已經完整的紀錄了他所要的功能性與非功能性需求，接著我們會將這些需求轉換成我們系統中要實現的特性(這邊我稱產品特性)，接著依產品的特性去做分類，將相同屬性的特性歸到同一個模組裡頭，緊接著開始進行SA、SD與Coding的工作，看起來似乎沒有什麼太大的問題，但在這樣的狀況下，我還是沒有提到，我們該該如何在每個階段去驗證我們的產出是滿足客戶需求呢？

這時候我就要透過追溯關係來告訴我，客戶的哪個需求對應到哪個產品特性，哪些產品特性被配置到哪個模組，而這個模組又產出了哪份SA文件，SA文件又對應到那些SD文件，SD文件又對應到那些Code及技術支援文件，透過這樣一層一層追蹤下來，我們只要確保上手(對SD來說，SA就是他的上手)交付下來的內容是正確的，我們依上手的工作產品去進行我們的設計，理論上就不應該會有問題。


雙向追溯的結果就類似下面這個樣子，我們可以清楚的看到一個客戶需求分別對應到哪些文件與程式，這樣可以確保我們確實將每個客戶需求都配置到我們的系統功能中，也讓我們在後續處理變更時能更清楚我們該同步修正那些文件，以確保其產出的一致性。
 

雙向追溯做起來並不簡單，最好要搭配系統或者Excel來使用，但必須要確保這份資料是正確的被維護，否則追溯矩陣將完全喪失了他的意義。

建立雙向追溯矩陣有兩大意義：
1.確保每項工作產品的內容都可以追溯到原始的客戶需求
2.可追溯到每項客戶需求影響的工作產品，讓後續的變更處理能更順利的進行
3.讓測試人員清楚的知道每個客戶需求應該以那些測試案例進行驗證

 

 

游舒帆 (gipi) 探索原力Co-founder，曾任TutorABC協理與鼎新電腦總監，並曾獲選兩屆微軟最有價值專家 ( MVP )，離開職場後創辦探索原力，致力於協助青少年培養面對未來的能力。認為教育與組織育才其實息息相關，都是在為未來儲備能量，2018年起成立為期一年的專題課程《職涯躍升的關鍵24堂課》，為培養台灣未來的領袖而努力。