整。這些因素包括:對業(yè)務(wù)需求了解多少？對IT要求了解多少？最終的解決方案的概貌如何？
　　這些因素在項(xiàng)目進(jìn)行期間會不斷地發(fā)生變化。這正是采用敏捷編程、IBM Global Services 方法、RUP或其他流程的技術(shù)人員不能盲目認(rèn)為其采用的方法就是正確的方法的眾多原因之一。
　　沒有捷徑，立即動(dòng)手，不要等待
　　如果無法足夠詳細(xì)而清晰地將干系人的需求用書面形式表述出來，則您就沒有完成捕獲項(xiàng)目要求的任務(wù)。
　　IT架構(gòu)師在項(xiàng)目的生命周期的初始階段扮演的主要角色之一是捕獲關(guān)于干系人的需求的信息。IT架構(gòu)師必須聽取客戶和干系人的看法，理解他們的業(yè)務(wù)需求，并系統(tǒng)地以增量方式形成IT解決方案的結(jié)構(gòu)更為詳細(xì)的結(jié)構(gòu)。這個(gè)過程通常不僅是靠通過經(jīng)驗(yàn)積累就能完成的，而且必須為一種有所控制的方法。
　　生活中的兩個(gè)事實(shí)也可應(yīng)用到 IT 解決方案的開發(fā)中: 幾乎沒有真正的捷徑;最好現(xiàn)在就動(dòng)手，而不要等待。
　　筆者和客戶一起工作時(shí)，我常常發(fā)現(xiàn)在構(gòu)建 IT 解決方案中為軟件開發(fā)項(xiàng)目記錄的需求級別非常少。這種定義缺乏的原因是由于將業(yè)務(wù)需求細(xì)化為可操作的 IT 要求是一項(xiàng)很困難的工作，需要經(jīng)驗(yàn)豐富的人員（這就是為什么 IT 架構(gòu)師是極其寶貴的資源的一個(gè)原因），將業(yè)務(wù)需求細(xì)化為 IT 要求是一項(xiàng)艱巨的任務(wù)，需要將精力放在細(xì)節(jié)上，而且是一個(gè)迭代的過程。
　　此處要指出的是，必須花大量的時(shí)間來詳細(xì)說明解決方案的需求。統(tǒng)計(jì)數(shù)據(jù)表明，在前期花的時(shí)間越多，在開發(fā)過程的后期階段花的時(shí)間就越少，從而可以縮短開發(fā)周期。
　　有很多方法可用于將業(yè)務(wù)需求細(xì)化為較高抽象級要求，然后再將此類要求細(xì)化為技術(shù) IT 要求。建模是從干系人捕獲初始功能要求集的一個(gè)主要方法。通過創(chuàng)建用例、建模過程流和形成統(tǒng)一建模語言（Unified Modeling Language，UML）交互關(guān)系圖，您可以開始將業(yè)務(wù)要求細(xì)化為更為詳細(xì)的定義，系統(tǒng)必須支持或啟用所定義的這些功能。在復(fù)雜環(huán)境中會使用包括以下內(nèi)容的更為復(fù)雜的方法:組件業(yè)務(wù)建?；蛘呙嫦蚍?wù)的模型體系結(jié)構(gòu)。
　　這些方法可以確保 IT 要求與業(yè)務(wù)目標(biāo)一致，從而讓公司能夠真正實(shí)現(xiàn) SOA 的價(jià)值主張。
　　從需求進(jìn)行轉(zhuǎn)換來選擇要用于構(gòu)造解決方案的技術(shù)或產(chǎn)品可能成為一個(gè)挑戰(zhàn)。架構(gòu)師從過去項(xiàng)目中獲得的經(jīng)驗(yàn)將影響這些決策，但架構(gòu)師還必須忠實(shí)地對每個(gè)要求（對滿足需求極為重要的 IT 功能）進(jìn)行評估。確定了 IT 功能后，架構(gòu)師可以將這些功能映射為體系結(jié)構(gòu)組件（然后映射到技術(shù)和產(chǎn)品），從而以增量的方式向他們的解決方案結(jié)構(gòu)添加更為詳細(xì)的定義。

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

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