把業(yè)務(wù)需求轉(zhuǎn)換為IT要求

申請(qǐng)免費(fèi)試用、咨詢(xún)電話(huà)：400-8352-114

作為 IT 架構(gòu)師，您可能經(jīng)常會(huì)發(fā)現(xiàn)自己處于進(jìn)退維谷的境地，前有您的業(yè)務(wù)目標(biāo)，后有您的 IT 系統(tǒng)。這兩方面都具有規(guī)模大、不易改變和靈活性差的特點(diǎn)。制定業(yè)務(wù)目標(biāo)的人員和開(kāi)發(fā)系統(tǒng)的人員不一定了解彼此的工作內(nèi)容和成果。似乎是這樣，業(yè)務(wù)人員使用一種語(yǔ)言來(lái)表達(dá)他們希望實(shí)現(xiàn)的業(yè)務(wù)目標(biāo)，而開(kāi)發(fā)人員則使用另一種語(yǔ)言來(lái)表述技術(shù)要求。

而這就是我們?yōu)榱藢?shí)現(xiàn)高效率而需要著手處理的問(wèn)題:理解這兩種語(yǔ)言并執(zhí)行必要的轉(zhuǎn)換，以便 IT 能反映業(yè)務(wù)的需求，并能在適當(dāng)?shù)臅r(shí)候?qū)I(yè)務(wù)目標(biāo)進(jìn)行更改，使其與 IT 的能力相適應(yīng)。這并不是一個(gè)容易完成的工作，但這正是您能夠獲得很大利益的原因。

由于這部分工作可能會(huì)非常困難而棘手，因此，我們向 IBM 體系結(jié)構(gòu)專(zhuān)家隊(duì)伍尋求指導(dǎo)。本月我們邀請(qǐng)這些專(zhuān)家分享他們用來(lái)將業(yè)務(wù)需求表述為明晰簡(jiǎn)潔的技術(shù)要求的方法，以便 IT 團(tuán)隊(duì)能成功地實(shí)現(xiàn)。

我們?cè)诖颂峁┑膬?nèi)容談不上全面。本文的全部?jī)?nèi)容都是在討論如何將業(yè)務(wù)需求轉(zhuǎn)換為技術(shù)要求，但關(guān)于這個(gè)主題還有很多可說(shuō)。每位 IT 架構(gòu)師對(duì)此問(wèn)題的答案的關(guān)注點(diǎn)都或多或少有自己的特別之處，沒(méi)有任何答案能滿(mǎn)足所有人的愿望。不過(guò)，我們的專(zhuān)家將為您指明有用的方向，以?huà)伌u引玉，我們相信這可以幫助您找到本月的問(wèn)題的最恰當(dāng)答案。

一個(gè)詞:用例

用電影畢業(yè)生 (The Graduate) 中的方式來(lái)說(shuō)，我只想對(duì)你說(shuō)一個(gè)詞:用例。很多年來(lái)，我們都將用例用于對(duì)應(yīng)用程序進(jìn)行建?！，F(xiàn)在，在面向服務(wù)的體系結(jié)構(gòu) (SOA) 中，我們也使用這個(gè)概念來(lái)對(duì)業(yè)務(wù)進(jìn)行建模。

在 Alistair Cockburn 的 Writing Effective Use Cases 一書(shū)中，他將用例定義為"系統(tǒng)干系人之間就系統(tǒng)的行為達(dá)成的協(xié)定"。用例必須適合所定義的系統(tǒng)范圍，能夠代表此情況下使用系統(tǒng)的主要參與者的觀(guān)點(diǎn)，且能夠在一致的抽象層次上表示參與者的系統(tǒng)使用情況。

例如，股票交易 Web 站點(diǎn)的一個(gè)用例是"購(gòu)買(mǎi)股票"，允許用戶(hù)通過(guò)此站點(diǎn)購(gòu)買(mǎi)股票。該用例描述了客戶(hù)進(jìn)行何種操作以及站點(diǎn)如何響應(yīng)，而暫時(shí)忽略了站點(diǎn)將如何實(shí)際實(shí)現(xiàn)此行為。

可以將用例用于對(duì)服務(wù)進(jìn)行建模;我將此稱(chēng)為服務(wù)用例。當(dāng)用例描述服務(wù)時(shí)，參與者就是服務(wù)使用者，而系統(tǒng)則為服務(wù)提供者。與任何用例一樣，此時(shí)的重點(diǎn)是服務(wù)提供者提供何種行為，而不是如何實(shí)現(xiàn)該行為。(有關(guān)服務(wù)用例的更多信息，請(qǐng)參閱我的 developerWorks 文章"通過(guò)服務(wù)模擬來(lái)簡(jiǎn)化 SOA 開(kāi)發(fā)"。)

還可以將用例用于對(duì)業(yè)務(wù)進(jìn)行建模。在業(yè)務(wù)用例中，參與者是干系人--業(yè)務(wù)用戶(hù)(如客戶(hù)或員工，甚至股東或政府監(jiān)管人員)，而系統(tǒng)則是業(yè)務(wù)本身(生產(chǎn)產(chǎn)品并將其銷(xiāo)售給客戶(hù)的公司)。您的業(yè)務(wù)如何開(kāi)展?客戶(hù)希望您的業(yè)務(wù)如何開(kāi)展，他們?cè)敢鉃楹畏N服務(wù)或產(chǎn)品付費(fèi)?員工需要業(yè)務(wù)如何開(kāi)展才能完成各自的工作?關(guān)鍵在于:這些干系人如何與公司進(jìn)行交互?這些都是業(yè)務(wù)用例。

獲得了業(yè)務(wù)用例后，則可以隨后將其鏈接起來(lái)，以形成業(yè)務(wù)流程--公司可以執(zhí)行的過(guò)程。這些流程本身就是業(yè)務(wù)用例，而復(fù)雜的業(yè)務(wù)用例可以被視為業(yè)務(wù)流程。簡(jiǎn)單地講，這些流程顯示了公司要做什么以及如何做。如前面所述，流程以及每個(gè)流程中的步驟都對(duì)服務(wù)進(jìn)行建模。

通過(guò)用例將公司(或公司的一部分)建模為由服務(wù)組成的業(yè)務(wù)流程后，隨后的目標(biāo)就是盡可能多地實(shí)現(xiàn)流程和服務(wù)的自動(dòng)化。(無(wú)法實(shí)現(xiàn)自動(dòng)化的就是需要人工完成的任務(wù)。)實(shí)現(xiàn)這種自動(dòng)化的應(yīng)用程序(實(shí)現(xiàn)流程和服務(wù))是采用面向服務(wù)的體系結(jié)構(gòu)的應(yīng)用程序。而您現(xiàn)在正在進(jìn)行 SOA 實(shí)踐。

記錄流程

