La etapa de análisis de los requisitos es la que destina el fabricante (o el desarrollador) a determinar los requerimientos de diseño, técnicos y funcionalidades que debe satisfacer el producto para considerarse adecuado.
Análisis de los requisitos y contenido
Los requisitos se clasifican en múltiples tipos de acuerdo a su propia naturaleza.
- Funcionales, como podrían ser las características de funcionamiento, la tecnología y las compatibilidades.
- Entradas y salidas del software, donde se determinarán de forma precisa cuáles son los datos de entrada y cuáles la salidas o salidas generadas por el programa informático (por ejemplo, imágenes de diagnóstico clínico y propuesta de diagnóstico).
- Interfaces, por ejemplo entre software y hardware o entre diferentes componentes informáticos (por ejemplo bases de datos o comunicaciones cruzadas entre aplicaciones).
- Alarmas y advertencias generadas por el producto, que serán necesarias para el correcto desempeño (por ejemplo, pérdida de comunicación IP o falta de suficiente resolución de imágenes).
- De seguridad, como pueda ser la protección de datos de carácter personal, la ciberseguridad o la necesidad de autenticación.
- Requisitos de aptitud de uso (también llamada usabilidad, por ejemplo tamaño de las fuentes o interactuación con el usuario, en general).
- Los relativos a los datos y especificaciones de la base de datos.
- Requisitos de instalación y aceptación, por ejemplo, los criterios de aceptación de tiempos de arranque, estabilidad o tolerancia a fallos.
- Los relativos a funcionamiento y mantenimiento, por ejemplo los criterios para considerar bugs o necesidad de actualización.
- Los requisitos de la red de datos y comunicaciones, por ejemplo, encriptación en las comunicaciones o la seguridad de la red.
- Requisitos de mantenimiento del usuario, por ejemplo los niveles de compatibilidad con tecnologías usadas y las acciones para garantizarla.
- Reglamentarios, como son los ya conocidos e impuestos por los Requisitos Generales de Seguridad y Funcionamiento, de MDR.
Medidas de control del riesgo en los requisitos del software
Las medidas que sean oportunas para mitigar riesgos relacionados con el producto (de cualquiera de sus naturalezas) en los requisitos. Es en este punto, donde personalmente me gusta diferenciar el proceso de diseño establecido por la norma 13485 (requisitos de diseño) con el análisis de los requisitos del software. Como es natural, estas medidas aparecen y se incorporan al proceso durante todo el ciclo de vida del producto, incluyendo todas las etapas y actuaciones de diseño y rediseño del producto.
Actualización de los requisitos del software
Se debe establecer una metodología que garantice la actualización de los requisitos. Se incluyen los del hardware o cualquier otro elemento necesario, durante el propio proceso de análisis de los requisitos.
En esta parte soy muy partidario de mantener un archivo vivo, ágil y revisado frecuentemente de forma planificada, por ejemplo, una vez al año. Lo haría junto con la revisión sistemática del informe de gestión de riesgos, o con el de PMS.
Verificación de los requisitos del software
Es importante dejar evidencia de la verificación de que los requisitos del software:
- Se implementan, incluidos los de control del riesgo (donde propongo el uso de la ISO 13485 y el concepto de salidas de diseño).
- No se contradicen
- Son claros y concisos, no ambiguos.
- Permiten el ensayo y la medida del grado de satisfacción con el requisito.
- Son identificables (y trazables, recomiendo un identificador por cada uno).
CONCLUSIÓN
Personalmente, me gusta aplicar el concepto de diseño de producto sanitario marcado por ISO 13485, junto con el de EN 62304. Esto me permite documentar la trazabilidad de los requisitos y justificar de forma sistemática su cumplimiento y evidencias.
Se debe tener presente las múltiples naturalezas de los requisitos, y en base a experiencias, recomiendo que se relacionen de forma clara con cada uno (aunque personalmente no creo que aporte valor).
Es esencial relacionar el diseño y rediseño (mantenimiento y resolución de problemas) con la gestión de riesgos y… ¡cuidado!, como vengo especificando, esto nos conduce a la Evaluación clínica.
