Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • demeter demeter
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 16
    • Issues 16
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Manuel de Blas
  • demeterdemeter
  • Wiki
    • 3.ers
  • 3.1 Requisitos

3.1 Requisitos · Changes

Page history
requisitos. authored Oct 13, 2025 by Manuel de Blas Pino's avatar Manuel de Blas Pino
Hide whitespace changes
Inline Side-by-side
Showing with 86 additions and 3 deletions
+86 -3
  • 3.ers/3.1 Requisitos.md 3.ers/3.1 Requisitos.md +86 -3
  • No files found.
3.ers/3.1 Requisitos.md
View page @ 2e1c6951
<div align="center">
<img src="https://git.institutomilitar.com/Manu0jeda/demeter/-/wikis/img/Demeter_Requisitos.png" alt="Requisitos" align="center"/>
</div>
# 🧩 Requisitos de la Aplicación
## Requisitos Funcionales
| Tipo | ID | Requisito | Historias de Usuario Relacionadas |
| ------------- | ----- | ------------------------------------------------------------------------------------------------------------ | --------------------------------- |
| **Funcional** | RF-01 | El sistema debe permitir **crear, modificar, consultar y eliminar solicitudes de activación**. | Activaciones #1 |
| **Funcional** | RF-02 | El sistema debe permitir **crear, modificar, consultar y eliminar solicitudes de plazas**. | Plazas #1 |
| **Funcional** | RF-03 | El sistema debe permitir **generar expedientes** y **asignarles solicitudes de activación**. | Activaciones #2 |
| **Funcional** | RF-04 | El nombre del expediente debe **generarse automáticamente**. | Activaciones #2 |
| **Funcional** | RF-05 | Debe ser posible **añadir o eliminar solicitudes dentro de un expediente**. | Activaciones #2 |
| **Funcional** | RF-06 | El estado de una solicitud debe **cambiar a “aceptado”** al ser asignada a un expediente. | Activaciones #2 |
| **Funcional** | RF-07 | El sistema debe implementar **autenticación de usuarios**. | Activaciones #3, Plazas #3 |
| **Funcional** | RF-08 | El sistema debe registrar **auditoría de todas las acciones de los usuarios** (quién, cuándo, qué modificó). | Activaciones #3, Plazas #3 |
| **Funcional** | RF-09 | Debe existir un **formulario guiado** para realizar solicitudes de activación. | Activaciones #4 |
| **Funcional** | RF-10 | El formulario de solicitud debe incluir **validación de campos obligatorios y formatos correctos**. | Activaciones #4, Plazas #6 |
| **Funcional** | RF-11 | El sistema debe permitir **cargar y asociar documentación** a las solicitudes. | Activaciones #5 |
| **Funcional** | RF-12 | El usuario debe poder **consultar la documentación asociada** a cada solicitud. | Activaciones #5 |
| **Funcional** | RF-13 | El sistema debe **enviar notificaciones por correo electrónico** cuando cambie el estado de una solicitud. | Activaciones #6, #12 |
| **Funcional** | RF-14 | En los detalles de una solicitud debe mostrarse **su estado actual y motivo**. | Activaciones #6 |
| **Funcional** | RF-15 | Debe permitirse **cerrar expedientes manual o automáticamente** (al llegar a 25 solicitudes). | Activaciones #8 |
| **Funcional** | RF-16 | Las solicitudes de un expediente cerrado deben pasar a **estado “pendiente de publicación”**. | Activaciones #8 |
| **Funcional** | RF-17 | No debe permitirse **modificar solicitudes** si el expediente está cerrado o la solicitud rechazada. | Activaciones #9 |
| **Funcional** | RF-18 | El usuario debe poder **reabrir un expediente** si no ha sido enviado para publicación. | Activaciones #8 |
| **Funcional** | RF-19 | El sistema debe permitir **rechazar solicitudes**, indicando un motivo y notificando al solicitante. | Activaciones #9 (rechazo) |
| **Funcional** | RF-20 | El usuario debe poder **consultar el crédito disponible** para activaciones. | Activaciones #10 |
| **Funcional** | RF-21 | El crédito debe **actualizarse automáticamente** al publicar un expediente. | Activaciones #10 |
| **Funcional** | RF-22 | El sistema debe **calcular el coste** de una solicitud de activación automáticamente. | Activaciones #11 |
| **Funcional** | RF-23 | Debe avisar si **no hay suficiente crédito** para aprobar una solicitud. | Activaciones #11 |
| **Funcional** | RF-24 | El sistema debe permitir **consultar y modificar el coste por empleo/día**. | Activaciones #13 |
| **Funcional** | RF-25 | El sistema debe permitir **filtrar solicitudes de plazas** según criterios definidos por RRHH. | Plazas #2 |
| **Funcional** | RF-26 | Debe ser posible **importar UCOs de forma masiva** desde un fichero `.txt` de SIPERDEF. | Plazas #4 |
| **Funcional** | RF-27 | Debe ser posible **importar titulaciones, formaciones y experiencia laboral** desde un fichero `.xlsx`. | Plazas #5 |
| **Funcional** | RF-28 | El sistema debe permitir **exportar convocatorias** en formato compatible con SIPERDEF. | Plazas #7 |
| **Funcional** | RF-29 | El sistema debe **generar un justificante** al registrar una solicitud de plaza. | Plazas #8 |
| **Funcional** | RF-30 | El justificante debe incluir **toda la información de la solicitud y la fecha/hora de creación**. | Plazas #8 |
## Requisitos No Funcionales
| Tipo | ID | Requisito | Justificación / Historias Relacionadas |
| ---------------- | ------ | -------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- |
| **No Funcional** | RNF-01 | El sistema debe contar con **autenticación segura** (p. ej., JWT, OAuth2 o Spring Security). | Activaciones #3, Plazas #3 |
| **No Funcional** | RNF-02 | Debe existir un **sistema de auditoría persistente** para registrar cambios. | Activaciones #3, Plazas #3 |
| **No Funcional** | RNF-03 | La aplicación debe ser **accesible desde distintos dispositivos** (PC, tablet, móvil). | Necesidad operativa general |
| **No Funcional** | RNF-04 | Las operaciones de consulta deben **responder en menos de 3 segundos** para un volumen estándar de solicitudes. | Rendimiento esperado |
| **No Funcional** | RNF-05 | Los datos de las solicitudes y expedientes deben **guardarse en una base de datos relacional** con integridad referencial. | Implicación funcional general |
| **No Funcional** | RNF-06 | El sistema debe **controlar los roles de usuario** (SECRES, UCO, peticionario). | Derivado de todas las historias con distintos actores |
| **No Funcional** | RNF-07 | El envío de correos debe ser **fiable y registrar errores de entrega**. | Activaciones #6, #12 |
| **No Funcional** | RNF-08 | El sistema debe ser **modular y mantenible**, separando claramente los módulos de activaciones y plazas. | Diseño de arquitectura |
| **No Funcional** | RNF-09 | Debe existir **validación de datos tanto en frontend como en backend**. | Activaciones #4, Plazas #6 |
| **No Funcional** | RNF-10 | La aplicación debe seguir una **interfaz homogénea y consistente** en todos los formularios. | Usabilidad general |
| **No Funcional** | RNF-11 | Debe registrarse la **fecha y usuario** de creación y última modificación de cada solicitud. | Auditoría |
| **No Funcional** | RNF-12 | El sistema debe permitir **trazabilidad total** de solicitudes y expedientes. | Activaciones #3, Plazas #3 |
| **No Funcional** | RNF-13 | La aplicación debe cumplir con **normas de seguridad y protección de datos (LOPD/GDPR)**. | Datos personales y documentación |
| **No Funcional** | RNF-14 | El sistema debe permitir **respaldo y recuperación de datos** ante fallo o pérdida. | Confiabilidad |
| **No Funcional** | RNF-15 | El sistema debe estar **desplegado en un entorno seguro y controlado** (HTTPS, cortafuegos, control de acceso). | Seguridad |
---
## 🔗 Matriz de Trazabilidad (Historias de Usuario ↔ Requisitos)
| Historia de Usuario | Requisitos Funcionales Relacionados | Requisitos No Funcionales Relacionados |
| --------------------------- | ----------------------------------- | -------------------------------------- |
| Activaciones #1 | RF-01 | RNF-05, RNF-09 |
| Activaciones #2 | RF-03, RF-04, RF-05, RF-06 | RNF-05 |
| Activaciones #3 | RF-07, RF-08 | RNF-01, RNF-02, RNF-12 |
| Activaciones #4 | RF-09, RF-10 | RNF-09, RNF-10 |
| Activaciones #5 | RF-11, RF-12 | RNF-13 |
| Activaciones #6 | RF-13, RF-14 | RNF-07 |
| Activaciones #8 | RF-15, RF-16, RF-18 | RNF-05 |
| Activaciones #9 (modificar) | RF-17 | RNF-05 |
| Activaciones #9 (rechazo) | RF-19 | RNF-07 |
| Activaciones #10 | RF-20, RF-21 | RNF-05 |
| Activaciones #11 | RF-22, RF-23 | RNF-05 |
| Activaciones #12 | RF-13 | RNF-07 |
| Activaciones #13 | RF-24 | RNF-05 |
| Plazas #1 | RF-02 | RNF-05 |
| Plazas #2 | RF-25 | RNF-05 |
| Plazas #3 | RF-07, RF-08 | RNF-01, RNF-02, RNF-12 |
| Plazas #4 | RF-26 | RNF-08 |
| Plazas #5 | RF-27 | RNF-08 |
| Plazas #6 | RF-10 | RNF-09 |
| Plazas #7 | RF-28 | RNF-08 |
| Plazas #8 | RF-29, RF-30 | RNF-10, RNF-13 |
---
Clone repository
  1. Especificación y formulación del problema
    1. Introducción
    2. Definición del problema
    3. Descripción del proceso actual
    4. Actores
    5. Alcance y limitaciones
  2. Estudio de Viabilidad del Sistema (EVS)
    1. Mind Map
    2. Impact Map
    3. Historias de Usuario
    4. Alternativas
      1. Sage HR
      2. OrangeHRM
      3. Deméter
      4. Matriz de decisión
  3. Especificación de Requisitos del Sistema (ERS)
    1. Requisitos
    2. Casos de Uso
    3. Diseño de la Interfaz de Usuario
    4. Product Backlog
  4. Definición del MVP
  5. Sprint 1
    1. Sprint Planning
    2. Sprint Review
    3. Sprint Retrospective
    4. Burndown
  6. Sprint 2
    1. Sprint Planning
    2. Sprint Review
    3. Sprint Retrospective
    4. Burndown
  7. Sprint 3
    1. Sprint Planning
    2. Sprint Review
    3. Sprint Retrospective
  8. Sprint 4
    1. Sprint Planning
    2. Sprint Review
    3. Sprint Restrospective
  9. Acrónimos y siglas