Historias de usuario¶

Las veinte US-0xx del proyecto, con su enunciado completo y su estado real.

Estado de cada historia¶

La última columna dice qué hace el sistema hoy, no qué decía el documento.

Qué cambió entre lo declarado y lo verificado¶

De las once historias que el documento daba por cumplidas, cuatro no lo están y tres lo están solo en parte:

Las veinte historias¶

El enunciado tal como fue entregado. Se conserva la redacción original, incluida la marca de las que el propio anexo declaró fuera del MVP.

US-001 · Gestión de usuarios (alta, baja, modificación, asignación de rol)¶

Módulo: Gestión de Usuarios y Seguridad

Objetivo. Permitir la administración completa de los usuarios del sistema dentro de una empresa (tenant), garantizando el aislamiento y los permisos correctos.

Contexto. Cada empresa cliente (tenant) debe gestionar sus propios usuarios. M.R.G. también necesita crear cuentas para soporte, supervisión o pruebas.

Historia. Cuando un administrador accede al módulo de usuarios, entonces debe poder crear, editar, eliminar y asignar roles a los usuarios, de forma que mantenga el control de acceso y seguridad de su entorno.

Requerimientos funcionales:

• Crear, editar, eliminar usuarios.
• Asociar usuarios a un tenant específico.
• Asignar roles a usuarios.
• Activar/desactivar cuentas.

Requerimientos no funcionales:

• Todas las operaciones deben ser auditadas.
• El sistema debe evitar que un usuario vea o modifique datos fuera de su tenant.

Fuera de alcance:

• Autoregistro por parte de usuarios externos.

Criterio de aceptación. Dado que el administrador ingresa al módulo de usuarios, cuando crea un usuario asignado a su empresa y rol, entonces este usuario debe poder iniciar sesión y acceder solo a los recursos permitidos.

US-002 · Administración de roles y permisos¶

Módulo: Gestión de Usuarios y Seguridad

Objetivo. Definir y gestionar los roles disponibles en el sistema y sus permisos asociados.

Contexto. Las empresas pueden tener distintos niveles de usuarios (operadores, supervisores, analistas, administradores) con distintas capacidades.

Historia. Cuando un administrador accede al módulo de roles, entonces debe poder crear o modificar roles personalizados, asignando permisos específicos para cada módulo del sistema.

Requerimientos funcionales:

• Crear, editar y eliminar roles.
• Asignar permisos específicos por módulo/acción.
• Asignar múltiples usuarios a un mismo rol.

Requerimientos no funcionales:

• Validar que siempre haya al menos un rol administrador en cada tenant.

Fuera de alcance:

• Roles con lógica condicional compleja.

Criterio de aceptación. Dado que un administrador define un nuevo rol, cuando lo asigna a un usuario, entonces este debe tener acceso solo a las funcionalidades habilitadas por ese rol.

US-003 · Gestión de empresas (tenants)¶

Módulo: Gestión de Usuarios y Seguridad

Objetivo. Permitir a M.R.G. crear y administrar las empresas (tenants) que utilizarán la plataforma.

Contexto. Cada cliente de M.R.G. debe operar en un entorno completamente aislado: datos, usuarios y configuraciones independientes.

Historia. Cuando un usuario con permisos de M.R.G. accede al módulo de empresas, entonces debe poder registrar una nueva empresa con sus datos iniciales, y gestionar su configuración y estado.

Requerimientos funcionales:

• Crear, editar, suspender o eliminar empresas.
• Asociar usuarios y máquinas a una empresa.
• Ver métricas globales por tenant.

Requerimientos no funcionales:

• Garantizar el aislamiento completo entre tenants (multi-tenant seguro).

Fuera de alcance:

• Autogestión por parte del cliente sin intervención de M.R.G.

Criterio de aceptación. Dado que M.R.G. crea una nueva empresa, cuando se configura y activa, entonces puede comenzar a registrar usuarios, máquinas y operar con su propio entorno.

