VPasCode (Sơ đồ dưới dạng mã) cho Sơ đồ Yêu cầu SysML — Hướng dẫn Toàn diện

1. Sơ đồ Yêu cầu là gì?

Mộtsơ đồ yêu cầu là một loại sơ đồ SysML có mục đích duy nhất làghi nhận các yêu cầu dưới dạng các phần tử mô hình cấp cao và làm cho các mối quan hệ giữa chúng trở nên rõ ràng và có thể truy vết. Không giống như một tài liệu yêu cầu (chỉ là một danh sách), một sơ đồ yêu cầu là mộtđồ thị: các yêu cầu là các nút, và các mối quan hệ giữa chúng — bao gồm sự bao hàm, suy ra, thỏa mãn, xác minh và truy vết — là các cạnh.

Ý tưởng cốt lõi làkhả năng truy vết. Trong một hệ thống CNTT, một yêu cầu không tồn tại biệt lập. Nhu cầu của bên liên quan thúc đẩy một yêu cầu hệ thống; yêu cầu đó được thỏa mãn bởi một khối kiến trúc; một trường hợp kiểm thử xác minh nó; và nó có thể được tinh chỉnh thành các yêu cầu con. Sơ đồ yêu cầu làm cho mọi liên kết trong số đó trở nên hiển thị và có thể kiểm toán. Đó chính là điều biến một bảng tính phẳng thành một mô hình.

Tại sao sử dụng nó cho các hệ thống CNTT?

Các dự án CNTT nổi tiếng vớisự trôi dạt yêu cầu — sự mở rộng phạm vi, các thay đổi không được quản lý và vấn đề “chúng tôi đã xây dựng nó nhưng không ai yêu cầu nó”. Một sơ đồ yêu cầu giúp ích vì nó cho phép bạn:

• Truy vết ngược — “Tại sao thành phần này lại tồn tại?” → theo dõithỏa mãn liên kết lên yêu cầu, vàsuy ra liên kết lên nhu cầu kinh doanh.
• Truy vết thuận — “Yêu cầu này đã được xác minh chưa?” → theo dõixác minh liên kết đến các trường hợp kiểm thử.
• Đánh giá tác động của thay đổi — “Nếu yêu cầu này thay đổi, những gì khác bị ảnh hưởng?” → theo dõi mọi cạnh đi vào và đi ra.
• Chứng minh phạm vi bao phủ — mỗi yêu cầu phải được thỏa mãn bởimột cái gì đó và được xác minh bởi một cái gì đó. Các yêu cầu bị cô lập sẽ hiển thị ngay lập tức.

2. Các khái niệm và ký hiệu chính

2.1 Phần tử yêu cầu

Một yêu cầu được vẽ dưới dạng hình chữ nhật với một tên, một ID duy nhất (thường có tính phân cấp, như 1.2.3), và văn bản yêu cầu. Phần tử giả định là «yêu cầu».

Yêu cầu có thể chứa thuộc tính — các thuộc tính được mô hình hóa chính thức như nguồn, rủi ro, mức độ ưu tiên, trạng thái, hoặc phương pháp xác minh. Những điều này biến một yêu cầu thành có thể đo lường được thay vì mơ hồ.

2.2 Các mối quan hệ (trái tim của sơ đồ)

Quy tắc quan trọng: Một quan hệ không bao giờ được vẽ đến chuỗi ID — nó được vẽ đến biệt danh. Và nếu yêu cầu A chứa yêu cầu B, bạn phải không vẽ thêm một «derive» giữa chúng theo bất kỳ hướng nào; việc chứa và suy dẫn là loại trừ lẫn nhau đối với cùng một cặp.

2.3 Khối, trường hợp kiểm thử và nguồn tinh chỉnh

• Khối («block»): phần tử thiết kế đáp ứng các yêu cầu. Trong ngữ cảnh CNTT, đây là thành phần kiến trúc của bạn — một dịch vụ, mô-đun hoặc API.
• Trường hợp kiểm thử («testCase»): đơn vị xác minh.
• Nguồn tinh chỉnh: các trường hợp sử dụng, hoạt động hoặc bất kỳ phần tử mô hình nào làm rõ một yêu cầu.

