3.2.-Requisitos.md

@@ -3,13 +3,13 @@ En este apartado se especifican los requisitos funcionales y no funcionales que
 
 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.
+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. La trazabilidad entre los requisitos funcionales y las historias de usuario se recoge posteriormente en la correspondiente matriz de trazabilidad.
+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.
 
 ---
 
@@ -17,91 +17,173 @@ Con el objetivo de facilitar su comprensión, implementación y posterior manten
 
 | 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 |
+| 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-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 |
+| 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. Gestión de solicitudes de apoyo sanitario
+#### 3.2.1.3. Planificación y asignación de recursos
 
 | 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 |
+| 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 apoyos sanitarios
+---
+
+#### 3.2.1.4. Gestión de solicitudes y tramitación
 
 | 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 |
+| 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.5. Administración del sistema
+#### 3.2.1.8. Integración con sistemas corporativos
 
 | 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 |
+| 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.6. Consulta y explotación de la información
+#### 3.2.1.9. Trazabilidad
 
 | 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 |
+| 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 que deberá cumplir PANACEA para garantizar un funcionamiento adecuado como aplicación interna de planificación y formalización de apoyos sanitarios.
+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
+---
 
-| Identificador | Categoría | Descripción | Prioridad |
+#### 3.2.2.1. Seguridad y control de acceso
+
+| Identificador | Nombre | 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 |
+| 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. Auditoría y trazabilidad
+#### 3.2.2.2. Rendimiento
 
-| Identificador | Categoría | Descripción | Prioridad |
+| Identificador | Nombre | 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 |
+| 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. Rendimiento y disponibilidad
+---
+
+#### 3.2.2.3. Disponibilidad y continuidad
 
-| Identificador | Categoría | Descripción | Prioridad |
+| Identificador | Nombre | 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 |
+| 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. Usabilidad
+#### 3.2.2.4. Integridad y concurrencia
 
-| Identificador | Categoría | Descripción | Prioridad |
+| Identificador | Nombre | 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 |
+| 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. Mantenibilidad y escalabilidad
+#### 3.2.2.5. Trazabilidad y auditoría
 
-| Identificador | Categoría | Descripción | Prioridad |
+| Identificador | Nombre | 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 |
+| 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.6. Interoperabilidad
+#### 3.2.2.8. Integración con sistemas externos
 
-| Identificador | Categoría | Descripción | Prioridad |
+| Identificador | Nombre | 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 |
+| 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 |
\ No newline at end of file