Hướng dẫn cú pháp sơ đồ Yêu cầu Mermaid.js và Hướng dẫn truy xuất

Sơ đồ Yêu cầu là một công cụ trực quan hóa kỹ thuật chuyên biệt được các kiến trúc sư hệ thống, quản lý sản phẩm và kỹ sư phần mềm sử dụng để lập bản đồ các thông số kỹ thuật, giới hạn hệ thống và các bài kiểm tra xác minh. Được xây dựng dựa trên tiêu chuẩn SysML (Ngôn ngữ mô hình hóa hệ thống), bộ xử lý gốcrequirementDiagramcho phép bạn liên kết các yêu cầu thiết kế trừu tượng trực tiếp với các thành phần hệ thống vật lý và các trường hợp kiểm thử bằng cách khai báo dựa trên văn bản.

Hiểu các thành phần trong sơ đồ Yêu cầu

Sơ đồ Yêu cầu chủ yếu bao gồm hai khối xây dựng cấu trúc khác nhau:Khối Yêu cầu (được dùng để xác định các quy tắc) vàKhối Thành phần (được dùng để mô hình hóa mã nguồn, phần cứng hoặc kịch bản kiểm thử). Sau đó, các mối quan hệ được vẽ giữa các khối này để tạo ra một ma trận truy xuất rõ ràng.

Cấu trúc cú pháp cơ bản

Mỗi sơ đồ bắt đầu bằng phần khai báorequirementDiagramtiêu đề khai báo. Tiếp theo là việc xác định các khối yêu cầu với các thuộc tính lồng ghép, các khối thành phần và các đường mối quan hệ theo hướng.

requirementDiagram
  requirement test_req {
    id: 1
    text: "Hệ thống phải xử lý thanh toán một cách an toàn."
    risk: cao
    verifymethod: test
  }

Phân loại đầy đủ các loại Yêu cầu

Không phải mọi yêu cầu kỹ thuật nào cũng giống nhau. Bộ xử lý cung cấp sáu từ khóa khối khác nhau để phân loại các thông số của bạn về mặt trực quan và ngữ nghĩa. Mỗi loại sẽ thay đổi nhãn tiêu đề được hiển thị bên trong hộp sơ đồ được tạo ra:

  • requirement: Một thông số hệ thống tiêu chuẩn hoặc chung chung.
  • functionalRequirement: Xác định một hành động hoặc khả năng hành vi mà hệ thống phải thực hiện.
  • interfaceRequirement: Xác định các điểm kết nối, trao đổi dữ liệu hoặc giao thức truyền thông giữa các thành phần.
  • performanceRequirement: Đặt các tiêu chí đo lường được về hiệu suất thực thi, chẳng hạn như tốc độ, khả năng mở rộng, băng thông hoặc dung lượng.
  • physicalRequirement: Quy định các giới hạn về vật liệu, kích thước, trọng lượng hoặc giới hạn phần cứng.
  • ràng buộc thiết kế: Hạn chế các lựa chọn phần mềm, phong cách kiến trúc, khung công tác hoặc các tiêu chuẩn tuân thủ.
sơ đồYêu cầu
  ràng buộcThiết kế ràng buộcLỗi {
    id: "CON-04"
    text: "Backend phải duy trì tính tương thích ngược với các luồng PHP 8.2."
    risk: low
    verifymethod: kiểm tra
  }

Tham chiếu Ngữ pháp: Các thành phần Yêu cầu & Các thay đổi

Bảng dưới đây phân tích các từ khóa ngữ nghĩa chính, các thuộc tính bắt buộc và các cấu trúc phân loại được bộ thông dịch yêu cầu nhận diện một cách tự nhiên.

