正確功能的正確解決方案
如果我所做的只是將價格信息發布到網上，我可以到最近的小學里找個人來編寫 HTML。如果我要做的是嘗試采用多種語言跨越國界擴展我的供應鏈，并確�？梢匀旌虻卦L問，那么我的功能和容量就必須更為可靠。
開發和設計解決方案的體系結構時需要考慮的最重要的事項之一就是所需的對應功能和容量級別。
經驗豐富的專業人員可以幫助客戶將業務需求轉換為業務意圖。業務意圖更為模糊，但更與“基本需求”和“投資回報”一致。
筆者相信業務需求和IT 功能存在重疊。正是由于這個模糊不清的界線使得體系結構設計成為了一個困難而費時的過程。不管是采用瀑布式還是迭代方法，規劃和需求分析階段始終都很單調乏味�？蛻艉苌僦浪麄冃枰裁�，經驗豐富的專業人員有責任幫助客戶將業務需求轉換為IT功能。
這并不能通過只使用良好的工具和方法來實現，因為每個項目都是獨特的。盡管兩家公司相似，但他們都會告訴你各自的業務具有獨特性，并將這些不同之處視為他們的競爭優勢。很多時候，文化、地域和地理位置對業務需求的影響決定著IT解決方案。政府法律法規和 標準可能要求技術人員根據部署解決方案的場合對相同的業務需求采用不同的方法來設計。
捕獲和交付構件的技術，包括用例、場景文檔、Rational Unified Process (RUP)—應當在參與的客戶中一致地實現。如果在項目進行中，客戶改變了主意（業務需求）和決定，例如系統不需要24x7的可用性，而只需要8x7的可用性即可，因為他們不希望承擔24x7解決方案所帶來的高成本，仍然可以很好地使用這些構件。
管理不確定性和易變性
由于這是一個與人相關的問題，將組織的業務需求轉換為 IT 要求的挑戰并不能僅靠使用工具或方法得以解決。
業務需求和IT要求有很大部分都是重合的;即對于某些人而言業務需求指的是“我已更改的或新的業務流程是什么樣的？”而對其他人而言，則指的是“我如何借助對應的關鍵成功因素實現一系列業務目標？”還有些人覺得，這可能只意味著為一系列業務干系人提供功能，如新設備或新頁面，或者僅是新的自動化業務規則執行而已。
重要的事實是:業務需求和IT要求之間是否存在差別？這可能會引出一通長篇大論，但我的觀點是，缺乏術語以及用來討論這個問題的共同語言本身就是一個問題。
我們的挑戰是業務需求和要求通常僅得到了部分理解，而且通常具有易變性。很多開發方法都在通過引入迭代開發、工具以及其他技術來適應這個不確定性和易變性。但這些方法僅解決了這個問題的一部分，因為這個不確定性和易變性僅是此問題的一部分而已。在假定特定方法是最優的方法之前，要求流程必須了解要進行的項目的類型。
項目類型因大小、范圍、組織關心的重點、文化、對解決方案的認識、當前環境以及其他因素的不同而有所差異。各種項目類型要求我們對每個項目采用不同的方式來處理將組織的需求轉換為 IT 要求的問題。不同的類型項目要求在開發方法、工具以及應如何管理要求方面采取不同的處理方式。
由于這是一個與人相關的問題，將組織的業務需求轉換為 IT 要求的挑戰并不能僅靠使用工具或方法得以解決。認為可以通過改善工具或創建新開發流程、方法或技術來完全解決此問題的想法是錯誤的。
經驗豐富的專業人員知道將組織的業務需求轉換為 IT 要求的過程中必須根據一系列因素進行調整。這些因素包括:對業務需求了解多少？對IT要求了解多少？最終的解決方案的概貌如何？
文章來源于領測軟件測試網 http://www.kjueaiud.com/
