概念: 增補需求分解
增補需求分解是一種導出分析(及設計)元素的非功能面需求的技術。
關係
主要說明

簡介

在分析過程中,架構設計師會開發一個初始「位置圖」。「位置」觀點是非功能面的綜合考量,提供一個環境來描述如何解決非功能面需求,例如可靠性和容量。

標準工程慣例可安排產能、規定允許的失敗率等,諸如此類。這項工作可以為每一個位置元素建立一套衍生的增補需求。這些需求將決定位特性。在決定和修正子系統的分割時(分散於各位置),也會重新評論衍生的需求和特性。

系統層次的「增補需求」也會影響子系統本身(硬體、軟體、人),搭配子系統特性及位置特性,可以形成期望的系統特性。

服務品質測量基準值

服務品質 (QoS) 是一種概念,涉及非功能面需求的觀點。這類特性的範圍可能很廣,包括許多的「特性」,例如可靠性、維護性及可用性,甚至是完整的工程特質,例如安全性、人為因素等。重大的工程專業問題通常交由領域專家來解決。有待系統和軟體工程師來解決的問題通常是關於:

  • 效能 - 系統在一段時間內運作的表現如何,亦即回應性、產能、符合底限。
  • 可靠性/失敗容忍度 - 系統在發生故障前可以持續多久來執行必要的功能,以及如何妥善地(適當地)因應局部故障情形。 系統「平均失效時間 (MTBF)」是測量可靠性的一種測量基準值。
  • 維護性 - 保持系統持續運作及診斷和修復系統問題的難易度。 系統「平均修復時間 (MTTR)」是測量維護性的一項測量基準值。

在建構系統之前,系統工程師一定會經常依賴系統模型,以定義替代方案及指派和分配非功能面需求。這些模型經過分析,當可瞭解達到預期服務品質的程度如何,接著就可以選擇解決方案(通常以成本為考量因素)。在系統設計的所有精練層次上,這種權衡分析很重要。可能的解決方案組合幾乎取決於架構設計師的專業能力和經驗。這些解決方案的分析(透過數學模型、模擬等)相當機械化。儘管如此,隨著輸入資料的正確性和模型的準確性,這些分析的可靠性也大不相同。

有許多技術可在模型分析時追蹤上述的 QoS 測量值 - 例如,「速率單調性分析」可檢查即時內嵌軟體系統的效能 [請參閱 Klein, M. H., et al. A Practitioners' Handbook for Real-Time Analysis: Guide to Rate Monotonic Analysis for Real-Time Systems, Kluwer Academic Publishers, 1993],以及用於辨識與認定硬體故障和安全風險的「失效模式效應與關鍵性分析 (FMECA)」 [請參閱 Kececioglu, Dimitri, Reliability Engineering Handbook, Vol. 2,  PTR Prentice Hall, 1991]。

UML 已透過 UML 設定檔來支援這幾種分析,最明顯的有排程性、效能及時間規格的 UML 設定檔服務品質和容錯特性與機制的 UML 設定檔。這些設定檔(可從 www.omg.org 取得)附上 UML 的註解,可利用各種現成和未來的模型分析技術與工具,以分析設定檔中定義的特性及這些特性的量化預測。