Requirement Diagrams

What are Requirement Diagrams?

Mermaid's Requirement diagrams provide a structured visualization of requirements, their attributes, and their relationships to elements or other requirements. Commonly used in systems engineering, these diagrams adhere to SysML standards and offer a clear view of dependencies, risks, and verification methods. For data and analytics teams, they can be used to ensure traceability of project requirements and their implementation.

Creating Your First Requirement Diagram

  1. From the Code IDE, click Apps and Agents from the left-hand panel.

  2. Select Mermaid. Paradime will automatically start a new Mermaid project.

  3. In the terminal that appears, use the arrow keys to select "Requirement Diagram."

  4. A new requirementDiagram.mmd file will be created in your editor with this starter template:

requirementDiagram

requirement test_req {
    id: 1
    text: the test text.
    risk: high
    verifymethod: test
}

element test_entity {
    type: simulation
}

test_entity - satisfies -> test_req
  1. Click the eye icon (👁️) in the top right corner of your Mermaid file to preview the diagram.

  2. Edit and update your .mmd file as needed—the preview will update automatically.

Diagram Syntax Guide

Requirement Definition

Defines requirements with attributes like ID, text, risk, and verification method.

<type> user_defined_name {
    id: user_defined_id
    text: user_defined_text
    risk: <risk>
    verifymethod: <method>
}

Attributes:

  • type: Options include requirement, functionalRequirement, performanceRequirement, interfaceRequirement, physicalRequirement, designConstraint

  • risk: Options include Low, Medium, High

  • verifymethod: Options include Analysis, Inspection, Test, Demonstration

Element Definition

Defines elements related to requirements, with attributes like type and document references.

element user_defined_name {
    type: user_defined_type
    docref: user_defined_ref
}

Relationship Syntax

Defines relationships between requirements and elements or between multiple requirements.

{name of source} - <type> -> {name of destination}

Relationship Types:

  • contains

  • copies

  • derives

  • satisfies

  • verifies

  • refines

  • traces

Data Team Examples

Single Requirement Satisfaction

requirementDiagram

requirement data_req {
    id: 101
    text: Ensure data quality.
    risk: high
    verifymethod: test
}

element pipeline {
    type: ETL process
}

pipeline - satisfies -> data_req

Complex Traceability

requirementDiagram

requirement initial_req {
    id: 201
    text: Initial data requirement.
    risk: medium
    verifymethod: inspection
}

functionalRequirement derived_req {
    id: 202
    text: Derived data functionality.
    risk: low
    verifymethod: analysis
}

element data_process {
    type: data pipeline
}

initial_req - traces -> derived_req
initial_req - satisfies -> data_process

Best Practices

  1. Clearly define requirement attributes (ID, text, risk level).

  2. Use descriptive names for requirements and elements.

  3. Limit diagram complexity by focusing on key relationships.

  4. Use relationships like traces and satisfies to show dependencies and fulfillment.

  5. Regularly review and update diagrams to reflect changes in project scope.


Last updated

Was this helpful?