Sintaxis del diagrama de requisitos de Mermaid.js y guía de trazabilidad

Un diagrama de requisitos es una herramienta especializada de visualización ingenieril utilizada por arquitectos de sistemas, gerentes de productos y ingenieros de software para representar especificaciones técnicas, restricciones del sistema y pruebas de verificación. Construido sobre la norma SysML (Lenguaje de modelado de sistemas), el motor nativorequirementDiagrampermite vincular directamente los requisitos de diseño abstractos a componentes físicos del sistema y casos de prueba mediante declaraciones basadas en texto.

Comprensión de los elementos del diagrama de requisitos

Un diagrama de requisitos consta principalmente de dos bloques estructurales distintos:Bloques de requisitos (que especifican las reglas) yBloques de elementos (que modelan el código, el hardware o los scripts de prueba). A continuación, se dibujan relaciones entre estos bloques para crear una matriz de trazabilidad clara.

Estructura básica de sintaxis

Cada diagrama comienza con el encabezadorequirementDiagramde declaración. A continuación se definen bloques de requisitos con propiedades anidadas, bloques de elementos y líneas de relación direccionales.

requirementDiagram
  requirement test_req {
    id: 1
    text: "El sistema debe procesar pagos de forma segura."
    risk: alto
    verifymethod: prueba
  }

La taxonomía completa de tipos de requisitos

No todos los requisitos de ingeniería son iguales. El motor proporciona seis palabras clave distintas para clasificar sus especificaciones visual y semánticamente. Cada tipo modifica la etiqueta del encabezado que se muestra dentro de la caja del diagrama renderizado:

  • requirement: Una especificación estándar o general del sistema.
  • functionalRequirement: Especifica una acción o capacidad comportamental que el sistema debe ejecutar.
  • interfaceRequirement: Define puntos de conexión, intercambios de datos o protocolos de comunicación entre componentes.
  • performanceRequirement: Establece métricas medibles de ejecución, como velocidad, escalabilidad, rendimiento o capacidad.
  • physicalRequirement: Establece restricciones de material, dimensiones, peso o limitaciones de hardware.
  • restricción de diseño: Restringe las opciones de software, estilos arquitectónicos, marcos de trabajo o estándares de cumplimiento.
diagramaDeRequisitos
  restricciónDeDiseño restricciónHereditaria {
    id: "CON-04"
    text: "El backend debe mantener la compatibilidad hacia atrás con las tuberías de PHP 8.2."
    risk: low
    verifymethod: inspección
  }

Referencia de sintaxis: Elementos y modificadores de requisitos

La tabla a continuación desglosa las palabras clave semánticas principales, los atributos requeridos y las estructuras de clasificación reconocidas nativamente por el intérprete de requisitos.

Componente de sintaxis Tipo de requisito Descripción y atributos del sistema admitidos
Declaración Identificador de palabra clave Inicializa el lienzo del espacio de trabajo de requisitos de SysML. Debe usar exactamente diagramaDeRequisitos encabezado de bloque.
Atributo de ID único id: Cadena / Entero Un parámetro anidado obligatorio que proporciona un índice de seguimiento o un código de referencia alfanumérico único dentro de su marco de seguimiento. Se permiten espacios mixtos.
Atributo de texto text: Cadena entre comillas Una cadena descriptiva obligatoria que detalla la especificación real o la restricción de comportamiento del elemento. Siempre debe ir entre comillas dobles.
Atributo de riesgo risk:Bandera de severidad Una marca opcional que rastrea la severidad del riesgo arquitectónico. Acepta tokens de bajo nivel: low, medio, o alto.
Atributo de verificación método de verificación:Etiqueta de método Un parámetro opcional que declara cómo se probará la regla. Acepta valores estándar de ingeniería: análisis, demonstración, inspección, o prueba.
Elemento del sistema elementoBloque Declara un componente físico, un componente de software o una secuencia de pruebas utilizando la sintaxis: elemento nombre_elemento { tipo: "tipo_componente" }.

Relaciones avanzadas y enlaces de trazabilidad

La principal potencia de un diagrama de requisitos radica en conectar requisitos con sistemas reales. Los enlaces se dibujan utilizando conectores de flecha especializados y tipificados (por ejemplo, - satisface ->) que establecen una intención estructural clara.

Operadores de relación admitidos

