Agustin Martin ArranzEn 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 apartado 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. Su definición parte de las historias de usuario y de las decisiones funcionales adoptadas durante el análisis del proceso.
3.2.1.1. Gestión de actividades
| Identificador | Nombre | Descripción | Origen | Prioridad |
|---|---|---|---|---|
| RF-001 | Creación de actividades | El sistema deberá permitir a las UCO crear actividades que requieran apoyo sanitario, registrando la información necesaria para su planificación. | HU-01 | Alta |
| RF-002 | Modificación de actividades | El sistema deberá permitir modificar las actividades mientras no existan restricciones derivadas de la asignación de recursos o de la existencia de una solicitud de apoyo. | HU-01 | Alta |
| RF-003 | Cancelación de actividades | El sistema deberá permitir a la UCO cancelar una actividad, liberando los recursos asignados, cerrando la solicitud asociada cuando exista y conservando la trazabilidad de las actuaciones realizadas. | HU-01 | Alta |
| RF-004 | Consulta de actividades | El sistema deberá permitir consultar las actividades mediante vistas de calendario y listado, con filtros por rango de fechas y estado y acceso al detalle de cada actividad. | HU-01, HU-05 | Alta |
| RF-005 | Estado de las actividades | El sistema deberá gestionar el estado de las actividades durante su ciclo de vida de acuerdo con su planificación, cobertura y resolución. | HU-01, HU-03, HU-04 | Alta |
3.2.1.2. Gestión de recursos sanitarios
| Identificador | Nombre | Descripción | Origen | Prioridad |
|---|---|---|---|---|
| RF-006 | Consulta de recursos sanitarios | El sistema deberá permitir consultar los recursos sanitarios y su estado y disponibilidad de acuerdo con el ámbito funcional del usuario. | HU-02, HU-06, HU-10 | Alta |
| RF-007 | Gestión de recursos propios | El sistema deberá permitir a las UCO mantener actualizada la información de los recursos sanitarios orgánicos cuya gestión les corresponda. | HU-02 | Alta |
| RF-008 | Disponibilidad y asignabilidad | El sistema deberá determinar la disponibilidad y asignabilidad de los recursos sanitarios para las fechas de una actividad, teniendo en cuenta sus condiciones y las asignaciones existentes. | HU-02, HU-03, HU-07, HU-11 | Alta |
| RF-009 | Prevención de conflictos de asignación | El sistema deberá impedir la asignación simultánea de un mismo recurso a actividades cuyas fechas se solapen. | HU-03, HU-07, HU-11 | Alta |
| RF-010 | Visibilidad de recursos del NAS | El sistema deberá permitir a los usuarios con contexto NAS consultar los recursos sanitarios de su ARG y los pertenecientes a otros ámbitos NAS. | HU-10 | Alta |
3.2.1.3. Planificación y asignación de recursos
| Identificador | Nombre | Descripción | Origen | Prioridad |
|---|---|---|---|---|
| RF-011 | Asignación directa de recursos propios | El sistema deberá permitir a la UCO asignar recursos sanitarios propios disponibles a una actividad. | HU-03 | Alta |
| RF-012 | Asignación de recursos a solicitudes | El sistema deberá permitir a los escalones responsables asignar recursos disponibles a las solicitudes de apoyo que se encuentren tramitando. | HU-07, HU-11 | Alta |
| RF-013 | Asignación parcial | El sistema deberá permitir cubrir parcialmente una necesidad de apoyo, manteniendo identificados los recursos ya asignados y las necesidades que permanezcan sin cubrir. | HU-07, HU-11 | Alta |
| RF-014 | Actualización de necesidades pendientes | El sistema deberá actualizar las necesidades pendientes de una actividad después de cada asignación realizada. | HU-03, HU-07, HU-11 | Alta |
3.2.1.4. Gestión de solicitudes y tramitación
| Identificador | Nombre | Descripción | Origen | Prioridad |
|---|---|---|---|---|
| RF-015 | Creación de solicitudes de apoyo | El sistema deberá permitir a la UCO generar una solicitud de apoyo asociada a una actividad cuando existan necesidades que no puedan ser cubiertas con medios propios. | HU-04 | Alta |
| RF-016 | Contenido de la solicitud | La solicitud deberá identificar las necesidades de apoyo que permanezcan sin cubrir y conservar su relación con la actividad que la origina. | HU-04 | Alta |
| RF-017 | Elevación manual | El sistema deberá permitir elevar manualmente al escalón superior aquellas necesidades que no hayan podido ser cubiertas en el escalón que tramita la solicitud. | HU-08, HU-12, HU-16 | Alta |
| RF-018 | Conservación de asignaciones en la elevación | Cuando una solicitud sea elevada, las asignaciones ya realizadas deberán mantenerse asociadas a la actividad y únicamente continuarán su tramitación las necesidades pendientes. | HU-08, HU-12 | Alta |
| RF-019 | Seguimiento de solicitudes | El sistema deberá permitir consultar el estado de una solicitud, el escalón en el que se encuentra su tramitación y las actuaciones realizadas durante el proceso. | HU-04, HU-06, HU-09, HU-10, HU-13, HU-14, HU-17 | Alta |
3.2.1.5. Resolución de los apoyos sanitarios
| Identificador | Nombre | Descripción | Origen | Prioridad |
|---|---|---|---|---|
| RF-020 | Coordinación de capacidades por BRILOG | El sistema deberá permitir a BRILOG gestionar las solicitudes recibidas y realizar las actuaciones de coordinación necesarias dentro de las capacidades disponibles. | HU-14, HU-15 | Alta |
| RF-021 | Declaración de apoyo no realizable | El sistema deberá permitir declarar que un apoyo no puede realizarse cuando corresponda, registrando la decisión, su motivo y sus efectos sobre la actividad y los recursos asignados. | HU-16, HU-18 | Alta |
| RF-022 | Externalización del apoyo | El sistema deberá permitir a DISAN registrar la externalización de un apoyo sanitario cuando esta sea la resolución adoptada. | HU-18 | Alta |
| RF-023 | Resolución de solicitudes | El sistema deberá registrar la resolución final de las solicitudes y conservar la trazabilidad completa de su tramitación. | HU-16, HU-18 | Alta |
3.2.1.6. Consulta de apoyos planificados
| Identificador | Nombre | Descripción | Origen | Prioridad |
|---|---|---|---|---|
| RF-024 | Consulta de apoyos del SMR | El sistema deberá permitir al SMR consultar las actividades con apoyo sanitario de su ámbito, los recursos comprometidos y las necesidades pendientes. | HU-09 | Alta |
| RF-025 | Consulta de apoyos del NAS | El sistema deberá permitir al NAS consultar las actividades con apoyo sanitario de su ARG, los recursos comprometidos y las necesidades pendientes. | HU-13 | Alta |
| RF-026 | Detalle de la tramitación | El sistema deberá permitir consultar, cuando exista una solicitud asociada, su estado y el escalón en el que se encuentra actualmente su tramitación. | HU-09, HU-13, HU-14, HU-17 | Alta |
3.2.1.7. Contexto funcional y control de ámbito
| Identificador | Nombre | Descripción | Origen | Prioridad |
|---|---|---|---|---|
| RF-027 | Selección de contexto funcional | El sistema deberá permitir al usuario seleccionar entre los contextos funcionales que tenga autorizados. | Requisito técnico de soporte | Alta |
| RF-028 | Cambio de contexto | El sistema deberá permitir cambiar de contexto funcional durante el uso de la aplicación sin necesidad de realizar una nueva autenticación. | Requisito técnico de soporte | Alta |
| RF-029 | Aplicación del ámbito funcional | El sistema deberá limitar las operaciones y la información accesible de acuerdo con el contexto funcional activo y el ámbito de responsabilidad asociado. | Requisito técnico de soporte | Alta |
3.2.1.8. Integración con sistemas corporativos
| Identificador | Nombre | Descripción | Origen | Prioridad |
|---|---|---|---|---|
| RF-030 | Integración con SIPERDEF | El sistema deberá integrar los datos orgánicos y de personal que se determinen procedentes de SIPERDEF. | Alcance del sistema | Alta |
| RF-031 | Integración con SIGLE | El sistema deberá integrar los datos relativos a los recursos materiales que se determinen procedentes de SIGLE. | Alcance del sistema | Alta |
3.2.1.9. Trazabilidad
| Identificador | Nombre | Descripción | Origen | Prioridad |
|---|---|---|---|---|
| RF-032 | Trazabilidad funcional | El sistema deberá conservar la trazabilidad de las actuaciones relevantes realizadas durante la planificación, asignación, tramitación y resolución de los apoyos sanitarios. | HU-01, HU-04, HU-07, HU-08, HU-11, HU-12, HU-15, HU-16, HU-18 | Alta |
3.2.2. Requisitos no funcionales
Los requisitos no funcionales establecen las condiciones de calidad, seguridad, rendimiento y operación que deberá cumplir PANACEA durante su utilización.
3.2.2.1. Seguridad y control de acceso
| Identificador | Nombre | Descripción | Prioridad |
|---|---|---|---|
| RNF-001 | Autenticación de usuarios | El acceso a PANACEA deberá realizarse mediante los mecanismos de autenticación proporcionados por MEDUSA. | Alta |
| RNF-002 | Autorización por contexto funcional | El sistema deberá autorizar las operaciones en función del usuario autenticado, el contexto funcional activo y el ámbito de responsabilidad asociado. | Alta |
| RNF-003 | Restricción de acceso a la información | El sistema deberá limitar el acceso a la información de acuerdo con el ámbito funcional correspondiente, respetando las excepciones expresamente definidas, como la visibilidad global de recursos para los contextos NAS. | Alta |
| RNF-004 | Validación en backend | Las reglas de autorización y ámbito deberán validarse siempre en el backend, independientemente de las restricciones aplicadas en la interfaz de usuario. | Alta |
3.2.2.2. Rendimiento
| Identificador | Nombre | Descripción | Prioridad |
|---|---|---|---|
| RNF-005 | Tiempo de respuesta | Las operaciones habituales de consulta y gestión deberán ofrecer tiempos de respuesta adecuados para un uso interactivo del sistema. | Media |
| RNF-006 | Optimización de consultas | Las consultas sobre actividades, recursos y solicitudes deberán implementarse de forma que eviten accesos innecesarios o repetitivos a la base de datos. | Media |
3.2.2.3. Disponibilidad y continuidad
| Identificador | Nombre | Descripción | Prioridad |
|---|---|---|---|
| RNF-007 | Disponibilidad del sistema | PANACEA deberá estar disponible durante los periodos de utilización previstos, salvo interrupciones debidas a mantenimiento o incidencias de la infraestructura. | Alta |
| RNF-008 | Recuperación ante errores | El sistema deberá gestionar los errores de forma controlada, evitando la pérdida o corrupción de información ante fallos de una operación. | Alta |
3.2.2.4. Integridad y concurrencia
| Identificador | Nombre | Descripción | Prioridad |
|---|---|---|---|
| RNF-009 | Integridad de la información | El sistema deberá mantener la coherencia de la información almacenada durante las operaciones de creación, modificación, asignación, cancelación, elevación y resolución. | Alta |
| RNF-010 | Control de concurrencia | El sistema deberá impedir que operaciones concurrentes produzcan asignaciones incompatibles o estados inconsistentes. | Alta |
| RNF-011 | Validación de disponibilidad en asignación | La disponibilidad y asignabilidad de un recurso deberán verificarse en el momento efectivo de realizar la asignación y no únicamente durante su consulta previa. | Alta |
3.2.2.5. Trazabilidad y auditoría
| Identificador | Nombre | Descripción | Prioridad |
|---|---|---|---|
| RNF-012 | Registro de actuaciones | El sistema deberá registrar las actuaciones relevantes realizadas sobre actividades, asignaciones, solicitudes, trámites y resoluciones. | Alta |
| RNF-013 | Identificación de usuario y fecha | Las actuaciones que requieran trazabilidad deberán permitir identificar al usuario responsable y la fecha en que fueron realizadas. | Alta |
| RNF-014 | Conservación del histórico | La cancelación, anulación o resolución de una actividad o solicitud no deberá eliminar la información histórica necesaria para reconstruir su tramitación. | Alta |
3.2.2.6. Usabilidad
| Identificador | Nombre | Descripción | Prioridad |
|---|---|---|---|
| RNF-015 | Consistencia de interfaz | La interfaz deberá mantener criterios homogéneos de navegación, presentación de información y ejecución de acciones. | Media |
| RNF-016 | Comprensibilidad | Las pantallas y acciones deberán emplear terminología comprensible para los usuarios del proceso de apoyo sanitario. | Media |
| RNF-017 | Información de estado | El sistema deberá mostrar de forma clara el estado de las actividades, solicitudes y recursos, así como las acciones disponibles en cada situación. | Alta |
3.2.2.7. Mantenibilidad y evolución
| Identificador | Nombre | Descripción | Prioridad |
|---|---|---|---|
| RNF-018 | Arquitectura modular | La aplicación deberá mantener una separación clara entre presentación, lógica de negocio y persistencia, facilitando su mantenimiento y evolución. | Media |
| RNF-019 | Compatibilidad con MEDUSA | El desarrollo deberá integrarse con la arquitectura y mecanismos proporcionados por MEDUSA sin alterar innecesariamente sus componentes reutilizables. | Alta |
| RNF-020 | Evolución funcional | La arquitectura deberá permitir incorporar nuevas capacidades o modificaciones del procedimiento sin requerir una reconstrucción completa del sistema. | Media |
3.2.2.8. Integración con sistemas externos
| Identificador | Nombre | Descripción | Prioridad |
|---|---|---|---|
| RNF-021 | Integración corporativa | Las integraciones con sistemas corporativos externos deberán realizarse mediante mecanismos compatibles con los requisitos técnicos y de seguridad establecidos para dichos sistemas. | Alta |
| RNF-022 | Independencia del dominio | El modelo interno de PANACEA deberá mantener una separación suficiente respecto a los mecanismos concretos de intercambio con sistemas externos, evitando que cambios en dichas interfaces afecten innecesariamente al núcleo funcional de la aplicación. | Media |