01Hace algo
Requisito funcional
El motor del auto
Describe qué hace el sistema: una acción observable, una regla o una respuesta ante un evento.
EjemploLa plataforma permite al aprendiz consultar su progreso.
Ruta de aprendizaje · ADSO
Convierte ideas ambiguas en software verificable.
Guía 2 · Ingeniería de Contexto, Historias de Usuario y sintaxis BDD (Gherkin).
En la era de la IA, un requerimiento claro no es burocracia: es el contexto que permite que personas, equipos y máquinas construyan la misma solución.
01 contexto
✓ verificable
RAP 02
Resultado de aprendizaje
Establecer los requisitos del software de acuerdo con la información recolectada.
00 · Ingeniería de contexto
La IA puede generar código. No puede adivinar tu intención.
El contexto convierte conversaciones, restricciones y decisiones del negocio en información útil para diseñar.
01
Pregunta antes de completar
Cuando una frase permite varias interpretaciones, el equipo debe detenerse y recolectar información. Es más barato aclarar una palabra hoy que corregir un producto mañana.
02
Conserva el porqué
El beneficio explica la decisión. Si solo documentamos botones y pantallas, perdemos la oportunidad de evaluar si la solución realmente aporta valor.
03
Haz visible lo verificable
Un buen requisito permite imaginar una prueba: una condición, una acción y un resultado que otra persona puede observar.
ClaroUna sola interpretación
CompletoActor, acción y valor
VerificableSe puede probar
TrazableConecta con el objetivo
01 · Fundamentos
Primero entiende el problema. Luego escribe la solución.
La ingeniería de requisitos conecta la necesidad del negocio con un comportamiento que el equipo puede desarrollar y probar.
02Cómo debe hacerlo
Requisito no funcional
La seguridad de los frenos
Define cómo debe comportarse: rendimiento, seguridad, accesibilidad, disponibilidad o restricciones.
EjemploEl progreso debe mostrarse en menos de 2 segundos.
Anatomía de una historia
01 — 0301
Rol
¿Quién necesita esta capacidad?
02
Acción
¿Qué quiere poder hacer?
03
Beneficio
¿Qué valor obtiene y por qué importa?
02 · Profundización
Especifica el qué. Mide el cómo.
Un requisito no es una frase decorativa: es una decisión que debe orientar el diseño, el desarrollo y la prueba.
RF
Requisitos funcionales
Explican las capacidades y reglas del producto. Responden: ¿qué debe hacer el sistema? Se escriben con un actor, una acción, datos de entrada, reglas y una respuesta observable.
RNF
Requisitos no funcionales
Definen las condiciones de calidad o las restricciones. Responden: ¿cómo debe hacerlo y bajo qué límites? Siempre que sea posible, incluyen una métrica y un contexto de medición.
| Tipo | Pregunta guía | Ejemplo bien formulado | ¿Cómo se verifica? |
|---|---|---|---|
| RF-01 | ¿Qué capacidad necesita el actor? | El sistema permite al cliente confirmar un pedido con los productos disponibles. | Prueba funcional + escenario Given / When / Then. |
| RF-02 | ¿Qué regla debe cumplirse? | Al confirmar el pedido, el sistema descuenta las unidades reservadas del inventario. | Prueba de regla de negocio y consistencia de datos. |
| RNF-01 | ¿Qué nivel de rendimiento se espera? | El resumen del pedido responde en menos de 2 segundos para el 95 % de las solicitudes. | Prueba de carga con datos y condiciones acordadas. |
| RNF-02 | ¿Qué restricción de seguridad aplica? | Las contraseñas se almacenan con un algoritmo de hash resistente y nunca se envían por HTTP. | Revisión técnica, análisis de configuración y prueba de seguridad. |
01 / RFComportamiento
Qué suele incluir un requisito funcional
- 01Actor y disparadorQuién inicia la acción y qué evento la activa.
- 02Flujo principalPasos que ocurren cuando todo está correcto.
- 03Reglas y excepcionesQué pasa si falta información, stock o permisos.
- 04Resultado y trazabilidadQué observa el usuario y qué objetivo satisface.
Ejemplo completo · RF-03
Actor: administrador.
Necesidad: registrar un curso con título, cupos y fecha.
Regla: no se puede guardar si los cupos son menores que 1.
Resultado: el curso aparece en el catálogo con estado “borrador”.
02 / RNFCalidad
Familias de requisitos no funcionales
Rendimientotiempo de respuesta, concurrencia, consumo.
Seguridadautenticación, autorización, cifrado, auditoría.
Disponibilidadhorario, porcentaje de uptime, recuperación.
Usabilidadaccesibilidad, aprendizaje, navegación con teclado.
Mantenibilidadlogs, pruebas, modularidad, documentación.
Compatibilidadnavegadores, dispositivos, versiones e integraciones.
Transforma lo vago en medible
✕ “La aplicación debe ser rápida y segura.”
✓ “El 95 % de las consultas responde en menos de 2 s y la API exige HTTPS y token válido.”
Ejercicios guiados
Practica antes de pasar al laboratorio
01Clasifica y mejora¿RF o RNF?+
“El sistema debe ser fácil de usar y permitir reportes.” Separa la frase en dos requisitos y agrega una forma de medir cada uno.
Respuesta orientadora
RF: el coordinador puede generar un reporte mensual en PDF. RNF: una persona nueva completa la tarea sin ayuda en máximo 3 minutos y la interfaz puede usarse con teclado.
02Construye un escenarioGiven / When / Then+
Convierte este RF en un criterio de aceptación: “El aprendiz consulta su progreso”. Incluye una condición inicial, una acción y un resultado visible.
Ejemplo de solución
Dado que el aprendiz tiene una sesión activa, cuando abre su panel, entonces observa el porcentaje actualizado y los módulos pendientes.
03Traza una decisiónRequisito → prueba+
Escribe un RNF para una pantalla de inicio de sesión y define qué evidencia usarías para comprobarlo.
Ejemplo de solución
RNF: tras enviar credenciales válidas, el usuario recibe respuesta en menos de 2 s en el 95 % de los casos. Evidencia: prueba de carga, medición de percentiles y registro de fecha, versión y entorno.
03 · Laboratorio interactivo
Construye. Ordena. Valida.
Simulador listo
A
USER_STORY
Constructor 01
Historia de Usuario
Selecciona cada pieza lógica. Una historia útil expresa valor, no solo una lista de tareas.
Vista previa compilada
Como [rol], quiero [acción] para [beneficio].
Completa las tres piezas para validar la historia.
B
Gherkin
Constructor 02
Escenario BDD
>_
Arrastra un bloque o haz clic para añadirlo al escenario. El orden debe ser Given → When → Then.
Bloques disponibles
+Haz clic en un bloque
o suéltalo aquí
o suéltalo aquí
Aún no hay bloques en tu escenario.
Pista de ingeniería: un criterio de aceptación no describe cómo programar; describe qué debe observarse cuando el sistema funciona.
Gherkin en una mirada
BDD convierte conversaciones en ejemplos ejecutables.
El escenario debe poder ser leído por una persona no técnica y, al mismo tiempo, servir como contrato para automatizar pruebas.
Regla de oroDescribe comportamiento, no implementación.
C
ANALYZERSimulador 03
Detector de ambigüedad
Escribe un requerimiento del cliente y observa qué información está presente y qué deberías preguntar antes de construir.
Prueba con:
El análisis aparecerá aquí.
04 · Vista de sistema
Una aplicación es un flujo. No solo una pantalla.
La arquitectura general muestra quién consume el sistema, dónde vive cada responsabilidad y cómo circulan los datos.
01 · EntradaUsuario / navegador / móvilInterfaz, sesión y acciones del usuario
02 · Borde de redDNS · HTTPS · proxy inversoRecibe solicitudes, cifra el tránsito y dirige el tráfico
03 · Aplicación
Frontendpresenta la experiencia
API / backendaplica reglas de negocio
Workertareas asíncronas
04 · Estado
Base de datosinformación estructurada
Cache / colavelocidad y trabajos
Archivosimágenes y documentos
↗Integracionescorreo, pagos, mapas o proveedor de IA mediante API
◌Operaciónlogs, métricas, alertas, backups y recuperación
05 · PlataformaVPS / nube · Docker · CoolifyLa infraestructura aloja; Docker empaqueta; Coolify despliega y opera la aplicación.
De la arquitectura al despliegue
Cada herramienta responde una decisión técnica.
Primero se define el requisito de calidad; después se elige la plataforma que puede demostrarlo con evidencia.
01
Dónde se ejecuta
Nube y VPS
La nube ofrece cómputo, red y almacenamiento bajo demanda. Un VPS es un servidor virtual concreto dentro de esa infraestructura, con CPU, memoria, disco y sistema operativo administrables.
Decisión vinculadaCapacidad, disponibilidad, costo, firewall y copias de seguridad.
02
Cómo se empaqueta
Docker
Convierte la aplicación y sus dependencias en una imagen reproducible. Cada contenedor ejecuta esa imagen con la misma configuración acordada por el equipo.
Decisión vinculadaVersiones, puertos, variables, persistencia y límites de recursos.
03
Cómo se despliega y opera
Coolify
Se instala sobre el servidor, conecta el repositorio y coordina servicios Docker, variables, dominios y HTTPS. Simplifica la operación, pero no sustituye monitoreo, actualizaciones ni recuperación.
Decisión vinculadaAutomatización del despliegue, secretos, certificados, logs y rollback.
Flujo de entrega
Del cambio versionado a una aplicación disponible
01GitCódigo, Dockerfile y configuración versionada
→
02CoolifyDetecta el cambio y prepara el despliegue
→
03DockerConstruye la imagen y ejecuta el contenedor
→
04VPS + dominioPublica con HTTPS, persistencia y observabilidad
Flujo de una petición
- El navegador resuelve el dominio y abre una conexión HTTPS.
- El proxy envía la solicitud al frontend o a la API.
- La API valida identidad y reglas; consulta datos o llama a un servicio externo.
- La respuesta vuelve al cliente y la operación queda registrada en logs.
Qué debe decidir el equipo
- Responsabilidades: qué pertenece a frontend, backend y base de datos.
- Datos: qué es persistente, qué puede perderse y qué debe respaldarse.
- Escala: cuántos usuarios, solicitudes y archivos se esperan.
- Riesgo: qué pasa si falla la base de datos, el proveedor de IA o el VPS.
La IA como copiloto arquitectónico
Aquí la IA se integra al proceso para explorar alternativas, convertir restricciones en preguntas y proponer pruebas. Un prompt útil entrega contexto y pide evidencia:
Contexto: app web con frontend, API y PostgreSQL.
Restricción: desplegar con Docker en un VPS usando Coolify.
Tarea: propone arquitectura, riesgos, RNF y pruebas.
No inventes secretos; justifica cada decisión.Revisa la propuesta con requisitos, pruebas de carga, seguridad y presupuesto antes de aplicarla.
Idea central: los requisitos dicen qué debe lograrse; la arquitectura organiza responsabilidades; la infraestructura aporta el entorno donde el sistema puede ejecutarse, observarse y recuperarse.
05 · Panel de validación
Ahora toma una decisión de diseño.
Reto final01 / 01
Mensaje del cliente · contexto insuficiente
“Necesito que el sistema gestione las compras y actualice todo automáticamente.”
El mensaje expresa una intención, pero no define actor, acción concreta, valor ni comportamiento verificable.
01
Tu misión
Reescribe el requerimiento
Usa el Constructor A y el Constructor B para expresar una historia específica y un escenario que se pueda comprobar.
Condición de aprobaciónHistoria completa + Given / When / Then lógico