¿Cómo capturas escenarios de error en requisitos?

Respuesta directa

Qué debe cubrir una buena respuesta

Cómo funciona

Cada flujo tiene más formas de fallar que de tener éxito, y los requisitos que solo describen el éxito dejan esos fallos para inventarlos con la fecha encima. Para cada paso, pregunta qué ocurre con entrada inválida o ausente, un actor no autorizado, una dependencia que expira o devuelve error, una solicitud que llega dos veces, dos actores cambiando lo mismo a la vez y un proceso que se detiene a medias. Para cada uno, el requisito indica qué ve el usuario, si el sistema reintenta o espera a una persona y en qué estado quedan los datos. Escribirlos como una tabla junto al flujo principal los mantiene visibles en la revisión y comprobables después.

Ejemplo

Para el flujo de pago de facturas, la tabla de errores listaba: tarjeta rechazada, mostrar el motivo y permitir otra tarjeta, la factura sigue impagada; timeout del proveedor de pagos, marcar el intento como pendiente y conciliar con la API de estado del proveedor en 15 minutos, sin mostrar fallo; envío duplicado con la misma clave de idempotencia, devolver el primer resultado; factura ya pagada por otro usuario, mostrar que se liquidó y por quién.

Errores frecuentes

• Documentar solo errores de validación y saltarse timeouts y fallos parciales.
• Especificar un mensaje de error sin el estado resultante del sistema.
• Dejar el comportamiento de reintentos al implementador y obtener cobros dobles.

Una estructura útil para responder

Responde desde tu propia experiencia.

No memorices un guion: usa solo ejemplos que puedas explicar con honestidad en preguntas posteriores.