amararrEn este apartado se especifican los requisitos funcionales y no funcionales que deberá satisfacer PANACEA para dar respuesta a las necesidades identificadas durante el estudio de viabilidad y el análisis del proceso de gestión del apoyo sanitario.
Los requisitos funcionales describen los servicios y capacidades que el sistema deberá proporcionar a sus distintos perfiles de usuario, mientras que los requisitos no funcionales establecen las características de calidad que deberá cumplir la solución en aspectos como seguridad, rendimiento, disponibilidad, auditoría y usabilidad.
La obtención de estos requisitos se ha realizado a partir de las historias de usuario definidas durante el análisis funcional, del modelo del proceso de negocio (AS-IS y TO-BE) y de la normativa vigente que regula el apoyo sanitario en el Ejército de Tierra, especialmente la Instrucción Técnica 08/24 y la Norma 452/24 de la Fuerza Terrestre. Los requisitos incluidos en este documento constituyen la base para el desarrollo del Product Backlog y servirán como referencia para la implementación y validación del sistema.
3.2.1. Requisitos funcionales
Los requisitos funcionales describen las capacidades que deberá proporcionar PANACEA para dar soporte al proceso de planificación, gestión y coordinación de apoyos sanitarios del Ejército de Tierra.
Con el objetivo de facilitar su comprensión, implementación y posterior mantenimiento, los requisitos se agrupan por dominios funcionales del sistema, independientemente del perfil de usuario que los ejecute. La trazabilidad entre los requisitos funcionales y las historias de usuario se recoge posteriormente en la correspondiente matriz de trazabilidad.
3.2.1.1. Gestión de actividades
| Identificador | Nombre | Descripción | Origen | Prioridad |
|---|---|---|---|---|
| RF-001 | Gestión de actividades | El sistema deberá permitir crear, consultar, modificar y cancelar actividades de preparación susceptibles de requerir apoyo sanitario, registrando la información necesaria para su planificación. | HU-01 | Alta |
| RF-002 | Calendario de actividades | El sistema deberá incorporar las actividades registradas a un calendario que permita su consulta y planificación por los usuarios autorizados. | HU-01, HU-05 | Alta |
| RF-003 | Validación de actividades | El sistema deberá validar la información obligatoria de cada actividad y gestionar su estado durante todo su ciclo de vida. | HU-01 | Alta |
3.2.1.2. Gestión de recursos sanitarios
| Identificador | Nombre | Descripción | Origen | Prioridad |
|---|---|---|---|---|
| RF-004 | Gestión de recursos sanitarios | El sistema deberá permitir registrar, consultar y actualizar la disponibilidad de los recursos sanitarios propios de cada organización. | HU-02 | Alta |
| RF-005 | Asignación de recursos | El sistema deberá permitir asignar recursos sanitarios disponibles a las actividades, evitando conflictos de disponibilidad y registrando las asignaciones realizadas. | HU-03 | Alta |
| RF-006 | Detección de insuficiencia de recursos | El sistema deberá identificar la insuficiencia de recursos propios e iniciar el procedimiento de solicitud de apoyo al escalón correspondiente. | HU-03, HU-04 | Alta |
3.2.1.3. Gestión de solicitudes de apoyo sanitario
| Identificador | Nombre | Descripción | Origen | Prioridad |
|---|---|---|---|---|
| RF-007 | Gestión de solicitudes | El sistema deberá permitir crear, consultar, modificar y cancelar solicitudes de apoyo sanitario asociadas a una actividad. | HU-04 | Alta |
| RF-008 | Gestión del estado de las solicitudes | El sistema deberá controlar el ciclo de vida de las solicitudes, registrando sus cambios de estado y garantizando su trazabilidad. | HU-04, HU-08, HU-11 | Alta |
| RF-009 | Elevación de solicitudes | El sistema deberá permitir elevar solicitudes a los escalones superiores cuando no puedan ser atendidas con los recursos disponibles, conservando toda la información asociada. | HU-08, HU-11 | Alta |
| RF-010 | Consulta y seguimiento | El sistema deberá permitir consultar y filtrar las solicitudes de apoyo sanitario de acuerdo con el perfil y ámbito de responsabilidad del usuario. | HU-04, HU-06, HU-13 | Alta |
3.2.1.4. Gestión de apoyos sanitarios
| Identificador | Nombre | Descripción | Origen | Prioridad |
|---|---|---|---|---|
| RF-011 | Asignación de apoyos sanitarios | El sistema deberá permitir asignar recursos sanitarios a las solicitudes de apoyo, registrando la resolución adoptada y actualizando el estado del expediente. | HU-07, HU-10, HU-14 | Alta |
| RF-012 | Calendario sanitario | El sistema deberá mostrar la planificación de apoyos sanitarios y los recursos comprometidos, permitiendo detectar conflictos de disponibilidad. | HU-12 | Media |
3.2.1.5. Administración del sistema
| Identificador | Nombre | Descripción | Origen | Prioridad |
|---|---|---|---|---|
| RF-013 | Gestión de usuarios y permisos | El sistema deberá permitir administrar usuarios, perfiles y permisos de acceso conforme a la organización y responsabilidades de cada usuario. | HU-16 | Alta |
3.2.1.6. Consulta y explotación de la información
| Identificador | Nombre | Descripción | Origen | Prioridad |
|---|---|---|---|---|
| RF-014 | Cuadro de mando | El sistema deberá proporcionar un cuadro de mando con indicadores que permitan realizar el seguimiento de la planificación y del empleo de los recursos sanitarios. | HU-15 | Media |
| RF-015 | Auditoría funcional | El sistema deberá registrar las actuaciones relevantes realizadas sobre actividades, solicitudes y apoyos sanitarios, garantizando la trazabilidad del proceso. | HU-04, HU-08, HU-10, HU-14, HU-15 | Alta |
3.2.2. Requisitos no funcionales
Los requisitos no funcionales establecen las condiciones de calidad que deberá cumplir PANACEA para garantizar un funcionamiento adecuado como aplicación interna de planificación y formalización de apoyos sanitarios.
3.2.2.1. Seguridad
| Identificador | Categoría | Descripción | Prioridad |
|---|---|---|---|
| RNF-001 | Seguridad | El sistema deberá requerir autenticación de usuario para acceder a cualquier funcionalidad. | Alta |
| RNF-002 | Seguridad | El sistema deberá aplicar control de acceso basado en roles, limitando las acciones disponibles según el perfil del usuario. | Alta |
| RNF-003 | Seguridad | El sistema deberá impedir que un usuario acceda a información ajena a su ámbito de responsabilidad. | Alta |
3.2.2.2. Auditoría y trazabilidad
| Identificador | Categoría | Descripción | Prioridad |
|---|---|---|---|
| RNF-004 | Auditoría | El sistema deberá registrar las acciones relevantes realizadas sobre actividades, solicitudes, recursos y apoyos sanitarios. | Alta |
| RNF-005 | Auditoría | Cada registro de auditoría deberá incluir, como mínimo, usuario, fecha, hora, acción realizada y elemento afectado. | Alta |
3.2.2.3. Rendimiento y disponibilidad
| Identificador | Categoría | Descripción | Prioridad |
|---|---|---|---|
| RNF-006 | Rendimiento | El sistema deberá permitir consultar actividades, solicitudes y recursos en un tiempo de respuesta adecuado para su uso operativo ordinario. | Media |
| RNF-007 | Rendimiento | El sistema deberá soportar el uso concurrente por parte de usuarios de distintas UCO sin degradación significativa del servicio. | Media |
| RNF-008 | Disponibilidad | El sistema deberá estar disponible durante el horario habitual de trabajo de las unidades usuarias. | Alta |
3.2.2.4. Usabilidad
| Identificador | Categoría | Descripción | Prioridad |
|---|---|---|---|
| RNF-009 | Usabilidad | La interfaz deberá permitir completar el registro de una actividad o solicitud sin introducir información redundante. | Media |
| RNF-010 | Usabilidad | El sistema deberá presentar los estados de actividades y solicitudes de forma clara y homogénea en todas las pantallas. | Media |
3.2.2.5. Mantenibilidad y escalabilidad
| Identificador | Categoría | Descripción | Prioridad |
|---|---|---|---|
| RNF-011 | Mantenibilidad | El sistema deberá organizarse en capas diferenciadas de presentación, lógica de negocio y persistencia. | Alta |
| RNF-012 | Mantenibilidad | El código fuente deberá estructurarse de forma que permita incorporar nuevos perfiles, estados o reglas de negocio sin rediseñar el sistema completo. | Media |
| RNF-013 | Escalabilidad | La arquitectura deberá permitir incorporar nuevos módulos funcionales en futuras iteraciones del proyecto. | Media |
3.2.2.6. Interoperabilidad
| Identificador | Categoría | Descripción | Prioridad |
|---|---|---|---|
| RNF-014 | Interoperabilidad | El sistema deberá contemplar la posibilidad de integración futura con herramientas corporativas, como sistemas de autenticación, repositorios documentales o plataformas colaborativas. | Media |