VPasCode (Diagrama como Código) para el Diagrama de Requisitos SysML — Una Guía Completa

1. ¿Qué es un Diagrama de Requisitos?

Un diagrama de requisitoses un tipo de diagrama SysML cuyo único propósito es capturar los requisitos como elementos de modelo de primera clase y hacer sus relaciones explícitas y rastreables. A diferencia de un documento de requisitos (que es simplemente una lista), un diagrama de requisitos es un grafo: los requisitos son nodos, y las relaciones entre ellos — contención, derivación, satisfacción, verificación y trazabilidad — son aristas.

La idea central es trazabilidad. En un sistema de TI, un requisito no existe de forma aislada. Una necesidad del interesado impulsa un requisito del sistema; ese requisito es satisfecho por un bloque arquitectónico; una prueba lo verifica; y puede refinarse en subrequisitos. El diagrama de requisitos hace visible y auditivo cada uno de esos enlaces. Eso es lo que convierte una hoja de cálculo plana en un modelo.

¿Por qué usarlo para sistemas de TI?

Los proyectos de TI son famosos por desviación de requisitos — expansión de alcance, cambios no gestionados y el problema de «lo construimos pero nadie lo pidió». Un diagrama de requisitos ayuda porque te permite:

• Rastrear hacia atrás — «¿Por qué existe este componente?» → sigue las conexiones de satisfacerhasta el requisito, y derivar se vincula con la necesidad del negocio.
• Rastrear hacia adelante — «¿Esta requisito está verificado?» → seguirverificar se vincula con los casos de prueba.
• Evaluar el impacto del cambio — «Si este requisito cambia, ¿qué más se ve afectado?» → seguir cada arista entrante y saliente.
• Demostrar cobertura — cada requisito debe ser cumplido poralgo y verificado poralgo. Los requisitos huérfanos son inmediatamente visibles.

2. Conceptos clave y notación

2.1 El elemento de requisito

Un requisito se representa como un rectángulo con unnombre, unID único(típicamente jerárquico, como 1.2.3), y texto del requisito. El estereotipo es «requisito».

Los requisitos pueden contener propiedades — atributos formalmente modelados, como fuente, riesgo, prioridad, estado, o método de verificación. Estos hacen que un requisito sea medible más bien que vago.

2.2 Las relaciones (el corazón del diagrama)

La regla fundamental: Una relación nunca se dibuja hacia el requisito de Cadena de identificación — se dibuja hacia el elemento de alias. Y si el requisito A contiene el requisito B, debes no también dibujar una «derivar» entre ellos en cualquier dirección; la contención y la derivación son mutuamente excluyentes para el mismo par.

2.3 Bloques, casos de prueba y fuentes de refinamiento

• Bloque («bloque»): el elemento de diseño que satisface los requisitos. En un contexto de TI, este es su componente arquitectónico — un servicio, módulo o API.
• Caso de prueba («casoDePrueba»): la unidad de verificación.
• Fuentes de refinamiento: casos de uso, actividades o cualquier elemento de modelo que detalle un requisito.

Nota de notación: las flechas de relación tienen cabezas específicas (la «satisfacer» flecha, por ejemplo, se abre hacia el requisito que se satisface). Al escribir sobre estos en prosa, siempre cite el estereotipo — escriba `«satisfacer»` — para que no sea interpretado por el analizador de markdown del lector.

3. Ejemplos de diagramas

Ejemplo 1 — Una jerarquía de requisitos fundamental

Este ejemplo muestra la contención y la derivación, el esqueleto con el que comienza todo diagrama de requisitos. Un requisito de rendimiento de nivel superior se descompone en subrequisitos medibles.

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/sysml-requirement-diagram.puml

skinparam vpDiagramType DiagramaDeRequisitos
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam linetype ortho

title Jerarquía de Requisitos de Rendimiento del Vehículo

$requirement("Rendimiento del Vehículo", ReqVehiclePerf, "1", "El vehículo deberá cumplir con los objetivos de rendimiento especificados bajo condiciones operativas nominales.")
$requirement("Aceleración", ReqAccel, "1.1", "El vehículo deberá acelerar de 0 a 100 km/h en menos de 6 segundos.")
$requirement("Velocidad Máxima", ReqTopSpeed, "1.2", "El vehículo deberá alcanzar una velocidad máxima de al menos 220 km/h.")
$requirement("Frenado", ReqBraking, "1.3", "El vehículo deberá detenerse desde 100 km/h en menos de 38 metros sobre pavimento seco.")
$requirement("Eficiencia de Combustible", ReqFuel, "1.4", "El vehículo deberá lograr al menos 15 km/l en el ciclo combinado.")

