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.
