Sintaxe do Diagrama de Requisitos do Mermaid.js e Guia de Rastreabilidade

Um Diagrama de Requisitos é uma ferramenta especializada de visualização em engenharia usada por arquitetos de sistemas, gerentes de produtos e engenheiros de software para mapear especificações técnicas, restrições do sistema e testes de verificação. Construído com base na norma SysML (Linguagem de Modelagem de Sistemas), o motor nativorequirementDiagrampermite vincular requisitos de design abstratos diretamente a componentes físicos do sistema e casos de teste usando declarações baseadas em texto.

Compreendendo os Elementos do Diagrama de Requisitos

Um Diagrama de Requisitos consiste principalmente em dois blocos estruturais distintos:Blocos de Requisitos (que especificam as regras) eBlocos de Elementos (que modelam o código, hardware ou scripts de teste). Em seguida, são traçadas relações entre esses blocos para criar uma matriz de rastreabilidade clara.

Estrutura Básica da Sintaxe

Todo diagrama começa com orequirementDiagramcabeçalho de declaração. Em seguida, definem-se blocos de requisitos com propriedades aninhadas, blocos de elementos e linhas de relacionamento direcionais.

requirementDiagram
  requirement test_req {
    id: 1
    text: "O sistema deve processar pagamentos de forma segura."
    risk: alto
    verifymethod: teste
  }

A Taxonomia Completa dos Tipos de Requisitos

Nem todos os requisitos de engenharia são iguais. O motor fornece seis palavras-chave distintas de blocos para classificar suas especificações visual e semanticamente. Cada tipo altera a etiqueta do cabeçalho exibida dentro da caixa do diagrama renderizado:

  • requisito: Uma especificação padrão ou geral do sistema.
  • requisitoFuncional: Especifica uma ação ou capacidade comportamental que o sistema deve executar.
  • requisitoInterface: Define pontos de conexão, trocas de dados ou protocolos de comunicação entre componentes.
  • requisitoDesempenho: Define métricas mensuráveis de execução, como velocidade, escalabilidade, throughput ou capacidade.
  • requisitoFísico: Determina restrições de material, dimensões, peso ou limitações de hardware.
  • restrição de design: Restringe escolhas de software, estilos arquitetônicos, frameworks ou padrões de conformidade.
diagramaDeRequisitos
  restriçãoDeDesign restriçãoLegado {
    id: "CON-04"
    text: "O backend deve manter a compatibilidade reversa com pipelines do PHP 8.2."
    risk: baixo
    methododeverificação: inspeção
  }

Referência de Sintaxe: Elementos e Modificadores de Requisitos

A tabela abaixo detalha as palavras-chave semânticas principais, atributos obrigatórios e estruturas de classificação reconhecidas nativamente pelo interpretador de requisitos.

Componente de Sintaxe Tipo de Requisito Descrição e Atributos de Sistema Suportados
Declaração Identificador de Palavra-Chave Inicializa a área de trabalho do canvas de requisitos SysML. Deve usar exatamente o diagramaDeRequisitos cabeçalho de bloco.
Atributo de ID Único id: String / Inteiro Um parâmetro aninhado obrigatório que fornece um índice de rastreamento ou código de referência alfanumérico único dentro do seu framework de rastreamento. Espaços mistos são permitidos.
Atributo de Texto text: String entre aspas Uma string descritiva obrigatória que detalha a especificação real ou a restrição comportamental do item. Sempre envolva entre aspas duplas.
Atributo de Risco risk:Bandeira de Severidade Um marcador opcional que rastreia a severidade do risco arquitetônico. Aceita tokens de baixo nível: baixo, médio, ou alto.
Atributo de Verificação metodoverificação:Etiqueta de Método Um parâmetro opcional que declara como a regra será provada. Aceita valores padrão de engenharia: análise, demonstração, inspeção, ou teste.
Elemento do Sistema elementoBloco Declara um componente físico, componente de software ou script de teste usando a sintaxe: elemento nome_elemento { tipo: "tipo_componente" }.

Relacionamentos Avançados e Links de Rastreabilidade

A principal força de um diagrama de requisitos reside em conectar requisitos a sistemas reais. Os links são desenhados usando conectores de seta especializados e tipificados (por exemplo, - satisfaz ->) que estabelecem uma intenção estrutural clara.

Operadores de Relacionamento Suportados