Thành phần Ngữ pháp Loại Yêu cầu Mô tả & Các Thuộc tính Hệ thống Hỗ trợ
Khai báo Chỉ định Từ khóa Khởi tạo bảng vẽ không gian làm việc yêu cầu SysML. Phải sử dụng chính xác sơ đồYêu cầu tiêu đề khối.
Thuộc tính ID Độc nhất id: Chuỗi / Số nguyên Tham số lồng ghép bắt buộc cung cấp chỉ số theo dõi hoặc mã tham chiếu duy nhất bằng chữ số và chữ cái bên trong khung theo dõi của bạn. Được phép sử dụng khoảng trắng hỗn hợp.
Thuộc tính Văn bản text: Chuỗi được đóng dấu Chuỗi mô tả bắt buộc mô tả chi tiết các yêu cầu cụ thể hoặc ràng buộc hành vi của mục. Luôn bao quanh bằng dấu ngoặc kép.
Thuộc tính Rủi ro risk:Cờ mức độ nghiêm trọng Một dấu hiệu tùy chọn theo dõi mức độ nghiêm trọng của rủi ro kiến trúc. Chấp nhận các mã cấp thấp: thấp, trung bình, hoặc cao.
Thuộc tính xác minh phương pháp xác minh:Nhãn phương pháp Một tham số tùy chọn khai báo cách thức quy tắc sẽ được chứng minh. Chấp nhận các giá trị tiêu chuẩn trong kỹ thuật: phân tích, minh chứng, kiểm tra, hoặc thử nghiệm.
Yếu tố hệ thống yếu tốKhối Khai báo một thành phần vật lý, thành phần phần mềm hoặc kịch bản thử nghiệm bằng cú pháp: yếu tố tên_yếu_tố { loại: "kiểu_thành_phần" }.

Các mối quan hệ nâng cao và các liên kết truy xuất

Sức mạnh chính của sơ đồ yêu cầu nằm ở việc kết nối các yêu cầu với các hệ thống thực tế. Các liên kết được vẽ bằng các bộ nối mũi tên đặc biệt, có kiểu (ví dụ như - đáp ứng ->) nhằm thiết lập ý định cấu trúc rõ ràng.

Các toán tử quan hệ được hỗ trợ

Token cú pháp quan hệ Ý nghĩa kỹ thuật chiến lược Quy tắc dòng chảy định hướng
nguồn - chứa -> mục tiêu Phân tích một yêu cầu cha rộng thành một yêu cầu con nhỏ hơn, lồng ghép bên trong. Chỉ từ khối Yêu cầu cha xuống khối Yêu cầu con.
phần tử - đáp ứng -> yêu cầu Chứng minh rằng một thành phần phần mềm hoặc phần cứng vật lý đã thành công trong việc đáp ứng một quy tắc. Chỉ từ phần tửkhối hướng đến khối mục tiêuyêu cầukhối.
phần tử - xác minh -> yêu cầu Chỉ ra rằng một kịch bản kiểm thử cụ thể hoặc trường hợp kiểm thử kiểm tra độ chính xác của một quy tắc. Chỉ từ khối kiểm thửphần tửkhối hướng đến khối mục tiêuyêu cầukhối.
nguồn - sao chép -> mục tiêu Chỉ ra một yêu cầu trùng lặp được ánh xạ hoàn toàn đến một yêu cầu chính nằm ở nơi khác. Chỉ từ bản sao trùng lặp hướng đến khối gốc chính.
nguồn - theo dõi -> mục tiêu Thiết lập mối quan hệ phụ thuộc rộng hoặc mối quan hệ lịch sử giữa hai yêu cầu riêng biệt. Chỉ từ yêu cầu phụ thuộc hướng đến khối mục tiêu chính.
nguồn - suy ra -> mục tiêu Chỉ ra rằng một yêu cầu được tính toán hoặc tạo ra trực tiếp từ một yêu cầu khác. Chỉ từ khối con được suy ra hướng đến khối cha nguồn.
nguồn - tinh chỉnh -> mục tiêu Thêm chiều sâu hoặc độ rõ ràng cho một tài liệu kỹ thuật cấp cao, rất phức tạp. Chỉ từ tài liệu đã được tinh chỉnh hướng đến khối mục tiêu cơ sở.

Các phần tử do người dùng định nghĩa & Thuộc tính mở rộng

