Introducción
En numerosos proyectos industriales, los requisitos se redactan como una formalidad inicial: un documento necesario para arrancar el desarrollo, pero que rara vez guía de forma efectiva el diseño técnico. Se habla de funcionalidades, prestaciones o comportamientos esperados, pero pocas veces se plantea una pregunta clave desde el inicio:
¿Cómo se va a verificar que este requisito se cumple realmente?
En sistemas industriales reales —y especialmente en entornos safety-critical— esta omisión no es menor. Diseñar sin pensar en la verificabilidad de los requisitos suele conducir a validaciones tardías, interpretaciones ambiguas y problemas que aparecen cuando el sistema ya está construido.
Diseñar con requisitos verificables no es una tarea administrativa: es una decisión de ingeniería.
El problema de los requisitos “bienintencionados”
Muchos requisitos fallan no porque estén mal escritos desde un punto de vista lingüístico, sino porque no son técnicamente verificables. Algunos ejemplos habituales:
- “El sistema debe ser rápido”
- “La respuesta debe ser fiable”
- “La comunicación no debe perder datos”
- “El sistema debe funcionar en tiempo real”
Estas frases expresan una intención correcta, pero no proporcionan:
- Un criterio objetivo de aceptación
- Un método claro de validación
- Un vínculo directo con el diseño técnico
Como resultado, cada equipo —o cada fase del proyecto— interpreta el requisito de forma distinta, y la validación se convierte en una discusión subjetiva en lugar de un proceso técnico.
Qué significa que un requisito sea verificable
Un requisito verificable es aquel que cumple, como mínimo, tres condiciones:
- Es medible u observable
Puede comprobarse mediante una medición, una simulación, un test o una inspección objetiva. - Tiene criterios de aceptación claros
Define qué significa cumplirlo y qué significa no cumplirlo. - Está vinculado a un método de validación
Desde el inicio se puede responder a la pregunta: ¿cómo voy a comprobar esto?
Por ejemplo, no es lo mismo decir:
“El sistema debe responder rápidamente”
que definir:
“El sistema deberá generar la señal de salida en menos de 10 ms tras la activación de la entrada, medido en condiciones nominales y validado mediante simulación temporal y test en banco.”
La diferencia no es semántica; es estructural.
El impacto directo en el diseño del sistema
Cuando los requisitos son verificables desde el inicio, el diseño cambia de forma natural:
- Se definen interfaces claras entre módulos
- Se identifican puntos de observación y medida
- Se prioriza la modularidad y el aislamiento funcional
- Se anticipan necesidades de simulación y test
Por el contrario, cuando los requisitos son vagos o no verificables:
- El diseño tiende a ser monolítico
- La validación se pospone
- Los problemas aparecen en integración o puesta en servicio
- El retrabajo se dispara
En la práctica, muchos problemas atribuidos a “fallos de implementación” son en realidad fallos de definición de requisitos.
Requisitos y simulación: una relación inseparable
Diseñar requisitos verificables obliga a pensar en la simulación desde el principio. No como una fase posterior, sino como una herramienta de diseño.
Algunas preguntas clave que deberían plantearse al definir requisitos son:
- ¿Este requisito se valida mejor mediante simulación funcional o temporal?
- ¿Necesito simular condiciones nominales, extremas o de fallo?
- ¿Qué señales o estados debo poder observar en simulación?
Cuando estas preguntas no se formulan al inicio, la simulación acaba siendo incompleta o irrelevante, limitada a comprobar que “el sistema funciona”, pero no que cumple lo que se esperaba de él.
El error habitual: validar al final lo que no se pensó al principio
Uno de los errores más comunes en proyectos industriales es intentar “forzar” la validación al final del desarrollo. Se construye el sistema, se integra, y solo entonces se intenta demostrar que cumple unos requisitos que nunca fueron pensados para ser verificados.
Esto suele derivar en:
- Tests ad hoc
- Criterios de aceptación redefinidos sobre la marcha
- Decisiones técnicas difíciles de justificar
- Incremento de costes y plazos
En sistemas safety-critical, además, este enfoque es directamente incompatible con normativas y procesos de certificación.
Diseñar para validar no es burocracia, es ingeniería
Existe la tentación de asociar la definición rigurosa de requisitos con burocracia o sobrecarga documental. En realidad, ocurre lo contrario:
- Los requisitos verificables simplifican la validación
- Reducen discusiones subjetivas
- Aportan trazabilidad técnica
- Facilitan el mantenimiento y la evolución del sistema
Diseñar pensando en cómo se va a validar no ralentiza el proyecto; lo hace más predecible y controlable.
Conclusión
En proyectos industriales reales, la diferencia entre un sistema que “funciona” y un sistema fiable no suele estar en la tecnología elegida, sino en cómo se definieron y pensaron los requisitos desde el inicio.
Diseñar con requisitos verificables es aceptar que la validación no es una fase final, sino una parte intrínseca del diseño. Es un cambio de mentalidad que afecta a la arquitectura, a la simulación y, en última instancia, a la calidad del sistema entregado.
En los próximos artículos profundizaremos en cómo traducir estos principios a arquitecturas concretas y a decisiones de diseño prácticas en sistemas industriales complejos.