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

2.1. Requisitos · Changes

Page history
Matriz de decisión authored Sep 15, 2023 by Camope's avatar Camope
Hide whitespace changes
Inline Side-by-side
Showing with 14 additions and 10 deletions
+14 -10
  • 2.1.-Requisitos.md 2.1.-Requisitos.md +14 -10
  • No files found.
2.1.-Requisitos.md
View page @ 8343c36a
......@@ -3,26 +3,30 @@
### 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| X | 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| X | Reunión developers - PO |
| RF3 | Alta | Los administradores centrales podrán dar de baja o modificar material existente. | X | 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| X | Reunión developers - PO |
| 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 | X | 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 podran 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 |
| 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 Uusarios se obtendrá del sistema de gestión de usuarios que proporcione Guardia Civil (LDAP, NERHU ...)| | 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 | Accesible desde múltiples dispositivos | X | Reunión developers - PO |
| RNF1 | Alta | El sistema debe estar protegido de accesos no autorizados | | Reunión developers - PO |
| 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