Token de Sintaxe de Relacionamento Significado Estratégico de Engenharia Regra de Fluxo Direcional
fonte - contém -> alvo Decompo um requisito pai amplo em um sub-requisito menor e aninhado. Aponta do bloco de Requisito Pai para o bloco de Sub-Requisito.
elemento - satisfaz -> requisito Prova que um componente físico de software ou hardware cumpre com sucesso uma regra. Aponta do elementobloco em direção ao requisitobloco.
elemento - verifica -> requisito Indica que um script de teste específico ou um caso de teste verifica a precisão de uma regra. Aponta do bloco de teste elementobloco em direção ao requisitobloco.
fonte - copia -> alvo Indica um requisito duplicado que mapeia completamente para um requisito principal localizado em outro lugar. Aponta da cópia duplicada em direção ao bloco original principal.
fonte - rastreia -> alvo Estabelece uma dependência ampla ou relação histórica entre dois requisitos separados. Aponta do requisito dependente em direção ao bloco-alvo principal.
fonte - deriva -> alvo Indica que um requisito foi calculado ou gerado diretamente como resultado de outro requisito. Aponta do bloco filho derivado em direção ao bloco pai de origem.
fonte - aprimora -> alvo Adiciona nuances extras ou clareza a uma especificação técnica de alto nível e altamente complexa. Aponta da especificação aprimorada em direção ao bloco-alvo de base.

Elementos Definidos pelo Usuário e Atributos Estendidos

Além dos requisitos padrão, o elementopalavra-chave permite mapear scripts específicos de aplicativos, itens de hardware ou pacotes de terceiros em seus caminhos de rastreamento. Cada bloco de elemento pode armazenar propriedades personalizadas de metadados chave-valor utilizando o tipo:esquema dentro de seus colchetes.

diagramaDeRequisitos
  elemento gateway_pagamento_api {
    tipo: "Módulo de Microserviço Stripe"
  }
  
  elemento log_auditoria_conformidade {
    tipo: "Tabela de Banco de Dados Imutável"
  }


Plano Real: Infraestrutura de Segurança Complexa para Comércio Eletrônico

Este plano abrangente rastreia um ecossistema completo de conformidade em produção. Ele demonstra a decomposição por meio de contém, mapeia restrições de desempenho, conecta módulos de software por meio de satisfaz, e mapeia casos de teste de integração usando verificaloops.

diagramaDeRequisitos
  
  %% Camada de Hierarquia de Requisitos
  requisito requisito_seguranca_mestre {
    id: "SEC-001"
    texto: "A plataforma de aplicativos deve manter conformidade rigorosa com o padrão PCI-DSS."
    risco: alto
    metodoVerificacao: teste
  }

  requisitoDesempenho requisito_velocidade_checkout {
    id: "PERF-22"
    texto: "Os apertos de mão de autenticação criptográfica MFA devem ser compilados em menos de 200ms."
    risco: médio
    metodoVerificacao: análise
  }

  requisitoInterface requisito_token_seguro {
    id: "INT-09"
    texto: "As transmissões de dados da API devem utilizar Tokens Web JSON (JWT) criptografados."
    risco: alto
    metodoVerificacao: teste
  }

  %% Camada de Elementos do Sistema
  elemento codigo_servico_autenticacao {
    tipo: "Microserviço Backend Go"
  }

  elemento script_teste_carga {
    tipo: "Script de Desempenho K6"
  }

  elemento teste_validador_jwt {
    tipo: "Suite de Unidades de Integração Jest"
  }

  %% Caminhos de Relacionamento Arquitetônica
  requisito_seguranca_mestre - contém -> requisito_velocidade_checkout
  requisito_seguranca_mestre - contém -> requisito_token_seguro
  
  codigo_servico_autenticacao - satisfaz -> requisito_token_seguro
  script_teste_carga - verifica -> requisito_velocidade_checkout
  teste_validador_jwt - verifica -> requisito_token_seguro


Armadilhas Comuns de Sintaxe e Restrições do Sistema

Ao compilar mapas de engenharia precisos, considere esses parâmetros de validação para evitar falhas de análise:

  • Aspas Duplas Obrigatórias para Strings: Blocos de texto e tipos (por exemplo, texto: "Descrição", tipo: "Componente") *devem* estar envolvidos por aspas duplas. Usar aspas simples ou deixar strings sem aspas fará com que o compilador falhe.
  • Sintaxe Estrita de Atributos: Os atributos dentro de chaves devem usar dois pontos seguidos diretamente por valores (por exemplo, id: 1). Esquecer o dois pontos ou escrevê-los na mesma linha sem espaçamento de indentação adequado pode gerar erros.
  • Escolhas de valor limitadas: O risco e verifymethod parâmetros aceitam apenas tokens explícitos do sistema (por exemplo, baixo, médio, alto para risco; análise, demonstração, inspeção, teste para verifymethod). Digitar valores personalizados como risco: extremo irá quebrar o construtor de layout.
  • Integridade do espaçamento de setas: Linhas direcionais devem ser digitadas com espaçamento de espaço ao redor dos operadores (por exemplo, A - satisfaz -> B). Compactando a string em A-satisfaz->B irá descartar exceções de processamento do sistema.
Scroll to Top