US-004 · Visualización de datos¶

Módulo: Dashboard y Paneles Visuales

Objetivo. Permitir a los usuarios monitorear el estado operativo de las máquinas embolsadoras.

Contexto. Los operadores y supervisores necesitan acceso a información actualizada para tomar decisiones rápidas y detectar fallas.

Historia. Cuando el usuario accede al dashboard, entonces debe visualizar widgets con información de sus máquinas, de forma que pueda supervisar el estado y responder ante eventos críticos.

Requerimientos funcionales:

• Mostrar datos actualizados por máquina.
• Permitir múltiples vistas segmentadas por usuario.
• Integrar datos de sensores y alertas en gráficos o indicadores.

Requerimientos no funcionales:

• La actualización debe tener una latencia menor a 2 segundos.
• Compatible con dispositivos móviles.

Fuera de alcance:

• Personalización con scripts externos.

Criterio de aceptación. Dado que un operador accede a su dashboard, cuando su máquina reporta datos nuevos, entonces los indicadores deben reflejar los cambios sin necesidad de recargar la página.

US-005 · Configuración de paneles y widgets¶

Módulo: Dashboard y Paneles Visuales

Objetivo. Permitir que cada usuario personalice su vista organizando widgets relevantes según su preferencia.

Contexto. Distintos perfiles de usuario tienen necesidades visuales diferentes según su rol (técnico, supervisor, administrador).

Historia. Cuando un usuario edita su dashboard, entonces debe poder agregar, quitar, redimensionar o mover widgets dentro de sus paneles, de forma que tenga una interfaz adaptada a su trabajo.

Requerimientos funcionales:

• Agregar y eliminar widgets de una galería.
• Organizar widgets dentro de paneles.
• Guardar configuración personal por usuario.

Requerimientos no funcionales:

• Carga inmediata sin refrescar la vista.

Fuera de alcance:

• Edición colaborativa de vistas entre usuarios.

Criterio de aceptación. Dado que un usuario configura su dashboard, cuando guarda los cambios, entonces la vista debe mantenerse persistente al volver a ingresar.

US-006 · Plantillas predefinidas de dashboard¶

Módulo: Dashboard y Paneles Visuales

Objetivo. Proveer configuraciones prediseñadas de vistas para diferentes tipos de usuarios o industrias.

Contexto. Los nuevos usuarios pueden no saber cómo configurar su dashboard desde cero.

Historia. Cuando un usuario accede por primera vez al dashboard, entonces debe poder seleccionar una plantilla con vistas y paneles preconfigurados, de forma que empiece a trabajar rápidamente.

Requerimientos funcionales:

• Mostrar lista de plantillas disponibles.
• Permitir aplicar una plantilla con un solo clic.
• Permitir editar la plantilla luego de aplicada.

Requerimientos no funcionales:

• Las plantillas deben estar disponibles en menos de 2 segundos.

Fuera de alcance:

• Plantillas inteligentes que se autoadapten según uso.

Criterio de aceptación. Dado que un nuevo usuario aplica una plantilla, cuando accede al dashboard, entonces debe ver los paneles y widgets configurados según esa plantilla.

US-007 · Generación de reportes personalizados¶

Módulo: Reportes y Análisis

Objetivo. Permitir a los usuarios configurar y generar reportes de datos históricos, métricas y KPIs según sus necesidades operativas o de control.

Contexto. Los técnicos y supervisores necesitan extraer información útil en formatos reutilizables, ya sea para informes internos, regulatorios o de mejora continua.

Historia. Cuando un usuario accede al módulo de reportes, entonces debe poder definir parámetros de filtrado (fechas, máquinas, lotes, variables), seleccionar un formato y generar un archivo descargable con esa información.

Requerimientos funcionales:

• Permitir filtrar por máquina, lote, período de tiempo y variables.
• Generar reportes en PDF, CSV y JSON.
• Incluir estadísticas, gráficas y totales.

