La decisión
Describa comportamiento observable antes de elegir tecnología: persona, situación inicial, acción y resultado verificable. Añada restricciones y excepciones que cambien ese resultado.
Un ejemplo práctico
En una herramienta ficticia de gastos, alguien presenta un recibo, su responsable aprueba o devuelve con motivo y finanzas exporta lo aprobado. Defina recibos ilegibles, ausencia del responsable y cambios posteriores en el importe.
Escribir un ejemplo representable
Use valores ficticios: una persona sube recibo de viaje, elige proyecto y envía. El responsable solo ve lo autorizado. Devolver exige motivo y vuelve editable; aprobar fija la versión. Explique si corregir después crea otra versión, requiere aprobación o se rechaza. El caso debe poder representarse con tarjetas antes de hablar de tecnología.
Separar reglas, preferencias y supuestos
“Solo finanzas exporta lo aprobado” es permiso; “botón arriba a la derecha”, sugerencia; “necesita hoja de cálculo”, supuesto hasta conocer recepción. Así diseño mejora sin alterar promesa. Anote fuente y aclarador de la regla. Para obligaciones contractuales o legales obtenga texto autorizado o interpretación cualificada, no una suposición del desarrollador.
Revisar con todas las partes
Solicitante, revisor y finanzas recorren el ejemplo: carga interrumpida, responsable ausente, exportación repetida y recibo corregido. Añada decisiones necesarias y deje preferencias abiertas. Escriba demostración y datos seguros. Versione requisitos aprobados para evaluar cambios. La claridad permite construir y juzgar comportamiento sin inventar decisiones del negocio.
Alternativas que conviene valorar
Un relato explica contexto, un boceto aclara interacción y los ejemplos de aceptación fijan límites. Combine lo necesario; un documento enorme no aporta valor si las decisiones no están actualizadas.
Dónde falla el plan
No use tablas de base de datos para explicar una regla de negocio. “Rápido” o “fácil” necesitan tarea y criterio. Separe comportamiento requerido de sugerencias visuales y nombre a quien resuelve desacuerdos.
Antes de encargar el trabajo
¿Otra persona puede demostrar éxito y fallo? ¿Los roles están definidos? ¿Los datos se pueden compartir? Lleve requisitos e incertidumbres al trabajo de definición del MVP.