Mermaid Requirement Diagrams

Mermaid Requirement Diagrams (requirementDiagram) track text-based requirements, system components, and the relationships between them based on the SysML v1.6 specification.

They bridge the gap between traditional text documentation and structural architectures.

Start with:

requirementDiagram

Declaring Requirements

Requirements capture capabilities or conditions that your system must fulfill. You define them using a specific keyword block containing mandatory parameters.

requirementDiagram
    requirement core_auth_req {
        id: 1.1
        text: Users must provide a valid email and password.
        risk: high
        verifymethod: test
}

Try this code ❯

Requirement Relationships

Requirements can be connected.

requirementDiagram
    FunctionalRequirement1 --> PerformanceRequirement2 : verifies

Requirement Type Options

You can substitute the standard requirement keyword with more descriptive classifications:

functionalRequirement : Specific behaviors or features the system must execute.
interfaceRequirement : System connection protocols, APIs, or UI criteria.
performanceRequirement : Execution limits, response times, or load constraints.
physicalRequirement : Material constraints, sizing, or hardware limits.
designConstraint : Architectural rules, software stacks, or technical limitations.

Allowed Parameter Inputs

risk: Must be exactly Low, Medium, or High.
verifymethod: Must be exactly Analysis, Inspection, Test, or Demonstration.

Declaring Design Elements

Elements represent actual software modules, hardware modules, test configurations, or components that interact with the rules.

requirementDiagram
    element authentication_service {
        type: "Microservice Node"
        docref: "https://company.local"
    }

type: Arbitrary text string describing what the element is.
docref: Optional text reference, URL, or filepath linking out to extra documentation.

Traceability Relationships

Connections tie your blocks together. The syntax uses a dash-bracket label sequence: - relationshipType ->.

Relationship Type	Meaning / Usage Scenario
`A - contains -> B`	A physically wraps or encompasses sub-requirement B.
`A - copies -> B`	A is a replica or duplicate of requirement B.
`A - derives -> B`	Requirement A stems from or is spawned by parent requirement B.
`Element - satisfies -> Req`	Element fulfills the criteria specified by the Requirement block.
`Element - verifies -> Req`	A test script or simulation confirms the requirement is met.
`A - refines -> B`	A adds extra context, narrowing the scope of requirement B.
`A - traces -> B`	Establishes a generic historical or analytical link between nodes.

Requirement Type Example

requirementDiagram
    interfaceRequirement LoginReq {
        id: R_Login
        text: "User must be able to log in"
        risk: Medium
        verifymethod: Test
}

The source identifies requirement types, risk levels, and verification methods such as functionalRequirement, Low, High, Test, and Demo.