當(dāng)我坐下來(lái)和客戶(hù)討論新程序或開(kāi)發(fā)工作時(shí)，我會(huì)立即了解業(yè)務(wù)干系人是否出席，或是否派了代表出席。然后，我會(huì)希望得到記錄良好的業(yè)務(wù)流程和數(shù)據(jù)要求。除非相關(guān)工作是一片"處女地"(即之前從沒(méi)有進(jìn)行過(guò)此類(lèi)工作)，否則一定會(huì)對(duì)新應(yīng)用程序或功能支持的原有的業(yè)務(wù)流程和將來(lái)的業(yè)務(wù)流程有良好的理解。不管采用哪一種方式，如果客戶(hù)不了解業(yè)務(wù)，架構(gòu)師有效定義系統(tǒng)要求的幾率都很小。

我個(gè)人非常贊同開(kāi)發(fā)業(yè)務(wù)場(chǎng)景來(lái)記錄業(yè)務(wù)流程。業(yè)務(wù)場(chǎng)景允許您在整個(gè)業(yè)務(wù)問(wèn)題的上下文中標(biāo)識(shí)系統(tǒng)要求。The Open Group 提供了一本非常出色的的小冊(cè)子，用于幫助了解和開(kāi)發(fā)業(yè)務(wù)場(chǎng)景，書(shū)名為 Manager's Guide to Business Scenarios。

確定了將來(lái)的業(yè)務(wù)需求后，如果能維護(hù)一份功能和非功能行式項(xiàng)目要求的列表，也很有好處。您可以使用電子表格來(lái)維護(hù)此列表，但如果想要盡量保持要求的可跟蹤性和根據(jù)優(yōu)先級(jí)或類(lèi)別管理各種要求，則這種方法就顯得不合適。我極力贊同使用工具來(lái)管理要求;為了達(dá)成此目的，我建議使用 IBM Rational? RequisitePro?。

通過(guò)使用根據(jù)業(yè)務(wù)場(chǎng)景確定的初始要求集，我們就可以開(kāi)始定義系統(tǒng)行為的過(guò)程了。為此，您可以召開(kāi)聯(lián)合應(yīng)用程序開(kāi)發(fā)(Joint application development，JAD)會(huì)議，以便根據(jù)一系列初始行式項(xiàng)目要求來(lái)充實(shí)將來(lái)的系統(tǒng)。通過(guò) JAD 會(huì)議，架構(gòu)師可以與干系人一起確定期望的系統(tǒng)行為，并以此為基礎(chǔ)記錄用例和場(chǎng)景。通過(guò)對(duì)用例和場(chǎng)景進(jìn)行細(xì)化，可以幫助定義最終的一系列功能和非功能要求。

從一開(kāi)始就使用 RequisitePro

Rational RequisitePro 是一個(gè)沒(méi)有得到足夠重視的 Rational 產(chǎn)品，該產(chǎn)品用于收集、記錄和細(xì)化需求和其他業(yè)務(wù)概念。它允許業(yè)務(wù)用戶(hù)在 Word 文檔中編寫(xiě)聲明，然后將其捕獲到數(shù)據(jù)庫(kù)中，并將這些聲明與用戶(hù)定義的其他屬性相關(guān)聯(lián)。這些聲明可以描述需求、策略、用戶(hù)角色、干系人以及與業(yè)務(wù)相關(guān)的任何其他內(nèi)容。

使用迭代需求細(xì)化流程時(shí)，可以在相關(guān)聲明之間建立聯(lián)系。例如，需求"Portlet 顯示 X、Y 和 Z 客戶(hù)信息"，可以與另一項(xiàng)需求"角色 A、B 和 C 應(yīng)接收所有必要的客戶(hù)信息"聯(lián)系起來(lái)。在這種情況下，第一項(xiàng)需求是第二項(xiàng)需求的細(xì)化。這樣就對(duì)一般需求和詳細(xì)需求之間的關(guān)系進(jìn)行了建模。

在我個(gè)人看來(lái)，您應(yīng)該在建模階段一開(kāi)始就使用 RequisitePro。RequisitePro 中管理的聲明可成為建模工具(如 IBM WebSphere? Business Integration Modeler、Rational Sofware Architect (RSA) 或 Rational Software Modeler (RSM)) 的輸入。事實(shí)上，Rational Sofware Architect 和 Rational Software Modeler 都提供了將 RequisitePro 需求顯式地鏈接到用例和其他建模元素的功能。您還可以將需求鏈接到 Java? Java 2 Platform Enterprise Edition (J2EE) 和其他類(lèi)似的實(shí)現(xiàn)構(gòu)件。通過(guò)此功能，您可以獲得各種問(wèn)題的答案，如"當(dāng)更改此項(xiàng)業(yè)務(wù)需求時(shí)，為了與其相匹配，必須對(duì)模型或?qū)崿F(xiàn)的哪些方面進(jìn)行相應(yīng)的更改?"

最后，在讀過(guò)了 Simon Johnston 所提出的觀(guān)點(diǎn)后，我希望補(bǔ)充一些內(nèi)容:

我最近組織了一次理解"策略"概念的工作，了解什么是策略，以及它應(yīng)該如何適應(yīng) IBM 的系列工具。通過(guò)這項(xiàng)工作，得出了以下定義:

策略 是在一定業(yè)務(wù)領(lǐng)域內(nèi)以實(shí)現(xiàn)特定業(yè)務(wù)目標(biāo)為目的的聲明。此定義與說(shuō)明和其他相關(guān)材料中強(qiáng)調(diào)的業(yè)務(wù)意圖是一致的。

聲明 是以某種人類(lèi)語(yǔ)言表述的語(yǔ)句。因此策略與 RequisitePro 的適應(yīng)性非常好;就某種意義而言，策略就是一種需求。

策略是通過(guò)一個(gè)細(xì)化流程制定的，該流程以高級(jí)策略聲明為基礎(chǔ)進(jìn)行，而這些高級(jí)策略聲明通常不能直接實(shí)現(xiàn);這些高級(jí)聲明將通過(guò)迭代方式細(xì)化為更為詳細(xì)的策略。然后，可以通過(guò)使用我前面描述的 RequisitePro 功能將完全細(xì)化的策略與實(shí)現(xiàn)工作聯(lián)系起來(lái)。Simon 所說(shuō)的"連續(xù)體"與策略生命周期這個(gè)觀(guān)點(diǎn)是一致的。

Calvin Powers 完成了一個(gè)基于 Web 的相對(duì)不錯(cuò)的演示文檔，演示了可以如何將 RequisitePro 用于捕獲和細(xì)化業(yè)務(wù)策略。請(qǐng)?jiān)L問(wèn) IBM Business and Technology Solutions Resource Library，并在 Demos 部分查找"Policy Provisioning using IBM Rational RequisitePro and IBM Workplace Business Controls and Reporting"。

正確功能的正確解決方案

我很喜歡 Kerrie Holley 對(duì)本月問(wèn)題的重新表述:"我如何從業(yè)務(wù)意圖轉(zhuǎn)到已實(shí)現(xiàn)的價(jià)值或 IT 解決方案?"開(kāi)發(fā)和設(shè)計(jì)解決方案的體系結(jié)構(gòu)時(shí)需要考慮的最重要的事項(xiàng)之一就是所需的對(duì)應(yīng)功能和容量級(jí)別。如果我所做的只是將價(jià)格信息發(fā)布到網(wǎng)上，我可以到最近的小學(xué)里找個(gè)人來(lái)編寫(xiě) HTML。不過(guò)，如果我是 Wal-Mart，而我要做的是嘗試采用多種語(yǔ)言跨越國(guó)界擴(kuò)展我的供應(yīng)鏈，并確?？梢匀旌虻卦L(fǎng)問(wèn)，那么我的功能和容量就必須更為可靠。