Requerimientos no funcionales:

• El reporte debe generarse en menos de 10 segundos.
• Debe estar disponible desde navegadores modernos y dispositivos móviles.

Fuera de alcance:

• Visualización en tiempo real dentro del reporte.

Criterio de aceptación. Dado que un usuario configura un conjunto de filtros para un reporte, cuando presiona generar, entonces debe descargar un archivo con la información solicitada y en el formato indicado.

US-008 · Reportes automáticos por mail¶

Módulo: Reportes y Análisis

Objetivo. Permitir a los usuarios recibir automáticamente resúmenes e informes por correo electrónico con base en una configuración previa.

Contexto. Muchos clientes desean recibir reportes periódicos sin necesidad de ingresar al sistema.

Historia. Cuando un usuario configura una tarea de reporte automático, entonces el sistema debe generarlo en el momento programado y enviarlo por correo al destinatario especificado.

Requerimientos funcionales:

• Configurar frecuencia, rango de datos, destinatario y formato.
• Generar y enviar reportes automáticamente.
• Permitir editar y eliminar tareas de reporte automático.

Requerimientos no funcionales:

• El envío debe completarse en menos de 1 minuto desde el disparador.
• El contenido debe ser compatible con clientes de correo estándar.

Fuera de alcance:

• Confirmación de lectura del reporte.

Criterio de aceptación. Dado que el usuario configura una tarea de envío semanal, cuando llega la fecha establecida, entonces el sistema debe enviar el archivo adjunto con el reporte sin intervención adicional.

US-009 · Comparación de indicadores entre máquinas¶

Módulo: Reportes y Análisis · Declarada fuera de MVP en el anexo

Objetivo. Proveer herramientas visuales para comparar el rendimiento de distintas máquinas o sitios de operación.

Contexto. M.R.G. y sus clientes necesitan detectar patrones, identificar máquinas menos eficientes y encontrar oportunidades de mejora.

Historia. Cuando el usuario accede a la funcionalidad de comparación, entonces debe poder seleccionar múltiples máquinas, fechas o turnos y ver una visualización comparativa de KPIs.

Requerimientos funcionales:

• Seleccionar múltiples máquinas o sitios.
• Calcular y mostrar KPIs comparativos en una misma vista.
• Exportar la comparación como imagen o archivo.

Requerimientos no funcionales:

• Carga de resultados en menos de 5 segundos.

Fuera de alcance:

• Comparaciones predictivas o basadas en IA.

Criterio de aceptación. Dado que un supervisor selecciona dos máquinas y un período, cuando ejecuta la comparación, entonces el sistema debe mostrar la evolución de KPIs en paralelo.

US-010 · Visualización de alertas en tiempo real¶

Módulo: Centro de Notificaciones

Objetivo. Centralizar las notificaciones generadas por eventos críticos en las máquinas o el sistema.

Contexto. Los operadores y supervisores deben responder rápidamente ante condiciones anómalas.

Historia. Cuando un usuario accede al centro de notificaciones, entonces debe visualizar las alertas recientes organizadas por prioridad y estado, de forma que pueda atenderlas según urgencia.

Requerimientos funcionales:

• Mostrar listado de alertas activas, en tratamiento y cerradas.
• Priorizar alertas por tipo, severidad y fecha.
• Permitir marcar como reconocida o resuelta.

Requerimientos no funcionales:

• Las alertas deben aparecer con un retardo menor a 2 segundos desde su origen.

Fuera de alcance:

• Notificaciones multilingües.

Criterio de aceptación. Dado que ocurre una alerta crítica, cuando un usuario accede al centro de notificaciones, entonces debe verla destacada con posibilidad de tratarla o cerrarla.

US-011 · Configuración de reglas de notificación¶

Módulo: Centro de Notificaciones

Objetivo. Permitir que los usuarios configuren condiciones bajo las cuales se generan alertas.