$containment(ReqVehiclePerf, ReqAccel)
$containment(ReqVehiclePerf, ReqTopSpeed)
$containment(ReqVehiclePerf, ReqBraking)
$containment(ReqVehiclePerf, ReqFuel)
$deriveReqt(ReqBraking, ReqVehiclePerf)
@enduml

Leyéndolo: Aceleración, Velocidad Máxima, Frenado, y Eficiencia de combustible son todos partes de el requisito general de Rendimiento del vehículo requisito (contención). Frenado también es derivado de él, lo que significa que se desglosó en un objetivo concreto y medible.

Ejemplo 2 — Satisfacción y verificación (el diseño cumple con los requisitos)

Esto añade el lado del diseño. Los componentes arquitectónicos satisfacenrequisitos, y los casos de prueba verificanellos. Este es el diagrama que muestras en una revisión de diseño.

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/sysml-requirement-diagram.puml

skinparam vpDiagramType DiagramaDeRequisitos
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam linetype ortho

title Sistema de Pago — Satisfacción y Verificación

$requirement("Cumplimiento PCI-DSS", ReqPci, "3", "El sistema no deberá almacenar valores de verificación de tarjeta y deberá cifrar los datos del titular de la tarjeta cuando estén en reposo.")
$requirement("Procesar Pago", ReqPay, "3.1", "El sistema deberá autorizar un pago del cliente dentro de los 3 segundos.")
$requirement("Cargo Idempotente", ReqIdem, "3.2", "El sistema no deberá cobrar dos veces al cliente en caso de reintento.")

$block("PaymentService", PaymentService)
$block("VaultService", VaultService)

$testCase("Auditoría PCI", TAudit)
$testCase("Prueba de Latencia", TLatency)
$testCase("Prueba de Idempotencia", TIdem)

$containment(ReqPci, ReqPay)
$containment(ReqPci, ReqIdem)

$satisfy(PaymentService, ReqPay)
$satisfy(VaultService, ReqPci)

$verify(TAudit, ReqPci)
$verify(TLatency, ReqPay)
$verify(TIdem, ReqIdem)
@enduml

Leyéndolo: PaymentService satisface el requisito de procesamiento de pagos, mientras que VaultService satisface el requisito más amplio de PCI-DSS. Cada requisito es verificado por un caso de prueba. Observe las direcciones de las flechas: `«satisfacer»` apunta desde el bloque hacia el requisito que cumple; `«verificar»` apunta desde el caso de prueba hacia el requisito que demuestra.

Ejemplo 3 — Cadena completa de trazabilidad del sistema de TI

Este es el diagrama que usarías para rastrear un necesidad empresarial desde el inicio hasta la verificación — la pregunta clásica de «¿por qué existe este código?».

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/sysml-requirement-diagram.puml

skinparam vpDiagramType DiagramaDeRequisitos
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam linetype ortho

title Sistema de Comercio Electrónico — Rastreabilidad de Requisitos

$requirement("Negocio: Reducir la abandono de carritos", ReqBiz, "B1", "El negocio deberá reducir el abandono de carritos en un 15% dentro de dos trimestres.")
$requirement("Experiencia de usuario en el checkout", ReqUx, "S1", "El sistema deberá permitir a un invitado completar el checkout en menos de 5 pasos.")
$requirement("Reordenar con un clic", ReqReorder, "S2", "El sistema deberá permitir a un cliente que regresa reordenar una compra anterior en una sola acción.")
$requirement("Residencia de datos", ReqResidency, "S3", "El sistema deberá almacenar los datos de los clientes de la UE dentro de las regiones de la UE.")

$block("CheckoutUI", CheckoutUI)
$block("ReorderService", ReorderService)
$block("AlmacenamientoRegional", AlmacenamientoRegional)

$testCase("Prueba del flujo de checkout", TCheckout)
$testCase("Prueba de reordenación", TReorder)
$testCase("Auditoría de residencia", TResidency)

