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