Contexto. No todas las condiciones operativas requieren alerta; algunas deben ajustarse por máquina o cliente.

Historia. Cuando un usuario accede a las reglas de alerta, entonces debe poder definir valores umbral y eventos que generen notificaciones, de forma que se adapten al proceso de su empresa.

Requerimientos funcionales:

• Crear, editar y eliminar reglas de alerta.
• Definir condiciones como valores máximos/mínimos, frecuencia o ausencia de datos.
• Asociar reglas a máquinas o grupos de máquinas.

Requerimientos no funcionales:

• Validar que las reglas no se superpongan o contradigan.

Fuera de alcance:

• Motor de inferencia o IA para ajuste automático de reglas.

Criterio de aceptación. Dado que un usuario crea una regla de temperatura máxima, cuando se supera el valor configurado, entonces el sistema debe generar la alerta asociada y mostrarla en el centro de notificaciones.

US-012 · Envío de notificaciones push¶

Módulo: Centro de Notificaciones · Declarada fuera de MVP en el anexo

Objetivo. Notificar a los usuarios móviles sobre eventos críticos mediante push notifications.

Contexto. Muchos técnicos no están frente a una computadora todo el tiempo.

Historia. Cuando se genera una alerta crítica, entonces el sistema debe enviar una notificación push al usuario responsable, de forma que pueda actuar de inmediato desde su dispositivo.

Requerimientos funcionales:

• Integración con servicios como FCM (Firebase Cloud Messaging).
• Configuración individual para recibir/notificar distintos tipos de alertas.

Requerimientos no funcionales:

• Latencia máxima de entrega de 5 segundos.

Fuera de alcance:

• Geofencing o notificaciones basadas en ubicación.

Criterio de aceptación. Dado que una alerta es clasificada como crítica y un usuario tiene habilitadas las notificaciones, cuando ocurre, entonces debe recibirla como push en su dispositivo móvil.

US-013 · Configuración de herramientas externas de integración¶

Módulo: Configuración avanzada (Settings)

Objetivo. Permitir a los administradores configurar los parámetros de integración de herramientas externas asociadas al sistema, como servicios de envío de correo, visualización de datos o mensajería.

Contexto. La plataforma puede conectarse con servicios como SMTP (correo), Twilio (mensajería), Firebase (notificaciones push), Kibana o Grafana (visualización de métricas y logs).

Historia. Cuando un administrador accede al apartado de configuración de integraciones, entonces debe poder cargar las credenciales y parámetros necesarios para cada servicio, de forma que las funcionalidades como alertas, dashboards o trazabilidad funcionen correctamente.

Requerimientos funcionales:

• Configurar SMTP para el envío de correos.
• Cargar claves de acceso o tokens para Twilio, Firebase, Grafana, Kibana, etc.
• Testear conectividad desde la interfaz.
• Habilitar o deshabilitar servicios.

Requerimientos no funcionales:

• Los tokens deben almacenarse cifrados.
• Las configuraciones deben ser auditables por M.R.G.

Fuera de alcance:

• Interfaz visual para edición avanzada de scripts externos.

Criterio de aceptación. Dado que un administrador configura las credenciales SMTP y Firebase, cuando guarda y prueba la conexión, entonces el sistema debe confirmar que puede enviar mails y notificaciones correctamente.

US-014 · Configuración de webhooks¶

Módulo: Configuración avanzada (Settings) · Declarada fuera de MVP en el anexo

Objetivo. Permitir el envío automático de eventos a servicios externos mediante llamadas HTTP configurables.

Contexto. Muchas empresas necesitan recibir notificaciones automáticas o sincronizar eventos con otras plataformas.

Historia. Cuando un administrador configura un webhook, entonces el sistema debe enviar una notificación HTTP con datos específicos a la URL definida cuando ocurre un evento relevante.

Requerimientos funcionales:

• Crear, editar y eliminar webhooks.
• Seleccionar eventos (creación de alerta, nuevo lote, fin de producción, etc.).
• Configurar método HTTP, cabeceras y payload.

Requerimientos no funcionales:

• Garantizar reintento ante fallas temporales.

Fuera de alcance:

• Validación automática de respuesta del webhook.

Criterio de aceptación. Dado que un webhook fue configurado para el evento “fin de lote”, cuando ocurre dicho evento, entonces se debe enviar una solicitud HTTP a la URL registrada con los datos del lote.

US-015 · Registro centralizado de eventos del sistema¶

Módulo: Centro de Logs

Objetivo. Proveer un registro completo de actividades del sistema para análisis, auditoría y debugging.

Contexto. Los administradores y técnicos de M.R.G. deben poder revisar eventos del sistema para detectar fallas, validar acciones de usuarios o reconstruir incidentes.

Historia. Cuando un administrador accede al centro de logs, entonces debe poder consultar y filtrar eventos registrados por fecha, tipo, módulo, usuario o severidad, de forma que pueda identificar patrones o problemas.

Requerimientos funcionales:

• Registrar eventos como logins, cambios de configuración, errores, envíos de notificaciones, etc.
• Permitir filtrado por múltiples criterios.
• Exportar registros como archivo.

Requerimientos no funcionales:

• Los logs deben almacenarse al menos 6 meses.
• El sistema debe soportar grandes volúmenes sin degradar el rendimiento.

Fuera de alcance:

• Correlación automática entre eventos.

Criterio de aceptación. Dado que un administrador accede al centro de logs, cuando aplica filtros de búsqueda, entonces debe obtener una lista detallada de los eventos correspondientes y poder exportarlos.

US-016 · Configuración de conectividad del dispositivo edge¶

Módulo: Edge Management

Objetivo. Permitir que un dispositivo físico (ej. Raspberry Pi) pueda conectarse de forma segura al sistema en la nube.

Contexto. Las máquinas embolsadoras operan con una Raspberry Pi que actúa como gateway. Esta debe ser configurada adecuadamente para integrarse con la nube y funcionar dentro de distintas redes.

Historia. Cuando un técnico prepara un nuevo dispositivo edge, entonces debe poder registrar su identidad y definir parámetros de conexión, de forma que el equipo quede autorizado y pueda comenzar a transmitir datos.

Requerimientos funcionales:

• Registrar dispositivos edge mediante token único.
• Establecer configuración de red (IP, proxy, VPN, puerto, protocolo).
• Asociar el dispositivo a una empresa y máquina específica.

Requerimientos no funcionales:

• Conexiones cifradas entre dispositivo y backend.
• Alta disponibilidad en el canal de sincronización.

Fuera de alcance:

• Instalación física y cableado de la Raspberry Pi.

Criterio de aceptación. Dado que se registra un nuevo edge con sus parámetros de red, cuando el dispositivo se conecta, entonces debe comenzar a enviar datos de forma segura al sistema.

US-017 · Monitoreo del estado del dispositivo¶

Módulo: Edge Management

Objetivo. Permitir visualizar el estado operativo, conectividad y últimas actividades de cada dispositivo conectado.

Contexto. Es fundamental poder detectar cuándo una Raspberry Pi pierde conectividad, no transmite datos o presenta fallas.

Historia. Cuando un usuario con permisos accede a la vista de dispositivos edge, entonces debe poder visualizar su estado (activo, inactivo, desconectado), últimos eventos, versión del software y tiempo desde la última sincronización.

Requerimientos funcionales:

• Listar todos los dispositivos edge registrados.
• Mostrar información de salud, conexión y últimas operaciones.

Requerimientos no funcionales:

• Actualización en tiempo casi real del estado de cada dispositivo.

Fuera de alcance:

• Control remoto o actualización OTA desde la nube.

Criterio de aceptación. Dado que una Raspberry Pi dejó de enviar datos, cuando un administrador consulta su estado, entonces debe verla como desconectada con indicación de la última actividad registrada.

