接上回，下層的圖描述的是乙個用例內部的事務（用例內部不一定是「單個用例」內部，也可能有用例之間的關係），主要有：
ø時序圖（順序圖）：描述事情變化在時間維度上的先後順序，善於表達物件（比如多個頁面之間）的互動。玩的好可以完全替代uc中對流程的文字表述。
ø活**（比較接近傳統意義上的流程圖）：描述各種動作如何引起系統變化，善於表達泳道較多、分支較多的情況。
ø協作圖：表達不同物件之間是怎麼互相影響的，這個圖團隊裡用到的不多，就不畫了，理論上他和時序圖是可以等價轉換的，時序圖關注互動在時間上的步驟，協作圖關注互動過程中各個物件間的關係。
這些圖我們都是用rational rose畫的，它最好的乙個點是可以在不同層次間的圖穿透，比如從用例包穿透看到用例圖，再穿透進某個用例看活**，再穿透進活**的某一步看具體的時序圖。
很多時候多種圖都可以描述同一件事情，只是從不同的視角去表達乙個系統，選用哪個關鍵是看針對特定的系統，從哪個角度來描述更容易讓受眾理解。另外還有表述軟體實施的構件圖、描述硬體結構的部署圖，暫時用處不大，遵循價效比的原則直接跳過了。
融入了uml標準圖元素以後，乙個功能模組的uc文件大約就是這樣的：文件說明、類圖+用例圖（需求描述部分）；乙個個的uc，uc裡包含時序圖、活**等等（需求分析階段）。整塊的需求規範化工作最近也在做，以後有機會再整體整理出來。
最後感慨一下rational rose真的太強大（建立了整個軟體工程的rup，rational unified process，包括分析、設計、編碼、測試、部署等等一切），想找乙個輕一點的工具，折騰了半天visio，發現總是缺點什麼，誰有更好的方案？
產品設計體會（九） 關於學習
這兩天在準備pd交流會的分享，目的是把前段時間去上海培訓 產品需求管理 的體會和大家說說。不妨順便說一下自己對培訓 分享這種學習活動的體會。用 武俠 裡的一些概念來比喻很有感覺，一直覺得培訓和分享在表面上交流的好比是招式，在短短的幾天甚至幾個小時內，最吸引人的往往是一些容易掌握 用來嚇 唬人很好的 ...
產品設計體會（十六） Feature List
看不清吧，那就對了，暫時不能讓你們看清 p 乙個feature，這次我給了它如下屬性 模組 一般來說，每個模組下分3 10個子模組是合理的，否則要考慮重新劃分 由於這個癖好，自己電腦裡的檔案目錄結構也是遵循這個原則的 子模組 稍大一點的產品至少要給功能模組做二級分類了，這部分其實又涉及另外乙個很大的...
產品設計體會（十二） 少而精
長假回來，這兩天基本在全力做 批量定時上架 的需求，n多的pk 評審 確認會搞得頭昏腦脹，不過終於算是把需求確認掉了。其中有些關於功能做多做少的爭論，這個話題在體會 三 中有所設計，但說的不深，這裡再寫點。一 個功能的多次需求會議中，必然有這樣乙個過程。開始對乙個功能想的不完整，說著說著大家都想把這...