15. Historias de usuario, casos de uso y criterios de aceptación

15.1 Introducción

Para construir software no basta con decir "el sistema debe gestionar usuarios" o "el sistema debe permitir reservas". El equipo necesita expresar los requerimientos de una forma que ayude a entender quién necesita algo, qué quiere lograr, cómo interactúa con el sistema y cuándo se considerará que la funcionalidad está correctamente implementada.

Entre las herramientas más usadas para expresar requerimientos se encuentran las historias de usuario, los casos de uso y los criterios de aceptación. Cada una tiene un propósito distinto y puede ser más útil según el contexto.

En este tema veremos qué son, cómo se escriben, cómo se relacionan y qué errores conviene evitar.

15.2 Historias de usuario

Una historia de usuario es una forma breve de expresar una necesidad desde la perspectiva de quien usará o se beneficiará del sistema. Es muy utilizada en enfoques ágiles porque ayuda a mantener el foco en valor, usuario y conversación.

Un formato habitual es:

Como [tipo de usuario], quiero [objetivo o capacidad], para [beneficio o razón].

Ejemplo:

Como socio del gimnasio, quiero reservar una clase desde mi celular, para asegurar mi lugar sin llamar por teléfono.

La historia no reemplaza toda la especificación. Es un punto de partida para conversar, aclarar reglas y definir criterios de aceptación.

15.3 Partes de una historia de usuario

Una historia de usuario suele incluir tres ideas principales:

Parte Propósito Ejemplo
Rol Identifica quién tiene la necesidad. Como socio del gimnasio...
Objetivo Describe qué quiere lograr. ...quiero reservar una clase...
Beneficio Explica para qué lo necesita. ...para asegurar mi lugar sin llamar por teléfono.

El beneficio es importante porque evita construir funciones sin entender el valor que aportan.

15.4 Buenas historias de usuario

Una historia de usuario debería ser comprensible, negociable, valiosa y verificable. No necesita contener todos los detalles desde el primer momento, pero sí debe permitir una conversación útil.

Una buena historia suele cumplir estas condiciones:

  • Está escrita desde la perspectiva de un usuario o beneficiario.
  • Expresa un resultado valioso, no solo una tarea técnica.
  • Es suficientemente pequeña para poder desarrollarse y probarse.
  • Puede discutirse y ajustarse con el equipo.
  • Tiene criterios de aceptación asociados.
  • No oculta reglas de negocio importantes.
Idea clave: una historia de usuario no es solo una frase; es una invitación a conversar sobre una necesidad concreta.

15.5 Ejemplos de historias de usuario

Algunos ejemplos:

  • Como cliente, quiero consultar el estado de mi pedido, para saber cuándo llegará.
  • Como administrador, quiero bloquear usuarios inactivos, para proteger el acceso al sistema.
  • Como docente, quiero cargar calificaciones por curso, para informar resultados a los estudiantes.
  • Como paciente, quiero recibir recordatorios de turnos, para evitar olvidos.
  • Como encargado de depósito, quiero actualizar stock desde una pantalla simple, para mantener inventario correcto.

Cada historia debe luego enriquecerse con reglas, ejemplos, validaciones y criterios de aceptación.

15.6 Casos de uso

Un caso de uso describe una interacción entre un actor y el sistema para alcanzar un objetivo. A diferencia de una historia de usuario, suele detallar más el flujo de pasos, las condiciones, las alternativas y los errores posibles.

Los casos de uso son útiles cuando se necesita entender procesos completos, interacciones con varios pasos o reglas importantes. Ayudan a responder:

  • ¿Quién inicia la interacción?
  • ¿Qué objetivo quiere lograr?
  • ¿Qué pasos ocurren normalmente?
  • ¿Qué alternativas pueden aparecer?
  • ¿Qué errores o excepciones deben manejarse?
  • ¿Cómo termina exitosamente el caso?

15.7 Estructura básica de un caso de uso

Un caso de uso puede documentarse con distintos niveles de detalle. Una estructura simple incluye:

Nombre Acción u objetivo del actor.
Actor principal Quien inicia o se beneficia directamente del caso.
Objetivo Resultado que el actor quiere lograr.
Precondiciones Condiciones que deben cumplirse antes de comenzar.
Flujo principal Pasos normales para completar el caso con éxito.
Flujos alternativos Variantes válidas del flujo principal.
Excepciones Situaciones de error o casos que impiden completar el objetivo.
Postcondiciones Estado final esperado después de completar el caso.

