作為IT架構(gòu)師，很可能經(jīng)常會發(fā)現(xiàn)自己處于進(jìn)退維谷的境地—前有業(yè)務(wù)目標(biāo)，后有IT系統(tǒng)。這兩方面都具有規(guī)模大、不易改變和靈活性差的特點(diǎn)，制定業(yè)務(wù)目標(biāo)的人員和開發(fā)系統(tǒng)的人員不一定了解彼此的工作內(nèi)容和成果。
　　業(yè)務(wù)人員使用一種語言來表達(dá)他們希望實(shí)現(xiàn)的業(yè)務(wù)目標(biāo)，而開發(fā)人員則使用另一種語言來表述技術(shù)要求。而這就是我們?yōu)榱藢?shí)現(xiàn)高效率而需要著手處理的問題:理解這兩種語言并執(zhí)行必要的轉(zhuǎn)換，以便 IT 能反映業(yè)務(wù)的需求，并能在適當(dāng)?shù)臅r(shí)候?qū)I(yè)務(wù)目標(biāo)進(jìn)行更改，使其與 IT 的能力相適應(yīng)。這并不是一個(gè)容易完成的工作，但這正是您能夠獲得很大利益的原因。
　　一個(gè)詞:用例
　　在業(yè)務(wù)用例中，參與者是干系人，而系統(tǒng)則是業(yè)務(wù)本身。
　　用電影《畢業(yè)生》中的方式，我只想對你說一個(gè)詞:用例。很多年來，我們都將用例用于對應(yīng)用程序進(jìn)行建模?，F(xiàn)在，在面向服務(wù)的體系結(jié)構(gòu) (SOA) 中，我們也使用這個(gè)概念來對業(yè)務(wù)進(jìn)行建模。
　　在Alistair Cockburn的《Writing Effective Use Cases》一書中，他將用例定義為“系統(tǒng)干系人之間就系統(tǒng)的行為達(dá)成的協(xié)定”。用例必須適合所定義的系統(tǒng)范圍，能夠代表此情況下使用系統(tǒng)的主要參與者的觀點(diǎn)，且能夠在一致的抽象層次上表示參與者的系統(tǒng)使用情況。
　　例如，股票交易Web站點(diǎn)的一個(gè)用例是“購買股票”，允許用戶通過此站點(diǎn)購買股票。該用例描述了客戶進(jìn)行何種操作以及站點(diǎn)如何響應(yīng)，而暫時(shí)忽略了站點(diǎn)將如何實(shí)際實(shí)現(xiàn)此行為。
　　可以將用例用于對服務(wù)進(jìn)行建模;我將此稱為服務(wù)用例。當(dāng)用例描述服務(wù)時(shí)，參與者就是服務(wù)使用者，而系統(tǒng)則為服務(wù)提供者。與任何用例一樣，此時(shí)的重點(diǎn)是服務(wù)提供者提供何種行為，而不是如何實(shí)現(xiàn)該行為。
　　還可以將用例用于對業(yè)務(wù)進(jìn)行建模。在業(yè)務(wù)用例中，參與者是干系人——業(yè)務(wù)用戶（如客戶或員工，甚至股東或政府監(jiān)管人員），而系統(tǒng)則是業(yè)務(wù)本身（生產(chǎn)產(chǎn)品并將其銷售給客戶的公司）。業(yè)務(wù)如何開展？客戶希望業(yè)務(wù)如何開展？他們愿意為何種服務(wù)或產(chǎn)品付費(fèi)？員工需要業(yè)務(wù)如何開展才能完成各自的工作？關(guān)鍵在于，這些干系人如何與公司進(jìn)行交互，這些都是業(yè)務(wù)用例。
　　獲得了業(yè)務(wù)用例后，則可以隨后將其鏈接起來，以形成業(yè)務(wù)流程—公司可以執(zhí)行的過程。這些流程本身就是業(yè)務(wù)用例，而復(fù)雜的業(yè)務(wù)用例可以被視為業(yè)務(wù)流程。簡單地講，這些流程顯示了公司要做什么以及如何做。如前面所述，流程以及每個(gè)流程中的步驟都對服務(wù)進(jìn)行建模。
　　通過用例將公司或公司的一部分建模為由服務(wù)組成的業(yè)務(wù)流程后，隨后的目標(biāo)就是盡可能多地實(shí)現(xiàn)流程和服務(wù)的自動化。實(shí)現(xiàn)這種自動化的應(yīng)用程序是采用面向服務(wù)的體系結(jié)構(gòu)的應(yīng)用程序，而現(xiàn)在正在進(jìn)行 SOA 實(shí)踐。
　　記錄流程
　　如果客戶不了解業(yè)務(wù)，架構(gòu)師有效定義系統(tǒng)要求的幾率都很小。
　　筆者在與客戶討論新程序或開發(fā)工作時(shí)，會立即了解業(yè)務(wù)干系人是否出席或派代表出席。然后，我會希望得到記錄良好的業(yè)務(wù)流程和數(shù)據(jù)要求。除非相關(guān)工作是一片“處女地”，否則一定會對新應(yīng)用程序或功能支持的原有的業(yè)務(wù)流程和將來的業(yè)務(wù)流程有良好的理解。不管采用哪一種方式，如果客戶不了解業(yè)務(wù)，架構(gòu)師有效定義系統(tǒng)要求的幾率就很小。
　　筆者個(gè)人非常贊同開發(fā)業(yè)務(wù)場景來記錄業(yè)務(wù)流程，業(yè)務(wù)場景允許在整個(gè)業(yè)務(wù)問題的上下文中標(biāo)識系統(tǒng)要求。
　　確定了將來的業(yè)務(wù)需求后，如果能維護(hù)一份功能和非功能行式項(xiàng)目要求的列表，也很有好處。我極力贊同使用工具來管理要求;為了達(dá)成此目的，我建議使用 IBM Rational RequisitePro。
　　通過使用根據(jù)業(yè)務(wù)場景確定的初始要求集，我們就可以開始定義系統(tǒng)行為的過程了。為此，可以召開聯(lián)合應(yīng)

    項(xiàng)目經(jīng)理勝任力免費(fèi)測評PMQ上線啦！快來測測你排多少名吧~

    http://m.opto-elec.com.cn/pmqhd/index.html