Lecciones aprendidas sobre la gestión de requisitos: el programa del submarino S-80

El programa del submarino S-80 nos muestra por qué los requisitos, las restricciones, los cambios de diseño y las comprobaciones de verificación deben mantenerse conectados en los proyectos de desarrollo de productos de hardware.

En el desarrollo de productos de hardware, un cambio de diseño puede resolver el problema inmediato y, al mismo tiempo, plantear nuevas preguntas en otra parte del sistema. Por eso, la gestión de requisitos no consiste solo en captar lo que el producto debe hacer, sino también en mantener visibles las restricciones relacionadas, las decisiones de diseño y las comprobaciones de verificación a medida que el diseño evoluciona.

El programa del submarino S-80 de España muestra este patrón con claridad. Durante el desarrollo, el programa afrontó un importante desafío de peso y flotabilidad. El rediseño ayudó a abordar ese problema, pero las dimensiones actualizadas de la embarcación introdujeron un nuevo problema práctico: el submarino ahora era demasiado largo para el puerto que debía utilizar.

Aquí hay una lección aplicable para todos los equipos que desarrollan productos de hardware, ya sea que estén construyendo un submarino o un dispositivo electrónico: cuando los requisitos, las restricciones, los cambios de diseño y las comprobaciones de verificación están desconectados, a los equipos les cuesta ver qué más puede verse afectado por un cambio.

Conclusiones clave

• Los conflictos de requisitos suelen surgir cuando las restricciones críticas quedan fuera del flujo de trabajo utilizado para revisar los cambios de diseño.
• Los equipos pueden reducir este riesgo vinculando los requisitos con las restricciones, las decisiones de diseño y las comprobaciones de verificación a las que afectan.
• Un flujo de trabajo de requisitos conectado facilita ver qué cambió, qué afecta y qué necesita revisión antes de que la repetición del trabajo se vuelva costosa.

Qué ocurrió en el programa S-80

España puso en marcha el programa S-80 para desarrollar una nueva clase de submarinos. Durante el desarrollo, el programa afrontó un serio problema de peso y flotabilidad. La embarcación se había vuelto más pesada de lo previsto, lo que generó dudas sobre si tendría suficiente margen de flotabilidad para salir a la superficie de forma fiable después de sumergirse.

El diseño fue revisado para resolver el problema. Uno de los cambios clave fue un casco más largo, lo que ayudó a recuperar el margen de flotabilidad necesario. Esa revisión también modificó las dimensiones físicas de la embarcación. Luego, el submarino actualizado tuvo que revisarse frente a la infraestructura donde operaría, y esa revisión reveló un problema práctico: ya no cabría en el puerto.

El problema de infraestructura añadió otra capa de trabajo a un programa que ya había requerido un rediseño importante. En última instancia, el programa se volvió más complejo, llevó más tiempo y resultó más costoso de lo esperado originalmente.

Este ejemplo nos recuerda que todo rediseño deja una pregunta más por responder: ¿qué más debe comprobarse ahora?

Qué pueden aprender los equipos de hardware del caso S-80

La mayoría de los equipos de hardware trabajan a una escala menor que la de un programa de submarinos, pero el mismo patrón puede aparecer en el desarrollo cotidiano de productos: un cambio de diseño puede afectar el tamaño, los requisitos de cumplimiento normativo o las restricciones de interfaz más allá del problema que el equipo intenta resolver en ese momento.

Conocer esas restricciones no es suficiente. Aquí es donde la gestión de requisitos importa: ayuda a los equipos a mantenerlas visibles, conectadas y revisables a medida que el diseño evoluciona. Para los equipos de hardware, esto se reduce a tres hábitos prácticos:

Mantener visibles las restricciones críticas

Las restricciones críticas no deberían existir solo en notas de reuniones, hojas de cálculo o en la memoria de alguien. Deben registrarse con claridad y, cuando sea posible, redactarse en términos medibles para que los equipos puedan comprobarlas a medida que cambia el diseño.

Conectar los requisitos con las decisiones de diseño

Un requisito es más útil cuando está vinculado con el área del sistema, bloque, objeto de diseño o actividad de ingeniería a la que afecta. Esa conexión ayuda a los ingenieros a ver por qué una decisión de diseño es importante, qué requisitos respalda y qué más puede verse afectado cuando cambia el diseño.

Usar la trazabilidad para revisar el impacto de los cambios

La trazabilidad ayuda a los equipos a responder una pregunta práctica: ¿qué más afecta este cambio? Cuando los requisitos permanecen vinculados a las decisiones de diseño, las restricciones, las comprobaciones de verificación y la evidencia, los equipos pueden ver qué cambió, qué sigue cubierto y qué necesita revisión antes de que la repetición del trabajo se vuelva costosa.

Cómo ayuda un flujo de trabajo de requisitos conectado

Los equipos de hardware necesitan algo más que un lugar donde almacenar el texto de los requisitos. Los documentos y las hojas de cálculo pueden registrar requisitos, pero se vuelven más difíciles de gestionar a medida que aumenta la complejidad del proyecto y cada requisito necesita mantenerse conectado a lo largo de toda la cadena de ingeniería.

Altium Requirements Portal está diseñado para dar soporte a ese flujo de trabajo mediante la gestión de requisitos, trazabilidad, responsabilidad y verificación en un entorno compartido. En lugar de tratar los requisitos como texto aislado, los equipos pueden ver qué cambió, qué afecta, quién es responsable del siguiente paso y cómo se comprobará el requisito.

¿Cuál es el "submarino" en su proyecto?

Todo proyecto de desarrollo de hardware tiene restricciones que es fácil pasar por alto cuando el diseño avanza con rapidez. Pueden ser mecánicas, eléctricas, normativas, operativas o relacionadas con procesos. El riesgo no es que los equipos carezcan de conocimiento, sino que el conocimiento importante no siempre se captura, se conecta y se revisa cuando cambia el diseño.

Eso es lo que hace que el caso S-80 sea útil más allá de su escala. El mismo patrón puede aparecer en el desarrollo cotidiano de productos cuando la intención de ingeniería, las decisiones de diseño y la evidencia no se mantienen conectadas a lo largo del tiempo.

Facilite el seguimiento del impacto de los cambios con una herramienta de gestión de requisitos a la que pueda acceder todo su equipo.

Comience con Requirements Portal →

Preguntas frecuentes

¿Qué causa los problemas de gestión de requisitos en los proyectos de hardware?

Los problemas de gestión de requisitos suelen aparecer cuando los requisitos no están conectados con el trabajo de diseño, las restricciones y las comprobaciones de verificación a las que afectan. Un requisito puede existir, pero si el equipo no puede ver con qué está conectado, pueden pasarse por alto impactos importantes cuando cambia el diseño.

¿Por qué las hojas de cálculo se vuelven difíciles para la gestión de requisitos?

Las hojas de cálculo pueden registrar el texto de los requisitos, pero se vuelven más difíciles de gestionar a medida que aumenta la complejidad del proyecto. Los equipos necesitan una forma de mantener los requisitos conectados con el trabajo de diseño, el historial de cambios, el estado de verificación y la evidencia a lo largo de toda la cadena de ingeniería.

¿Cómo ayuda la trazabilidad a reducir la repetición de trabajo en etapas tardías?

La trazabilidad ayuda a los equipos a responder una pregunta práctica: ¿qué más afecta este cambio? Al vincular los requisitos con las decisiones de diseño, las restricciones, las comprobaciones de verificación y la evidencia, los equipos pueden ver qué necesita revisión antes de que la repetición del trabajo se vuelva costosa.