Ghi chú ký hiệu: các mũi tên quan hệ có đầu mũi tên cụ thể (ví dụ, mũi tên «satisfy» chẳng hạn, hướng về phía yêu cầu đang được đáp ứng). Khi viết về chúng trong văn bản, luôn trích dẫn phần biệt danh — viết `«satisfy»` — để nó không bị trình biên dịch markdown của người đọc nuốt chửng.

3. Ví dụ biểu đồ

Ví dụ 1 — Một phân cấp yêu cầu nền tảng

Ví dụ này minh họa sự bao hàm và suy dẫn, là khung xương mà mọi sơ đồ yêu cầu đều bắt đầu. Một yêu cầu hiệu suất cấp cao được phân rã thành các yêu cầu con có thể đo lường được.

@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 Phân cấp Yêu cầu Hiệu suất Xe

$requirement("Hiệu suất Xe", ReqVehiclePerf, "1", "Xe phải đáp ứng các mục tiêu hiệu suất được chỉ định trong điều kiện vận hành danh định.")
$requirement("Gia tốc", ReqAccel, "1.1", "Xe phải tăng tốc từ 0 đến 100 km/h trong dưới 6 giây.")
$requirement("Tốc độ tối đa", ReqTopSpeed, "1.2", "Xe phải đạt tốc độ tối thiểu 220 km/h.")
$requirement("Phanh", ReqBraking, "1.3", "Xe phải dừng lại từ 100 km/h trong dưới 38 mét trên mặt đường khô.")
$requirement("Hiệu suất nhiên liệu", ReqFuel, "1.4", "Xe phải đạt ít nhất 15 km/l trên chu trình kết hợp.")

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

Đọc nó: Gia tốc, Tốc độ tối đa, Phanh, và Hiệu suất nhiên liệu đều là các phần của yêu cầu tổng thể Hiệu suất Xe (bao hàm).Phanh cũng được suy dẫn từ nó, có nghĩa là nó đã được tách ra thành một mục tiêu cụ thể và có thể đo lường được.

Ví dụ 2 — Sự đáp ứng và xác minh (thiết kế đáp ứng yêu cầu)

Điều này bổ sung khía cạnh thiết kế. Các thành phần kiến trúc đáp ứng các yêu cầu, và các trường hợp kiểm thử xác minh chúng. Đây là sơ đồ bạn sẽ trình bày trong cuộc họp xem xét thiết kế.

@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 Hệ thống Thanh toán — Sự thỏa mãn và Xác minh

$requirement("Tuân thủ PCI-DSS", ReqPci, "3", "Hệ thống không được lưu trữ giá trị xác minh thẻ và phải mã hóa dữ liệu chủ thẻ khi lưu trữ.")
$requirement("Xử lý Thanh toán", ReqPay, "3.1", "Hệ thống phải xác thực thanh toán của khách hàng trong vòng 3 giây.")
$requirement("Ghi Nợ Đơn Nhất", ReqIdem, "3.2", "Hệ thống không được tính phí kép cho khách hàng khi thử lại.")

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

$testCase("Kiểm toán PCI", TAudit)
$testCase("Kiểm tra Độ trễ", TLatency)
$testCase("Kiểm tra Tính Đơn nhất", TIdem)

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

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

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

Đọc nó: PaymentService thỏa mãn yêu cầu xử lý thanh toán, trong khi VaultService thỏa mãn yêu cầu PCI-DSS rộng hơn. Mỗi yêu cầu đều được xác minh bởi một trường hợp kiểm thử. Hãy chú ý hướng của các mũi tên: `«satisfy»` chỉ từ khối đến yêu cầu mà nó đáp ứng; `«verify»` chỉ từ trường hợp kiểm thử đến yêu cầu mà nó chứng minh.

Ví dụ 3 — Chuỗi truy vết toàn diện của hệ thống CNTT

Đây là sơ đồ bạn sẽ dùng để truy vết một nhu cầu kinh doanh cho đến khi xác minh — câu hỏi kinh điển “tại sao đoạn mã này lại tồn tại?”

@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 Hệ thống Thương mại Điện tử — Truy vết Yêu cầu

