Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GATEL GATEL
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • 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
  • Camope
  • GATELGATEL
  • Wiki
  • 2.1. Requisitos

Last edited by Carlos Moreno Sep 23, 2023
Page history
This is an old version of this page. You can view the most recent version or browse the history.

2.1. Requisitos

Requisitos Funcionales

Id Prioridad Descripción MVP Fuente
RF1 Alta Existirán cuatro roles diferenciados: Administrador Central, Administrador de Unidad, Agente GC y Técnico ✔️ Reunión developers - PO
RF2 Alta Usuarios administradores centrales podrán de alta nuevo material, categorizado dentro de una de las categorías (subtipos) existentes ✔️ Reunión developers - PO
RF3 Alta Los administradores centrales podrán dar de baja o modificar material existente. ✔️ Reunión developers - PO
RF4 Alta El material se podrá asignar a un usuario (agente gc) o a una unidad - PO ✔️ Reunión developers - PO
RF5 Alta Los agentes pertenecerán a una unidad determinada, pudendo los administradores listar el material que tiene la unidad, bien asignado a la propia unidad, o asignado a alguno de sus usuarios. Los usuarios agentes, solo podrán ver sus materiales ✔️ Reunión developers - PO
RF6 Media Los agentes y los administradores de Unidad podrán dar de alta nuevas incidencias, que pueden ser relativas a configuración, avería o extravío. Reunión developers - PO
RF7 Media Los usuarios técnicos/órganos resolutores podrán marcar las incidencias como resueltas, o cambiarlas al estado que corresponda ✔️ Reunión developers - PO
RF8 Media Habrá tres órganos resolutores, uno por cada tipo de inicidencia. Las incidencias se asignarán al órgano reslutor que corresponda Reunión developers - PO
RF9 Media Los dos tipos de administradores podrán listar todas las incidencias existentes, pudiendo filtrar por diferentes criterios. Los administradores de Unidad solamente podŕan acceder a las incidencias reportadas por sus usuarios Reunión developers - PO
RF10 Alta Los administradores centrales podrán ver estadísticas sobre el número de usuarios, unidades, en relación con el material que tienen asignado y las incidencias que han dado de alta Reunión developers - PO
RF11 Alta Los administradores de unidad podran ver estadísticas sobre su personal y metariales dependientes Reunión developers - PO
RF12 Alta Los usuarios Administradores de Unidad podrán visualizar los usuarios de su unidad, así como el material que tienen asignado Reunión developers - PO
RF13 Baja El listado de Unidades se obtendrá del sistema NERHU (Nuevo Entorno de Recursos Humanos) de la Guardia Civil Reunión developers - PO
RF14 Baja El listado de Usarios se obtendrá del sistema de gestión de usuarios que proporcione Guardia Civil (LDAP, NERHU ...) Reunión developers - PO
RF15 Media Los diferentes usuarios deben poder autenticarse mediante usuario/contraseña Reunión developers - PO

Requisitos No Funcionales

Id Prioridad Descripción MVP Fuente
RNF1 Alta La aplicación debe poseer un diseño que garantice la adecuada visualización en PC, tablets y smartphones ✔️ Reunión developers - PO
RNF2 Alta El sistema debe garantizar el cumplimiento del régimen general de protección de datos personales ✔️ Restricción legal
RNF3 Alta El acceso a la aplicación se realizará a través de protocolos que aseguren la confidencialidad de la información ✔️ Reunión developers - PO
RNF4 Baja La aplicación se desplegará en cluster de alta disponiblidad con, al menos, dos servidores ✔️ Reunión developers - PO
Clone repository

Home

  1. Especificación y formulación del problema
  2. Estudio de viabilidad del sistema
    2.1 Requisitos
    2.2 Mind Map
    2.3 Estudio de Alternativas
    2.4 Matriz de Cumplimento de Requisitos-Alternativas
    2.5 Matriz de decisión
  3. Especificación de Requisitos del Software
    3.1 Planificación general
    3.2 Impact Map
    3.3 Modelos de Negocio y Dominio
    3.4 Interfaz de Usuario
    3.5 Definición del MVP