Ingeniería de Requerimientos

Nivel básico-intermedio — distinguir requerimientos funcionales de no funcionales y especificarlos con la precisión que necesita un arquitecto.

Idea central "El sistema debe ser rápido" no es un requerimiento, es un deseo. Sin una cifra verificable detrás, el arquitecto no puede tomar decisiones informadas y nadie puede validar si el sistema las cumple.

01 —

El problema

Los equipos reciben requerimientos vagos: "el sistema debe ser rápido", "necesitamos que sea seguro", "tiene que escalar". Son frases, no especificaciones.

Situación típica: el cliente dice "necesito un sistema rápido". El equipo asume que 2 segundos de respuesta es aceptable. En producción, el cliente se queja porque esperaba 200ms. Nadie definió "rápido" con un número. // la ambigüedad no se descubre hasta que ya es cara de arreglar

Los requerimientos no funcionales mal definidos son la causa principal de sistemas que "funcionan" pero no satisfacen al cliente — y son los que más impactan las decisiones arquitectónicas: elegir monolito vs. microservicios depende más de escalabilidad y disponibilidad que de features.

02 —

RF vs. RNF

Requerimientos Funcionales (RF) — qué hace el sistema. Verbos de acción, verificables con un test funcional.

✓ RF-001: El sistema permite al usuario registrarse con email y contraseña
✓ RF-002: El sistema envía un email de confirmación dentro de 60 segundos tras el registro

✗ "El sistema debe manejar usuarios" (vago, no accionable)
✗ "El sistema es user-friendly" (subjetivo, no verificable)

Requerimientos No Funcionales (RNF) — cómo se comporta el sistema. Restricciones sobre cualidades operativas.

Categoría	Qué define	Ejemplo de métrica
Rendimiento	Velocidad y throughput	Latencia p95 < 200ms
Escalabilidad	Capacidad de crecimiento	10.000 usuarios concurrentes
Disponibilidad	Uptime del sistema	99.9% mensual
Seguridad	Protección de datos	Cifrado AES-256 en reposo
Mantenibilidad	Facilidad de cambio	Deploy en <30 min
Compliance	Regulaciones legales	Cumplimiento GDPR

03 —

El patrón SMART

Todo RNF debe ser Specific, Measurable, Achievable, Relevant, Time-bound.

Vago	SMART
"El sistema debe ser rápido"	"El 95% de las peticiones a la API responden en <300ms bajo carga normal (100 req/seg)"
"Debe ser seguro"	"Contraseñas con bcrypt (factor 12). Sesiones expiran tras 30 min de inactividad"
"Tiene que escalar"	"Soporta incremento de 1.000 a 50.000 usuarios mensuales sin cambios arquitectónicos"

04 —

Cuándo aplicarlo

Profundiza en RNFs si...	RFs son suficientes si...
El sistema es crítico para el negocio	Es un MVP/prototipo desechable
Hay SLAs contractuales	No hay compromisos de nivel de servicio
Regulaciones aplican (GDPR, HIPAA)	Uso interno sin datos sensibles

La cifra la pone el negocio, no la plantilla

SMART te da la forma ("95% de peticiones en <300ms"), no el número correcto para tu sistema. Copiar las cifras de ejemplo de esta lección sin validarlas contra tu propio negocio es el mismo error que "el sistema debe ser rápido" — solo que con más decimales.

05 —

Practica: brief vago → especificación

Brief real de cliente: "Necesitamos una plataforma de e-learning para nuestra empresa. Los empleados deben poder tomar cursos online, ver videos, hacer quizzes y obtener certificados. Debe funcionar bien, ser seguro porque hay datos de empleados, y aguantar que toda la empresa lo use a la vez cuando lancemos una capacitación obligatoria. Tenemos 5.000 empleados en 3 países."

Transforma este brief en un documento de RFs y RNFs SMART.