VPasCode（圖形即程式碼）用於 SysML 需求圖形 — 完整指南

1. 什麼是需求圖形？

一個需求圖形是一種 SysML 圖形類型，其唯一目的是將需求作為一級模型元素進行捕捉，並使其關係明確且可追蹤。與僅為列表的需求文件不同，需求圖形是一種圖形：需求是節點，它們之間的關係——包含、推導、滿足、驗證與追蹤——則是邊。

核心概念是可追蹤性。在資訊系統中，需求並非孤立存在。利害關係人的需求驅動系統需求；該需求由架構區塊滿足；測試案例驗證它；它也可能被細化為子需求。需求圖形使每一項連結都可見且可審計。這正是將扁平化試算表轉變為模型的原因。

為何在資訊系統中使用它？

資訊專案以需求漂移聞名——範圍蔓延、未受控變更，以及「我們建好了但沒人要求」的問題。需求圖形之所以有幫助，是因為它能讓您：

• 向後追蹤——「此元件為何存在？」→ 追蹤滿足連結至需求，以及推導連結至業務需求。

• 向前追蹤——「此需求是否已驗證？」→ 追蹤驗證連結至測試案例。

• 評估變更影響——「若此需求變更，還有哪些會受影響？」→ 追蹤所有入邊與出邊。

• 證明覆蓋範圍——每個需求都應由某事物 並由 驗證某事物。孤兒需求會立即顯現。

2. 關鍵概念與記號

2.1 需求元素

需求以帶有 的矩形表示名稱、一個 唯一識別碼（通常為層級結構，例如 1.2.3），以及 需求文字。其標記為 «需求».

需求可包含 屬性——形式化建模的屬性，例如 來源, 風險, 優先級, 狀態，或 驗證方法。這些使需求成為 可量測的而非模糊。

2.2 關係（圖表的核心）

關鍵規則：關係絕不會繪製到需求之「ID 字串」ID 字串」——而是繪製到該元素之「別名」。若需求 A「包含」需求 B，則您必須「不得」再繪製一條「衍生」於兩者之間（任一方向）；對於同一對元素，包含與衍生互斥。

2.3 區塊、測試案例與細化來源