15.8 Ejemplo de caso de uso

Ejemplo: reservar una clase en un gimnasio.

Nombre Reservar clase
Actor principal Socio
Objetivo Reservar un lugar en una clase disponible.
Precondiciones El socio está registrado y tiene cuota activa.
Flujo principal El socio consulta clases disponibles, selecciona una clase, confirma la reserva y el sistema registra el cupo.
Flujo alternativo Si quedan pocos cupos, el sistema informa la cantidad disponible antes de confirmar.
Excepción Si la clase no tiene cupo, el sistema no permite reservar y ofrece ver otros horarios.
Postcondición La reserva queda registrada y el socio recibe confirmación.

15.9 Historias de usuario y casos de uso comparados

Aspecto Historia de usuario Caso de uso
Enfoque Necesidad y valor desde la perspectiva del usuario. Interacción detallada entre actor y sistema.
Extensión Breve, pensada para conversación. Más detallado, describe pasos y variantes.
Uso común Backlogs ágiles y planificación incremental. Análisis funcional de procesos e interacciones.
Fortaleza Mantiene foco en valor. Ayuda a descubrir escenarios, reglas y excepciones.
Riesgo Puede quedar demasiado vaga si no se conversa. Puede volverse excesivamente detallado si no se controla.

No son herramientas enemigas. En algunos proyectos se usan historias para priorizar y casos de uso para detallar interacciones complejas.

15.10 Criterios de aceptación

Los criterios de aceptación describen las condiciones que deben cumplirse para considerar que una historia, funcionalidad o requerimiento está terminado correctamente. Ayudan a evitar interpretaciones distintas sobre lo que significa "listo".

Sirven para:

  • Aclarar reglas de negocio.
  • Definir resultados esperados.
  • Diseñar pruebas.
  • Validar entregas con usuarios o responsables.
  • Reducir ambigüedad.
  • Evitar discusiones tardías sobre alcance.

Un criterio de aceptación debe ser observable y verificable.

15.11 Formato Dado-Cuando-Entonces

Un formato habitual para escribir criterios de aceptación es Dado-Cuando-Entonces:

Dado [contexto inicial], cuando [acción o evento], entonces [resultado esperado].

Ejemplo:

Dado un socio con cuota activa y una clase con cupo disponible, cuando confirma la reserva, entonces el sistema registra la reserva y reduce en uno el cupo disponible.

Este formato ayuda a expresar condiciones, acciones y resultados de forma clara.

15.12 Ejemplo completo con historia y criterios

Historia de usuario:

Como socio del gimnasio, quiero cancelar una reserva, para liberar mi lugar si no puedo asistir.

Criterios de aceptación:

  • Dada una reserva activa, cuando el socio la cancela con más de dos horas de anticipación, entonces la reserva queda cancelada y el cupo vuelve a estar disponible.
  • Dada una reserva activa, cuando el socio intenta cancelarla con menos de dos horas de anticipación, entonces el sistema rechaza la cancelación e informa el motivo.
  • Dada una reserva cancelada, cuando el socio intenta cancelarla nuevamente, entonces el sistema informa que la reserva ya fue cancelada.
  • Dada una cancelación exitosa, cuando se completa la operación, entonces el sistema envía una confirmación al socio.

Estos criterios aclaran reglas, límites y resultados esperados.

15.13 Criterios de aceptación y pruebas

Los criterios de aceptación son una base para diseñar pruebas. No son exactamente lo mismo que casos de prueba detallados, pero ayudan a definir qué situaciones deben verificarse.

Criterio de aceptación Posible prueba
El sistema rechaza reservas si no hay cupo. Intentar reservar una clase completa y verificar mensaje y estado.
El usuario recibe confirmación al reservar. Crear una reserva válida y verificar que se genere la notificación.
Solo administradores pueden bloquear horarios. Intentar bloquear horarios con usuario administrador y usuario común.
La cancelación libera el cupo. Cancelar una reserva y verificar que otro socio pueda reservar ese lugar.

15.14 Cuándo usar cada herramienta

