軟考系統分析師：誰最應該學用例
9年前，我們開發一個商業連鎖公司的業務管理系統，開發組興致勃勃地第一次使用了UML建模語言進行系統的分析和設計。開發組花了大概2個月的時間完成了對業務系統的分析，并使用Use Cases描述用戶需求和軟件功能------盡管對這兩個元素的區分那時還經常混為一談，最后形成了一個幾十頁的需求文檔。裝訂成冊后，一天下午由項目經理和一個博士分析師兩人去甲方哪里溝通，并期望對需求達成一致，并獲得甲方的簽字。大家認為，使用這樣清晰和結構化的表達方式，需求真的已經比較清楚了。可是，意想不到的事情發生了。
甲方看了文檔后，說“我看不懂！……我不能簽字！”后來，無論我們的項目經理和博士怎么一一就需求講給他聽，他都無法，或者不愿意把聽到的和需求文檔里的那些陌生的符號（小人和橢圓）關聯起來------他不相信他看不懂的東西，他無法對他看不懂的東西承擔責任、簽字畫押。生氣的自然是我們的項目經理，可是甲方錯了嗎？
其實，這是一個典型的甲乙方溝通問題。而問題的關鍵是，雙方沒有約定彼此認可的、相同的溝通語言。就好像你說中文，他說西文；就好像RAS非對稱密鑰，你用一種密鑰加密，而要求他用另一種密鑰解密。這在人與人的溝通世界里，簡直就是痛苦----雙方的痛苦！那時候，有人笑侃，“這是加密了的需求，要用UML這把鑰匙才能把它打開，才能翻譯成自然語言文本。” 人類在語言上不斷地進步，最終出現了非常好用、溝通自由、表達準備的“自然語言”。可是，在計算機世界里，自然語言卻失去了它的價值。我們似乎需要反達爾文進化，把自然語言再符號化、結構化。另外，當我們對復雜現實世界（如：專業業務系統等）進行描述的時候，由于我們自然語言的過于靈活，使得我們溝通的雙方出現了理解偏差，而且隨著復雜性的增大，偏差越大。直到現在，關于復雜業務系統的溝通，在軟件工程師和客戶之間，還依然存在著理解的偏差。這是需求工程中的一個全球性疑難問題。
那么，既然如此，UML可以作為一個面向專業業務系統的描述語言，來表達實際業務嗎？我想，UML之父Ivar Jacobson 、Booch 和 James Rumbaugh 已經幫助我們回答了這個問題。但是，接下來，你能強迫你的客戶去懂得UML嗎？有人說，在過去20年來，軟件工程師是最辛苦的職業，因為他們不僅要懂計算機，還要懂甲方的業務，更重要的是，還要讓甲方相信你懂他的業務。而甲方，也許什么不懂都沒有什么大不了的。這種交易中的不對等，溝通中的不對等嚴重地束縛了軟件產業的發展，返工、重開發等等幾乎在每個軟件企業里發生過；也因此造成了甲方許多投資失敗。想想吧，所有的產業鏈中，沒有那個產業象軟件業一樣，把它和它的客戶如此緊密的聯系在一起。所以，在一個共同的“生存鏈條里”，我們需要一起成長，一起進步。當需求的問題日日夜夜糾纏著我們彼此的大腦的時候，我們需要共同的努力，需求結構化我們的需求，需要在溝通上創造新的方式，那就是：共同使用UML來確認需求。當然，除過UML之外，還有IDEF0、Workflow等輔助技術。
因此，甲方的項目人，如果你還停留在初級的需求表達上，請進入UML的世界吧，請試用用例的利器吧。它幫助你分解需求，關聯需求，結構化需求，和快速理解需求。
【編輯推薦】
