Requisitos No Funcionales (RNF)

Este documento consolida los requisitos no funcionales transversales de Finnova. Los requisitos funcionales (RF01–RF70) ya incluyen criterios no funcionales locales (rendimiento por endpoint, cifrado, TLS); aquí se definen los atributos de calidad a nivel sistema que aplican a todos ellos y que antes estaban dispersos o ausentes.

Convención de prioridad: MVP (15-jun-2026) vs Post-MVP. Donde un RNF no es exigible para el MVP, se documenta el riesgo aceptado y el plan de evolución.

---

RNF-01 — Disponibilidad y continuidad

Aspecto	Definición
Objetivo de disponibilidad (MVP)	≥ 99.0 % mensual (best-effort). El MVP corre sobre una sola instancia de aplicación (ver riesgo abajo).
Objetivo de disponibilidad (Post-MVP)	≥ 99.9 % mensual con redundancia multi-instancia / multi-AZ.
RPO (Recovery Point Objective)	≤ 24 h en MVP (respaldos automatizados diarios de PostgreSQL); objetivo ≤ 1 h post-MVP con PITR/replicación.
RTO (Recovery Time Objective)	≤ 4 h en MVP (restauración manual desde respaldo + réplica de lectura); objetivo ≤ 30 min post-MVP.
Respaldos	Respaldos automatizados y réplica de solo lectura ya contemplados en el Manual de Arquitectura. Se debe probar la restauración periódicamente (un respaldo no verificado no cuenta).

⚠️ Riesgo aceptado para el MVP — punto único de fallo (SPOF). La capa de aplicación (un solo Application Server con un Nginx/Docker que aloja todos los módulos) es un punto único de fallo: una caída de esa instancia tira todo el servicio. Decisión: se acepta para el MVP del 15-jun-2026 para no comprometer la fecha; se prioriza eliminarlo en el primer incremento post-MVP (ver RNF-03). Este riesgo queda explícitamente aceptado por negocio.

RNF-02 — Rendimiento y capacidad

• Los objetivos de latencia por endpoint definidos en cada RF (p. ej. registro < 1.5 s, dashboard < 2 s, inicio de video < 3 s) se interpretan como p95 bajo carga nominal, no como promedio en vacío.
• Carga nominal de referencia (MVP): a definir con negocio (ver preguntas abiertas), por defecto se asume [X] usuarios activos concurrentes y [Y] req/s pico. Sin este número, los objetivos de latencia no son verificables: deben fijarse antes de las pruebas de carga.
• Presupuesto de cómputo de Argon2id: el hashing de contraseñas (memoryCost: 64 MB, timeCost: 3) es intencionalmente costoso. En una sola instancia, N registros/logins concurrentes consumen N × 64 MB. Se debe (a) limitar la concurrencia de hashing, y (b) proteger los endpoints de auth con rate limiting (RNF-04) para evitar agotamiento de memoria / DoS.
• Las operaciones de lectura agregada (dashboard, reportes) deben usar la réplica de lectura cuando aplique.
• Las cargas pesadas (OCR de tickets RF20, análisis de facturas RF64, generación de recomendaciones IA RF28, declaración anual RF63) deben ser asíncronas y no bloquear la UI.

RNF-03 — Escalabilidad

• Roadmap post-MVP: desacoplar la capa de aplicación a múltiples instancias detrás del Load Balancer (stateless + sesiones por token ya lo permiten), con auto-scaling y despliegue multi-AZ.
• Los workers asíncronos (IA, OCR, contabilidad) deben poder escalar de forma independiente del API.
• La base de datos debe contemplar particionamiento/índices por user_id para el crecimiento de movimientos financieros.

RNF-04 — Seguridad transversal

Complementa las estrategias detalladas en Cifrado y Almacenamiento, Control de Sesiones y Compliance y Privacidad.