$containment(ReqBiz, ReqUx)
$containment(ReqBiz, ReqReorder)
$deriveReqt(ReqUx, ReqBiz)
$deriveReqt(ReqReorder, ReqBiz)

$satisfy(CheckoutUI, ReqUx)
$satisfy(ReorderService, ReqReorder)
$satisfy(AlmacenamientoRegional, ReqResidency)

$verify(TCheckout, ReqUx)
$verify(TReorder, ReqReorder)
$verify(TResidency, ReqResidency)

$trace(ReqResidency, ReqBiz)
@enduml

Leyéndolo: El requisito del negocio B1 ancla todo. Los requisitos del sistema S1 y S2 son derivados de él (el «por qué»), mientras que S3 (residencia de datos) es una rastreable restricción vinculada únicamente por `«rastrear»`. Cada requisito del sistema es satisfecho por un componente y verificado por una prueba. Si B1cambia, este diagrama te indica de inmediato qué componentes y pruebas están dentro del alcance.

4. Cómo construir uno (flujo práctico)

1. Comienza con la necesidad de nivel superior.Normalmente una necesidad de negocio o de interesado. Dale un espacio de identificación claro (por ejemplo, B* para negocio, S* para sistema).
2. Descompón hacia abajo con contención. Divide los requisitos grandes en otros más pequeños, mediblesuno. Un buen texto de requisito tiene un número en él (“menos de 3 segundos”, “15%”, “dentro de las regiones de la UE”).
3. Agrega enlaces de derivación donde un hijo sea una reformulación concreta, no solo una parte. Recuerda: un par puede unirse mediante contención oderivación, nunca ambos.
4. Asocia el diseño con los requisitos mediante satisfacer.Cada bloque arquitectónico debe satisfacer al menos un requisito. Los bloques que no satisfacen nada son candidatos para eliminación; los requisitos que no son satisfechos por nada son brechas de cobertura.
5. Asocia las pruebas con verificar.Cada requisito necesita un camino de verificación. Los requisitos verificados por nada son imposibles de probar — una alerta roja.
6. Utiliza rastrear solo cuando nada más encaja. Es la salida de emergencia para asociaciones sueltas; su uso excesivo reduce su valor.
7. Mantén menos de ~24 elementos.Los diagramas grandes se vuelven ilegibles. Divide por subsistema o por categoría de requisito (seguridad, rendimiento, funcional).

Las tres preguntas de cobertura

Ejecuta esta lista de verificación contra cada diagrama de requisitos:

• ¿Cada requisito está satisfecho? (si es un requisito del sistema, algo debe implementarlo)
• ¿Cada requisito está verificado? (algo debe demostrarlo)
• ¿Cada requisito se traza hasta una necesidad? (sin requisitos huérfanos flotando sin justificación comercial)

Cualquier “no” es una observación.

5. Aplicación a Sistemas de TI — Patrones y Peligros

Buenas prácticas

• Requisito separadotipos visualmente. Puedes estereotipar requisitos («funcional», «rendimiento», «seguridad», «usabilidad») para que los requisitos no funcionales destaquen frente a los funcionales.
• Mantén la jerarquía de identificadores significativa. 2.3.4 debe indicarle al lector que este requisito se encuentra bajo el módulo 2, la característica 3, la subcaracteística 4. La consistencia entre los diagramas y tu herramienta ALM es importante.
• Modela la fuente.Añade un fuentepropiedad (regulatoria, nombre del interesado, documento de requisitos del mercado). Rastreabilidad hacia origenes a menudo más importante que la rastreabilidad hacia el diseño.
• Un diagrama, una preocupación.Un diagrama de satisfacción (revisión de diseño) y un diagrama de verificación (revisión de pruebas) tienen audiencias diferentes. No intentes incluir ambos, además de toda la jerarquía, en una sola imagen.

Errores comunes

