En el anterior post vimos que es una historia de usuario, la cual me permite describir una funcionalidad desde la perspectiva de un usuario. Pero esta no es la única forma traducir un requisito.

Hoy vamos a ver otra alternativa usada en el mundo del desarrollo para describir una funcionalidad: Los casos de uso 

¿Qué es un caso de uso? 

Un caso de uso describe una secuencia de iteraciones entre un sistema dado y un actor externo para una funcionalidad. En el mismo se detalla el comportamiento externo que es observado del sistema. 

Los casos de usos toman un enfoque diferente al concepto que manejamos de historia de usuario. Mientras que en una historia de usuario buscamos detallar una funcionalidad con el mínimo de detalle posible para generar las conversaciones necesarias; un caso de uso detalla al completo las interacciones y respuestas de nuestro sistema. 

En nuestro día a día vamos a encontrar diferentes formatos de casos de usos, pero generalmente debe tener los siguientes elementos: 

• Un identificador único y un título en el cual se represente cual es el objetivo del mismo. 
• Una breve descripción indicando el propósito del caso. 
• El detonante o trigger que inicia la secuencia de pasos 
• Las precondiciones que se deben satisfacer a la hora del iniciar un caso de uso 
• Las postcondiciones que describen el estado del sistema luego de ejecutarse el caso de uso 
• Una lista de pasos que muestren las iteraciones entre los actores externos y el sistema. 

Es importante diferenciar que estamos hablando de un actor externo y no de un usuario. Un actor puede ser una persona, un sistema externo e incluso un dispositivo de hardware el cual interactúa con nuestro sistema. 

Además, un caso de uso puede incluir los diferentes escenarios posibles que podemos encontrarnos a la hora de la interacción del actor externo con nuestro sistema. 

Un ejemplo práctico

Veamos un ejemplo práctico para notar las diferencias: 

Supongamos que tenemos una aplicación web en la cual ofrecemos el servicio de suscripción de streaming para poder ver las carreras de Formula 1 en vivo. Una funcionalidad que deseamos tener es que el usuario pueda poder subscribirse a la misma. 

Esta funcionalidad traducida a historia de usuario podemos describirla de la siguiente manera: 

Como visitante del sitio quiero suscribirme al sitio para ver la carrera de formula 1 en vivo. 

Como vemos la misma carece de detalles. Con las conversaciones necesarias iremos refinando la misma y empezando a armar los criterios de aceptación. 

En un caso de uso tomamos otro enfoque. La funcionalidad en si sigue siendo la misma, buscamos que un visitante del sitio pueda subscribirse, pero al contrario debemos detallar cual es la interacción del actor externo (en nuestro caso el visitante) con nuestro sistema hasta llegar a la suscripción. 

Además, debemos plantear que tipo de precondiciones, postcondiciones deben existir para que se inicie la suscripción (El visitante debe estar registrado en nuestro sitio, etc.…)  

A continuación, listamos un ejemplo de un caso de uso. 

Conclusión 

Ahora que ya sabemos que es un caso, observamos la primera diferencia notoria respecto a las historias de usuario, los detalles. Los casos de usos implican que debemos realizar un relevamiento previo para acotar todos los detalles y recién empezar con el desarrollo. Mientras que una historia de usuario los detalles implican que los detalles deben buscarse.  

Independiente del método usado, lo ideal es llegar a lo mismo. Tener en detalle la funcionalidad, solamente que con la historia de usuario podemos empezar antes el desarrollo e ir refinando. 

Otra diferencia que nos encontramos es que, mientras que en las historias de usuarios estamos enfocados en encontrar la necesidad de la funcionalidad por parte del usuario (el para qué), en los casos de usos describimos detalladamente las interacciones de nuestro software con actores externos para satisfacer esa necesidad. Dado eso, adicionalmente se los utiliza como una herramienta para documentar requerimientos. 

Además, los casos de usos al ser más complejos son más difíciles de leer y pueden contener algún lenguaje técnico, mientras que en una historia de usuario son fáciles de leer y cualquier persona fuera del proyecto logra comprender sobre la misma 

Hasta acá llegamos con una pequeña introducción a los casos de usos. ¡Espero que les haya gustado! 

¡Gracias!