1.2-UML並非萬能

寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML

1.2-UML並非萬能

有些系統分析師對UML懷有高度期望，希望採用UML來蒐集及編寫需求之後，可以不再誤解或遺漏需求，或者可以降低需求變動。不難想見，系統分析師經常得面對這些的問題，當然期望學了UML之後，可以一勞永逸地解決掉這些問題。可是UML並非萬能，無法根除這些本質性的問題，不過也不必悲觀，總是有對策可以來處置需求誤解、遺漏或變動的情況。

人跟人的溝通，本來就會產生誤解，更何況使用者與系統分析師的專業背景不同，當然在訪談的過程中，充滿大大小小的誤解，既是在所難免，也就無法避免。再者，人腦並非電腦，談著談著，總是有多多少少的遺漏，無法在區區幾次匆忙的訪談中，明確又清晰地條理分明，這無疑是強人所難。

既然，訪談之中，會有誤解與遺漏，那日後反反覆覆多次地透過電話、電郵、會面來變動需求，或者是經過展示之後，才發現錯誤而變動需求的煩人事件，也就不可抗拒地自然而然地發生了。

雖然，UML無法根除這些本質性的問題，但我們還是有對策可以來面對這樣的現象，試圖減輕系統分析師的工作壓力。對策如下：

1.使用UML圖(Diagram)引導訪談，降低遺漏需求的情況。UML提供10多款不同功能的圖，可以讓系統分析師在訪談過程中，透過多款不同的圖來釐清需求各種不同角度的面貌，降低遺漏。而且，每款圖都有它獨特的組成圖示，在繪製每一個圖示時，都將引導系統分析師提出適時且重要的問題，以便蒐集與釐清需求。
2.快速產出可執行的程式片段，透過展示來突顯誤解。
3.封裝變動，讓需求發生變動時，可以追蹤到變動之處，迅速改版，並且不讓變動起漣漪效應，向外擴散。

所以，在本書裡，我們將要求系統分析師學習多款UML圖，並且在編寫需求時，不僅得產出讓使用者簽字的文件，還得同時產出讓設計師能接續設計的UML圖件。這樣的要求對於系統分析師確實相當為難，但是想要跟使用者確認需求、簽字同意，除了提交使用者能夠看懂的文字(Text)之外，別無選擇。然而，想要滿腦子OO概念的設計師和程式設計師，可以高效率且零誤解地看懂系統分析師產出的需求文件，除了透過具OO概念的UML圖外，目前看來似乎別無它法。