經(jīng)驗(yàn)豐富的專(zhuān)業(yè)人員可以幫助客戶(hù)將業(yè)務(wù)需求轉(zhuǎn)換為業(yè)務(wù)意圖。業(yè)務(wù)意圖更為模糊，但更與"基本需求"和"投資回報(bào)"一致。確定了業(yè)務(wù)意圖之后，就可以通過(guò)創(chuàng)新且可重復(fù)的 IT 解決方案獲得實(shí)現(xiàn)的價(jià)值。

和 Kerrie 一樣，我相信業(yè)務(wù)需求和 IT 功能存在重疊。正是由于這個(gè)模糊不清的界線(xiàn)使得體系結(jié)構(gòu)設(shè)計(jì)成為了一個(gè)困難而費(fèi)時(shí)的過(guò)程。不管是采用瀑布式還是迭代方法(我們喜歡后者)，規(guī)劃和需求分析階段始終都很單調(diào)乏味?？蛻?hù)很少知道他們需要什么(盡管很多人知道他們希望得到什么)。經(jīng)驗(yàn)豐富的專(zhuān)業(yè)人員有責(zé)任幫助客戶(hù)將業(yè)務(wù)需求轉(zhuǎn)換為 IT 功能。

這并不能通過(guò)只使用良好的工具和方法來(lái)實(shí)現(xiàn)，因?yàn)槊總€(gè)項(xiàng)目都是獨(dú)特的。方法和技術(shù)是指導(dǎo)方法，而工具則用于幫助實(shí)現(xiàn)這些方法的自動(dòng)化。雖然很多項(xiàng)目都具有共同之處，但他們彼此完全一樣的情況卻很少。假設(shè)它們彼此相同就是假設(shè)兩個(gè)完全不同的業(yè)務(wù)彼此完全相同(雖然有一定的相似性)。我過(guò)去曾和 Home Depot 及 Lowe's 進(jìn)行過(guò)大量合作。盡管這兩家公司相似，但他們都會(huì)告訴您各自的業(yè)務(wù)具有獨(dú)特性。而他們都將這些不同之處視為他們的競(jìng)爭(zhēng)優(yōu)勢(shì)。很多時(shí)候，文化、地域和地理位置對(duì)業(yè)務(wù)需求的影響決定著所建議的 IT 解決方案。政府法律法規(guī)和標(biāo)準(zhǔn)可能要求技術(shù)人員根據(jù)部署解決方案的場(chǎng)合對(duì)相同的業(yè)務(wù)需求采用不同的方法來(lái)設(shè)計(jì)解決方案。

捕獲和交付構(gòu)件的技術(shù)--用例、場(chǎng)景文檔、Rational Unified Process (RUP)--應(yīng)當(dāng)在參與的客戶(hù)中一致地實(shí)現(xiàn)。如果在項(xiàng)目進(jìn)行中，客戶(hù)改變了主意(業(yè)務(wù)需求)和決定，例如系統(tǒng)不需要 24x7 的可用性，而只需要 8x7 的可用性即可，因?yàn)樗麄儾幌Ｍ袚?dān) 24x7 解決方案所帶來(lái)的高成本，您仍然可以很好地使用這些構(gòu)件。

捕獲最佳實(shí)踐的模式解決方案

當(dāng)我看到這個(gè)問(wèn)題時(shí)，我的第一個(gè)念頭是我沒(méi)有資格回答這個(gè)問(wèn)題，因?yàn)槲也皇桥c客戶(hù)接觸的架構(gòu)師。不過(guò)，我通過(guò)一些咨詢(xún)活動(dòng)與客戶(hù)接觸過(guò)。我所用的技術(shù)并非基于任何正式的方法，而是基于對(duì)技術(shù)和產(chǎn)品的深入了解。我同意 Holt Adams 所說(shuō)的"從需求進(jìn)行轉(zhuǎn)換來(lái)選擇要用于構(gòu)造解決方案的技術(shù)或產(chǎn)品可能成為一個(gè)挑戰(zhàn)。"不過(guò)幫助卻是唾手可得的。

我的團(tuán)隊(duì)和我已經(jīng)開(kāi)始研究一項(xiàng)用于將設(shè)計(jì)模式鏈接起來(lái)的技術(shù)，我們將這些技術(shù)稱(chēng)為模式解決方案。我們的目的是為了使用 Rational Software Architect 中全面的模式框架來(lái)捕獲針對(duì)重復(fù)出現(xiàn)的問(wèn)題的最佳實(shí)踐。通過(guò)這個(gè)方法，我們可以采用可重復(fù)的方式更有效地將需求轉(zhuǎn)換為技術(shù)。我們的目標(biāo)是構(gòu)建一個(gè)圍繞可重復(fù)模式社區(qū)。我們希望形成一個(gè)像 Amazon.com 一樣的社區(qū)，人們可以在其中對(duì)各種模式進(jìn)行評(píng)論，并為他們喜歡的模式投票。請(qǐng)使用 Pattern Solutions discussion forum 告訴我們您對(duì)此主意及我們的實(shí)現(xiàn)的看法。

急需:通用技術(shù)

我也同意 Kerrie 對(duì)原來(lái)的問(wèn)題中提出的轉(zhuǎn)換的真正目的的描述(我如何從業(yè)務(wù)意圖轉(zhuǎn)到已實(shí)現(xiàn)的價(jià)值或 IT 解決方案?):其目的是通過(guò) IT 提供支持業(yè)務(wù)意圖的功能來(lái)實(shí)現(xiàn)業(yè)務(wù)的價(jià)值。讓我們來(lái)詳細(xì)地了解一下此概念。

首先，我們必須關(guān)注業(yè)務(wù)價(jià)值。IT 的目的不是使用不斷發(fā)展的新技術(shù)來(lái)持續(xù)更新我們的技能，而是為業(yè)務(wù)價(jià)值作出貢獻(xiàn)。

這句話(huà)的另一個(gè)重要方面就是 IT 不再僅是開(kāi)發(fā)獨(dú)立應(yīng)用程序了。相反，我們提供了可組合到一起實(shí)現(xiàn)業(yè)務(wù)流程的各個(gè)功能。SOA 的承諾之一是，我們通過(guò)它可以在業(yè)務(wù)組織和 IT 組織(在其中通過(guò)使用服務(wù)實(shí)現(xiàn)業(yè)務(wù)流程)之間提供一個(gè)相互都能理解的語(yǔ)言機(jī)制。

最后，我們需要討論一下 Kerrie 使用的一個(gè)有意思的術(shù)語(yǔ):即業(yè)務(wù)意圖。請(qǐng)注意，他沒(méi)有使用要求、需求 或用例。業(yè)務(wù)具有意圖。當(dāng)然，用例或 WebSphere Business Integration Modeler 模型可以幫助了解當(dāng)前的情況和清楚地說(shuō)明此意圖。但此類(lèi)工具有一定風(fēng)險(xiǎn)，可能會(huì)過(guò)早地根據(jù) Modeler 假定的解決方案表述問(wèn)題。