$requirement("Kinh doanh: Giảm tỷ lệ bỏ giỏ hàng", ReqBiz, "B1", "Doanh nghiệp phải giảm tỷ lệ bỏ giỏ hàng 15% trong vòng hai quý.")
$requirement("UX Thanh toán", ReqUx, "S1", "Hệ thống phải cho phép khách không đăng ký hoàn tất thanh toán trong dưới 5 bước.")
$requirement("Đặt lại Đơn hàng Một cú nhấp", ReqReorder, "S2", "Hệ thống phải cho phép khách hàng quay lại đặt lại một đơn hàng trước đó chỉ bằng một thao tác.")
$requirement("Định vị Dữ liệu", ReqResidency, "S3", "Hệ thống phải lưu trữ dữ liệu khách hàng EU trong các khu vực EU.")

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

$testCase("Kiểm tra Luồng Thanh toán", TCheckout)
$testCase("Kiểm tra Đặt lại", TReorder)
$testCase("Kiểm toán Định vị", 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

Đọc nó: Yêu cầu kinh doanh B1 là điểm neo cho mọi thứ. Các yêu cầu hệ thống S1 và S2 là được suy ra từ nó (tức là “tại sao”), trong khi S3(tính lưu trữ dữ liệu) là một có thể truy vết ràng buộc chỉ được liên kết bởi `«trace»`. Mỗi yêu cầu hệ thống đều được đáp ứng bởi một thành phần và được xác minh bởi một bài kiểm tra. Nếu B1 thay đổi, biểu đồ này sẽ cho bạn biết ngay lập tức những thành phần và bài kiểm tra nào nằm trong phạm vi.

4. Cách xây dựng một biểu đồ (quy trình thực tiễn)

1. Bắt đầu từ nhu cầu cấp cao nhất. Thông thường là yêu cầu của doanh nghiệp hoặc bên liên quan. Gán cho nó một không gian ID rõ ràng (ví dụ: B* cho doanh nghiệp, S* cho hệ thống).
2. Phân rã xuống dưới bằng cách sử dụng quan hệ bao hàm. Chia các yêu cầu lớn thành các yêu cầu nhỏ hơn, có thể đo lường được những yêu cầu đó. Văn bản yêu cầu tốt phải chứa một con số (“dưới 3 giây”, “15%”, “trong khu vực EU”).
3. Thêm các liên kết suy ra ở nơi mà yêu cầu con là một phát biểu cụ thể, không chỉ là một phần. Hãy nhớ: một cặp có thể được liên kết bằng quan hệ bao hàm hoặc suy ra, không bao giờ là cả hai.
4. Ánh xạ thiết kế sang yêu cầu bằng cách sử dụng thỏa mãn.Mỗi khối kiến trúc nên thỏa mãn ít nhất một yêu cầu. Các khối không thỏa mãn gì là ứng viên để xóa; các yêu cầu không được thỏa mãn bởi gì là khoảng trống phủ.
5. Ánh xạ bài kiểm tra bằng cách sử dụng xác minh.Mỗi yêu cầu đều cần một đường dẫn xác minh. Các yêu cầu không được xác minh bởi gì là không thể kiểm thử — một dấu hiệu cảnh báo.
6. Sử dụng theo dõichỉ khi không có cách nào khác phù hợp.Đây là lối thoát cho các mối liên kết lỏng lẻo; lạm dụng nó làm giảm giá trị.
7. Giữ nó dưới khoảng 24 phần tử.Các sơ đồ lớn trở nên khó đọc. Chia theo phân hệ hoặc theo nhóm yêu cầu (bảo mật, hiệu năng, chức năng).

Ba câu hỏi về phủ

Thực hiện danh sách kiểm tra này đối với mọi sơ đồ yêu cầu:

• Mọi yêu cầu đều được thỏa mãn?(nếu đó là yêu cầu hệ thống, thì phải có thứ gì đó hiện thực hóa nó)
• Mọi yêu cầu đều được xác minh?(phải có thứ gì đó chứng minh nó)
• Mọi yêu cầu đều theo dõi lên đến một nhu cầu?(không có yêu cầu mồ côi trôi nổi mà không có lý do kinh doanh)

Bất kỳ câu trả lời “không” nào đều là một phát hiện.

5. Áp dụng vào Hệ thống CNTT — Các Mẫu & Rủi ro

Thực hành tốt

• Tách biệt yêu cầu loạimột cách trực quan.Bạn có thể áp dụng biệt danh cho yêu cầu («chức năng», «hiệu suất», «bảo mật», «tính khả dụng») để các yêu cầu phi chức năng nổi bật so với các yêu cầu chức năng.
• Giữ cho thứ bậc ID có ý nghĩa. 2.3.4 nên cho người đọc biết rằng yêu cầu này nằm dưới mô-đun 2, tính năng 3, tiểu tính năng 4. Tính nhất quán giữa các sơ đồ và công cụ ALM của bạn là rất quan trọng.
• Mô hình hóa nguồn gốc. Thêm một nguồn thuộc tính (quy định, tên bên liên quan, tài liệu yêu cầu thị trường). Khả năng truy vết đến gốc thường quan trọng hơn khả năng truy vết đến thiết kế.
• Một sơ đồ, một mối quan tâm. Một sơ đồ thỏa mãn (đánh giá thiết kế) và một sơ đồ xác minh (đánh giá kiểm thử) có đối tượng khác nhau. Đừng nhồi nhét cả hai cùng toàn bộ thứ bậc vào một hình ảnh.

Các lỗi phổ biến

• Nhầm lẫn giữa suy diễn và chứa đựng. Chúng trông giống nhau nhưng mang ý nghĩa khác nhau. Chứa đựng là phân rã cấu trúc; suy diễn là sự tiến hóa logic của ý định. Trộn lẫn chúng (hoặc vẽ cả hai giữa một cặp) sẽ làm cho mô hình không hợp lệ.
• Tham chiếu theo ID thay vì biệt danh. Trong công cụ, các mối quan hệ liên kết với phần tử biệt danh chứ không phải chuỗi ID có thể đọc được bằng con người. Hãy đặt biệt danh đúng, nếu không mối quan hệ sẽ vô tình không trỏ đến bất kỳ thứ gì.
• Xử lý theo dõi là thỏa mãn. Một liên kết theo dõi không khẳng định mục tiêu đáp ứng bất kỳ điều gì. Nếu bạn muốn nói “thành phần này thực hiện yêu cầu này,” hãy sử dụng `«thỏa mãn»`.
• Yêu cầu không có số. “Hệ thống phải nhanh” không thể được xác minh. Một yêu cầu không có ngưỡng đo lường được chỉ là một mong ước, không phải là một yêu cầu.
• Để sơ đồ trở thành tài liệu đặc tả. Sơ đồ hiển thị các mối quan hệ; yêu cầu văn bản và thuộc tínhchứa đựng chi tiết. Hãy giữ văn bản chính xác và gắn các thuộc tính (trạng thái, mức độ ưu tiên, rủi ro) để mô hình có thể truy vấn được.

6. Công cụ

Bạn có thể hiển thị các sơ đồ này trực tiếp từ mã nguồn PlantUML được hiển thị ở trên bằng cách sử dụng VPasCode — dán mã, và sơ đồ sẽ được hiển thị ngay lập tức. Từ đó, bạn cũng có thể xuất hoặc tinh chỉnh nó.

Tài liệu tham khảo nhanh: các macro phần tử và mối quan hệ

$requirement("Tên", bí danh, "id", "Văn bản yêu cầu")
$block("TênKhối", bí danh)
$testCase("TênKiểmTra", bí danh)

$containment(bíDanhCha, bíDanhCon)
$deriveReqt(bíDanhCon, bíDanhCha)
$satisfy(bíDanhKhối, bíDanhYêuCầu)
$verify(bíDanhKiểmTra, bíDanhYêuCầu)
$refine(bíDanhMôHình, bíDanhYêuCầu)
$trace(bíDanhTừ, bíDanhĐến)
$copy(bíDanhTừ, bíDanhĐến)

Tóm tắt

Sơ đồ yêu cầu là xương sống theo dõi của một mô hình. Đối với các hệ thống CNTT, nó trả lời ba câu hỏi mà mọi cuộc kiểm toán, đánh giá thiết kế và yêu cầu thay đổi đều đặt ra: Tại sao điều này tồn tại? Cái gì thực hiện nó? Cái gì chứng minh nó? Được sử dụng hiệu quả — với văn bản yêu cầu có thể đo lường được, ngữ nghĩa mối quan hệ chính xác và các kiểm tra phạm vi có kỷ luật — nó biến yêu cầu từ một tài liệu tĩnh thành một mô hình sống, có thể truy vấn, giúp giữ cho thiết kế, mã nguồn và kiểm thử luôn phù hợp với ý định kinh doanh.

Tài liệu tham khảo

1. VPasCode: Sơ đồ dưới dạng mã được hỗ trợ bởi AI với PlantUML, Mermaid và Graphviz: Hướng dẫn chính thức bao gồm việc tạo sơ đồ được hỗ trợ bởi AI, quy trình chỉnh sửa và hỗ trợ đa DSL bao gồm PlantUML, Mermaid và Graphviz.
2. Visual Paradigm VPasCode: Hướng dẫn toàn diện: Tổng quan chi tiết về các tính năng của VPasCode, người dùng mục tiêu (nhà phát triển, kiến trúc sư, nhà phân tích) và vai trò của nó trong quy trình làm việc tài liệu Agile.
3. Chào mừng đến với Visual Paradigm VPasCode: Sự chuyển dịch sang Sơ đồ dưới dạng Mã (DaC): Giới thiệu về nền tảng thống nhất, giải thích các lợi ích của quy trình làm việc từ văn bản sang sơ đồ và kỹ thuật bố cục tự động.
4. Hướng dẫn Khởi động Nhanh 60 giây | Hướng dẫn VPasCode Chuyển văn bản sang Sơ đồ: Hướng dẫn từng bước để tạo, tùy chỉnh và xuất sơ đồ bằng trình duyệt có trình soạn thảo dựa trên trình duyệt với xem trước trực tiếp.
5. Tính năng mới trong VPasCode: Công cụ tạo Sơ đồ Hồ sơ UML bằng AI: Cập nhật sản phẩm giới thiệu khả năng tạo Sơ đồ Hồ sơ UML bằng AI sử dụng các lệnh bằng tiếng Anh đơn giản, kèm theo ví dụ về tuân thủ quyền riêng tư dữ liệu trong lĩnh vực chăm sóc sức khỏe.
6. Tạo sơ đồ AI bản địa trong Visual Paradigm VPasCode: Thông báo về các khả năng AI nhúng để tạo, sửa đổi và sửa lỗi sơ đồ thông qua các lệnh bằng ngôn ngữ tự nhiên trực tiếp trong trình soạn thảo.
7. Công cụ tạo sơ đồ và công cụ năng suất được hỗ trợ bởi AI | VPasCode: Tổng quan về các tích hợp của VPasCode với trợ lý ảo AI, Visual Paradigm Desktop và OpenDocs để tối ưu hóa quy trình tài liệu.
8. Các giải pháp thay thế PlantUML tốt nhất & Trình soạn thảo Sơ đồ dưới dạng Mã miễn phí: Bảng so sánh các giải pháp thay thế PlantUML, làm nổi bật khả năng hỗ trợ đa DSL của VPasCode, các tính năng AI và phương pháp tiếp cận không cần cài đặt dựa trên trình duyệt.
9. Trình soạn thảo Sơ đồ dưới dạng Mã: Chuyển đổi Văn bản sang Sơ đồ Ngay lập tức: Tổng quan về các tính năng bao gồm phát hiện định dạng tự động, hiển thị thời gian thực và các tùy chọn xuất đa định dạng (SVG, PNG, PDF).
10. Hướng dẫn về Hệ sinh thái Visual Paradigm: Giải thích khi nào nên sử dụng VPasCode so với VP Desktop, kèm theo hướng dẫn về việc bảo trì sơ đồ có kiểm soát phiên bản và tích hợp với tài liệu sống.

This post is also available in Deutsch, English, Español, فارسی, Français, English, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, 简体中文 and 繁體中文.