• RNF-04.1 — Rate limiting / anti-fuerza bruta (MVP). Todos los endpoints de autenticación y de operaciones sensibles (login RF02, recuperación RF11, registro RF01, cambio de correo/contraseña, pagos, canje de recompensas) deben aplicar limitación de tasa por IP y por cuenta, con bloqueo temporal progresivo tras intentos fallidos y, opcionalmente, CAPTCHA. Esto era un hueco en los RF de auth.
• RNF-04.2 — Validación en servidor. Toda entrada se valida en backend con DTO y consultas parametrizadas; la validación de cliente es solo UX (ya aplicado en los RF).
• RNF-04.3 — Gestión de secretos. Secretos (tokens bancarios, claves de Stripe, claves de cifrado por usuario, credenciales de IA) viven en AWS Secrets Manager con rotación; nunca en código, logs ni DB en claro.
• RNF-04.4 — Transporte. TLS 1.2+ en todas las comunicaciones (cliente↔API, API↔terceros).
• RNF-04.5 — Cabeceras y superficie. Cabeceras de seguridad, CORS restrictivo y tamaño máximo de payload por endpoint.

RNF-05 — Manejo monetario

Era un hueco crítico: los montos solo se especificaban como "numérico, máx. 2 decimales".

• RNF-05.1 — Tipo de dato. Todo monto se almacena y opera como decimal de precisión fija (p. ej. NUMERIC(18,2) en PostgreSQL); nunca punto flotante binario, para evitar errores de redondeo.
• RNF-05.2 — Moneda explícita. Toda cantidad monetaria lleva un código de moneda ISO 4217 (currency). En el MVP el valor por defecto es MXN; el modelo se diseña multi-moneda-ready para la expansión a LatAm (ver RNF-14).
• RNF-05.3 — Redondeo. Reglas de redondeo definidas y consistentes (medio-arriba) por moneda y por su número de decimales.
• RNF-05.4 — Agregaciones. Las sumas en el dashboard/reportes solo agregan montos de la misma moneda; la conversión FX queda fuera del MVP.

RNF-06 — Auditoría y trazabilidad

• RNF-06.1 — Bitácora inmutable. Las operaciones financieras y de seguridad (registro, login, cambio de credenciales, conexión bancaria, pagos, inversiones, canjes, generación de declaración, cambios de consentimiento, eliminación de cuenta) se registran en una bitácora de auditoría append-only.
• RNF-06.2 — Contenido. Cada evento registra actor (user_id), acción, timestamp, resultado y metadatos no sensibles. Nunca se registran contraseñas, tokens, datos de tarjeta ni montos en claro de campos cifrados.
• RNF-06.3 — Retención. La auditoría se conserva según la Política de retención y obligaciones fiscales (hasta 5 años para datos fiscales).

RNF-07 — Observabilidad

• Logging estructurado centralizado (sin datos sensibles), métricas (latencia p50/p95/p99, tasa de error, saturación de recursos) y alertamiento sobre SLO de RNF-01.
• Health checks por módulo y del Load Balancer; trazas para los flujos asíncronos (IA, OCR, contabilidad).

RNF-08 — Privacidad, retención y portabilidad de datos

• RNF-08.1 — Base legal. El tratamiento se rige por Compliance y Privacidad (LFPDPPP + GDPR). Los datos financieros son sensibles y requieren consentimiento explícito (RF70).
• RNF-08.2 — Borrado vs. retención fiscal. Al eliminar la cuenta (RF06) se anonimizan los datos personales pero se retienen los datos fiscales (CFDI, movimientos con efecto fiscal) durante el periodo legal antes de la purga. Regla de prevalencia: retención legal > derecho al olvido mientras dure la obligación.
• RNF-08.3 — Portabilidad (derecho ARCO de Acceso). El usuario puede solicitar la exportación de sus datos en formato estructurado y legible por máquina (p. ej. JSON/CSV). Pendiente de RF dedicado (post-MVP).

RNF-09 — Idempotencia y consistencia

• RNF-09.1 — Toda operación que cree dinero, cobros o efectos financieros (pagos RF38, inversiones RF31, canjes RF69, y escrituras de movimientos RF18/RF19/RF23) debe aceptar una idempotency key para que un reintento por fallo de red no duplique el efecto.
• RNF-09.2 — Las operaciones con riesgo de concurrencia (canje de recompensa, cobro) usan transacciones y control de concurrencia (p. ej. SELECT ... FOR UPDATE).

RNF-10 — Notificaciones

