先來張圖
1.**分支不解釋了。
2.內容分支
為什麼需要名稱？便於記憶、引用
為什麼需要描述？定義需求的細節
為什麼需要關係？這樣才能知道某個需求變更會對其他需求、任務、模組帶來什麼影響
為什麼需要屬性？提供了分類的視角，便於檢索、篩選、統計具有共性的需求
為什麼需要id？地球人都知道
為什麼需要狀態？對需求從被提出到被滿足的全生命週期進行過程控制。3.管理分支
首先是記錄版本變遷過程：who在when對需求的where(這個where應該包括名稱、描述、關係、屬性、id，狀態可以不管，因為過程控制會處理狀態)做了what，當然還有why。
其次是比較版本差異：比如乙個gui需求，版本1說要outlook風格，版本2改成了office風格，需求分析師需要查詢和比較版本差異，以便提高分析質量
再次是利用版本控制相關的事件執行動作：比如乙個a需求的內容變更事件發生了，需要自動通知a需求相關的評審者嗎？或者更進一步，除了a需求的評審者，還要通知與a需求相關的b需求的評審者？
當然要是提供二次開發介面就更完美了。
首先是記錄狀態變遷過程：who在when對需求的狀態做了what，當然還有why。過程控制的基礎就是基於狀態的管理
再次是利用過程控制相關的事件執行動作：比如乙個a需求的狀態改變事件發生了，需要自動通知a需求相關的評審者嗎？或者更進一步，除了a需求的評審者，還要通知與a需求相關的b需求的評審者？
首先是基於屬性的篩選：基於屬性的篩選是把需求看做乙個列表，然後從列表中選取一段。這個屬性可以是優先順序、複雜度、重要性....，專案經理也許要用優先順序來安排進度，架構師也許要用複雜度來評估風險，產品經理也許要用重要性來權衡任務價效比，。。。總之，屬性提供了一種多視角的分類法，讓需求的各種使用者可以從自己的視角聚焦感興趣的需求。
其次是基於關係的篩選：基於關係的篩選是把需求看做一張使用者自定義的網，然後從網中選取乙個子網。這個屬性可以是優先順序、複雜度、重要性....，專案經理也許要用優先順序來安排進度，架構師也許要用複雜度來評估風險，產品經理也許要用重要性來權衡任務價效比，。。。總之，屬性提供了一種多視角的分類法，讓需求的各種使用者可以從自己的視角聚焦感興趣的需求。
基於版本的篩選以及基於狀態的篩選：可以被看做是基於屬性篩選的特例。
基於文字的篩選：基於文字的篩選把需求看做一張基於文字自組織的網，只要這些需求的名稱、描述中包含同樣的搜尋詞，他們之間就發生關係。
基於文字、基於屬性、基於狀態、基於依賴關係的統計都要，有什麼樣的檢索篩選自然就有什麼樣的統計
需求與專案任務之間、與專案人員之間、與**模組之間、與測試結果之間、與其他需求之間都可能存在依賴關係，追蹤時兩個問題必須考慮：追蹤的方向性、追蹤的顆粒度。
追蹤的方向性是說從誰向誰追。比如需求與任務，查詢速度要求從10s提到5s了，與之相關的資料庫設計任務需要修改嗎？一般是的，最起碼要新增一些測試任務。那麼提出了新的任務去實現原來的需求呢？比如把資料庫從sqlserver換成mysql，原來的查詢速度要求要變嗎？一般不是的。所以需求和任務之間從需求追向任務就夠了。但需求和需求之間呢，乙個需求變了，關聯需求需要變嗎？可能性很大，所以需求追向需求要雙向的。
追蹤的顆粒度是說追到何種程度。需求是分層次的，任務是分層次的，**模組也是分層次的，人員也是分層次的。乙個需求要關聯到任務的哪個層次，**的哪個層次，人員的哪個層次？一種解決辦法是消除層次。比如bug管理時，bug修改需求通常是獨立的，需求沒有層次了，**的每次提交也是獨立的，需求與**之間都沒層次了，所以我們在bug管理中常看到bug號直接和**版本號關聯。但是非bug類的需求呢？恕我淺薄，還沒看到滿意的好辦法。這也許是個仁者見仁智者見智的問題。4.工具分支這些工具能支援需求管理嗎？
專案子項
excel
腦圖需求管理系統
內容記錄
總評：良
excel表裡記錄需求的內容沒有問題，但「關係」不好處理，因為需求與其他物件(其他需求/設計文件/實現**)之間是多對多關係，而列表記錄多對多關係是很麻煩的（想象一下，每個一對一需要一行，如果發生變更，可能需要手動修改多行，買糕的，千萬別讓我來維護）
總評：中
以mindmanager為例，名稱用topic，描述就是note，屬性就是text marker，關係不好辦，需求與其他文件的關聯還能hyperlink，需求之間的關係怎麼辦？
topic之間
連上relationship，再加個text marker標記？需求少還好辦，多了腦圖就變迷宮圖了。
總評：優
各項內容記錄都支援
版本控制
總評：中
總評：中
總評：優
記錄狀態變遷過程
借助svn
把記錄需求的
excel
檔案管起來，需求變更的歷史可以輕鬆搞定，但顆粒度只能細到文件級。
同excel
內建，顆粒度到需求級
利用過程控制相關的事件執行動作
自己程式設計吧，學學vba，:)
這回要學腦圖軟體的api了，如果它有的話
內建標準動作如email，自定義動作可以二次開發
過程控制
總評：中
總評：中
總評：優
記錄狀態變遷過程
在excel中新增過程控制欄位如「當前狀態、變更時間...」也能實現，狀態變遷歷史當然也只能求svn，管理的顆粒度也是文件級
給topic加屬性，加標記,顆粒度同excel
內建，顆粒度到需求級
利用過程控制相關的事件執行動作
自己程式設計吧，學學vba，:)
這回要學腦圖軟體的api了，如果它有的話
內建標準動作如email，自定義動作可以二次開發
檢索篩選
總評：良
總評：中
總評：優
基於屬性
ok基本ok，看具體腦圖軟體是否支援
ok
基於關係
困難困難ok，需求與**的關聯看與svn等版本控制的結合度
基於狀態
ok基本ok，看具體腦圖軟體是否支援
ok
基於版本
利用svn，顆粒度文件級
利用svn，顆粒度文件級
ok
基於文字
ok基本ok，看具體腦圖軟體是否支援
ok，看軟體本身是否支援
統計總評：中
總評：差
總評：良
基於屬性
ok困難，現有軟體基本不支援
ok
基於關係
困難困難，現有軟體基本不支援
ok，需求與**的關聯看與svn等版本控制的結合度
基於狀態
ok困難，現有軟體基本不支援
ok
基於版本
困難困難，現有軟體基本不支援
ok
基於文字
困難困難，現有軟體基本不支援
ok，看軟體本身是否支援
追蹤總評：差
總評：差
總評：良
需求與任務
困難，因為多對多關係
困難，現有軟體基本不支援
ok
需求與**
困難，因為多對多關係
困難，現有軟體基本不支援
ok，需求與**的關聯看與svn等版本控制的結合度
需求與測試
困難，因為多對多關係
困難，現有軟體基本不支援
ok
需求與人員
困難，因為多對多關係
困難，現有軟體基本不支援
ok
關於設計模式的胡思亂想
設計模式是乙個指導，並不強制。有很多地方並不需要設計模式介入，因為設計模式是分離變化，很多 是一次性的，不會變。如果我們一開始寫程式的時候就加入設計模式，這樣就顯得過度設計，既耗時又費力。並且設計模式大多數會增加 量，不必要的設計又有了乙個額外的弊端。設計模式並不能解決所有的問題，都是解決特定的問題...
深夜的胡思亂想
時間過得好快呀五天都過去了 然而感覺沒什麼起色依舊是乙個什麼都不會的蒟蒻 老師講課聽不懂 講過的題講的時候還記得，並且理解，講完就忘了 感覺自己好失敗呀 看到別人用自己的智慧型一道道刷題，可以為了刷題不顧一切，在同學身邊條理清晰地講題的樣子 覺得自己的努力太少 有些不甘 還是自身的問題有什麼資格抱怨...
關於近期的焦躁與胡思亂想
近期很焦躁，大腦胡思亂想 身處網際網路這個行業中，作為乙個不咋的的開發人員，在此想吐吐自己的一點想法。敏捷到今天似乎已經很普遍了，產品是運營出來的理念也幾乎已成為網際網路每間公司掛在口頭上的東西。小步快跑，不斷根據使用者的反饋在產品體驗上做快速的變更這也是大家都懂的.快，關鍵就是快。作為乙個後台開發...