前段時(shí)間，曾進(jìn)行過(guò)一次關(guān)于描述需求的連續(xù)體的 Rational 管理內(nèi)部討論，涉及的范圍包括從描述業(yè)務(wù)策略的需求到人員或計(jì)算機(jī)系統(tǒng)在執(zhí)行任務(wù)時(shí)的操作。此連續(xù)體包括遠(yuǎn)景聲明、業(yè)務(wù)目標(biāo)、關(guān)鍵性能指標(biāo) (KPI)、業(yè)務(wù)流程描述/業(yè)務(wù)用例(這兩個(gè)術(shù)語(yǔ)可交換使用)、非功能要求，諸如此類(lèi)。此討論持續(xù)了很長(zhǎng)時(shí)間，也非常激烈，但卻并不一定是因?yàn)閷?duì)此概念存在異議，而是因?yàn)榇嬖诤芏嘈g(shù)語(yǔ)問(wèn)題--該如何稱(chēng)呼這些"東西"。

雖然我們?cè)谛枨筮B續(xù)體實(shí)踐中已經(jīng)取得了成功，但我仍然和 Kerrie 一樣認(rèn)為不可能采用工具解決此問(wèn)題。該連續(xù)體并不是旨在說(shuō)明我們必須在需求處理方面使用單一的工具，也不是要指出可以使用唯一的方法來(lái)描述各種需求之間的轉(zhuǎn)換。不過(guò)，我們的確需要一種方法，以據(jù)此對(duì)所有這些"東西"進(jìn)行管理。我們需要一個(gè)全局視圖，以幫助我們了解在從一個(gè)需求級(jí)別到另一個(gè)需求級(jí)別的轉(zhuǎn)換期間所做的決策和假設(shè)。

另一點(diǎn)與數(shù)據(jù)相關(guān)，但更多地屬于業(yè)務(wù)級(jí)別和 IT 級(jí)別所給出的聲明間的抽象差距。例如，一個(gè)業(yè)務(wù)用戶(hù)通常會(huì)聲明某個(gè)特定任務(wù)的需求--它需要是"安全的"。但這對(duì)架構(gòu)師意味著什么呢?我們有經(jīng)驗(yàn)的 IT 架構(gòu)師詢(xún)問(wèn)這是否意味著該任務(wù)必須保密地執(zhí)行，還是必須具有防篡改功能或者要求強(qiáng)加密機(jī)制或更短暫的內(nèi)容。業(yè)務(wù)用戶(hù)愣了一下，然后有些結(jié)巴地說(shuō)"全-全-全部"。然后，我們討論如果支持該安全性的所有內(nèi)容，以在已知且顯式信任的邊界內(nèi)將一段簡(jiǎn)單的數(shù)據(jù)從一個(gè)服務(wù)發(fā)送到另一個(gè)服務(wù)，則所需的基礎(chǔ)設(shè)施的成本是多少，在充分理解之后，業(yè)務(wù)用戶(hù)指出他們需要的是確保沒(méi)有未經(jīng)授權(quán)的用戶(hù)能夠看到他們不應(yīng)該看到的數(shù)據(jù)。因此，當(dāng)我們分析業(yè)務(wù)用戶(hù)的需求說(shuō)明時(shí)，我們不能因?yàn)樗麄儾欢夹g(shù)而讓他們強(qiáng)行接受某些東西。相反，我們需要獲得將這些意圖的聲明轉(zhuǎn)換為 IT 級(jí)別的具體要求的機(jī)制。

而這直接意味著我們的確需要更多地利用 RequisitePro，Mark 說(shuō)從一開(kāi)始就需要使用這個(gè)工具的意見(jiàn)是非常正確的。我們不僅需要能夠在 RequisitePro 中捕獲業(yè)務(wù)意圖，而且必須利用 RequisitePro 和 Rational Software Architect 之間的聯(lián)系來(lái)跟蹤模型，以對(duì)業(yè)務(wù)意圖進(jìn)行反饋。不過(guò)，在此消息中存在一個(gè)斷層，因?yàn)?WebSphere Business Integration Modeler 尚未與 RequisitePro 實(shí)現(xiàn)集成。這可以通過(guò)以下方法得到處理:在 Rational Software Architect 中打開(kāi) WebSphere Business Integration Modeler 模型，并將業(yè)務(wù)模型的 Rational Software Architect 視圖與 RequisitePro 相鏈接。

最近，我對(duì) Rational 業(yè)務(wù)驅(qū)動(dòng)的開(kāi)發(fā)技術(shù)驗(yàn)證進(jìn)行了更改，以準(zhǔn)確地反映以下觀(guān)點(diǎn):需要在該過(guò)程中盡早引入 RequisitePro，以在開(kāi)發(fā)任何模型--業(yè)務(wù)模型或 IT 模型--描述解決方案之前捕獲真正的意圖(如果您愿意，可以將其稱(chēng)為問(wèn)題)。Don 說(shuō)明了需求和設(shè)計(jì)模型為什么經(jīng)常被視為項(xiàng)目的障礙，而不是價(jià)值。在我看來(lái)，如果沒(méi)有鏈接到一起，一系列需求聲明和漂亮的模型仍然是二流構(gòu)件--而且可能是障礙。

正是通過(guò)這個(gè)使用 RequisitePro 鏈接和管理的構(gòu)件集，開(kāi)發(fā)團(tuán)隊(duì)才能了解其在項(xiàng)目中所處的位置，并能作為整體 IT 控制流程的一部分進(jìn)行項(xiàng)目組合管理決策。
管理不確定性和易變性

我同意 Don Ferguson 的意見(jiàn)和看法，他已經(jīng)進(jìn)行了很好的闡述，我將不對(duì)此進(jìn)行復(fù)述，而要增加一些新的東西。2005 年 11 月的 CIO 雜志中也有一篇關(guān)于將業(yè)務(wù)需求轉(zhuǎn)換為 IT 要求的文章"Fixing the Requirements Mess"。我也希望能不重復(fù)這其中的內(nèi)容。

本月的問(wèn)題也可以表述為:"我如何從業(yè)務(wù)意圖轉(zhuǎn)到已實(shí)現(xiàn)的價(jià)值或 IT 解決方案?"

業(yè)務(wù)需求和 IT 要求有很大部分都是重合的;即，對(duì)于某些人而言業(yè)務(wù)需求 指的是"我已更改的或新的業(yè)務(wù)流程是什么樣的?"而對(duì)其他人而言，則指的是"我如何借助對(duì)應(yīng)的關(guān)鍵成功因素實(shí)現(xiàn)一系列業(yè)務(wù)目標(biāo)?"還有些人覺(jué)得，這可能只意味著為一系列業(yè)務(wù)干系人提供功能，如新設(shè)備或新頁(yè)面，或者僅是新的自動(dòng)化業(yè)務(wù)規(guī)則執(zhí)行而已。

