升級到 SOA 中的系統需求工程框架

想知道如何升級到面向服務的體系結構（Service-Oriented Architecture，SOA）中的系統需求工程框架（requirements engineering framework，REF）嗎？瞭解與轉換到該框架、軟目標可操作化以及使用約束、風險和更改來完成該框架相關的問題。developerWorks 的作者 Judith Myerson 為您提供了開發軟目標的示例，並建議了使目標可操作化的方法。

引言

“使用多重 SOA 來消除企業系統之間的差異”探索瞭如何從一個或多個 SOA 中重用 Web 服務——以資料為中心和業務邏輯——並將它們合併到組合應用程式中。“SOA 中的緊密耦合 Web Services”研究了緊密耦合和鬆散耦合 Web 服務的優點和缺點，以及緊密耦合所帶來的規模上的最終變化。

這些文章討論了 SOA 開發的不同方面。本文介紹應該如何調整系統 REF 以適應構成 SOA 應用程式的各個 Web 服務，以此作為使用多個 SOA 來縮小系統差距的方式。瞭解業務和系統需求工程如何改進由 SLA Web 服務組成的 SOA 應用程式的效能和系統安全性，這些 Web 服務大部分是鬆散耦合的，只有一小部分是緊密耦合的。

傳統需求工程

作為軟體開發流程中的第一步，傳統需求工程確定新產品或系統所必須滿足的功能性和非功能性需求或條件。

• 功能性需求指定系統或產品必須具有的行為或功能。
• 非功能性需求指定用於確定系統如何執行或工作的質量標準。

定義需求工程並沒有解釋軟體開發流程的為什麼問題；它只是告訴您需要做什麼，以及應該如何在需求工程的引出、分析、驗證和文件說明方面繼續下去。

轉換到系統需求工程框架

要解釋流程，可以轉換到系統 REF。此框架從作為需求的輸入的系統上下文和目標開始，並使用需求的約束和風險完成其執行。該框架響應系統上下文、目標、約束和風險方面的重大更改而重複執行流程。

不要在該框架中忽略的是參與到設計一個或多個目標的涉眾（stakeholder）。涉眾的參與允許分析人員權衡不同涉眾對制定需求（以響應 SOA 約束和風險方面的變化）的不同目標意見。

系統上下文考慮有關構建 SLA Web 服務的需求引出、協商和文件說明所必需的需求源。系統上下文的更改可能使目標更改變得必要。一些系統上下文更改示例包括：

• 用於實現更快響應的高速頻寬升級。
• 企業收購和合並導致的企業網路擴充。
• 實施 SOA 以縮小企業系統差距。
• 緊密耦合的 SLA Web 服務元件。
• 利用未使用資源的網格計算。

必須對所有更改進行版本管理、驗證、文件說明和監視。

使軟目標可操作

目標並非始終是確定和可測量的；有些目標還是軟目標。分析人員需要將軟目標轉換為可實現的需求。在該框架中，在對需求進行實現、驗證和版本管理之後，或在對系統上下文施加新的約束之後，您可以在將軟目標轉換為可實現的需求之前整合新的更改。傳統需求工程不允許您在實現需求之後整合新的更改。

例如，您指定了某個 Web 服務必須使服務可用的硬目標；該服務充當自動 SLA Web 服務。同時，目標發起者或代理之間的協議集中於三個軟目標變數（舉例而言），系統分析人員可以將這些變數轉換為可實現的需求。其中包括正常執行時間可用性、異常和可用性變數。您以後可以進行更改。

第一個軟目標：正常執行時間可用性

第一個軟目標指定必須保證達到 99%（舉例而言）或更多的正常執行時間可用性。目標發起者或分析人員決定要在可用時間低於保證時間時施加什麼懲罰，以及要在可用時間在給定時間段內實現了目標時給予什麼激勵。

第二個軟目標：異常

第二個軟目標指定異常，例如計劃的故障、拒絕服務、計劃的維護、網路中斷和服務提供商控制內的網路問題。在確定提供商做出的哪些服務停用懲罰不公平和不合理之後，目標發起者或分析人員將關注這些異常。當第一個軟目標的條件顯著更改時，分析人員可以新增新的異常或從第二個目標中去掉現有的異常。

