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

Last edited by Manuel de Blas Pino Oct 13, 2025
Page history

3.1 Requisitos

🧩 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 (closed)
Funcional RF-04 El nombre del expediente debe generarse automáticamente. Activaciones #2 (closed)
Funcional RF-05 Debe ser posible añadir o eliminar solicitudes dentro de un expediente. Activaciones #2 (closed)
Funcional RF-06 El estado de una solicitud debe cambiar a “aceptado” al ser asignada a un expediente. Activaciones #2 (closed)
Funcional RF-07 El sistema debe implementar autenticación de usuarios. Activaciones #3 (closed), Plazas #3 (closed)
Funcional RF-08 El sistema debe registrar auditoría de todas las acciones de los usuarios (quién, cuándo, qué modificó). Activaciones #3 (closed), Plazas #3 (closed)
Funcional RF-09 Debe existir un formulario guiado para realizar solicitudes de activación. Activaciones #4 (closed)
Funcional RF-10 El formulario de solicitud debe incluir validación de campos obligatorios y formatos correctos. Activaciones #4 (closed), 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 (closed)
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 (closed)
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 (closed) (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 (closed)
Funcional RF-23 Debe avisar si no hay suficiente crédito para aprobar una solicitud. Activaciones #11 (closed)
Funcional RF-24 El sistema debe permitir consultar y modificar el coste por empleo/día. Activaciones #13 (closed)
Funcional RF-25 El sistema debe permitir filtrar solicitudes de plazas según criterios definidos por RRHH. Plazas #2 (closed)
Funcional RF-26 Debe ser posible importar UCOs de forma masiva desde un fichero .txt de SIPERDEF. Plazas #4 (closed)
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 (closed)
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 (closed), Plazas #3 (closed)
No Funcional RNF-02 Debe existir un sistema de auditoría persistente para registrar cambios. Activaciones #3 (closed), Plazas #3 (closed)
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 (closed)
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 (closed), 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 (closed), Plazas #3 (closed)
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 (closed) RF-03, RF-04, RF-05, RF-06 RNF-05
Activaciones #3 (closed) RF-07, RF-08 RNF-01, RNF-02, RNF-12
Activaciones #4 (closed) 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 (closed) (modificar) RF-17 RNF-05
Activaciones #9 (closed) (rechazo) RF-19 RNF-07
Activaciones #10 RF-20, RF-21 RNF-05
Activaciones #11 (closed) RF-22, RF-23 RNF-05
Activaciones #12 (closed) RF-13 RNF-07
Activaciones #13 (closed) RF-24 RNF-05
Plazas #1 RF-02 RNF-05
Plazas #2 (closed) RF-25 RNF-05
Plazas #3 (closed) RF-07, RF-08 RNF-01, RNF-02, RNF-12
Plazas #4 (closed) RF-26 RNF-08
Plazas #5 RF-27 RNF-08
Plazas #6 RF-10 RNF-09
Plazas #7 (closed) 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