Corto y simple de entender es mejor

Los casos de uso funcionan mejor como instrumentos de
comunicación mientras más cortos y más simple sean,
sin dejar por fuera nada esencial en el proceso

Cuando hay que comprender el problema y la solución, mientras más corto y más sencillo es es el contenido, mejor es el resultado. Dentro de una conversación sobre la etapa de definición o de conceptualización de una solución de gestión de información, hemos dedicado algunos post para hablar de los requisitos, así como de los "casos de uso". Estos últimos los presentamos como un interesante instrumento de comunicación, útil en numerosas ocasiones. Pero cualquier descripción acerca de ellos, particularmente señalando sus virtudes, está incompleta si no se incluye también la conversación polémica de sus limitaciones y malos usos, un tema sobre el que hay discusiones abiertas, sin bien más entre la gente ligada al software que a la Arquitectura de información.

El valor que aportan los casos de uso es la comunicación gráfica de la vinculación entre las acciones y pasos principales de un proceso y los actores que los ejecutan. Funcionan excelentemente en la medida en que sean lo más cortos y comprensibles que sea posible. Obviamente sin dejar por fuera los elementos esencias del proceso.

El punto importante es entender que mucha información puede ser demasiada información. En efecto, un excesivo desarrollo de los casos de uso puede no aportar claridad sino confusión.

La razón por la cual los casos de uso no deben detallarse demasiado es que, cuando se trata de comprender globalmente un proceso, si hay muchos detalles en la información, lo más probable es que se nos diluya la concentración en aspectos irrelevantes y perdamos de vista las relaciones principales. Si eso sucede, las virtudes expositivas de los casos de uso se pierden.

Lo que esencialmente se debe comunicar en ellos, lo que debemos entender después de haberlos visto, es algo relativamente simple: cuáles son los actores involucrados en el proceso, cuáles son los pasos que se realizan y cuáles son las decisiones principales que bifurcan el proceso hacia un lado o hacia otro.

Una de las cosas que confunde acerca de los casos de uso es que como en alguna literatura hay mucha insistencia en ciertas herramientas y plantillas, en ocasiones la forma diluye la esencia. Por otro lado, si se pierde de vista su propósito principal y se confunde su sentido con un instrumento para documentar al detalle todos los requisitos, o todo sobre cada requisito, se pierde su razón de ser.

Por ejemplo, los casos de uso están pensados para describir transacciones, no requisitos no funcionales (ver Después de la visión viene la lista de requisitos). Deben ayudar a comprender el proceso, no a documentar la interfaz de usuario. Deben ser una ayuda para la comprensión de la esencia, no una documentación comprehensiva. Si se tiene esto en mente y si no nos perdemos en los detalles de forma, seguramente los escribiremos bien.

Como vemos, los errores en los casos de uso tienen que ver cuando se entra demasiados detalles, de fondo o de forma. Los buenos Arquitectos de Información de un modo natural trabajan en una zona cercana los usuarios concentrándose y aportando la compresión de la esencia de los procesos, por ellos suelen escribir casos de uso simples y descriptivos.