對於某些異常，目標發起者可以指定客戶公司獲取合理的補償。太多的異常會導致客戶選擇競爭者的 SLA Web 服務，只要那些服務提供更少的異常、更多的正常業務執行時間和更好的服務保證。該軟目標應該為客戶提供機會以選擇服務提供商允許的異常。

第三個軟目標：可用性變數

第三個軟目標指定服務可用性變數。表 1 顯示了可用性變數的列表以及每個變數的說明。

表 1. 服務可用性變數

可用性變數	說明
有狀態性	伺服器必須在後續狀態中正確地響應。
訪問	未經授權的使用者成功訪問了某個只有管理員才被授權使用的控制元件。
響應時間	Web 服務可用並可靠和快速地響應，否則沒有耐心的使用者會轉而投向競爭者的服務。超過最大響應中斷閾值數量將對響應時間產生負面影響。
版本管理	新的構建不會破壞現有 Web 服務的功能。如果功能被破壞，則使用版本管理過程來恢復功能。
超時	Web 服務需要在超時時採取的步驟。它可以轉到另一個具有相同或不同任務或功能集的 Web 服務。或者，可以向使用者傳送警報，表明該 SLA Web 服務已超時。

當第一或第二軟目標更改時，可用性變數的型別將更改。

可操作化示例

下面檢視一個示例，看看如何操作某個有關訪問可用性變數的軟目標。為了將該軟目標轉換為可實現的需求，您需要構建一個質量模型，然後填充該模型。

例如在構建該模型時，分析人員應該允許涉眾判斷服務的可用性有多迅即。涉眾能夠確定使某個服務對組織可用所需要的時間，以及在服務不中斷的時候下載文件的時間。

然後分析人員使用涉眾所需要的系統行為的相關資料來填充質量模型。擁有正確訪問授權的涉眾可能要求該服務在 99% 的時間內可用，並且每個文件頁的下載時間不超過四秒。類似地，要使某個文件可訪問，涉眾可能要求他們訪問該文件所花的時間不超過 20 秒。

如果涉眾發現服務可用性懲罰不公平和不合理，例如計劃的維護、拒絕服務和不在提供商控制之內的網路中斷，則涉眾和目標分析人員必須就要在質量模型中包括有關異常的什麼資料達成一致。此外，質量模型資料應該包括有關狀態性、訪問、響應時間、版本管理、超時和其他 SLA Web 服務可用性變數的資料。

約束、風險和更改

為了在第一回閤中完成該框架，您需要執行幾個額外的步驟。首先，您需要驗證需求以確保它們按最初預期的那樣正確工作，並假設系統上下文的約束還沒有變化。作為驗證過程的一部分，如果打算通過 Internet 提供由緊密耦合和鬆散耦合的 SLA Web 服務組成的 SOA 應用程式，您需要評估服務可用性風險。如果結果表明風險概率很高，您可能希望更改目標和需求，以將風險緩解到更加可接受的級別。

然而，如果監視表明在完成驗證過程和緩解風險之後出現了新的環境約束，那些約束可能造成負面影響或限制需求。這意味著您需要重新評估施加在系統上下文上的新約束是什麼，哪些當前約束不再適用，以及目標和需求的哪些部分可以重用。

然後將目標作為新的輸入來新增、刪除或轉換為可實現的需求，並在框架中重複執行驗證和風險緩解過程。只需確保在框架的每個階段中對所有更改流程做文件說明，以允許分析人員和其他角色根據需要執行影響分析。

結束語

您需要一個由開發人員、系統管理員和需求開發人員組成的專案團隊，以協作升級到 SOA 中的系統 REF。提前計劃到 REF 的轉換，並將軟目標轉換為可實現的需求。使用約束、風險緩解和變更管理來解決完成該框架所涉及的問題，從而使得更容易轉換到該框架。

您的團隊可以使用 IBM® Rational® RequisitePro® 來管理需求、改進可跟蹤性、加強協作、降低專案風險和提高質量。可以將此軟體與 IBM Rational Portfolio Manager 整合在一起，以提供業務案例管理和活動的定期管理和戰略檢查。還可以使用 IBM Rational Method Composer 來改進已確定更改時的流程，以及使用 IBM Rational ClearQuest® 來通過縮短測試時間提高工作效率。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-420459/，如需轉載，請註明出處，否則將追究法律責任。