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.4. Matriz de cumplimiento de requisitos

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

2.4. Matriz de cumplimiento de requisitos

ID Descripción Desarrollo Propio JSM GLPI
RF1 Existirán cuatro roles diferenciados: Administrador Central, Administrador de Unidad, Agente GC y Técnico ✔️ ✔️ ✔️
RF2 Usuarios administradores centrales podrán de alta nuevo material, categorizado dentro de una de las categorías (subtipos) existentes ✔️ ✔️ ✔️
RF3 Los administradores centrales podrán dar de baja o modificar material existente ✔️ ✔️ ✔️
RF4 El material se podrá asignar a un usuario (agente gc) o a una unidad ✔️ ✔️ ✔️
RF5 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 ✔️ ✔️ ✔️
RF6 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 ✔️ ✔️ ✔️
RF7 Los usuarios técnicos/órganos resolutores podrán marcar las incidencias como resueltas, o cambiarlas al estado que corresponda ✔️ ✔️ ✔️
RF8 Habrá tres órganos resolutores, uno por cada tipo de inicidencia. Las incidencias se asignarán al órgano reslutor que corresponda ✔️ ✔️ ✔️
RF9 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 ✔️ ✔️ ✔️
RF10 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 ✔️ ✔️ ✔️
RF11 Los administradores de unidad podran ver estadísticas sobre su personal y metariales dependientes ✔️ ✔️ ✔️
RF12 Los usuarios Administradores de Unidad podrán visualizar los usuarios de su unidad, así como el material que tienen asignado ✔️ ✔️ ✔️
RF13 El listado de Unidades se obtendrá del sistema NERHU (Nuevo Entorno de Recursos Humanos) de la Guardia Civil ✔️ ❌ ❌
RF14 El listado de Usarios se obtendrá del sistema de gestión de usuarios que proporcione Guardia Civil (LDAP, NERHU ...) ✔️ ❌ ❌
RF15 Los diferentes usuarios deben poder autenticarse mediante usuario/contraseña ✔️ ✔️ ✔️
RNF1 La aplicación debe poseer un diseño que garantice la adecuada visualización en PC, tablets y smartphones ✔️ ✔️ ✔️
RNF2 El sistema debe garantizar el cumplimiento del régimen general de protección de datos personales ✔️ ✔️ ✔️
RNF3 El acceso a la aplicación se realizará a través de protocolos que aseguren la confidencialidad de la información ✔️ ✔️ ✔️
RNF4 La aplicación se desplegará en cluster de alta disponiblidad con, al menos, dos servidores ✔️ ✔️ ✔️
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