E1 — Especificación de Requerimientos del Sistema (SRS)¶
Estándar: IEEE 29148 · Competencia CE0211
Proyecto: LOGYX — Sistema Operativo Logístico Colaborativo para PYMEs
Equipo: Jorge Gutiérrez Miranda · Fabrizio Sanchez Saravia · Alex Coila Jarita
Institución: Universidad Peruana Unión · Ingeniería de Sistemas
Versión: 1.0 · Junio 2026
Las pequeñas y medianas empresas (PYMEs) en el Perú gestionan su logística de carga mediante canales informales: llamadas telefónicas, grupos de WhatsApp, hojas de cálculo y acuerdos verbales con transportistas. No existe un mecanismo estandarizado, trazable ni seguro para contratar transporte de carga en corredores interprovinciales.
En el corredor Lima–Sierra Sur (Lima–Arequipa–Juliaca–Puno), uno de los más activos del país, esta problemática es especialmente crítica: las PYMEs no conocen el precio justo de mercado antes de negociar, no tienen forma de verificar la confiabilidad de un transportista antes de entregarle mercancía, y los transportistas regresan con sus vehículos vacíos después de cada entrega, elevando el costo logístico para todos.
LOGYX opera en el mercado logístico B2B del Perú, con foco inicial en el corredor Lima–Sierra Sur. El sistema digital reemplaza la coordinación informal (WhatsApp, llamadas) con un marketplace estructurado que conecta PYMEs demandantes de transporte con empresas transportistas, bajo supervisión de operadores logísticos.
Desarrollar una plataforma digital B2B que conecte PYMEs y empresas transportistas mediante un sistema de subastas inversas, negociación bidireccional, planificación inteligente de carga y reputación verificable, reduciendo los costos logísticos y la informalidad en el corredor Lima–Sierra Sur del Perú.
La PYME debe poder crear una solicitud de carga especificando: origen, destino, peso (kg), tipo de carga, fecha requerida y descripción
PYME
RF10
Al crear la solicitud, el sistema debe calcular y mostrar un precio de referencia de mercado basado en distancia real (ORS), peso, tipo de carga y tarifas históricas del corredor
Sistema
RF11
La PYME debe poder ver el listado de sus solicitudes activas con estado actual y contador de ofertas recibidas
PYME
RF12
La PYME debe poder ver el detalle de una solicitud, incluyendo todas las ofertas recibidas con precio, datos del transportista y su score de reputación
PYME
RF13
La PYME debe poder aceptar una oferta, lo que genera automáticamente un contrato de envío con código de tracking
Al publicarse una solicitud de carga, el sistema debe abrir automáticamente una subasta con tiempo límite configurable (default: 20 minutos) o hasta recibir N ofertas (default: 5)
Sistema
RF16
El transportista debe ver en el marketplace las solicitudes de carga activas filtradas y rankeadas según compatibilidad con su perfil (zona, capacidad, historial de ruta)
Transportista
RF17
El transportista debe poder enviar una oferta a una subasta activa indicando: precio ofertado, vehículo asignado y notas adicionales
Transportista
RF18
El sistema debe cerrar automáticamente la subasta al cumplirse el tiempo o el número máximo de ofertas, notificando a la PYME
Sistema
RF19
El sistema no debe permitir que un transportista oferte un precio inferior al precio mínimo viable calculado por el motor de precios (price floor)
Sistema
RF20
El sistema no debe permitir que un transportista oferte si su capacidad disponible real es insuficiente para la carga solicitada
El transportista debe poder publicar un viaje disponible especificando: ruta (origen-destino-paradas), fecha de salida, capacidad disponible (kg/m³) y precio por kg
Transportista
RF22
La PYME debe poder explorar los viajes disponibles publicados y reservar espacio en uno de ellos indicando el peso y tipo de su carga
PYME
RF23
El sistema debe validar que el peso reservado no exceda la capacidad disponible del viaje en el momento de la reserva
Sistema
RF24
El transportista debe poder ver todas las cargas reservadas en su viaje con detalle de cada una
El sistema debe proveer un hilo de chat por cada par (solicitud + transportista), visible para ambas partes
PYME / Transportista
RF26
El transportista debe poder enviar una contra-oferta desde el chat indicando el precio propuesto
Transportista
RF27
La PYME debe poder enviar una contra-oferta al transportista indicando el precio que está dispuesta a pagar
PYME
RF28
Cualquiera de las dos partes debe poder aceptar la contra-oferta vigente, actualizando el precio de la oferta automáticamente
PYME / Transportista
RF29
El sistema debe detectar y bloquear mensajes que contengan información de contacto (teléfonos, emails, handles de redes sociales) en el chat
Sistema
Módulo SMART LOAD PLANNER — Planificación de Carga¶
ID
Descripción
Actor
RF30
El sistema debe detectar automáticamente solicitudes de carga compatibles entre sí por criterios de: origen similar (radio 50 km), destino similar (radio 80 km), fechas compatibles (±24h) y peso combinado dentro de la capacidad de un vehículo disponible
Sistema
RF31
El sistema debe mostrar al transportista las combinaciones de carga compatibles como sugerencias de Smart Load Plan, indicando ingreso combinado estimado, porcentaje de ocupación y ruta optimizada
Transportista
RF32
El transportista debe poder aceptar un Smart Load Plan, lo que genera automáticamente un envío multi-parada con las cargas incluidas
Transportista
RF33
Al ser incluidas en un Smart Load Plan, las PYMEs involucradas deben recibir una notificación indicando que su carga fue agrupada con otras
Al completarse una entrega, la PYME debe poder calificar al transportista en dos dimensiones: puntualidad (1–5) y calidad del servicio (1–5), con comentario opcional
PYME
RF41
Al completarse una entrega, el transportista debe poder calificar a la PYME en: exactitud de información declarada (peso/tipo de carga) y comportamiento como cliente
Transportista
RF42
El sistema debe calcular automáticamente un Trust Score compuesto para transportistas con 5 métricas: tasa de entregas exitosas (25%), puntualidad (25%), tasa de cancelación (15%), índice de incidentes (15%) y rating promedio (20%)
Sistema
RF43
El sistema debe calcular automáticamente un Trust Score para PYMEs con métricas: cumplimiento de pago (30%), exactitud de carga declarada (25%), tasa de cancelación (20%), tiempo de respuesta (15%) y rating (10%)
Sistema
RF44
El perfil de reputación de cada organización debe ser visible públicamente en el marketplace, mostrando el score compuesto, métricas individuales y badges obtenidos
Todos
RF45
El sistema solo debe habilitar el formulario de calificación si existe evidencia verificada de entrega (al menos una foto + confirmación de estado)
El sistema debe enviar notificaciones in-app ante los siguientes eventos: nueva oferta recibida, oferta aceptada/rechazada, cambio de estado del envío, nueva calificación, nuevo mensaje en chat, incidencia reportada/resuelta
Sistema
RF50
El sistema debe enviar notificaciones por email para eventos críticos: oferta aceptada, envío creado, entrega confirmada
Sistema
RF51
La PYME debe poder ver un centro de notificaciones con historial y marcar como leídas
Al confirmarse la entrega final de un transportista, el sistema debe detectar solicitudes de carga abiertas con origen geográficamente cercano (radio 30 km) al destino recién completado
Sistema
RF62
El sistema debe notificar al transportista las oportunidades de carga de retorno detectadas, rankeadas por compatibilidad y distancia al punto de recojo
Transportista
RF63
El transportista debe poder hacer una oferta desde la pantalla de retornos sin necesidad de ir al marketplace
El transportista debe poder registrar sus vehículos con: placa, tipo, capacidad máxima (kg/m³), tipo de carga que acepta y estado (disponible/en ruta/mantenimiento)
Transportista
RF65
El transportista debe poder registrar conductores vinculados a su empresa con: nombre, DNI y número de licencia
Transportista
RF66
El transportista debe poder asignar un conductor y vehículo específico a un envío aceptado
Transportista
RF67
El sistema debe impedir que un transportista oferte en cargas que superen la capacidad disponible real de sus vehículos activos
El sistema debe responder en menos de 2 segundos para el 95% de las solicitudes bajo carga normal (hasta 200 usuarios concurrentes)
RNF02
Rendimiento
Las consultas al marketplace deben retornar resultados en menos de 1.5 segundos incluyendo el cálculo del score de matching
RNF03
Disponibilidad
El sistema debe tener una disponibilidad mínima del 99% mensual
RNF04
Seguridad
Todas las comunicaciones deben usar HTTPS/TLS 1.3
RNF05
Seguridad
La autenticación debe implementarse con JWT (access token 1h + refresh token 7 días)
RNF06
Seguridad
El control de acceso debe implementarse con RBAC a nivel de endpoint y a nivel de datos
RNF07
Seguridad
Las contraseñas deben almacenarse con hash bcrypt (factor de costo mínimo 12)
RNF08
Usabilidad
La app móvil debe ser operable en dispositivos Android 10+ con pantallas desde 5"
RNF09
Usabilidad
El tiempo máximo para completar la acción "publicar solicitud de carga" no debe superar 3 minutos para un usuario nuevo
RNF10
Escalabilidad
La arquitectura debe soportar despliegue en contenedores Docker y permitir escalado horizontal del backend
RNF11
Mantenibilidad
El backend debe seguir arquitectura de monolito modular con límites de módulo claros, permitiendo extracción futura a microservicios
RNF12
Compatibilidad web
La aplicación web debe funcionar correctamente en Chrome 120+, Firefox 120+ y Edge 120+
RNF13
Compatibilidad móvil
La app mobile debe funcionar en Android 10+ e iOS 16+
RNF14
Integridad de datos
La base de datos debe implementar integridad referencial completa con claves foráneas y constraints
RNF15
Trazabilidad
Todas las acciones de negocio críticas (aceptar oferta, cambiar estado, resolver incidencia) deben quedar registradas con timestamp y usuario responsable
RNF16
Disponibilidad offline
La app del conductor debe mantener en caché la ruta asignada y permitir actualización de estados sin conexión, sincronizando al recuperar conectividad
RNF17
Cumplimiento normativo
El sistema debe exponer una política de privacidad pública y visible en app y web, conforme al Art. 18 de la Ley N° 29733, antes del primer registro de usuario real
RNF18
Cumplimiento normativo
El flujo de onboarding debe incluir un paso de consentimiento informado y explícito para el tratamiento de datos personales, conforme al Art. 13 de la Ley N° 29733
RNF19
Cumplimiento normativo
El sistema debe mantener un registro interno de actividades de tratamiento de datos y un procedimiento operativo de notificación de brechas a la ANPD en un plazo máximo de 72 horas, conforme al Art. 39 del Reglamento de la Ley N° 29733
RNF20
Cumplimiento normativo (pagos)
El sistema no debe almacenar datos de tarjeta en ningún momento; el procesamiento de pagos se delega íntegramente a una pasarela certificada PCI-DSS (tokenización delegada)
Origen: RNF17–RNF20 derivan del análisis de Gobierno de TI bajo COBIT 2019 (Gestión TI, Entregable 1, sección 1.7) y de la sección de Cumplimiento Normativo del Plan de Gestión del Proyecto (Gestión TI, Entregable 3, sección 3.7).
Ver documento E1_Arquitectura.md para la descripción completa con diagramas C4.
Resumen: Monolito modular con Quarkus (backend), Angular (web), Flutter (mobile × 3 apps) y PostgreSQL. Cada módulo tiene límites de dominio claros para facilitar la migración futura a microservicios.