Bên cạnh các yêu cầu tiêu chuẩn, elementtừ khóa cho phép bạn ánh xạ các đoạn mã ứng dụng cụ thể, các thành phần phần cứng hoặc các gói phần mềm bên thứ ba vào các đường đi theo dõi của bạn. Mỗi khối element có thể lưu trữ các thuộc tính metadata tùy chỉnh dạng khóa-giá trị bằng cách sử dụng lược đồ type: bên trong các dấu ngoặc nhọn của nó.

requirementDiagram
  element payment_gateway_api {
    type: "Mô-đun Microservice Stripe"
  }
  
  element compliance_audit_log {
    type: "Bảng Cơ sở Dữ liệu Không Thể Thay Đổi"
  }


Bản thiết kế thực tế: Cơ sở hạ tầng bảo mật thương mại điện tử phức tạp

Bản thiết kế toàn diện này theo dõi một hệ sinh thái tuân thủ sản xuất hoàn chỉnh. Nó minh họa quá trình phân rã thông qua contains, ánh xạ các giới hạn hiệu suất, kết nối các mô-đun phần mềm thông qua satisfies, và ánh xạ các trường hợp kiểm thử tích hợp bằng cách sử dụng verifiesvòng lặp.

requirementDiagram
  
  %% Lớp phân cấp Yêu cầu
  requirement security_master_req {
    id: "SEC-001"
    text: "Nền tảng ứng dụng phải duy trì tuân thủ nghiêm ngặt tiêu chuẩn PCI-DSS."
    risk: cao
    verifymethod: test
  }

  performanceRequirement checkout_speed_req {
    id: "PERF-22"
    text: "Các thao tác thiết lập xác thực mã hóa MFA phải được biên dịch trong dưới 200ms."
    risk: trung bình
    verifymethod: analysis
  }

  interfaceRequirement secure_token_req {
    id: "INT-09"
    text: "Các truyền tải dữ liệu API phải sử dụng các Token Web JSON được mã hóa (JWT)."
    risk: cao
    verifymethod: test
  }

  %% Lớp Thành phần Hệ thống
  element auth_service_code {
    type: "Microservice Backend Go"
  }

  element load_tester_script {
    type: "Script Hiệu suất K6"
  }

  element jwt_validator_test {
    type: "Bộ kiểm thử Đơn vị Tích hợp Jest"
  }

  %% Các Đường Mối Quan Hệ Kiến trúc
  security_master_req - contains -> checkout_speed_req
  security_master_req - contains -> secure_token_req
  
  auth_service_code - satisfies -> secure_token_req
  load_tester_script - verifies -> checkout_speed_req
  jwt_validator_test - verifies -> secure_token_req


Những lỗi cú pháp phổ biến & Các giới hạn hệ thống

Khi biên dịch các bản đồ kỹ thuật chính xác, hãy lưu ý những tham số xác thực này để tránh lỗi phân tích cú pháp:

  • Dấu ngoặc kép bắt buộc cho chuỗi:Các khối văn bản và loại (ví dụ như text: "Mô tả", type: "Thành phần") *phải* được bao quanh bằng dấu ngoặc kép. Sử dụng dấu ngoặc đơn hoặc để chuỗi không được bao quanh sẽ khiến trình biên dịch bị sập.
  • Cú pháp thuộc tính nghiêm ngặt: Các thuộc tính bên trong dấu ngoặc nhọn phải sử dụng dấu hai chấm theo sau ngay lập tức bởi các giá trị (ví dụ: id: 1). Bỏ quên dấu hai chấm hoặc viết chúng trên cùng một dòng mà không có khoảng cách thụt lề phù hợp có thể gây ra lỗi.
  • Lựa chọn giá trị hạn chế: Các riskverifymethod tham số chỉ chấp nhận các token hệ thống rõ ràng (ví dụ: low, medium, high cho risk; analysis, demonstration, inspection, test cho verifymethod). Nhập các giá trị tùy chỉnh như risk: extreme sẽ làm hỏng trình xây dựng bố cục.
  • Độ chính xác khoảng cách mũi tên: Các dòng định hướng phải được gõ với khoảng cách trắng bao quanh các toán tử (ví dụ: A - satisfies -> B). Gom chuỗi lại thành A-satisfies->B sẽ bỏ qua các ngoại lệ xử lý hệ thống.
Lên đầu trang