Casos de Abuso, Parte 10: Los flujos de eventos en los casos de uso son escritos en pseudocódigo

Este es el que yo llamo “síndrome del programador que se volvió analista”, algo así como el hombre-lobo del proceso de desarrollo de software. Creo que todos los que hemos recorrido este largo pero tortuoso laberinto que significa el ciclo de vida del desarrollo de software hemos experimentado, al menos, una o más de esas manifestaciones “fenomenoides” del universo informático. Además, este abuso es primo del abuso 5, donde usamos detalles técnicos en la documentación del caso de uso.

El antídoto es sencillo: un caso de uso siempre, sin ninguna excepción, se escribe en terminología del negocio, con las palabras que usa el usuario en sus actividades diarias. Si esto no es posible, quizás no estamos ante un caso de uso.

Nada de incluir expresiones como: “si ocurre esto entonces hacer aquello”, en cambio usar distintas secuencias o flujos alternos; o “mientras se cumpla una condición, realizar estas acciones”, en vez de ello, describir el conjunto de acciones para un elemento-sujeto de la condición y en los requisitos especiales del caso de uso dejar de manifiesto que puede haber uno o más elementos para esa condición. Y mucho menos usar nombres de “variables”, ciclos for o while o selección múltiple. Lo único que lograremos con ello es confundir a los usuarios.

Veamos con un caso de uso algo escueto un ejemplo típico:

Caso de uso: Retirar fondos

Actor: Cliente

Secuencia Básica:

1.    El caso de uso inicia cuando el cliente decide retirar dinero en efectivo de un cajero automático

2.    El sistema solicita la cantidad de dinero a retirar

3.    El Cliente ingresa la cantidad de dinero a retirar

4.    El sistema verifica el saldo del Cliente

5.    Si el Saldo del Cliente es mayor que o igual a la cantidad a retirar, el cajero entrega el dinero. De lo contrario, muestra el mensaje “Fondos insuficientes”

6.    El caso de uso termina

Los pasos 4 y 5 de este caso de uso son una muestra de lo que no se debe hacer al documentar requisitos. En cambio, podríamos decir:

4.    El sistema verifica que el Cliente tiene saldo suficiente en su cuenta y entrega el dinero.

5.    El caso de uso termina

Para el caso de falta de fondos, escribimos una secuencia alternativa. Esta estrategia además posibilita una implementación más rápida y “limpia” del caso de uso y permite al equipo de pruebas tener mayor visibilidad de los escenarios para verificar el software.

Impacto en la calidad: Alto.

PD. Para saber más de sobre casos de uso, abecés, anatomía, prácticas y requisitos en general, puedes visitar mi Sección Lecturas Fundamentales en mi Gazafatonario IT.

Lectura Fundamental 1: “Casos de Uso: de vuelta a lo fundamental”

http://gazafatonarioit.blogspot.com/2006/11/lecturas-fundamentales.html