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

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, MiembroGC no administrador y Personal Externo (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 (MiembroGC) o a una unidad ✔️ ✔️ ✔️
RF5 Los MiembroGC pertenecerán a una unidad determinada, pudiendo los administradores listar el material que tiene la unidad, bien asignado a la propia unidad, o asignado a alguno de sus usuarios. Los MiembroGC no administrador, solo podrán ver sus materiales ✔️ ✔️ ✔️
RF6 Todos los MiembroGC (administrador y no administrador) podrán dar de alta nuevas incidencias, que pueden ser relativas a configuración, avería, extravío o solicitud ✔️ ✔️ ✔️
RF7 Los Administradores y Técnicos podrán marcar las incidencias como resueltas, o cambiarlas al estado que corresponda ✔️ ✔️ ✔️
RF8 Los Administradores y Técnicos solo podrán atender aquellas incidencias que estén dentro de su ámbito competencias (restringido por su perfil) ✔️ ✔️ ✔️
RF9 Los dos tipos de administradores podrán listar todas las incidencias existentes, pudiendo filtrar por diferentes criterios. Los administradores de Unidad solamente podrán acceder a las incidencias reportadas por sus usuarios ✔️ ✔️ ✔️
RF10 Los administradores centrales podrán ver estadísticas sobre el número total de equipamiento asignado a cada unidad y del tipo de cada equipamiento ✔️ ✔️ ✔️
RF11 Los administradores de unidad podran ver estadísticas sobre el tipo de equipamiento que tienen asignado ✔️ ✔️ ✔️
RF12 Los 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 interfaz de la aplicación se desarrollará siguiendo las pautas de accesibilidad recogidas en la especificación WCAG 2.1, debiendo seguir, al menos, el nivel A de las directrices que guían cada uno de sus principios (Perceptible, Operable, Comprensible y Robusto) ✔️ ✔️ ✔️
RNF5 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

  4. Sprint 1
    4.1 Sprint Planning
    4.2 Daily Scrum
    4.3 Sprint Review
    4.4 Sprint Retrospective
    4.5 Burndown

  5. Sprint 2
    5.1 Sprint Planning
    5.2 Daily Scrum
    5.3 Sprint Review
    5.4 Sprint Retrospective
    5.5 Burndown

  6. ANEXOS - UML
    6.1 Diagrama de secuencia
    6.2 Diagrama de clases API-Libreria