• Confusión entre derivación y contención.Parecen similares pero significan cosas diferentes. La contención es descomposición estructural; la derivación es evolución lógicade la intención. Mezclarlos (o dibujar ambos entre un par) hace que el modelo sea inválido.
• Referenciar por ID en lugar de alias.En la herramienta, las relaciones se vinculan al elemento alias, no a las cadenas de ID legibles por humanos. Asegúrate de tener el alias correcto, o la relación apuntará silenciosamente a nada.
• Tratar rastrear como cumplir. Un enlace de rastreo no afirma que el objetivo cumpla nada. Si quieres decir «este componente implementa este requisito», usa `«cumplir»`.
• Requisitos sin número. «El sistema deberá ser rápido» no puede verificarse. Un requisito sin umbral medible es un deseo, no un requisito.
• Dejar que el diagrama se convierta en la especificación. El diagrama muestra relaciones; el requisito texto y propiedades llevan los detalles. Mantén el texto preciso y adjunta propiedades (estado, prioridad, riesgo) para que el modelo sea consultable.

6. Herramientas

Puedes renderizar estos diagramas directamente desde el código PlantUML mostrado anteriormente usando VPasCode — pega el código, y el diagrama se renderiza inmediatamente. Desde ahí también puedes exportarlo o mejorarlo.

Referencia rápida: macros de elementos y relaciones

$requirement("Nombre", alias, "id", "Texto del requisito")
$block("NombreBloque", alias)
$testCase("NombreCasoPrueba", alias)

$containment(aliasPadre, aliasHijo)
$deriveReqt(aliasHijo, aliasPadre)
$satisfy(aliasBloque, aliasRequisito)
$verify(aliasCasoPrueba, aliasRequisito)
$refine(aliasModelo, aliasRequisito)
$trace(aliasOrigen, aliasDestino)
$copy(aliasOrigen, aliasDestino)

Resumen

Un diagrama de requisitos es el eje de trazabilidad de un modelo. Para sistemas de TI, responde las tres preguntas que toda auditoría, revisión de diseño y solicitud de cambio plantean: ¿Por qué existe esto? ¿Qué lo implementa? ¿Qué lo demuestra? Utilizado correctamente — con texto de requisitos medible, semántica de relaciones correcta y verificaciones disciplinadas de cobertura — convierte los requisitos de un documento estático en un modelo vivo y consultable que mantiene alineados el diseño, el código y las pruebas con la intención del negocio.

Referencia

1. VPasCode: Diagramación asistida por IA con PlantUML, Mermaid y Graphviz: Guía oficial que cubre la generación de diagramas asistida por IA, flujos de trabajo de modificación y soporte multi-DSL, incluyendo PlantUML, Mermaid y Graphviz.
2. Visual Paradigm VPasCode: Guía completa: Visión general detallada de las características de VPasCode, usuarios objetivo (desarrolladores, arquitectos, analistas) y su papel en los flujos de trabajo de documentación ágil.
3. Bienvenido a Visual Paradigm VPasCode: El cambio hacia la diagramación como código (DaC): Introducción a la plataforma unificada, explicando las ventajas de los flujos de trabajo de texto a diagrama y la ingeniería automática de disposición.
4. Guía rápida de 60 segundos | Guía de texto a diagrama de VPasCode: Recorrido paso a paso para crear, personalizar y exportar diagramas utilizando el editor basado en navegador con vista previa en tiempo real.
5. Novedad en VPasCode: Generador de diagramas de perfil UML con IA: Actualización del producto que presenta la generación de diagramas de perfil UML con IA utilizando promps en inglés sencillo, con ejemplo para cumplimiento de privacidad de datos en salud.
6. Generación nativa de diagramas con IA en Visual Paradigm VPasCode: Anuncio de capacidades integradas de IA para generar, modificar y corregir diagramas mediante promts en lenguaje natural directamente en el editor.
7. Generador de diagramas impulsado por IA y herramientas de productividad | VPasCode: Resumen de las integraciones de VPasCode con chatbots de IA, Visual Paradigm Desktop y OpenDocs para flujos de documentación optimizados.
8. Mejores alternativas de PlantUML y editores gratuitos de diagramas como código: Matriz de comparación de alternativas de PlantUML, destacando el soporte multi-DSL de VPasCode, sus funciones de IA y su enfoque basado en navegador sin configuración.
9. Editor de diagramas como código: convierte texto en diagrama instantáneamente: Resumen de características que cubren la detección automática de formatos, renderizado en tiempo real y opciones de exportación en múltiples formatos (SVG, PNG, PDF).
10. Guía del ecosistema de Visual Paradigm: Explica cuándo usar VPasCode frente a VP Desktop, con orientación sobre el mantenimiento de diagramas con control de versiones e integración con documentación dinámica.