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

申請免費試用、咨詢電話：400-8352-114

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

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

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

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

一個詞:用例

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

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

例如，股票交易 Web 站點的一個用例是"購買股票"，允許用戶通過此站點購買股票。該用例描述了客戶進行何種操作以及站點如何響應(yīng)，而暫時忽略了站點將如何實際實現(xiàn)此行為。

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

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

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

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

記錄流程

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

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

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

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

從一開始就使用 RequisitePro

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

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

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

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

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

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

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

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

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

正確功能的正確解決方案

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

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

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

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

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

捕獲最佳實踐的模式解決方案

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

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

急需:通用技術(shù)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖 1. John Cameron 所做的不確定性分類

"Outside-in"設(shè)計

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

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

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

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

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

使用一點技巧進行迭代和增量改進

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

了解真正的需求

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

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

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

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

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

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

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

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

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

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

簡單項目的需求管理在范圍和深度方面與一系列業(yè)務(wù)或企業(yè)與價值鏈都有所不同。我們曾說過，業(yè)務(wù)需求通常是一個時間點的剪影，可能會發(fā)生徹底的變化。業(yè)務(wù)功能的區(qū)分通常不會隨著時間而發(fā)生徹底變化，而會更加細化?；竟δ茏詈髮⒊蔀樽罱K解決方案的一部分，但任何情況下都應(yīng)由 IT 系統(tǒng)加以支持。

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

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

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

沒有捷徑，立即動手，不要等待

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

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

幾乎沒有真正的捷徑。

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

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

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

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

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

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

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