US-018 · Consumo de API por parte de clientes externos¶

Módulo: API Usage · Declarada fuera de MVP en el anexo

Objetivo. Permitir que los clientes accedan programáticamente a los datos y funcionalidades del sistema dentro del alcance de su tenant.

Contexto. Algunos clientes desean integrar sus sistemas ERP, BI o tableros con la información recolectada por el sistema.

Historia. Cuando un cliente obtiene un token de acceso, entonces debe poder usar la API para consultar información sobre lotes, sensores, máquinas o reportes asociados a su tenant, sin acceder a datos ajenos.

Requerimientos funcionales:

• La API debe ofrecer endpoints seguros y documentados.
• Los tokens deben estar asociados al tenant y su scope.
• El cliente puede consultar y exportar datos.

Requerimientos no funcionales:

• El sistema debe tener límites de uso (rate limiting).
• Las respuestas deben estar en formato estándar (JSON).

Fuera de alcance:

• API de escritura para crear o modificar datos internos del sistema.

Criterio de aceptación. Dado que un cliente hace una consulta con token válido, cuando accede a un endpoint de lectura, entonces debe recibir solo datos que pertenecen a su tenant.

US-019 · Visualización y monitoreo de uso de la API¶

Módulo: API Usage

Objetivo. Permitir que administradores de M.R.G. visualicen el consumo y comportamiento de los tokens y llamadas a la API.

Contexto. Es necesario controlar el uso indebido, detectar problemas de seguridad o abusos en el acceso programático.

Historia. Cuando un administrador accede al panel de uso de API, entonces debe poder ver estadísticas por token, frecuencia de uso, errores y distribución por endpoints, de forma que pueda tomar medidas de control.

Requerimientos funcionales:

• Registrar todas las llamadas a la API con su origen.
• Visualizar consumo por token o cliente.
• Exportar el log de uso.

Requerimientos no funcionales:

• El registro debe persistir al menos 90 días.

Fuera de alcance:

• Gráficos personalizados o alertas automáticas sobre uso anómalo.

Criterio de aceptación. Dado que un token realiza muchas llamadas en poco tiempo, cuando el administrador revisa el panel de monitoreo, entonces debe poder identificarlo y tomar acción.

US-020 · Autenticación de doble factor para usuarios¶

Módulo: Seguridad (2FA)

Objetivo. Aumentar la seguridad del acceso al sistema mediante un segundo paso de validación.

Contexto. Algunas cuentas tienen acceso a información crítica o funciones administrativas que requieren medidas adicionales de protección.

Historia. Cuando un usuario activa la autenticación de doble factor desde su perfil, entonces al iniciar sesión debe ingresar además de su contraseña un código de verificación temporal, de forma que se reduzcan los riesgos de acceso indebido.

Requerimientos funcionales:

• Permitir activar/desactivar el segundo factor por usuario.
• Enviar el código por correo o utilizar una app como Google Authenticator.
• Validar el código en el proceso de login.

Requerimientos no funcionales:

• El código debe tener una validez máxima de 5 minutos.
• La implementación debe ser compatible con TOTP.

Fuera de alcance:

• Métodos biométricos o autenticación por SMS.

Criterio de aceptación. Dado que un usuario tiene 2FA activado, cuando inicia sesión, entonces debe ingresar correctamente el código temporal para acceder al sistema.

Lo que esta página todavía no puede decir¶

• Prioridad y estimación de cada historia. El anexo no las registra; viven en el backlog, que las ordena por sprint pero no por valor.
• Quién las escribió y cuándo. El documento no tiene autoría por historia, sólo la fecha del informe que las contiene.

Relacionado¶

• Casos de uso — los nueve casos que agrupan estas historias
• Releases — el otro eslabón de la trazabilidad, cerrado el mismo día
• Matriz de evidencias — la cadena completa
• Bitácora de alcance — qué se comprometió y no se construyó