非常重要的事實(shí)是，術(shù)語(yǔ)IT 要求 隱含著一個(gè)問(wèn)題:業(yè)務(wù)需求和 IT 要求之間是否存在差別?這可能會(huì)引出一通長(zhǎng)篇大論，但我的觀(guān)點(diǎn)是，缺乏術(shù)語(yǔ)以及用來(lái)討論這個(gè)問(wèn)題的共同語(yǔ)言本身就是一個(gè)問(wèn)題。

我們的挑戰(zhàn)是業(yè)務(wù)需求和要求通常僅得到了部分理解，而且通常具有易變性。很多開(kāi)發(fā)方法都在通過(guò)引入迭代開(kāi)發(fā)、工具以及其他技術(shù)來(lái)適應(yīng)這個(gè)不確定性和易變性。但這些方法僅解決了這個(gè)問(wèn)題的一部分，因?yàn)檫@個(gè)不確定性和易變性?xún)H是此問(wèn)題的一部分而已。在假定特定方法是最優(yōu)的方法之前，要求流程必須了解要進(jìn)行的項(xiàng)目的類(lèi)型。

項(xiàng)目類(lèi)型因大小、范圍、組織關(guān)心的重點(diǎn)、文化、對(duì)解決方案的認(rèn)識(shí)、當(dāng)前環(huán)境以及其他因素的不同而有所差異。各種項(xiàng)目類(lèi)型要求我們對(duì)每個(gè)項(xiàng)目采用不同的方式來(lái)處理將組織的需求轉(zhuǎn)換為 IT 要求的問(wèn)題。不同的類(lèi)型項(xiàng)目要求在開(kāi)發(fā)方法、工具以及應(yīng)如何管理要求方面采取不同的處理方式。

由于這是一個(gè)與人相關(guān)的問(wèn)題，將組織的業(yè)務(wù)需求轉(zhuǎn)換為 IT 要求的挑戰(zhàn)并不能僅靠使用工具或方法得以解決。認(rèn)為可以通過(guò)改善工具或創(chuàng)建新開(kāi)發(fā)流程、方法或技術(shù)來(lái)完全地解決此問(wèn)題的想法是錯(cuò)誤的。

管理很多項(xiàng)目的需求流程需要我們具有確定應(yīng)在軟件中包含哪些東西不包含哪些東西的方法。此過(guò)程要求結(jié)合使用各種協(xié)作技能、輔助技能、工具、技術(shù)和方法。

經(jīng)驗(yàn)豐富的專(zhuān)業(yè)人員知道將組織的業(yè)務(wù)需求轉(zhuǎn)換為 IT 要求的過(guò)程中必須根據(jù)一系列因素進(jìn)行調(diào)整。這些因素包括:

對(duì)業(yè)務(wù)需求了解多少?
對(duì) IT 要求了解多少?
最終的解決方案的概貌如何?
這些因素在項(xiàng)目進(jìn)行期間會(huì)不斷地發(fā)生變化。

這正是采用敏捷編程、IBM Global Services (GS) 方法、Rational Unified Process (RUP) 或其他流程的技術(shù)人員不能盲目認(rèn)為其采用的方法就是正確的方法的眾多原因之一。沒(méi)有"萬(wàn)能"方法;這些都是工具。有見(jiàn)識(shí)的專(zhuān)業(yè)人員必須選擇何時(shí)以及如何使用正確的工具，并使這些工具與正在開(kāi)發(fā)的項(xiàng)目類(lèi)型和場(chǎng)景相匹配。

例如，GS 方法在幫助清楚地闡述一些要求必須適應(yīng)的大環(huán)境(如系統(tǒng)上下文、用例、基礎(chǔ)結(jié)構(gòu)、安全)方面非常不錯(cuò)。此方法可幫助建立分類(lèi)，以便我們?cè)谟懻?IT 要求 和業(yè)務(wù)需求 時(shí)知道各自明確的對(duì)象。

我的 IBM 同事 John Cameron 在一篇關(guān)于在啟動(dòng)項(xiàng)目時(shí)經(jīng)常遇到的不確定性分類(lèi)的文章中談到了這其中的一些方面。他認(rèn)為，此不確定性的程度以及我們對(duì)解決方案的認(rèn)識(shí)程度在如何將組織的業(yè)務(wù)需求轉(zhuǎn)換為 IT 要求方面扮演著重要的角色。John 的分析在圖 1 中得到了描述，圖中根據(jù)我們對(duì)需求以及項(xiàng)目的了解情況用一個(gè)簡(jiǎn)單的矩陣對(duì)項(xiàng)目進(jìn)行了分類(lèi)。

圖 1. John Cameron 所做的不確定性分類(lèi)

"Outside-in"設(shè)計(jì)

這是個(gè)很好的問(wèn)題，我希望給出而且也能給出一個(gè)很好的回答。我想，解決此問(wèn)題的最重要方法就是在開(kāi)發(fā)流程和開(kāi)發(fā)規(guī)則的過(guò)程中保持耐心。

很多項(xiàng)目并不能在需要的時(shí)候獲得前端需求文檔與分析以及業(yè)務(wù)建模。有時(shí)候，似乎會(huì)存在不利于提高編碼效率的未說(shuō)明的假設(shè)。正式的一流需求處理、流程建模和構(gòu)件建?？赡芊浅ＹM(fèi)時(shí)，但同時(shí)也能確保開(kāi)發(fā)過(guò)程的結(jié)果能完美地滿(mǎn)足業(yè)務(wù)需求。需求文檔和建模工作應(yīng)定義開(kāi)發(fā)工作輸出的測(cè)試用例。如果團(tuán)隊(duì)無(wú)法將需求轉(zhuǎn)換為測(cè)試用例，團(tuán)隊(duì)就沒(méi)有理解這些需求。

開(kāi)發(fā)也需要進(jìn)行迭代。我們從 Eclipse 開(kāi)發(fā)和其他項(xiàng)目了解到，我們的開(kāi)發(fā)工作每四到六周就需要生產(chǎn)出可以使用的過(guò)渡性版本。該版本應(yīng)該提供給業(yè)務(wù)干系人使用，并驗(yàn)證項(xiàng)目是否滿(mǎn)足了業(yè)務(wù)需求。每個(gè)過(guò)渡性版本階段均應(yīng)以一組得到一致認(rèn)可的并且該版本將滿(mǎn)足的需求和用例/場(chǎng)景作為出發(fā)點(diǎn)。

最后，我們已經(jīng)開(kāi)始在 IBM Software Group 內(nèi)試用一個(gè)稱(chēng)為"Outside-in-in design"的概念。在此方法中，我們依賴(lài)于以下原則:

進(jìn)行正式的用戶(hù)建模，包括角色和用戶(hù)概念對(duì)象
為與概念對(duì)象交互的角色定義一組用例
提供用例/場(chǎng)景的低精度和高精度可視模擬(有時(shí)簡(jiǎn)單得像紙上的鉛筆畫(huà)一樣。通過(guò)這種方式，解決方案的用戶(hù)可以提供早期評(píng)估和反饋。)
構(gòu)建過(guò)渡性版本
此過(guò)程不是瀑布型的，而是迭代過(guò)程。(此方法可幫助提供項(xiàng)目的持續(xù)細(xì)化，以確保其向提高業(yè)務(wù)需求和要求的滿(mǎn)足程度方向發(fā)展。)

