← All diagram types

Mermaid requirement diagram syntax: requirements, elements and relations with examples

Mermaid requirementDiagram syntax with rendered examples: typed requirement blocks and their fields, elements, and the seven relation types.

A requirement diagram is the SysML view of what a system must do and how that is evidenced: requirement boxes, the elements that satisfy or verify them, and typed relations between the two.

Everything on this page is rendered by makesPDF's own Mermaid renderer, so a ```mermaid block produces exactly this in the PDF.

A requirement block

requirement <id> { … } opens a block, and the fields inside are key: value lines. Mermaid defines four for a requirement: id, text, risk and verifymethod:

mermaid
requirementDiagram
  requirement checkout {
    id: LIB-1
    text: Patrons can check out books at the kiosk.
    risk: high
    verifymethod: test
  }
Render this to PDF →How diagram blocks work

Each field is drawn as a row in the box under the stereotype header, so the requirement reads as a record rather than a label.

Requirement kinds

The kind is the keyword before the id, and it sets the stereotype shown in the box. Besides requirement there are functionalRequirement, performanceRequirement, interfaceRequirement, physicalRequirement and designConstraint:

mermaid
requirementDiagram
  functionalRequirement scan {
    id: LIB-1.1
    text: The scanner reads ISBN barcodes on the first pass.
    risk: medium
    verifymethod: inspection
  }
  performanceRequirement speed {
    id: LIB-1.2
    text: Checkout completes within two seconds.
    risk: medium
    verifymethod: demonstration
  }
  designConstraint offline {
    id: LIB-3
    text: The kiosk runs an open-source OS only.
    risk: low
    verifymethod: inspection
  }
Render this to PDF →How diagram blocks work

Elements

element <id> { … } declares a system element — the thing that implements or verifies requirements. Its fields are type and docref:

mermaid
requirementDiagram
  element kiosk {
    type: hardware
    docref: specs/kiosk-rev-c
  }
  requirement fits {
    id: LIB-2
    text: The kiosk fits a 60cm countertop.
    risk: low
    verifymethod: inspection
  }
  kiosk - satisfies -> fits
Render this to PDF →How diagram blocks work

Relations

A relation is source - type -> target, and the seven types are contains, copies, derives, satisfies, verifies, refines and traces:

mermaid
requirementDiagram
  requirement checkout {
    id: LIB-1
    text: Patrons can check out books.
    risk: high
    verifymethod: test
  }
  functionalRequirement scan {
    id: LIB-1.1
    text: The scanner reads barcodes.
    risk: medium
    verifymethod: inspection
  }
  element kiosk {
    type: hardware
  }
  checkout - contains -> scan
  kiosk - satisfies -> scan
  kiosk - verifies -> checkout
Render this to PDF →How diagram blocks work

contains and copies draw a solid line with a filled arrow; the other five draw a dashed line with an open arrow, which is SysML's own distinction. An unknown relation type is drawn in the derive family with its name as written, so a typo shows up as an odd arrow rather than a failed diagram.

A requirement or element needs no body at all if you only want the box to appear in a relation — element gateway on its own is valid.

Not supported in makesPDF yet: field values are not validated — risk: whatever is drawn as written — and a field key the renderer does not know (owner:, say) is ignored rather than displayed. docref is rendered as text, not as a followable link, and requirement styling (style, classDef) is not applied.