22.1 Introducción
Los criterios de aceptación y la definición de terminado ayudan a responder una pregunta central: ¿cómo sabemos que un requerimiento, historia o funcionalidad está realmente completo?
Sin criterios claros, una persona puede considerar que una función está terminada mientras otra piensa que faltan reglas, mensajes, validaciones, pruebas o documentación.
Estos elementos reducen ambigüedad, mejoran la comunicación y permiten verificar el resultado de manera más objetiva.
22.2 ¿Qué son los criterios de aceptación?
Los criterios de aceptación son condiciones específicas que deben cumplirse para aceptar un requerimiento, historia de usuario o funcionalidad.
Un criterio de aceptación define qué debe ser verdadero para considerar que una necesidad fue satisfecha correctamente.
Ejemplo:
- El sistema no debe permitir guardar un reclamo sin cliente asociado.
- Al registrar un reclamo correctamente, debe asignarse un número único.
- Si el correo ingresado no tiene formato válido, debe mostrarse un mensaje de error.
- Solo usuarios con rol supervisor pueden cerrar reclamos de prioridad alta.
22.3 ¿Para qué sirven?
Los criterios de aceptación sirven para:
- Aclarar el comportamiento esperado.
- Reducir interpretaciones distintas.
- Guiar desarrollo y pruebas.
- Definir cuándo una funcionalidad puede aceptarse.
- Detectar reglas faltantes.
- Facilitar conversación con usuarios e interesados.
- Relacionar requerimientos con pruebas de aceptación.
Un buen criterio de aceptación convierte una expectativa en una condición observable.
22.4 Criterios de aceptación y requerimientos
Un requerimiento describe lo que el sistema debe cumplir. Los criterios de aceptación detallan condiciones para considerar ese requerimiento satisfecho.
| Requerimiento |
Criterios de aceptación posibles |
| El sistema debe permitir registrar clientes. |
Nombre y documento son obligatorios. El documento no debe repetirse. El correo debe tener formato válido. |
| El sistema debe permitir consultar pedidos. |
Debe filtrar por cliente, fecha y estado. Si no hay resultados, debe informar que no existen pedidos. |
| El sistema debe permitir cerrar reclamos. |
Solo reclamos resueltos pueden cerrarse. Debe registrarse usuario y fecha de cierre. |
22.5 Características de un buen criterio
Un buen criterio de aceptación debe ser:
- Claro: puede entenderse sin interpretaciones complicadas.
- Verificable: puede comprobarse mediante prueba, revisión o demostración.
- Concreto: describe una condición específica.
- Relevante: está relacionado con el valor o la regla del requerimiento.
- Completo: cubre casos principales y condiciones importantes.
- No ambiguo: evita términos como rápido, fácil o adecuado sin medida.
Los criterios no deben repetir simplemente el requerimiento con otras palabras.
22.6 Formato de lista
Una forma simple de escribir criterios es mediante una lista de condiciones.
Ejemplo:
Historia: como alumno, quiero inscribirme a un curso, para reservar mi lugar.
Criterios de aceptación:
- El curso debe tener cupo disponible.
- El alumno no debe estar previamente inscripto en el mismo curso.
- Si la inscripción se confirma, el sistema debe enviar un correo de confirmación.
- Si no hay cupo, el sistema debe informar el motivo y no registrar la inscripción.
Este formato es claro y fácil de revisar con usuarios.
22.7 Formato Dado-Cuando-Entonces
Otro formato frecuente es Dado-Cuando-Entonces. Ayuda a expresar escenarios verificables.
Dado [contexto inicial], cuando [acción o evento], entonces [resultado esperado].
Ejemplo:
- Dado un curso con cupo disponible, cuando el alumno confirma la inscripción, entonces el sistema registra la inscripción y descuenta un cupo.
- Dado un curso sin cupo disponible, cuando el alumno intenta inscribirse, entonces el sistema rechaza la operación e informa que no hay cupo.
- Dado un alumno ya inscripto, cuando intenta inscribirse nuevamente al mismo curso, entonces el sistema no permite duplicar la inscripción.
Este formato facilita la conexión entre requerimientos y pruebas.
22.8 Casos positivos y negativos
Los criterios de aceptación deben considerar casos positivos y negativos.
- Caso positivo: la operación se realiza correctamente.
- Caso negativo: el sistema rechaza la operación por datos inválidos, falta de permisos o regla incumplida.
- Caso límite: la operación ocurre en una condición extrema o especial.
Ejemplo: para registrar un pedido, no alcanza con probar un pedido válido. También hay que considerar productos sin stock, cliente bloqueado, cantidades inválidas o falta de datos obligatorios.
22.9 Criterios para requerimientos no funcionales
Los requerimientos no funcionales también necesitan criterios de aceptación. Deben expresarse de forma medible.
| Requerimiento no funcional |
Criterio de aceptación |
| La búsqueda debe ser rápida. |
La búsqueda de productos debe responder en menos de 2 segundos con hasta 50.000 productos cargados. |
| El sistema debe ser seguro. |
Después de 5 intentos fallidos, la cuenta debe bloquearse durante 15 minutos. |
| La aplicación debe ser usable en celulares. |
Las funciones principales deben poder utilizarse en pantallas de 360 píxeles de ancho sin desplazamiento horizontal. |
22.10 ¿Qué es la definición de terminado?
La definición de terminado es un acuerdo general del equipo sobre las condiciones que debe cumplir cualquier trabajo para considerarse completo.
Mientras los criterios de aceptación pertenecen a un requerimiento o historia específica, la definición de terminado suele aplicarse a todos los elementos de trabajo.
Los criterios de aceptación dicen qué debe cumplir una funcionalidad específica. La definición de terminado dice qué condiciones generales deben cumplirse para dar por terminado el trabajo.
22.11 Ejemplos de definición de terminado
Una definición de terminado puede incluir condiciones como:
- El código fue implementado.
- Los criterios de aceptación fueron cumplidos.
- Las pruebas acordadas fueron ejecutadas.
- No quedan defectos críticos abiertos.
- La funcionalidad fue revisada por otra persona del equipo.
- La documentación necesaria fue actualizada.
- Los permisos y validaciones fueron revisados.
- La funcionalidad fue demostrada o validada con el responsable correspondiente.
La definición debe adaptarse al contexto y madurez del equipo.
22.12 Diferencia entre aceptación y terminado
| Concepto |
Pregunta que responde |
Ejemplo |
| Criterios de aceptación |
¿Qué debe cumplir esta historia o requerimiento? |
Un reclamo no puede cerrarse si no tiene resolución registrada. |
| Definición de terminado |
¿Qué condiciones generales debe cumplir cualquier trabajo para considerarse completo? |
Debe tener pruebas ejecutadas, revisión realizada y documentación actualizada. |
Ambos conceptos se complementan. Una historia puede cumplir sus criterios de aceptación, pero no estar terminada si faltan pruebas o documentación.
22.13 Relación con pruebas
Los criterios de aceptación son una base natural para diseñar pruebas. Cada criterio puede transformarse en uno o más casos de prueba.
Ejemplo:
- Criterio: el sistema debe impedir una venta sin stock suficiente.
- Prueba: intentar confirmar una venta con cantidad mayor al stock disponible.
- Resultado esperado: la venta no se confirma y se informa el motivo.
Esta relación mejora la trazabilidad entre requerimientos y verificación.
22.14 Quién define los criterios
Los criterios de aceptación deben definirse con participación de las personas adecuadas. No deberían ser responsabilidad exclusiva de una sola persona si el requerimiento afecta a varios roles.
Pueden participar:
- Usuarios o representantes del negocio.
- Analista de requerimientos.
- Product owner o responsable del producto.
- Equipo de desarrollo.
- Equipo de pruebas o calidad.
- Seguridad, legal o auditoría cuando corresponda.
La colaboración mejora la claridad y reduce omisiones.
22.15 Cuándo definirlos
Los criterios de aceptación deben definirse antes de construir la funcionalidad, no después. Pueden refinarse durante el análisis, pero el equipo necesita claridad antes de comprometer implementación.
Definirlos temprano permite:
- Detectar reglas faltantes.
- Aclarar datos y permisos.
- Estimar mejor el esfuerzo.
- Diseñar pruebas antes o durante el desarrollo.
- Evitar discusiones al momento de aceptar la entrega.
22.16 Ejemplo completo
Historia:
Como vendedor, quiero confirmar un pedido, para reservar productos y avanzar con la venta.
Criterios de aceptación:
- El pedido debe tener cliente asociado.
- El pedido debe tener al menos un producto.
- Todos los productos deben tener stock suficiente.
- Si el cliente está bloqueado, el pedido no puede confirmarse.
- Al confirmar, el sistema debe cambiar el estado a "confirmado".
- Al confirmar, el sistema debe reservar stock de los productos incluidos.
- Si ocurre un error al reservar stock, el pedido debe permanecer sin confirmar.
22.17 Criterios y alcance
Los criterios de aceptación también ayudan a controlar alcance. Aclaran qué se espera en una entrega específica y qué no está incluido.
Por ejemplo, para la historia "consultar estado de pedido", los criterios pueden aclarar que la primera versión solo mostrará estado general y fecha estimada, pero no seguimiento geográfico en tiempo real.
Esto reduce expectativas incorrectas y facilita planificar versiones futuras.
22.18 Errores frecuentes
Al definir criterios de aceptación y terminado, suelen aparecer estos errores:
- Escribir criterios demasiado generales.
- Repetir el requerimiento sin agregar condiciones verificables.
- No considerar casos negativos o excepciones.
- No incluir reglas de negocio importantes.
- Definir criterios después de desarrollar.
- No involucrar a usuarios o testers.
- Confundir criterios de aceptación con tareas técnicas.
- No tener una definición de terminado compartida por el equipo.
22.19 Buenas prácticas
Algunas buenas prácticas son:
- Definir criterios antes de implementar.
- Escribirlos en lenguaje claro y verificable.
- Incluir casos positivos, negativos y excepciones importantes.
- Relacionarlos con reglas, datos y permisos.
- Usarlos como base para pruebas de aceptación.
- Revisarlos con interesados adecuados.
- Mantener una definición de terminado visible y compartida.
- Actualizar criterios si cambia el requerimiento.
Un criterio de aceptación útil reduce la frase "yo pensé que..." al momento de revisar una entrega.
22.20 Qué debes recordar de este tema
- Los criterios de aceptación definen condiciones para aceptar un requerimiento específico.
- Deben ser claros, verificables y concretos.
- Pueden escribirse como lista o con formato Dado-Cuando-Entonces.
- Deben incluir casos positivos, negativos y excepciones importantes.
- Sirven como base para pruebas de aceptación.
- La definición de terminado establece condiciones generales para considerar completo el trabajo.
- Criterios de aceptación y definición de terminado se complementan.
22.21 Conclusión
Los criterios de aceptación y la definición de terminado ayudan a transformar expectativas en condiciones verificables. Permiten que usuarios, analistas, desarrolladores y testers compartan una comprensión común sobre lo que significa completar un requerimiento.
Definirlos temprano reduce ambigüedades, mejora las pruebas y facilita la aceptación del producto.
En el próximo tema estudiaremos escenarios, flujos principales y flujos alternativos, herramientas útiles para describir cómo se comporta el sistema ante distintas situaciones.