La escritura de casos de uso

Explicar un proceso no tiene por que ser demasiado complicado

En nuestros últimos post hemos estado hablando sobre los casos de uso: un importante instrumento de comunicación de lo esencial de un proceso de gestión de información: los actores que intervienen, los pasos que realizan y las decisiones principales que toman. Hemos hablado sobre su valor en las distintas etapas del ciclo de vida de una solución, sobre la importancia del seguimiento de sus cambios y la relación con la calidad de la solución, sobre los problemas y las polémicas que se presentan cuando se documentan en exceso los procesos, aportando más confusión que claridad. Queremos cerrar estas conversaciones con unas recomendaciones sencillas acerca de cómo escribirlos.

En primer lugar es bueno observar que no es conveniente creer que hay una receta válida para todos los casos. Lo que hay son experiencias utiles que muchas veces pueden funcionar.

Una de la primera recomendaciones es identificar los actores, las entradas y las salidas claves de un proceso. Recordemos que los actores pueden ser personas o sistemas o módulos programados. Identificar las entradas y salidas principales suele ser sencillo, porque las salidas principales son normalmente la razón de ser del proceso y porque las entradas son los insumos que se requieren. Esas entradas y salidas tienen actores vinculados.

Lo siguiente es descubrir los pasos intermedios. Suelen ser de cuatro tipos básicos: Solicitar información al actor, Proporcionar información al actor, hacer un trabajo en nombre del actor, tomar una decisión. Obviamente las frases y relaciones concretas son las que describen lo específico.

Sorprendentemente estas orientaciones suelen ser suficientes para trabajar y explicar casi cualquier proceso. Al menos cuando se trabaja en Arquitectura de información. No se requiere abundar con muchos detalles la descripción de un caso de uso ya que como vimos la semana pasada (ver Corto y simple de entender es mejor) mucha información puede ser demasiada información. La interfaz de usuario, los formatos, los requisitos no funcionales (ver Después de la visión viene la lista de requisitos), las fórmulas o las reglas de negocio pueden ser relevantes en el plan de trabajo con el que se desarrolla una solución, pero estorban al comprender el proceso y describir los casos de uso.

Cuando de explicar un proceso se trata, es importante centrarse y lo que interesa en la descripción de un proceso es cuándo el usuario o el sistema proporciona información, cuándo el usuario o el sistema la solicita, cuándo el sistema realiza un cierto procesamiento y cuándo el usuario o el sistema toma una decisión que compromete el flujo posterior del proceso.

Así trabajan los Arquitectos de información, de una manera naturalmente ágil y eficiente, escribiendo casos de uso cortos y comprensibles, que evitan la hiperdocumentación al tiempo que logran la efectividad que se requiere para una solución bien diseñada, desarrollada e implantada. Como señala Martin Fowler, escribir casos de uso largos, durante semanas, más que un buena señal, es un indicador de que la descripción que se espera y necesita, no se está haciendo bien.