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 9
    • Issues 9
    • 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.2 Historias de Usuario

Last edited by Manuel de Blas Pino Nov 21, 2025
Page history
This is an old version of this page. You can view the most recent version or browse the history.

3.2 Historias de Usuario

Especificación de Requisitos

Dado que la metodología empleada se basa en enfoques ágiles, la especificación tradicional de requisitos funcionales y no funcionales carece de relevancia. En su lugar, se utilizan Historias de Usuario (HU) como producto principal para la especificación de requisitos.

Las HU permiten traducir los elementos del Impact Map en ítems que posteriormente conforman el PB, facilitando la priorización del trabajo pendiente.

El formato de una HU es el siguiente:

  • Quién: Actor.
  • Quiero: Entregable.
  • Para: Impacto.
  • Criterios de aceptación: Condiciones que deben cumplirse para considerar finalizada la implementación de la HU.

Historias de Usuario

A continuación, se describen las HU de la aplicación, organizadas por módulos y priorizadas según su importancia.

Módulo de Activaciones

  1. Como UCO quiero rellenar un formulario de solicitud de activación para no cometer errores al realizar una solicitud.

    • Criterios de aceptación:
      1. Se muestra un formulario con todos los campos requeridos.
      2. Se validan los datos antes del envío.
      3. La solicitud se registra correctamente en el sistema.
  2. Como SECRES quiero gestionar solicitudes de activación (crear, consultar, modificar y eliminar) para evitar utilizar una hoja de cálculo para registrar las solicitudes.

    • Criterios de aceptación:
      1. Se pueden crear nuevas solicitudes.
      2. Se pueden consultar las solicitudes existentes.
      3. Se pueden modificar los datos de una solicitud.
      4. Se pueden eliminar solicitudes si no están asociadas a expedientes cerrados.
  3. Como SECRES quiero asignar solicitudes aprobadas a un expediente para evitar utilizar una hoja de cálculo para registrar las solicitudes.

    • Criterios de aceptación:
      1. Se permite añadir una solicitud a un expediente desde la propia solicitud o desde el expediente.
      2. La solicitud se asigna correctamente y su estado cambia a “Aceptada”.
      3. No se permite reasignar solicitudes de expedientes cerrados.
  4. Como SECRES quiero que la aplicación notifique los cambios de estado de las solicitudes para evitar recibir llamadas preguntando por el estado de las solicitudes.

    • Criterios de aceptación:
      1. Se envía un correo al aprobar una solicitud.
      2. Se envía un correo al rechazar una solicitud.
      3. El correo incluye el motivo de rechazo o el expediente al que se ha asignado.
  5. Como SECRES quiero calcular el costea de una solicitud de activación para evitar tener que usar una hoja de cálculo para controlar del presupuesto.

    • Criterios de aceptación:
      1. El sistema calcula automáticamente el coste en función del empleo y la duración.
      2. Se muestra un aviso si el crédito disponible es insuficiente.
      3. El cálculo se actualiza al modificar datos de la solicitud.
  6. Como SECRES quiero rechazar solicitudes de activación para evitar utilizar una hoja de cálculo para registrar las solicitudes.

    • Criterios de aceptación:
      1. Se permite marcar una solicitud como Rechazada.
      2. Se requiere indicar un motivo de rechazo.
      3. El motivo queda registrado y visible en el detalle de la solicitud.
  7. Como UCO quiero adjuntar documentos a mi solicitud de activación para reducir la cantidad de oficios que se envían.

    • Criterios de aceptación:
      1. Se permite adjuntar documentos al crear la solicitud.
      2. Se permite consultar los documentos adjuntos desde la vista de detalle.
      3. La documentación se almacena y asocia correctamente a la solicitud.
  8. Como SECRES quiero consultar y actualizar el crédito disponible para activaciones para evitar tener que usar una hoja de cálculo para controlar del presupuesto.

    • Criterios de aceptación:
      1. Se muestra el crédito disponible actual.
      2. El crédito se actualiza automáticamente al publicar expedientes.
      3. Los cambios quedan registrados en el sistema.
  9. Como SECRES quiero consultar y modificar el coste por día y empleo para evitar tener que usar una hoja de cálculo para controlar del presupuesto.

    • Criterios de aceptación:
      1. Se permite visualizar la tabla de costes por empleo/día.
      2. Se pueden modificar los valores individualmente.
      3. Los cambios se aplican correctamente a los nuevos cálculos de coste.

Módulo de Plazas

  1. Como SECRES quiero gestionar solicitudes de plazas (crear, consultar, modificar y anular) para evitar el uso de hojas de cálculo.

    • Criterios de aceptación:
      1. Crear solicitudes de plazas.
      2. Editar solicitudes de plazas.
      3. Consultar solicitudes de plazas.
      4. Eliminar solicitudes de plazas.
  2. Como SECRES quiero filtrar solicitudes de plazas según criterios de RRHH del EME.

    • Criterios de aceptación:
      1. Seleccionar criterios de filtrado.
      2. Obtener un listado de plazas priorizadas.
  3. Como SECRES quiero que la aplicación requiera autenticación para garantizar trazabilidad.

    • Criterios de aceptación:
      1. Registrar qué usuario realiza cada cambio en las solicitudes.
  4. Como SECRES quiero importar UCOs de forma masiva para evitar ingreso manual.

    • Criterios de aceptación:
      1. Reconocer ficheros .txt con formato SIPERDEF.
  5. Como SECRES quiero importar titulaciones, formaciones y experiencia laboral de forma masiva.

    • Criterios de aceptación:
      1. Importar ficheros .xlsx con toda la información necesaria.
  6. Como UCO quiero un formulario guiado para solicitudes de plazas.

    • Criterios de aceptación:
      1. No permitir envío de solicitudes incompletas.
  7. Como SECRES quiero exportar convocatorias en formato específico para importarlas en SIPERDEF.

    • Criterios de aceptación:
      1. Exportar con todos los campos necesarios para SIPERDEF.
  8. Como UCO quiero un justificante al realizar una solicitud para enviarlo a la UCO superior.

    • Criterios de aceptación:
      1. El justificante contiene toda la información de la solicitud y la fecha y hora de creación.
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
    6. Analistas
  2. Estudio de Viabilidad del Sistema (EVS)
    1. Mind Map
    2. Impact Map
    3. Alternativas
      1. Sage HR
      2. OrangeHRM
      3. Deméter
      4. Matriz de decisión
  3. Especificación de Requisitos del Sistema (ERS)
    1. Planificación
    2. Historias de Usuario
    3. Product Backlog
    4. Diseño de la Interfaz de Usuario
    5. Diagramas
  4. Definición del MVP
  5. Sprint 1
    1. Sprint Planning
    2. Sprint Review
    3. Sprint Retrospective
  6. Sprint 2
    1. Sprint Planning
    2. Plan de pruebas
    3. Sprint Review
    4. Sprint Retrospective
  7. Sprint 3
    1. Sprint Planning
    2. Sprint Review
    3. Sprint Retrospective
  8. Sprint 4
    1. Sprint Planning
    2. Plan de pruebas
    3. Sprint Review
    4. Sprint Restrospective
  9. Sprint 5
    1. Sprint Planning
    2. Sprint Review
    3. Sprint Retrospective
  10. Manual de desarrollador
    1. Guía de instalación
    2. Estructura del backend
    3. Estructura del frontend
  11. Siglas
  12. Referencias