UML,對大家來說越來越熟悉了，隨著我們對項目管理的日益重視，UML作為統一建模語言支撐著“統一軟件開發(fā)過程”（RUP）。編寫需求說明書，幾乎每一個商業(yè)軟件中都必須經歷的過程，雖然有國家標準，但是還是因為各個系統不一樣,寫需求說明書的人不一樣，需求說明書寫得也是各式各樣。在這里我不想詳細描述UML（有很多書您可以去看，一定比我寫得好）或者是講解如何寫需求說明書，我只是總結一下我在MIS項目的需求說明書的撰寫過程中關于畫UML圖的一點經驗。

       在《軟件需求說明書編寫規(guī)范》中，已經給我們搭好了一個不錯的框架。作為系統分析人員，只要根據實際情況向這個骨架里填肉就可以了。在這里我們可能用到的UML圖有如下幾種：模型管理圖、對象圖、部署圖、部署和構建組合圖、用例圖、活動圖和順序圖。如果你對這幾個圖還比較陌生，建議你還是先了解一下，因為這幾個圖各有特點，從不同的角度說明問題，只有你對他們有一定的了解才能應用自如J

       下面我們就來看看如何在需求說明書中使用他們：

       對于需求說明書前面和結尾的那些死板的套話我們就不用費神了，讓我們直接來看“具體需求”，在這里才是UML圖的用武之地。

到這一步，《軟件需求說明書編寫規(guī)范》中直接就進入了一個個“功能需求”的條目，但是我認為作為MIS系統，首先應該將即將開發(fā)的系統的整體印象呈現給讀者，而且MIS系統，大多是多客戶端的分布式應用，所以在這里用UML中的部署圖將系統實現環(huán)境的硬件進行建模，讓讀者一目了然系統將要運行的環(huán)境。如果調研做得好的話，我們可以更深入一層，用UML中的部署和構建組合圖，用它來反映軟件之間的通信和硬件平臺之間的連接關系。當然這要有相當的經驗。

完成了總體印象，我們還是不應急于進入“功能需求”中。MIS系統中用戶常常會分為很多級別，信息流也就在這幾級用戶間傳來傳去。我們系統的目的也通常是為了讓幾條重要的信息流方便快捷的傳遞。所以不管什么“功能需求”都是為了這幾條信息流服務的。所以很有必要把幾條重要的信息流弄清楚。在這里用UML中的順序圖是個不錯的選擇，它的作用是用來表現隨著時間推移發(fā)生在對象之間的交互情況，它的好處是表現范圍比較窄，可以描繪一個典型用例的場景，突出重點，讓用戶知道你是否抓住了主要矛盾。這顯然是一個項目成敗的關鍵。

前面都是比較貼近于實際環(huán)境，距離我們的系統軟件部分稍遠了一點，那么我們現在就把思路向回拉一拉。描述一下“系統的功能分布”，這可以說是馬上要寫的“功能需求”的總體概括。用UML中的模型管理圖，在這里把各個功能模塊之間的依賴關系表現出來應該是個不錯的選擇。

好了，前面的鋪墊做完了，我們可以心安理得的進入“功能需求”了。這里可是真正反映系統分析員功底的時候了。如何用UML圖來配合功能模塊的IPO(輸入、處理、輸出)描述，我想各位大俠可以各顯神通，從不同的角度多方位勾勒。在這里再次強調需求調研一定要認真仔細，不然在這里，只能對著電腦屏幕空想，對自己的每次決定都會問：“這能行嗎？”相信你做好了充分的準備。那么讓我們開始吧！用例圖在這里可是不可缺的，它描述了參與者與系統之間的交互，展現用戶的需求。在“功能需求”的一開始用用例圖作一個概括。后面更詳細的敘述就交給活動圖來完成。由于活動圖來源于流程圖，讀者更容易接受。我們可以利用活動圖細致得刻畫出用戶在某一活動中的操作，也可以敘述系統在某一處理中的流程。最好再用對象圖來為問題領域模型建立一個例子，對于需求結束后的設計會有很大的幫助，而且對象圖還可以作為測試的用例，真是好處多多。但是要想畫出好的對象圖可不是一件容易的事，你必須對要描述的領域有很明白的認識，對相關對象的重要屬性有很好地把握。

OK，在“功能需求”中這些圖就足夠了，至于《軟件需求說明書》中其他地方用UML圖就由你視情況靈活使用了。UML圖我們可以大膽的用，總之，我的原則就是在遵守規(guī)則的基礎上只要能說明問題就行。說了這么多，僅供大家參考，本人水平有限，望多多指教。