使用一點(diǎn)技巧進(jìn)行迭代和增量改進(jìn)

這是大部分業(yè)務(wù)和 IT 專(zhuān)業(yè)人員的圣杯。多年來(lái)，各種方法、技術(shù)、工具和技巧層出不窮--最后都會(huì)通過(guò)信息技術(shù)不帶偏見(jiàn)且不斷發(fā)展的大門(mén)退出歷史舞臺(tái)。但我們不斷的求知欲望會(huì)讓我們?cè)俅螄L試不同的方式，或許采用頭腦風(fēng)暴的方式……嗯，在嘗試不同方法的時(shí)候可能會(huì)就得到給出的 P=?NP 問(wèn)題的答案!

對(duì)于此問(wèn)題沒(méi)有完全標(biāo)準(zhǔn)的答案，以下是我對(duì)將干系人需求轉(zhuǎn)換為 IT 解決方案的問(wèn)題的一些看法:

缺乏用于建立共同環(huán)境的一致的術(shù)語(yǔ)

通常，業(yè)務(wù)管理人員所使用的語(yǔ)言與 IT 架構(gòu)師的語(yǔ)言是不同的。業(yè)務(wù)分析人員/咨詢(xún)?nèi)藛T在嘗試縮小這個(gè)差距，但他們通常會(huì)加入自己的業(yè)務(wù)領(lǐng)越的數(shù)據(jù)和解釋?zhuān)瑥亩骨闆r變得更為混亂。更為雪上加霜的是，由于近年來(lái)工作和角色的流動(dòng)性，大多數(shù)人會(huì)將以前所擔(dān)任的角色的術(shù)語(yǔ)環(huán)境和包袱帶到新崗位來(lái)。我經(jīng)常在客戶(hù)會(huì)議和需求研討會(huì)上看到術(shù)語(yǔ)混淆的情況。

因此，主要需求之一是為在解決方案的業(yè)務(wù)和技術(shù)上下文中使用的所有術(shù)語(yǔ)(名詞、動(dòng)詞、形容詞等)建立清楚、一致、連貫且簡(jiǎn)潔的(我稱(chēng)為 4C，即 clear、consistent、coherent 和 crisp)定義和語(yǔ)義。這樣就為管理人員、分析人員和架構(gòu)師進(jìn)行有效的對(duì)話(huà)建立了基礎(chǔ)。是的，為了對(duì)術(shù)語(yǔ)和模式進(jìn)行標(biāo)準(zhǔn)化，的確存在跨行業(yè)部門(mén)--橫向和縱向--的協(xié)作活動(dòng)，但這大部分都在早期階段進(jìn)行。我對(duì)架構(gòu)師的建議是這樣的:不要對(duì)術(shù)語(yǔ)的含義想當(dāng)然，要勇于舉手要求澄清。

當(dāng)轉(zhuǎn)到最佳技術(shù)角度時(shí)的低效率(或能力缺乏)

可以直接將這個(gè)問(wèn)題簡(jiǎn)單地描述為錘子-釘子綜合癥。即，如果您是錘子，所有事項(xiàng)都是釘子。此處，人力元素是一個(gè)阻礙因素--這源于我們多年的認(rèn)知條件作用、我們了解的問(wèn)題分析和綜合模式以及我們習(xí)慣的技術(shù)領(lǐng)域(通常是我們最具專(zhuān)業(yè)知識(shí)的領(lǐng)域)。

例如:以數(shù)據(jù)為中心的架構(gòu)師將需求集看作是由實(shí)體和關(guān)系組成的。以狀態(tài)機(jī)為中心的架構(gòu)師則將其可視化為一系列的狀態(tài)、轉(zhuǎn)換和動(dòng)作。以流程為中心的架構(gòu)師將需求組織成經(jīng)過(guò)組合的任務(wù)和活動(dòng)。以對(duì)象為中心的架構(gòu)師則將其視為多態(tài)類(lèi)、接口及其關(guān)系?，F(xiàn)在，我們有以服務(wù)為中心的架構(gòu)師，他們將需求集當(dāng)作組合服務(wù)組成的拼板。如此等等。每個(gè)觀(guān)點(diǎn)都有其優(yōu)點(diǎn)和缺點(diǎn)，而架構(gòu)師務(wù)必對(duì)每個(gè)不同的業(yè)務(wù)需求或功能應(yīng)用恰當(dāng)?shù)囊暯?，這非常重要。顯然，決定哪個(gè)是"正確的"視角可以看作相當(dāng)主觀(guān)的問(wèn)題，非常有爭(zhēng)議。不過(guò)，應(yīng)用正確的方法可以采用最有效、最典雅且最令人滿(mǎn)意的方式實(shí)現(xiàn)要求。切換視角有些困難，而嘗試完成此工作甚至是主題專(zhuān)家 (SME) 討論的最大的話(huà)題。為每個(gè)視角配備一個(gè) SME 可能會(huì)使得體系結(jié)構(gòu)設(shè)計(jì)過(guò)程爭(zhēng)議不斷，可能會(huì)帶來(lái)大的反復(fù)，并且可能出現(xiàn)"分析癱瘓"。

需求驗(yàn)證、優(yōu)先排序和可跟蹤性方面的問(wèn)題

務(wù)必對(duì)業(yè)務(wù)需求進(jìn)行評(píng)審，并與干系人一起進(jìn)行分析，以合成真正的業(yè)務(wù)需求。有各種技術(shù)(用例、場(chǎng)景)、概念和相關(guān)工具用于捕獲此工作的結(jié)果。但這個(gè)領(lǐng)域不是藝術(shù)，并不能靠模仿來(lái)掌握，您只能通過(guò)全心投入加以適應(yīng)才能獲得相關(guān)的專(zhuān)業(yè)知識(shí)。對(duì)每個(gè)需求進(jìn)行了評(píng)審后，務(wù)必要與干系人就技術(shù)看法和一系列解決方案選擇(以及成本效益分析)進(jìn)行溝通。這個(gè)步驟可幫助從技術(shù)角度驗(yàn)證需求，也進(jìn)一步使其與未聲明的業(yè)務(wù)需求保持一致。在驗(yàn)證選項(xiàng)時(shí)，請(qǐng)通過(guò)討論來(lái)確定各種不同需求的優(yōu)先級(jí)，并在需求間建立交叉依賴(lài)關(guān)系。這些需求的依賴(lài)關(guān)系有助于創(chuàng)建可跟蹤性，而且在出現(xiàn)更改請(qǐng)求時(shí)扮演著重要的角色。同樣，這也不完全是技術(shù)問(wèn)題。RequisitePro 之類(lèi)的工具允許您包含一個(gè)請(qǐng)求管理模板(基于 RUP 或任何自定義方法)，此功能可實(shí)現(xiàn)很多方面的自動(dòng)化，如可跟蹤性、需求的狀態(tài)和構(gòu)建之間的轉(zhuǎn)換等等。