La elección depende del contexto y del nivel de detalle necesario.

  • Usa historias de usuario cuando necesites expresar valor, priorizar y conversar sobre necesidades.
  • Usa casos de uso cuando necesites describir interacciones completas, flujos alternativos y excepciones.
  • Usa criterios de aceptación para aclarar cuándo una historia o requerimiento se considera cumplido.
  • Combina herramientas cuando una historia breve no alcanza para explicar un proceso complejo.
  • Evita documentar por documentar: cada herramienta debe ayudar a entender, construir, probar o decidir.

15.15 Ejemplo comparado: recuperar contraseña

Historia de usuario:

Como usuario registrado, quiero recuperar mi contraseña, para volver a acceder a mi cuenta si la olvidé.

Caso de uso resumido:

  • El usuario selecciona "Olvidé mi contraseña".
  • El sistema solicita el correo electrónico registrado.
  • El usuario ingresa su correo.
  • El sistema genera un enlace temporal de recuperación.
  • El sistema envía el enlace al correo del usuario.
  • El usuario abre el enlace y define una nueva contraseña.
  • El sistema actualiza la contraseña y permite iniciar sesión.

Criterios de aceptación:

  • Dado un correo registrado, cuando el usuario solicita recuperación, entonces el sistema envía un enlace temporal.
  • Dado un enlace vencido, cuando el usuario intenta usarlo, entonces el sistema rechaza la operación e informa que debe solicitar uno nuevo.
  • Dada una nueva contraseña que no cumple la política definida, cuando el usuario intenta guardarla, entonces el sistema informa las condiciones faltantes.

15.16 Errores comunes

Al trabajar con estas herramientas suelen aparecer errores como:

  • Escribir historias de usuario como tareas técnicas sin valor visible.
  • Omitir el beneficio de la historia y perder el motivo del requerimiento.
  • Crear historias demasiado grandes para desarrollarlas y probarlas con claridad.
  • Documentar casos de uso enormes que nadie lee ni mantiene.
  • No incluir flujos alternativos ni excepciones importantes.
  • Escribir criterios de aceptación ambiguos o imposibles de verificar.
  • Confundir criterios de aceptación con detalles internos de implementación.
  • No validar historias, casos de uso o criterios con usuarios o responsables.

15.17 Plantillas simples

Plantilla de historia de usuario:

Como [actor o usuario], quiero [acción o capacidad], para [beneficio o necesidad].

Plantilla de caso de uso:

Nombre Objetivo del caso de uso.
Actor principal Quién inicia o se beneficia del caso.
Precondiciones Qué debe cumplirse antes de comenzar.
Flujo principal Pasos normales para lograr el objetivo.
Flujos alternativos Variantes válidas del flujo principal.
Excepciones Errores o situaciones que impiden completar el objetivo.
Postcondiciones Estado final esperado.

Plantilla de criterio de aceptación:

Dado [contexto], cuando [acción], entonces [resultado esperado].

15.18 Qué debes recordar de este tema

  • Las historias de usuario expresan necesidades desde la perspectiva del usuario o beneficiario.
  • Los casos de uso describen interacciones entre actores y sistema para lograr un objetivo.
  • Los criterios de aceptación definen condiciones verificables para considerar cumplido un requerimiento.
  • Una historia de usuario debe generar conversación, no reemplazar todo el análisis.
  • Un caso de uso ayuda a descubrir flujos principales, alternativas y excepciones.
  • Los criterios de aceptación son una base importante para diseñar pruebas.
  • Estas herramientas pueden combinarse según el nivel de detalle que necesite el proyecto.

15.19 Conclusión

Historias de usuario, casos de uso y criterios de aceptación son herramientas complementarias para expresar requerimientos. Las historias ayudan a enfocarse en valor, los casos de uso detallan interacciones y los criterios de aceptación permiten verificar si lo construido cumple lo esperado.

Para quien comienza, la idea principal es esta: un requerimiento bien expresado debe ayudar a entender quién necesita algo, qué quiere lograr, cómo interactúa con el sistema y cómo sabremos que quedó correctamente resuelto.

En el próximo tema veremos la trazabilidad entre necesidades, requerimientos y solución, para comprender cómo conservar la relación entre lo que se pide, lo que se construye y lo que se prueba.

Volver al índice