En la epoca de RUP se manejaban los «Casos de Uso» como el elemento fundamental de declaración de requerimientos de usuario. Hoy en día esto a evolucionado y se maneja un instrumento más amplio llamado «Historias de Usuario».
Quienes venimos de varios años de análisis de sistemas de TI podríamos pensar «ahh! le cambiaron el nombre a los Casos de Uso», pero no es así; sin embargo no se trata de un «cambio» sino más bien de la adición de un instrumento más que facilita más el resolver ese problema comunicacional que históricamente ha afectado a todos los proyectos de TI.
Casos de Uso
Los «Casos de Uso» son artefactos que permiten describir en términos coloquiales, es decir en términos del lenguaje del usuario, lo que un sistema debe permitir a un actor que interactúa con él.
Históricamente se utilizó esta notación como punto de partida para documentar el requerimiento de los usuarios, en un lenguaje si bien coloquial, con un mínimo de formalidad que le daba «orden».
Ahora bien, la generación de los «Casos de Uso» si bien se ejecutan en un lenguaje «Coloquial», exige el conocimiento técnico de la notación. Esto generó siempre la necesidad de que los casos de uso fuesen documentados por Analistas, sin perder la facilidad de que presentados a un usuario en esa notación, el usuario tuviese la capacidad de entenderlos y confirmar si reflejaban el requerimiento de manera acertada y completa.
Aclaremos una cosa, un «Caso de Uso» es la declaración de una (1) interacción de un Usuario con el Sistema, nada más que eso; aquí la complejidad «técnica» yace en dos elementos fundamentales; el primer elemento es el siguiente criterio, el cual los usuarios no suelen entender claramente:
Todo caso de uso es atómico respecto a la descripción de una interacción entre el usuario y el sistema.
Por ejemplo, si un sistema ofrece la capacidad de contestar una pregunta X, y para eso requiere tener actualizado en su base de datos los catálogos de información Y y Z, entonces estamos en presencia de un sistema con 3 casos de uso (y no 1):
- Realización de pregunta X
- Actualización del catálogo Y
- Actualización del catálogo Z
Estas declaraciones como «Caso de Uso» se pueden hacer con los dibujos como la figura 2 pero eso es realmente opcional.
Y el segundo elemento, es declarar la metadata de cada «caso de uso» (interacción), como por ejemplo: ID, NOMBRE, REFERENCIAS CRUZADAS, CREADO POR, ÚLTIMA ACTUALIZACIÓN POR, FECHA DE CREACIÓN, FECHA DE ÚLTIMA ACTUALIZACIÓN, ACTORES, DESCRIPCIÓN, TRIGGER, PRE-CONDICIÓN, POST-CONDICIÓN, FLUJO NORMAL, FLUJOS ALTERNATIVOS, INCLUDES, FRECUENCIA DE USO, REGLAS DE NEGOCIO, REQUISITOS ESPECIALES, NOTAS Y ASUNTO.
Historias de Usuario
Entonces fue necesario un artefacto más general, que pudiese ser generado por el usuario mismo, sin la necesidad de una notación formal (por muy simple que sea), el cual fue llamado «Historias de Usuario».
Una historia de usuario es la declaración en texto libre, producido por un usuario, con su mejor esfuerzo de circunscribir en esa declaración sólo los alcances que están directa e íntimamente relacionados.
Lo más importante de una historia de usuario, es que no es necesario que cumpla ninguna formalidad ni criterio; simplemente debe declarar el «cómo debe funcionar» un aspecto del sistema tal y como lo imagina el usuario.
Entonces, a partir de una Historia de Usuario (que ha sido generada por el usuario… al final del día es «su historia»), el analista empieza a destilar cada historia y extrae de ahí los casos de uso que están contenidos, entrando entonces en el terreno ya conocido de los casos de uso.
Claro, los usuarios no se van a poner a redactar «Historias de Usuario», sino que en reuniones o entrevistas entre el analista con el/los usuario(s), el analista generan estos documentos que entrega al Usuario para que, al hacerlos suyo, puede mejorar, aumentar, reducir, etc. hasta quedar satisfecho.
Conclusión
Usen Historias de Usuario, y como conclusión de éstas, siempre tenga claro cuántos casos de uso están contenidos en cada una. De esta manera podrán cuantificar de manera simple el alcance funcional de lo que estén modelando.