• 區塊」 («block»」）：滿足需求之設計元素。在資訊科技脈絡中，此即您的架構元件——服務、模組或 API。

• 測試案例」 («testCase»」）：驗證單元。

• 細化來源」：使用案例、活動，或任何闡述需求之模型元素。

記號註解：關係箭頭具有特定箭頭頭（例如「滿足」箭頭，例如，會朝向被滿足之需求開啟）。當以敘述文字撰寫這些內容時，請務必將標記語法以引號標註——撰寫「`«satisfy»`」——以免被讀者的 Markdown 解析器吞沒。

3. 圖表示例

範例 1 — 基礎需求階層結構

此範例展示了包含與衍生，這是每個需求圖的基礎骨架。頂層效能需求可分解為可量測的次級需求。

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/sysml-requirement-diagram.puml

skinparam vpDiagramType RequirementDiagram
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam linetype ortho

title 車輛效能需求層級

$requirement("車輛效能", ReqVehiclePerf, "1", "車輛在標準操作條件下應符合指定的效能目標。")
$requirement("加速", ReqAccel, "1.1", "車輛應在 6 秒內從 0 加速至 100 km/h。")
$requirement("最高速度", ReqTopSpeed, "1.2", "車輛應達到至少 220 km/h 的最高速度。")
$requirement("煞車", ReqBraking, "1.3", "車輛應在乾燥路面上於 38 公尺內從 100 km/h 煞停。")
$requirement("燃油效率", ReqFuel, "1.4", "車輛在綜合循環中應達到至少 15 km/l 的燃油效率。")

$containment(ReqVehiclePerf, ReqAccel)
$containment(ReqVehiclePerf, ReqTopSpeed)
$containment(ReqVehiclePerf, ReqBraking)
$containment(ReqVehiclePerf, ReqFuel)
$deriveReqt(ReqBraking, ReqVehiclePerf)
@enduml

閱讀內容： 加速, 最高速度, 煞車、以及 燃油效率均為 「車輛效能」 overarching 車輛效能需求（包含關係）。煞車亦為 衍生自，表示其已拆解為具體且可量測的目標。

範例 2 — 滿足與驗證（設計符合需求）

此處加入設計面向。架構元件 滿足需求，而測試案例 驗證它們。此即您在設計審查時所展示的圖表。

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/sysml-requirement-diagram.puml

skinparam vpDiagramType RequirementDiagram
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam linetype ortho

title 支付系統 — 滿足與驗證

$requirement("PCI-DSS 合規性", ReqPci, "3", "系統不得儲存卡片驗證值，並應對靜止狀態下的持卡人資料進行加密。")
$requirement("處理付款", ReqPay, "3.1", "系統應在 3 秒內授權客戶付款。")
$requirement("冪等扣款", ReqIdem, "3.2", "系統在重試時不得對客戶重複扣款。")

$block("PaymentService", PaymentService)
$block("VaultService", VaultService)

$testCase("PCI 審計", TAudit)
$testCase("延遲測試", TLatency)
$testCase("冪等性測試", TIdem)

$containment(ReqPci, ReqPay)
$containment(ReqPci, ReqIdem)

$satisfy(PaymentService, ReqPay)
$satisfy(VaultService, ReqPci)

$verify(TAudit, ReqPci)
$verify(TLatency, ReqPay)
$verify(TIdem, ReqIdem)
@enduml

閱讀說明： PaymentService 滿足 滿足付款處理需求，而 VaultService 滿足 滿足更廣泛的 PCI-DSS 需求。每個需求均 經驗證 由測試案例驗證。請注意箭頭方向： `«satisfy»` 從模組指向其滿足的需求； `«verify»` 從測試案例指向其驗證的需求。

範例 3 — 完整的 IT 系統追蹤鏈

這是您用來追蹤「業務需求」至「驗證」階段的圖表，即經典的「這段程式碼為何存在？」之疑問。 — 即經典的「這段程式碼為何存在？」之疑問。

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/sysml-requirement-diagram.puml

skinparam vpDiagramType RequirementDiagram
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam linetype ortho

title 電子商務系統 — 需求追蹤

$requirement("業務：降低購物車放棄率", ReqBiz, "B1", "業務單位應在兩個季內將購物車放棄率降低 15%。")
$requirement("結帳使用者體驗", ReqUx, "S1", "系統應允許訪客在 5 個步驟內完成結帳。")
$requirement("一鍵重購", ReqReorder, "S2", "系統應讓回頭客透過單一動作重購過往訂單。")
$requirement("資料 residency", ReqResidency, "S3", "系統應將歐盟客戶資料儲存於歐盟境內區域。")

$block("CheckoutUI", CheckoutUI)
$block("ReorderService", ReorderService)
$block("RegionalDatastore", RegionalDatastore)

$testCase("結帳流程測試", TCheckout)
$testCase("重購測試", TReorder)
$testCase("residency 審計", TResidency)

$containment(ReqBiz, ReqUx)
$containment(ReqBiz, ReqReorder)
$deriveReqt(ReqUx, ReqBiz)
$deriveReqt(ReqReorder, ReqBiz)

$satisfy(CheckoutUI, ReqUx)
$satisfy(ReorderService, ReqReorder)
$satisfy(RegionalDatastore, ReqResidency)

$verify(TCheckout, ReqUx)
$verify(TReorder, ReqReorder)
$verify(TResidency, ReqResidency)

$trace(ReqResidency, ReqBiz)
@enduml

閱讀說明： 業務需求 B1 是整體的基礎。系統需求 S1 與 S2 是 源自 它（即「為什麼」），而 S3（資料駐留）是 可追溯 限制僅透過 `「追蹤」`。每個系統需求 由元件滿足 並由 測試驗證。若 B1 發生變更，此圖表會立即告訴您哪些元件與測試在範圍內。

4. 如何建立（實務工作流程）

1. 從最高層級的需求開始。 通常是業務或利害關係人的需求。為其分配清晰的 ID 空間（例如 B* 代表業務， S* 代表系統）。

2. 以包含關係向下分解。 將大型需求拆解為較小的、 可衡量 需求。良好的需求文字應包含數值（例如「低於 3 秒」、「15%」、「位於歐盟區域內」）。

3. 在子需求為具體重述之處新增推導連結，而不僅僅是部分。請記住：一組配對可透過包含關係連結 或 推導關係，絕不可同時使用兩者。

4. 以「滿足」將設計映射至需求滿足.每個架構區塊都應滿足至少一項需求。無法滿足任何需求的區塊可考慮刪除；未被任何內容滿足的需求則代表覆蓋缺口。

5. 以「驗證」將測試映射至需求驗證.每項需求都必須有驗證路徑。若無任何內容可驗證某項需求，則該需求無法測試——這是危險信號。

6. 僅在無其他合適選項時使用「追蹤」追蹤僅在無其他合適選項時使用「追蹤」它是處理鬆散關聯的逃生通道；過度使用會稀釋其價值。

7. 將其控制在約 24 個元素以內。大型圖表會變得難以閱讀。請按子系統或需求類別（安全性、效能、功能）進行拆分。

三個覆蓋問題

針對每張需求圖表執行以下檢查清單：

• 每項需求是否都已滿足？（若是系統需求，則必須有內容能實現它）

• 每項需求是否都已驗證？（必須有內容能證明它）

• 每項需求是否都能追蹤至一項需求？（不得有無業務依據的孤兒需求浮現）

任何「否」即為發現問題。

5. 應用於資訊系統 — 模式與陷阱

良好實踐

• 以視覺方式區分需求「類型」類型以視覺方式區分需求「類型」您可以為需求套用標記（「功能」「功能」, 「效能」, 「安全性」, 「可用性」) 以便非功能性需求能與功能性需求區分開來。

• 保持 ID 層級具有意義。 2.3.4應讓讀者了解此需求位於模組 2、功能 3、子功能 4 之下。圖表之間以及您使用的應用生命週期管理（ALM）工具之間的一致性至關重要。

• 對來源進行建模。新增一個「來源」屬性（法規、利害關係人名稱、市場需求文件）。追溯至「起源」通常比追溯至設計更為重要。

• 一張圖表，一個關注點。滿足度圖表（設計審查）與驗證圖表（測試審查）面向不同的受眾。切勿將兩者以及整個層級結構擠進同一張圖中。

常見陷阱

• 推導與包含關係混淆。它們外觀相似，但含義不同。包含關係是「結構分解」；推導關係是「意圖的邏輯演進」。將兩者混用（或在同一對元素之間同時繪製兩者）會使模型無效。

• 以 ID 而非別名進行引用。在工具中，關聯係綁定至元素的「別名」，而非人類可讀的 ID 字串。別名設定錯誤，則該關聯係將靜默地指向無效目標。

• 將「追蹤 作為 滿足.追蹤連結並不表示目標滿足任何內容。如果您想表達「此元件實作此需求」，請使用 `«滿足»`.

• 未編號的需求。「系統必須快速」無法驗證。缺乏可測量閾值的需求只是願望，而非正式需求。

• 讓圖表成為規格書。 圖表顯示 關係；需求 文字與屬性承載詳細資訊。保持文字精確，並附加屬性（狀態、優先級、風險），使模型可被查詢。

6. 工具

您可以使用 VPasCode — 貼上程式碼，圖表將立即渲染。接著您還可以匯出或進一步優化它。

快速參考：元素與關係巨集

$requirement("Name", alias, "id", "Requirement text")
$block("BlockName", alias)
$testCase("TestCaseName", alias)

$containment(parentAlias, childAlias)
$deriveReqt(childAlias, parentAlias)
$satisfy(blockAlias, requirementAlias)
$verify(testCaseAlias, requirementAlias)
$refine(modelAlias, requirementAlias)
$trace(fromAlias, toAlias)
$copy(fromAlias, toAlias)

摘要

需求圖是 可追蹤性的骨幹的模型。對於資訊系統，它能回答每項稽核、設計審查與變更請求所提出的三個問題： 為何存在？由何實作？如何證明？善用此法——搭配可量化的需求文字、正確的關係語意，以及嚴謹的覆蓋度檢查——即可將需求從靜態文件轉化為活潑且可查詢的模型，確保設計、程式碼與測試與業務意圖保持一致。

參考資料

1. VPasCode：結合 PlantUML、Mermaid 與 Graphviz 的 AI 輔助圖表即程式碼工具：官方指南涵蓋 AI 輔助圖表生成、修改工作流程，以及對 PlantUML、Mermaid 與 Graphviz 等多種領域特定語言（DSL）的支援。
2. Visual Paradigm VPasCode：綜合指南: VPasCode 功能、目標用戶（開發人員、架構師、分析師）及其在敏捷文檔工作流程中角色的詳細概述。
3. 歡迎使用 Visual Paradigm VPasCode：轉向圖形即代碼（DaC）: 介紹統一的平台，說明從文本到圖形的工作流程優勢以及自動化佈局工程。
4. 60 秒快速入門指南 | VPasCode 文本轉圖形指南: 使用帶有即時預覽的瀏覽器編輯器創建、自定義和導出圖形的逐步指南。
5. VPasCode 新功能：AI UML 配置文件圖形生成器: 產品更新，引入基於純英文提示的 AI 驅動 UML 配置文件圖形生成，並提供醫療保健數據隱私合規的示例。
6. Visual Paradigm VPasCode 中的原生 AI 圖形生成: 宣佈在編輯器內直接通過自然語言提示生成、修改和修復圖形的內嵌 AI 功能。
7. AI 驅動圖形生成器與生產力工具 | VPasCode: 概述 VPasCode 與 AI 聊天機器人、Visual Paradigm Desktop 及 OpenDocs 的整合，以實現簡化的文檔管線。
8. 最佳 PlantUML 替代方案及免費圖形即代碼編輯器: PlantUML 替代方案的比較矩陣，突出 VPasCode 的多 DSL 支持、AI 功能以及基於瀏覽器的零設置方法。
9. 圖形即代碼編輯器：即時將文本轉換為圖形: 功能概述，涵蓋自動格式檢測、實時渲染以及多格式導出選項（SVG、PNG、PDF）。
10. Visual Paradigm 生態系統指南: 說明何時使用 VPasCode 與 VP Desktop，並提供關於版本控制圖形維護及與動態文檔整合的指導。