Token de sintaxis de relación Significado estratégico de ingeniería Regla de flujo direccional
origen - contiene -> destino Descompone un requisito padre amplio en un requisito secundario más pequeño y anidado. Apunta desde el bloque de Requisito Padre hacia el bloque de Requisito Secundario.
elemento - satisface -> requisito Demuestra que un componente físico de software o hardware cumple con éxito una regla. Apunta desde el elementobloque hacia el requisitobloque.
elemento - verifica -> requisito Indica que una secuencia de pruebas específica o un caso de prueba verifica la exactitud de una regla. Apunta desde el elementobloque hacia el requisitobloque.
origen - copia -> destino Indica un requisito duplicado que se mapea completamente a un requisito principal ubicado en otra parte. Apunta desde la copia duplicada hacia el bloque original principal.
origen - rastrea -> destino Establece una dependencia amplia o relación histórica entre dos requisitos separados. Apunta desde el requisito dependiente hacia el bloque objetivo principal.
origen - deriva -> destino Indica que un requisito fue calculado o generado como resultado directo de otro requisito. Apunta desde el bloque hijo derivado hacia el bloque padre de origen.
origen - refina -> destino Añade matiz adicional o claridad a una especificación técnica de alto nivel y muy compleja. Apunta desde la especificación refinada hacia el bloque objetivo base.

Elementos definidos por el usuario y atributos extendidos

Además de los requisitos estándar, el elementopalabra clave le permite mapear scripts específicos de aplicaciones, elementos de hardware o paquetes de terceros en sus rutas de seguimiento. Cada bloque de elemento puede almacenar propiedades de metadatos clave-valor personalizadas utilizando el esquema tipo:esquema dentro de sus corchetes.

diagramaRequerimiento
  elemento gateway_pago_api {
    tipo: "Módulo de microservicio Stripe"
  }
  
  elemento registro_auditoria_cumplimiento {
    tipo: "Tabla de base de datos inmutable"
  }


Plantilla del mundo real: Infraestructura de seguridad compleja para comercio electrónico

Esta plantilla completa rastrea un ecosistema completo de cumplimiento en producción. Muestra la descomposición mediante contiene, mapea las restricciones de rendimiento, conecta módulos de software mediante satisface, y mapea casos de prueba de integración utilizando verificabucles.

diagramaRequerimiento
  
  %% Capa de jerarquía de requisitos
  requisito seguridad_requisito_principal {
    id: "SEC-001"
    texto: "La plataforma de aplicación debe mantener un cumplimiento estricto con el estándar PCI-DSS."
    riesgo: alto
    métodoVerificación: prueba
  }

  requisitoRendimiento velocidadCajaRequisito {
    id: "PERF-22"
    texto: "Los intercambios de autenticación criptográfica de MFA deben compilarse en menos de 200ms."
    riesgo: medio
    métodoVerificación: análisis
  }

  requisitoInterfaz tokenSeguroRequisito {
    id: "INT-09"
    texto: "Las transmisiones de datos de la API deben utilizar Tokens Web JSON (JWT) cifrados."
    riesgo: alto
    métodoVerificación: prueba
  }

  %% Capa de elementos del sistema
  elemento servicioAutenticacionCodigo {
    tipo: "Microservicio de backend en Go"
  }

  elemento scriptPruebaCarga {
    tipo: "Script de rendimiento K6"
  }

  elemento pruebaValidadorJwt {
    tipo: "Suite de pruebas unitarias de integración Jest"
  }

  %% Rutas de relaciones arquitectónicas
  seguridad_requisito_principal - contiene -> velocidadCajaRequisito
  seguridad_requisito_principal - contiene -> tokenSeguroRequisito
  
  servicioAutenticacionCodigo - satisface -> tokenSeguroRequisito
  scriptPruebaCarga - verifica -> velocidadCajaRequisito
  pruebaValidadorJwt - verifica -> tokenSeguroRequisito


Errores comunes de sintaxis y restricciones del sistema

Al compilar mapas de ingeniería precisos, tenga en cuenta estos parámetros de validación para evitar errores de análisis:

  • Comillas dobles obligatorias para cadenas:Bloques de texto y tipos (por ejemplo, texto: "Descripción", tipo: "Componente") *deben* estar envueltos entre comillas dobles. Usar comillas simples o dejar las cadenas sin comillas hará que el compilador falle.
  • Sintaxis estricta de atributos: Los atributos dentro de llaves deben usar dos puntos seguidos directamente por valores (por ejemplo, id: 1). Olvidar el dos punto o escribirlos en la misma línea sin espaciado de sangría adecuado puede generar errores.
  • Opciones de valor limitadas: El risk y verifymethod los parámetros solo aceptan tokens de sistema explícitos (por ejemplo, low, medium, high para risk; analysis, demonstration, inspection, test para verifymethod). Escribir valores personalizados como risk: extreme romperá el constructor de diseño.
  • Integridad del espaciado de flechas: Las líneas direccionales deben escribirse con espaciado de espacio alrededor de los operadores (por ejemplo, A - satisfies -> B). Compactar la cadena en A-satisfies->B eliminará las excepciones de procesamiento del sistema.
Scroll al inicio