還有其他幾個(gè)問(wèn)題，如改變業(yè)務(wù)優(yōu)先級(jí)、更改操作環(huán)境、政治與文化壁壘、技能差距和很多其他問(wèn)題--都可能妨礙解決方案對(duì)需求的滿(mǎn)足。我和人合作撰寫(xiě)了一篇 IBM Systems Journal 文章"Impact of SOA on Enterprise Systems, Organizational Structures, and Individuals"，談了一些對(duì)其中一些問(wèn)題的看法。

最后，正如我在最近接受 IDevNews 采訪(fǎng)所說(shuō)的，將業(yè)務(wù)需求轉(zhuǎn)換為 IT 系統(tǒng)體系結(jié)構(gòu)的一種不錯(cuò)的方法就是采用迭代增量的方式進(jìn)行(借用了數(shù)學(xué)上的漸近法)。

所有需求并非全部同樣重要

成熟的組織了解所有需求并非都同樣重要。大多數(shù)需求本身對(duì)體系結(jié)構(gòu)并沒(méi)有影響;相反，它們與實(shí)現(xiàn)有關(guān)。某些需求要比其他需求重要很多，只要了解了這個(gè)區(qū)別，您就能作出更好的決定，以分配資源滿(mǎn)足高優(yōu)先級(jí)的需求。直到系統(tǒng)部署完成之后，需求收集才結(jié)束?？蓤?zhí)行系統(tǒng)的出現(xiàn)會(huì)改變干系人看待問(wèn)題的方式。

這些評(píng)論的一個(gè)非常重要的隱含意義--正如 Don Ferguson 所指出的--就是成熟的組織會(huì)執(zhí)行迭代增量的流程，這些流程的主要構(gòu)件都是可執(zhí)行的。這樣就強(qiáng)行讓開(kāi)發(fā)團(tuán)隊(duì)有規(guī)律地開(kāi)展工作，新需求可以在開(kāi)發(fā)過(guò)程中不斷地發(fā)現(xiàn)，舊需求會(huì)重新確定優(yōu)先級(jí)(有時(shí)會(huì)將其丟棄)，而最重要的，每個(gè)需求都會(huì)針對(duì)實(shí)際情況而不是文檔進(jìn)行度量。

了解真正的需求

我觀(guān)察到的一點(diǎn)就是，業(yè)務(wù)部門(mén)在了解自己的需求方面并不在行，而 IT 部門(mén)如果假設(shè)業(yè)務(wù)部門(mén)能夠很好地了解自己的需求，則犯了一個(gè)很大的錯(cuò)誤。就像病人去看醫(yī)生，要求得到科學(xué)的治療一樣，業(yè)務(wù)部門(mén)通常以所需的解決方案來(lái)表述自己的需求，而不是他們希望實(shí)現(xiàn)的業(yè)務(wù)成果。在我實(shí)際遇到的客戶(hù)中，業(yè)務(wù)團(tuán)隊(duì)會(huì)說(shuō)"我們需要新的保險(xiǎn)索賠系統(tǒng)。"不過(guò)，他們真正需要的卻是將他們?cè)谔幚硭髻r方面的效率提高 X% 或降低成本 Y% ，或者其他類(lèi)似的說(shuō)法。新的索賠系統(tǒng)可能提供也可能不提供這個(gè)改進(jìn)，但如果實(shí)際需求未知，則幾乎可以肯定不會(huì)提供這種改進(jìn)。

由于不清楚真正的需求，需要將更多的精力放在幫助由業(yè)務(wù)人員和 IT 人員組成的擴(kuò)大團(tuán)隊(duì)了解真正的需求。通常需要專(zhuān)家級(jí)輔助人員來(lái)幫助指導(dǎo)討論并消除爭(zhēng)議。我完全同意 Kerrie 所說(shuō)的，最大的挑戰(zhàn)是"人員問(wèn)題"，這個(gè)問(wèn)題是由業(yè)務(wù)和 IT 之間的價(jià)值認(rèn)識(shí)不一致及目標(biāo)不同、不同文化和組織間執(zhí)行不同目標(biāo)的獎(jiǎng)勵(lì)結(jié)構(gòu)不同而引起的。即使世界上最好的工具也不能克服這個(gè)問(wèn)題，而且，實(shí)際上還有可能會(huì)使得情況更糟。強(qiáng)大的工具放在不能勝任的工匠手中只會(huì)導(dǎo)致材料報(bào)廢的速度更快。

有時(shí)候，回避人為因素，而嘗試使用技術(shù)解決問(wèn)題會(huì)更為簡(jiǎn)單一些。人員和組織不喜歡變化，而大部分改進(jìn)都要求進(jìn)行大幅度更改，如果不能滿(mǎn)足這個(gè)要求，通常會(huì)導(dǎo)致組織無(wú)法緩和所遭遇的文化/價(jià)值隔閡問(wèn)題。

使用表述良好的需求武裝業(yè)務(wù)分析人員

可以對(duì)業(yè)務(wù)需求進(jìn)行捕獲、解釋并轉(zhuǎn)換為將為業(yè)務(wù)提供支持的功能和非功能 IT 要求。

業(yè)務(wù)需求是通過(guò)對(duì)業(yè)務(wù)流程、業(yè)務(wù)目標(biāo)、業(yè)務(wù)實(shí)體類(lèi)型和決策過(guò)程的業(yè)務(wù)模型的分析捕獲的。業(yè)務(wù)需求應(yīng)或可以通過(guò)一組關(guān)鍵性能指標(biāo)進(jìn)行度量，以便提供有關(guān)實(shí)現(xiàn)要求和滿(mǎn)足業(yè)務(wù)需求方面的成功程度的反饋。

它們是通過(guò)一個(gè)對(duì)變化進(jìn)行劃分、分解、細(xì)化、映射和分析的過(guò)程(面向變化的分析和設(shè)計(jì))解釋的。劃分是將業(yè)務(wù)域分解為域組成類(lèi)型或功能區(qū)域。這表示結(jié)構(gòu)劃分。業(yè)務(wù)的分解是對(duì)如何將流程分解為子流程和用例的解釋。分解過(guò)程將創(chuàng)建一個(gè)分層結(jié)構(gòu)，而細(xì)化過(guò)程則將這個(gè)分層結(jié)構(gòu)細(xì)化為一組可操作的面向目標(biāo)的交互序列。

將業(yè)務(wù)需求映射為 IT 要求的過(guò)程需要能證明給定業(yè)務(wù)要求是可跟蹤的，而且受到一組互補(bǔ)的 IT 功能的支持(這些 IT 功能由非功能方面提供支持)。此映射通常通過(guò)目標(biāo)-服務(wù)建模完成。我們將逐個(gè)研究各個(gè)變化，并表示流程、域/功能領(lǐng)域和規(guī)則間的共同之處。

將需求轉(zhuǎn)換為 IT 服務(wù)的過(guò)程可以通過(guò)組合使用以下互補(bǔ)的技術(shù)來(lái)完成:

