文章來自：http://www.agilep365.com
首先來說，這個概念並不難，我們過去是採用需求規格說明書的形式來編寫的，所以也會產生一個非常大的文檔，裏面包含了種種我們所需要的項目基本的需求，當然其中也會包含的功能性的和非功能性的一些需求，也有一些項目的例外情況所能考慮到的。
那麼爲什麼需要去悄悄謀劃呢？很多的一部分原因是因爲我們的一頓一份大的需求在項目進行過程中可能會被無數次的更改，並且底下的工作人員，我在開發的時候在後期發現這些需求和開發的進度是很難被完全的追蹤起來的疾病，按照項目管理的做法，我們也會有需求跟蹤矩陣，但是這麼一份需求跟蹤矩陣如何去有效地跟蹤到那麼大的一份需求規格說明書呢？
由此，我們需要需求條目化來17更清晰易懂。而在敏捷的時候，我們說可以採用那用戶故事地圖的一個方式是最早的大型的一個需求能夠被有效的有層次的進行拆解，其實每一次的裁決都是對其進行的一次細化，而最終我們把這些需求每一條需求細化成一到兩句非常簡單的語句來表達這個需求所包含的一個真正的內容。
這樣做的話，這些需求其實就會變成碎片化，這很好地順應了我們現在的碎片化信息的時代，但是由此也會產生一些問題，就是這麼多碎片化的一些需求如何纔能有效的去跟蹤，有效跟蹤他們的進度呢？
我們，我們還是可以利用項目管理的需求，跟蹤矩陣來進行跟蹤。一個簡單的方法就是在用戶故事地圖做完以後，我們就可以妥善地去建立這麼一個矩陣，同時也可以很有效的去管理這些需求，後期所產生的變化。
用戶故事地圖之後所產生的用戶故事地圖還是可以予以保留，作爲組織的一資產，以便將來某些西化的條目可以被其它項目重複利用。