模板
教程
環境
性能
功能
管理
如何將業務需求轉化成IT要求
業務人員使用一種語言來表達他們希望實現的業務目標，而開發人員則使用另一種語言來表述技術要求。而這就是我們為了實現高效率而需要著手處理的問題:理解這兩種語言并執行必要的轉換，以便 IT 能反映業務的需求，并能在適當的時候對業務目標進行更改，使其與 IT 的能力相適應。這并不是一個容易完成的工作，但這正是您能夠獲得很大利益的原因。
一個詞:用例
在業務用例中，參與者是干系人，而系統則是業務本身。
用電影《畢業生》中的方式，我只想對你說一個詞:用例。很多年來，我們都將用例用于對應用程序進行建?！，F在，在面向服務的體系結構 (SOA) 中，我們也使用這個概念來對業務進行建模。
在Alistair Cockburn的《Writing Effective Use Cases》一書中，他將用例定義為“系統干系人之間就系統的行為達成的協定”。用例必須適合所定義的系統范圍，能夠代表此情況下使用系統的主要參與者的觀點，且能夠在一致的抽象層次上表示參與者的系統使用情況。
例如，股票交易Web站點的一個用例是“購買股票”，允許用戶通過此站點購買股票。該用例描述了客戶進行何種操作以及站點如何響應，而暫時忽略了站點將如何實際實現此行為。
可以將用例用于對服務進行建模;我將此稱為服務用例。當用例描述服務時，參與者就是服務使用者，而系統則為服務提供者。與任何用例一樣，此時的重點是服務提供者提供何種行為，而不是如何實現該行為。
還可以將用例用于對業務進行建模。在業務用例中，參與者是干系人——業務用戶（如客戶或員工，甚至股東或政府監管人員），而系統則是業務本身（生產產品并將其銷售給客戶的公司）。業務如何開展？客戶希望業務如何開展？他們愿意為何種服務或產品付費？員工需要業務如何開展才能完成各自的工作？關鍵在于，這些干系人如何與公司進行交互，這些都是業務用例。
獲得了業務用例后，則可以隨后將其鏈接起來，以形成業務流程—公司可以執行的過程。這些流程本身就是業務用例，而復雜的業務用例可以被視為業務流程。簡單地講，這些流程顯示了公司要做什么以及如何做。如前面所述，流程以及每個流程中的步驟都對服務進行建模。
通過用例將公司或公司的一部分建模為由服務組成的業務流程后，隨后的目標就是盡可能多地實現流程和服務的自動化。實現這種自動化的應用程序是采用面向服務的體系結構的應用程序，而現在正在進行 SOA 實踐。
記錄流程
如果客戶不了解業務，架構師有效定義系統要求的幾率都很小。
筆者在與客戶討論新程序或開發工作時，會立即了解業務干系人是否出席或派代表出席。然后，我會希望得到記錄良好的業務流程和數據要求。除非相關工作是一片“處女地”，否則一定會對新應用程序或功能支持的原有的業務流程和將來的業務流程有良好的理解。不管采用哪一種方式，如果客戶不了解業務，架構師有效定義系統要求的幾率就很小。
筆者個人非常贊同開發業務場景來記錄業務流程，業務場景允許在整個業務問題的上下文中標識系統要求。
確定了將來的業務需求后，如果能維護一份功能和非功能行式項目要求的列表，也很有好處。我極力贊同使用工具來管理要求;為了達成此目的，我建議使用 IBM Rational RequisitePro。
通過使用根據業務場景確定的初始要求集，我們就可以開始定義系統行為的過程了。為此，可以召開聯合應用程序開發（JAD）會議，以便根據一系列初始行式項目要求來充實將來的系統。通過JAD會議，架構師可以與干系人一起確定期望的系統行為，并以此為基礎記錄用例和場景。通過對用例和場景進行細化，可以幫助定義最終的一系列功能和非功能要求。
正確功能的正確解決方案
如果我所做的只是將價格信息發布到網上，我可以到最近的小學里找個人來編寫HTML。如果我要做的是嘗試采用多種語言跨越國界擴展我的供應鏈，并確?？梢匀旌虻卦L問，那么我的功能和容量就必須更為可靠。
開發和設計解決方案的體系結構時需要考慮的最重要的事項之一就是所需的對應功能和容量級別。
經驗豐富的專業人員可以幫助客戶將業務需求轉換為業務意圖。業務意圖更為模糊，但更與“基本需求”和“投資回報”一致。
筆者相信業務需求和IT 功能存在重疊。正是由于這個模糊不清的界線使得體系結構設計成為了一個困難而費時的過程。不管是采用瀑布式還是迭代方法，規劃和需求分析階段始終都很單調乏味?？蛻艉苌僦浪麄冃枰裁?，經驗豐富的專業人員有責任幫助客戶將業務需求轉換為IT功能。
這并不能通過只使用良好的工具和方法來實現，因為每個項目都是獨特的。盡管兩家公司相似，但他們都會告訴你各自的業務具有獨特性，并將這些不同之處視為他們的競爭優勢。很多時候，文化、地域和地理位置對業務需求的影響決定著IT解決方案。政府法律法規和標準可能要求技術人員根據部署解決方案的場合對相同的業務需求采用不同的方法來設計。
捕獲和交付構件的技術，包括用例、場景文檔、Rational Unified Process (RUP)—應當在參與的客戶中一致地實現。如果在項目進行中，客戶改變了主意（業務需求）和決定，例如系統不需要24x7的可用性，而只需要8x7的可用性即可，因為他們不希望承擔24x7解決方案所帶來的高成本，仍然可以很好地使用這些構件。
管理不確定性和易變性
由于這是一個與人相關的問題，將組織的業務需求轉換為 IT 要求的挑戰并不能僅靠使用工具或方法得以解決。
業務需求和IT要求有很大部分都是重合的;即對于某些人而言業務需求指的是“我已更改的或新的業務流程是什么樣的？”而對其他人而言，則指的是“我如何借助對應的關鍵成功因素實現一系列業務目標？”還有些人覺得，這可能只意味著為一系列業務干系人提供功能，如新設備或新頁面，或者僅是新的自動化業務規則執行而已。
重要的事實是:業務需求和IT要求之間是否存在差別？這可能會引出一通長篇大論，但我的觀點是，缺乏術語以及用來討論這個問題的共同語言本身就是一個問題。
我們的挑戰是業務需求和要求通常僅得到了部分理解，而且通常具有易變性。很多開發方法都在通過引入迭代開發、工具以及其他技術來適應這個不確定性和易變性。但這些方法僅解決了這個問題的一部分，因為這個不確定性和易變性僅是此問題的一部分而已。在假定特定方法是最優的方法之前，要求流程必須了解要進行的項目的類型。
項目類型因大小、范圍、組織關心的重點、文化、對解決方案的認識、當前環境以及其他因素的不同而有所差異。各種項目類型要求我們對每個項目采用不同的方式來處理將組織的需求轉換為 IT 要求的問題。不同的類型項目要求在開發方法、工具以及應如何管理要求方面采取不同的處理方式。
由于這是一個與人相關的問題，將組織的業務需求轉換為 IT 要求的挑戰并不能僅靠使用工具或方法得以解決。認為可以通過改善工具或創建新開發流程、方法或技術來完全解決此問題的想法是錯誤的。
經驗豐富的專業人員知道將組織的業務需求轉換為 IT 要求的過程中必須根據一系列因素進行調整。這些因素包括:對業務需求了解多少？對IT要求了解多少？最終的解決方案的概貌如何？
這些因素在項目進行期間會不斷地發生變化。這正是采用敏捷編程、IBM Global Services 方法、RUP或其他流程的技術人員不能盲目認為其采用的方法就是正確的方法的眾多原因之一。
沒有捷徑，立即動手，不要等待
如果無法足夠詳細而清晰地將干系人的需求用書面形式表述出來，則您就沒有完成捕獲項目要求的任務。
IT架構師在項目的生命周期的初始階段扮演的主要角色之一是捕獲關于干系人的需求的信息。IT架構師必須聽取客戶和干系人的看法，理解他們的業務需求，并系統地以增量方式形成IT解決方案的結構更為詳細的結構。這個過程通常不僅是靠通過經驗積累就能完成的，而且必須為一種有所控制的方法。
生活中的兩個事實也可應用到 IT 解決方案的開發中: 幾乎沒有真正的捷徑;最好現在就動手，而不要等待。
筆者和客戶一起工作時，我常常發現在構建 IT 解決方案中為軟件開發項目記錄的需求級別非常少。這種定義缺乏的原因是由于將業務需求細化為可操作的 IT 要求是一項很困難的工作，需要經驗豐富的人員（這就是為什么 IT 架構師是極其寶貴的資源的一個原因），將業務需求細化為 IT 要求是一項艱巨的任務，需要將精力放在細節上，而且是一個迭代的過程。
此處要指出的是，必須花大量的時間來詳細說明解決方案的需求。統計數據表明，在前期花的時間越多，在開發過程的后期階段花的時間就越少，從而可以縮短開發周期。
有很多方法可用于將業務需求細化為較高抽象級要求，然后再將此類要求細化為技術 IT 要求。建模是從干系人捕獲初始功能要求集的一個主要方法。通過創建用例、建模過程流和形成統一建模語言（Unified Modeling Language，UML）交互關系圖，您可以開始將業務要求細化為更為詳細的定義，系統必須支持或啟用所定義的這些功能。在復雜環境中會使用包括以下內容的更為復雜的方法:組件業務建?；蛘呙嫦蚍盏哪Ｐ腕w系結構。
這些方法可以確保 IT 要求與業務目標一致，從而讓公司能夠真正實現 SOA 的價值主張。
從需求進行轉換來選擇要用于構造解決方案的技術或產品可能成為一個挑戰。架構師從過去項目中獲得的經驗將影響這些決策，但架構師還必須忠實地對每個要求（對滿足需求極為重要的 IT 功能）進行評估。確定了 IT 功能后，架構師可以將這些功能映射為體系結構組件（然后映射到技術和產品），從而以增量的方式向他們的解決方案結構添加更為詳細的定義。