域分解(包括流程分解、功能區(qū)域分析和面向變化的分析)
目標(biāo)-服務(wù)建模
分析現(xiàn)有資產(chǎn)(包括現(xiàn)有系統(tǒng)、打包的應(yīng)用程序和任何我們可以利用的資產(chǎn)，如標(biāo)準(zhǔn)、框架、各個(gè)領(lǐng)域的專(zhuān)用語(yǔ)言等等)
此過(guò)程的關(guān)鍵在于在給定時(shí)間框架內(nèi)標(biāo)識(shí)難點(diǎn)和業(yè)務(wù)相關(guān)的驅(qū)動(dòng)因素，更改將存在于此框架外，因而需要應(yīng)用面向變化的分析。我們將隨后以這些重要的出發(fā)點(diǎn)為基礎(chǔ)，將我們的理解細(xì)化為可操作的 IT 要求，可以通過(guò)組合功能和非功能要求來(lái)滿(mǎn)足這些 IT 要求。

簡(jiǎn)單項(xiàng)目的需求管理在范圍和深度方面與一系列業(yè)務(wù)或企業(yè)與價(jià)值鏈都有所不同。我們?cè)f(shuō)過(guò)，業(yè)務(wù)需求通常是一個(gè)時(shí)間點(diǎn)的剪影，可能會(huì)發(fā)生徹底的變化。業(yè)務(wù)功能的區(qū)分通常不會(huì)隨著時(shí)間而發(fā)生徹底變化，而會(huì)更加細(xì)化。基本功能最后將成為最終解決方案的一部分，但任何情況下都應(yīng)由 IT 系統(tǒng)加以支持。

每個(gè)領(lǐng)域也都在其中嵌入了可以用于表述該領(lǐng)域的問(wèn)題的語(yǔ)言。了解這個(gè)基礎(chǔ)語(yǔ)義對(duì)于了解需求背后的意圖(從而提供滿(mǎn)足這些意圖的需求)十分關(guān)鍵。

(業(yè)務(wù))流程建模對(duì)了解業(yè)務(wù)如何工作非常重要。有些人更喜歡采取用例建模或業(yè)務(wù)用例的方式。就最終目的而言，此過(guò)程就是記錄面向目標(biāo)的業(yè)務(wù)活動(dòng)的動(dòng)態(tài)或流方面的特征。

業(yè)務(wù)需求的實(shí)現(xiàn)是通過(guò)實(shí)現(xiàn)一系列基礎(chǔ) IT 功能和非功能要求而達(dá)成的。能以聲明的方式表達(dá)這些要求--使用業(yè)務(wù)域提供的服務(wù)的語(yǔ)法和語(yǔ)義--非常重要。通過(guò)這個(gè)功能，業(yè)務(wù)分析人員可以參與到軟件開(kāi)發(fā)生命周期中來(lái)。

沒(méi)有捷徑，立即動(dòng)手，不要等待

IT 架構(gòu)師在項(xiàng)目的生命周期的初始階段扮演的主要角色之一是捕獲關(guān)于干系人的需求的信息。IT 架構(gòu)師必須聽(tīng)取客戶(hù)和干系人的看法，理解他們的業(yè)務(wù)需求，并系統(tǒng)地以增量方式形成 IT 解決方案的結(jié)構(gòu)更為詳細(xì)的結(jié)構(gòu)。這個(gè)過(guò)程通常不僅是靠通過(guò)經(jīng)驗(yàn)積累就能完成的，而且必須為一種有所控制的方法。

生活中的兩個(gè)事實(shí)也可應(yīng)用到 IT 解決方案的開(kāi)發(fā)中:

幾乎沒(méi)有真正的捷徑。

最好現(xiàn)在就動(dòng)手，而不要等待。

我和客戶(hù)一起工作時(shí)，我常常發(fā)現(xiàn)在構(gòu)建 IT 解決方案中為軟件開(kāi)發(fā)項(xiàng)目記錄的需求級(jí)別非常少。這種定義缺乏的原因是由于將業(yè)務(wù)需求細(xì)化為可操作的 IT 要求是一項(xiàng)很困難的工作，需要經(jīng)驗(yàn)豐富的人員(這就是為什么 IT 架構(gòu)師是極其寶貴的資源的一個(gè)原因)。將業(yè)務(wù)需求細(xì)化為 IT 要求是一項(xiàng)艱巨的任務(wù)，需要將精力放在細(xì)節(jié)上，而且是一個(gè)迭代的過(guò)程。

此處要指出的是，您必須花大量的時(shí)間來(lái)詳細(xì)說(shuō)明您的解決方案的需求。統(tǒng)計(jì)數(shù)據(jù)表明，在前期花的時(shí)間越多，在開(kāi)發(fā)過(guò)程的后期階段花的時(shí)間就越少，從而可以縮短開(kāi)發(fā)周期。如果無(wú)法足夠詳細(xì)(以便能通過(guò)技術(shù)加以實(shí)現(xiàn))而清晰地將干系人的需求用書(shū)面形式表述出來(lái)，您就沒(méi)有完成捕獲項(xiàng)目要求的任務(wù)。

有很多方法可用于將業(yè)務(wù)需求細(xì)化為較高抽象級(jí)要求，然后再將此類(lèi)要求細(xì)化為技術(shù) IT 要求。建模是從干系人捕獲初始功能要求集的一個(gè)主要方法。通過(guò)創(chuàng)建用例、建模過(guò)程流和形成統(tǒng)一建模語(yǔ)言(Unified Modeling Language，UML)交互關(guān)系圖，您可以開(kāi)始將業(yè)務(wù)要求細(xì)化為更為詳細(xì)的定義，系統(tǒng)必須支持或啟用所定義的這些功能。在復(fù)雜環(huán)境中會(huì)使用包括以下內(nèi)容的更為復(fù)雜的方法:

組件業(yè)務(wù)建模 (Component Business Modeling)

面向服務(wù)的模型體系結(jié)構(gòu)
 
這些方法可以確保 IT 要求與業(yè)務(wù)目標(biāo)一致，從而讓公司能夠真正實(shí)現(xiàn) SOA 的價(jià)值主張。

從需求進(jìn)行轉(zhuǎn)換來(lái)選擇要用于構(gòu)造解決方案的技術(shù)或產(chǎn)品可能成為一個(gè)挑戰(zhàn)。架構(gòu)師從過(guò)去項(xiàng)目中獲得的經(jīng)驗(yàn)將影響這些決策，但架構(gòu)師還必須忠實(shí)地對(duì)每個(gè)要求(對(duì)滿(mǎn)足需求極為重要的 IT 功能)進(jìn)行評(píng)估。確定了 IT 功能后，架構(gòu)師可以將這些功能映射為體系結(jié)構(gòu)組件(然后映射到技術(shù)和產(chǎn)品)，從而以增量的方式向他們的解決方案結(jié)構(gòu)添加更為詳細(xì)的定義。在開(kāi)發(fā)解決方案的體系結(jié)構(gòu)時(shí)，架構(gòu)師應(yīng)該利用工具的功能類(lèi)捕獲和管理要求，對(duì)業(yè)務(wù)組織、需求和流程進(jìn)行建模，細(xì)化并將要求映射到 IT 功能，并標(biāo)識(shí)體系結(jié)構(gòu)組件和技術(shù)/產(chǎn)品。(techtarget)