Un requisito que constriñe explícitamente el rendimiento, las interfaces, la verificación u otras propiedades a través de dos o más dominios funcionales o grupos de interés de un sistema, de modo que ninguna implementación de subsistema por sí sola puede cumplirlo.

Principio

Un requisito transversal introduce una restricción a nivel de sistema que debe asignarse, trazarse y verificarse a través de los límites de los subsistemas; su cumplimiento requiere especificaciones coordinadas de interfaces, criterios de prueba compartidos o un servicio común designado.

Demostración

Escenario ilustrativo → Un programa espacial define un requisito transversal de compatibilidad electromagnética (CEM) entre aviónica, distribución de energía y estructura. Reconocimiento → Los ingenieros de sistemas identifican la CEM abarcando diseño eléctrico, puesta a tierra, blindaje y puntos de anclaje estructural. Acción → El equipo asigna partes del requisito a electrónica, cableado y estructura, define procedimientos de prueba de interfaz y registra las asignaciones en la base de requisitos. Consecuencia → En la integración, las emisiones medidas cumplen el criterio CEM del sistema porque las interfaces y pruebas se definieron y trazaron entre dominios.

Aplicación incorrecta

Tratar el requisito transversal como un conjunto de requisitos funcionales independientes y permitir que cada equipo de subsistema verifique solo su conformidad local. El error semántico es suponer que la verificación local implica conformidad del sistema mientras se ignoran las interacciones entre dominios y las pruebas de aceptación de interfaz.

Consecuencia

Cuando se reconoce y gestiona, el requisito transversal reduce el riesgo de integración al forzar diseños coordinados y una verificación conjunta; cuando se ignora o fragmenta produce incompatibilidades de interfaz, rediseños tardíos, costes mayores y posibles modos de fallo a nivel sistema.

Inversión

Si los dominios están estrictamente desacoplados por la arquitectura (por ejemplo, mediante un servicio común certificado o una partición rígida), un requisito transversal puede cumplirse por un único elemento compartido; inversamente, ciertos requisitos que parecen transversales pueden volverse locales cuando la arquitectura impone separación clara de responsabilidades.

Límite

Claramente dentro → Un requisito de latencia único para todo el vehículo que cubra sensores, redes y unidades de control. Caso límite → Un requisito de fiabilidad declarado a nivel sistema sin asignación explícita; su carácter transversal depende de las asignaciones. Claramente fuera → Un requisito de interfaz específico de función limitado a la API de un único módulo que no afecta a otros dominios.

Tensión semántica

Gobernanza centralizada y trazabilidad frente a autonomía de subsistemas e innovación local rápida: el control estricto facilita la verificación pero puede frenar el desarrollo y reducir la libertad de diseño.

Síntesis

Los requisitos transversales son restricciones de coordinación: convierten atributos deseados del sistema en obligaciones repartidas entre equipos e interfaces y requieren por tanto asignación explícita, definición de interfaces y verificación integrada en lugar de soluciones unilaterales de subsistemas.