今天在看《agile software development》，讀到附錄中關於uml的介紹，不禁慨嘆：我以前在uml的時候怎麼就那麼的蹩腳呢，特別是在描述需求的時候。
我剛剛設計了乙個專案，一開頭就碰到乙個頭疼的問題——需求分析。我想取消我們以前那種繁雜的用文字描述的文件方法，採用uml的圖形化來表示。取消的原因有兩個，一是專案的組員不怎麼願意看那個文件來了解需求，我們這些搞技術的文字表述能力都不咋樣，自己的東西自己看還好，給別人看就禁不住考驗了；二是那個文件寫起來太麻煩，以後需求改變了，沒有時間也沒有精力改那個文件，組員之間也是通過口頭或者mail裡面的只言片語來溝通需求，結果文件就成了乙個擺設，需求到最後也沒有真正管理起來。
可是怎麼用uml來清晰的描述需求呢？認真看了《uml distilled》，這本寫得很通俗易懂，很容易上手。然而在具體的應用過程中，卻碰到了麻煩。能夠表述需求的，就是那個用例圖了，領域圖也可以勉強用用。更加要命的是，用例圖在描述需求的時候顯得太簡單了，就是actor加上use case，幾乎是把顯而易見的東西畫了簡單明瞭的圖而已。而那個領域圖，更加偏向分析設計方面，也不適合跟不懂技術的人員溝通。在這種情況下，只有採用圖形+文字的描述方法，通過簡單的圖形配上大段的文字描述。這也使我一直耿耿於懷。
讀了《agile software development》中關於uml的介紹之後，讓我有了新的啟發。比如說用例圖吧，可以通過擴充套件點(extension point)，使用《extend》關係來連線用例。舉例說，客戶在買單的時候，可以選擇多種支付方式，每種支付方式有不一樣的處理流程。如果把買單作為用例a，而把多種支付方式作為用例b1,用例b2等，那麼用例b1，用例b2就擴充套件了用例a。這樣準確的描述了多種支付方式的需求。其中關於《include》關係的描述也有用途。這些方法以前我也看到過，但是沒有今天看得這麼清晰。也許是在經歷了挫折之後，看到一種新的解決方法，格外的注意。
不過雖然在uml的圖形表示法上取得了一些進展，需求管理的根本問題還沒有得到解決。有很多的需求（至少客戶這麼認為），比如：介面上的要求、操作上的要求（要支援觸控等）、流程上細化的需求（要按照星期幾**等）等等，所有的這些需求，跨越了專案範圍、關鍵流程、細化的流程、介面要求等等，怎麼管理起來真是乙個問題。
UML學習 通過用例分析來確認需求
uml學習 通過用例分析來確認需求 2005年8月24日 前言用例是從使用者的觀點出發對系統建立模型。對於開發團隊，正確和全面的理解客戶的需求對建立期待的系統來說十分關鍵，至少系統能夠滿足使用者的需求。概念 可以認為用例是系統的乙個功能或者說是乙個使用場景，使用每個功能的實體 可以使人 另乙個系統等...
管理感悟 談談使用者和需求
談談使用者和需求 柳鯤鵬2007 7 27 關鍵字 使用者 需求 簡介 使用者自己也不知道自己需要什麼，也不知道自己的需求。使用者提的意見，可以說絕大多數是沒有意義的 而使用者的需求，必須由你詳細考察使用者的工作過程才能搞清楚。軟體要做好，才有資格聽取使用者意見。別把使用者反映的產品的問題和缺陷當作...
如何做需求管理
參考居士文章 做好需求管理文件 目的 背景 需求deadline 需求字段 此處是個大坑，掌握主動權很重要，一定要給業務做選擇題，而非填空題，不然業務提個複雜難度字段，邏輯不清晰，計算還複雜，會浪費很多精力 資料週期 部分字段口徑備註 主要的就是這幾個方面 重要度 業務線階段性戰略目標 部門定位 年...