En la generación previa de diseño de programas (llamada diseño procedural), esto se llamaba «crear el análisis de requisitos y especificación del sistema». Éstos, por supuesto, eran lugares donde perderse; documentos con nombres intimidantes que podrían llegar a ser grandes proyectos en sí mismos. Sin embargo, su intención era buena. El análisis de requisitos dice: «Haga una lista de las directrices que usará para saber cuándo está terminado el trabajo y el cliente está satisfecho». La especificación del sistema dice: «Ésta es una descripción de lo que hará el programa (no cómo) para satisfacer los requisitos». El análisis de requisitos es realmente un contrato entre usted y el cliente (incluso si el cliente trabaja dentro de su compañía o es algún otro objeto o sistema). La especificación del sistema es una exploración de alto nivel del problema y en algún sentido un descubrimiento de si se puede hacer y cuánto se tardará. Dado que ambos requerirán consenso entre la gente (y porque suelen cambiar con el tiempo), creo que es mejor mantenerlos todo lo escueto posible -en el mejor de los casos, listas y diagramas básicos- para ahorrar tiempo. Podría tener otras restricciones que le exijan ampliarlos en documentos más grandes, pero manteniendo el documento inicial pequeño y conciso, puede crearse en algunas sesiones de tormentas de ideas de grupo con un líder que cree la descripción dinámicamente. Esto no sólo recaba la participación de todos, sino que también fomenta la implicación inicial y el acuerdo de todo el equipo. Y, quizá lo más importante, permite arrancar el proyecto con mucho entusiasmo.

Es necesario no perder de vista lo que está intentando conseguir en esta fase: determinar qué se supone que debe hacer el sistema. La herramienta más valiosa para eso es una colección de los llamados «casos de uso». Los casos de uso identifican características clave en el sistema que pueden revelar algunas de las clases fundamentales que se usarán. En esencia son respuestas descriptivas a preguntas como^[21]:

Si está diseñando un cajero automático, por ejemplo, el caso de uso para un aspecto particular de la funcionalidad del sistema es capaz de describir qué hace el cajero automático en todas las situaciones posibles. Cada una de esas «situaciones» se denomina escenario, y se puede considerar que un caso de uso es una colección de escenarios. Puede pensar en un escenario como una pregunta que comienza con: «¿Qué hace el sistema si...?» Por ejemplo, «¿Qué hace el cajero automático si un cliente ha ingresado un cheque hace menos de 24 horas y, sin contar el cheque, no hay saldo suficiente en la cuenta para el reintegro solicitado?»

Los diagramas de caso de uso son intencionadamente simples para impedir que se atasque con los detalles de implementación del sistema demasiado pronto:

Cada monigote representa un «actor», que típicamente es un humano o algún otro tipo de agente libre. (Incluso puede ser otro sistema de computación, como es el caso del «Cajero automático»). La caja representa el límite del sistema. Las elipses representan los casos de uso, los cuales son descripciones de trabajo útil que se puede llevar a cabo con el sistema. Las líneas entre los actores y los casos de uso representan las interacciones.

No importa cómo esté implementado realmente el sistema, siempre que el usuario lo vea así.

Un caso de uso no necesita ser terriblemente complejo, incluso si el sistema subyacente es complejo. Lo único que se persigue es mostrar el sistema tal como aparece ante el usuario. Por ejemplo:

Los casos de uso producen las especificaciones de requisitos determinando todas las interacciones que el usuario puede tener con el sistema. Intente descubrir una serie completa de casos de uso para su sistema, y una vez que lo haya hecho tendrá lo esencial sobre lo que se supone que hace su sistema. Lo bueno de centrarse en casos de uso es que siempre le lleva de vuelta a lo esencial y le mantiene alejado de los asuntos no críticos para conseguir terminar el trabajo. Es decir, si tiene una serie completa de casos de uso puede describir su sistema y pasar a la siguiente fase. Probablemente no lo hará todo perfectamente en el primer intento, pero no pasa nada. Todo le será revelado en su momento, y si pide una especificación del sistema perfecta en este punto se atascará.

Si se ha atascado, puede reactivar esta fase usando una herramienta tosca de aproximación: describir el sistema en pocos párrafos y después buscar sustantivos y verbos. Los sustantivos pueden sugerir actores, contexto del caso de uso (p. ej. «vestíbulo»), o artefactos manipulados en el caso de uso. Los verbos pueden sugerir interacción entre actores y casos de uso, y pasos específicos dentro del caso de uso. Además descubrirá que sustantivos y verbos producen objetos y mensajes durante la fase de diseño (y observe que los casos de uso describen interacciones entre subsistemas, así que la técnica «sustantivo y verbo» sólo se puede usar como una herramienta de lluvia de ideas puesto que no genera casos de uso) ^[22].

El límite entre un caso de uso y un actor puede mostrar la existencia de una interfaz de usuario, pero no la define. Si le interesa el proceso de definición y creación de interfaces de usuario, vea Software for Use de Larry Constantine y Lucy Lockwood, (Addison Wesley Longman, 1999) o vaya a www.ForUse.com.

Aunque es un arte oscuro, en este punto es importante hacer algún tipo de estimación de tiempo básica. Ahora tiene una visión general de qué está construyendo así que probablemente será capaz de tener alguna idea de cuánto tiempo llevará. Aquí entran en juego muchos factores. Si estima un plazo largo, la compañía puede decidir no construirlo (y usar sus recursos en algo más razonable -eso es bueno). O un gerente puede tener ya decidido cuánto debería durar el proyecto e intentar influir en su estimación. Pero es mejor tener una estimación honesta desde el principio y afrontar pronto las decisiones difíciles. Ha habido un montón de intentos de crear técnicas de estimación precisas (como técnicas para predecir la bolsa), pero probablemente la mejor aproximación es confiar en su experiencia e intuición. Utilice su instinto para predecir cuánto tiempo llevará tenerlo terminado, entonces multiplique por dos y añada un 10%. Su instinto visceral probablemente sea correcto; puede conseguir que algo funcione en ese tiempo. El «doble» le permitirá convertirlo en algo decente, y el 10% es para tratar los refinamientos y detalles finales ^[23]. Lo explique como lo explique, y a pesar de las quejas y manipulaciones que se producen cuando presenta una estimación así, parece que las cosas salen de esa forma.