• Infraestructura de notificaciones (push móvil y/o email) que da soporte a RF24 (recomendación), RF41 (renovación/cancelación) y RF68 (recompensa).
• Opt-in/opt-out granular por tipo de notificación y respeto del permiso de push del sistema operativo.
• Política de reintentos y registro de entrega; las notificaciones nunca incluyen datos financieros sensibles en el cuerpo. Detalle de RF dedicado pendiente (post-MVP).

RNF-11 — Conectividad y modo offline

• La app móvil es de uso diario; las pantallas de captura manual (RF18/RF19/RF23, foto de ticket RF20) deben tolerar conectividad intermitente: permitir captura offline y sincronizar al recuperar conexión, con resolución de conflictos determinista (servidor como fuente de verdad + idempotencia RNF-09). Alcance exacto a confirmar; candidato post-MVP.

RNF-12 — Versionado y compatibilidad de API

• La API se versiona (p. ej. prefijo /v1) para poder evolucionar sin romper clientes móviles ya instalados.
• Política de deprecación y compatibilidad hacia atrás de al menos una versión mayor.

RNF-13 — Gobernanza de IA

Aplica a RF28 y a cualquier funcionalidad con IA.

• RNF-13.1 — Minimización y DLP. Los datos enviados al servicio de IA se minimizan y seudonimizan; se aplica prevención de fuga de datos (DLP) y se valida que el proveedor no reentrene con los datos del usuario.
• RNF-13.2 — Trazabilidad de modelo. Se registra versión del modelo, prompt/plantilla y fecha por cada generación, para auditoría y DPIA.
• RNF-13.3 — Calidad. Se valida/parsea la salida; se descartan recomendaciones mal formadas; se define un mecanismo de evaluación de calidad y un fallback ante indisponibilidad del proveedor.
• RNF-13.4 — Human-in-the-loop en inversión. Las recomendaciones de inversión no se publican de forma totalmente automática: pasan por reglas de negocio/curaduría y descargo de responsabilidad (no son asesoría financiera personalizada formal). Las de presupuesto/ahorro/deuda pueden ser automáticas con descargo.

RNF-14 — Alcance y cumplimiento regulatorio

• RNF-14.1 — Alcance del MVP: México. Fiscalidad (SAT, CFDI, RFC) y privacidad (LFPDPPP) son mexicanas; moneda por defecto MXN. La expansión a LatAm es post-MVP y exigirá multi-moneda (RNF-05) y multi-jurisdicción fiscal/legal.
• RNF-14.2 — AML/PLD. Cualquier funcionalidad que mueva o capte dinero (producto de rendimiento fijo RF31, futuras) requerirá controles de Prevención de Lavado de Dinero y KYC, soportados por un socio financiero regulado. Fuera del MVP.
• RNF-14.3 — Producto de rendimiento fijo. El producto tipo "cajita" (RF31) implica captación de recursos y promesa de tasa: está fuera del alcance del MVP y, cuando se implemente, será a través de una entidad regulada (CNBV/Banxico, cobertura aplicable).

RNF-15 — Mantenibilidad y calidad

• Se siguen las Convenciones de código y Convenciones de testing.
• Cobertura mínima y criterios de aceptación de cada RF como base de pruebas automatizadas (los escenarios Gherkin de cada RF son la fuente de los casos de prueba).

---

Trazabilidad: RNF ↔ hallazgos corregidos

RNF	Hueco que cierra
RNF-01, RNF-03	Disponibilidad/SLA/RTO/RPO y punto único de fallo no contemplados
RNF-02	Objetivos de rendimiento sin perfil de carga; riesgo de Argon2id
RNF-04	Falta de rate limiting / anti-fuerza bruta en auth
RNF-05	Precisión monetaria y moneda no especificadas
RNF-06	Auditoría dispersa, sin inmutabilidad ni retención definida
RNF-07	Observabilidad ausente
RNF-08	Portabilidad de datos y regla borrado-vs-retención
RNF-09	Idempotencia inconsistente en escrituras financieras
RNF-10, RNF-11	Notificaciones y modo offline no especificados
RNF-12	Versionado de API ausente
RNF-13	Gobernanza de IA insuficiente
RNF-14	Conflicto LatAm vs. México; AML/PLD; producto de rendimiento fijo