Si entra basura, sale basura... una gran verdad en cualquier proceso, a menos que te dediques al reciclaje de desechos. Los proyectos de software no son la excepción; si no iniciamos el desarrollo partiendo de requerimientos correctamente establecidos tendremos muchos problemas para lograr que al final todos los involucrados queden satisfechos.

Evitando Malentendidos

Como lo comentamos en la edicion anterior, la mayoría de los proyectos de software que fallan tienen como causa principal una mala administración de requerimientos. Un ejemplo en este sentido suele ser un mal entendimiento de los requerimientos entre usuarios y desarrolladores.

Aún y cuando el equipo de desarrollo cree comprender lo que el cliente le está solicitando, existe una buena probabilidad de que no sea así. Incluso me atrevo a decir que en la mayoría de las ocasiones lo que yo he visto es que en las primeras etapas ni siquiera el cliente está totalmente conciente de qué es lo que quiere o necesita.

Ahí es donde el analista entra al rescate, pues debe facilitarle al usuario expresar sus necesidades para validarlas posteriormente mediante mecanismos eficientes de comunicación que ambos entiendan. Un ejemplo excelente de estos mecanismos son las especificaciones de casos de uso.

Aclarando el Panorama

Partiendo de la premisa que ya se identificaron los actores y casos de uso apropiados del sistema (ver número anterior: Casos de Uso y el Valor del Sistema) lo que corresponde es detallar los pasos necesarios para cumplir con dicho caso de uso.

Para especificar cada caso de uso deberíamos de tomar en consideración los siguientes aspectos:

1. Interacciones. Mencionar la participación del actor primario y la de cada actor secundario desde que inicia el caso de uso hasta que termina.
   
2. Eventos. Indicar cada uno de los eventos que ocurren durante el caso de uso (consulta de datos, capturas, cálculos, etc.)
   
3. Nivel de detalle. Los casos de uso y sus especificaciones son la base del contrato que establecemos con nuestro cliente, por lo que debemos de buscar especificarlo al máximo detalle. Recuerda que entre más sepamos de la funcionalidad del sistema más precisas serán las estimaciones de nuestro plan de trabajo.
   
4. Escenarios. Un caso de uso muestra diferentes escenarios posibles y no una sola forma de ejecutarlo. Debemos de explicar cada uno de esos escenarios, mediante un flujo principal y sus diferentes flujos alternos y excepcionales.
   
5. Claridad y Enfoque de Usuario. Busca claridad en la explicación de los casos de uso utilizando la jerga de negocio a la hora de redactarlo sin mencionar detalles técnicos a los que no está acostumbrado. Sobre todo te interesa poder validar con éste que lo documentado en las espceificaciones de los casos de uso es lo que requiere para su sistema, así que si no los entiende no cumplirán su propósito principal.
   

Durante los cursos y consultoría que impartimos a los analistas, les pido que me “platiquen” de qué se trata el caso de uso solicitado por su cliente, y después escribimos eso mismo en las especificaciones, generalmente logramos así un documento más claro que cuando lo escriben directamente sin platicarlo. La experiencia me dice que, por lo menos en sistemas, la gente explica mejor las cosas oralmente que de forma escrita.

Generalmente se recomiendan varios elementos adicionales para documentar los casos de uso. Pero, puedo asegurarte que la esencia es lo mencionado anteriormente. Pero, a continuación se mencionan algunos de esos elementos extras con los que puedes complementar la plantilla para documentar tus especificaciones de casos de uso.

• Propósito. Si comienzas por este punto se te facilitará definir los pasos más relevantes para ejecutar el caso de uso.
• Precondiciones. Son las condiciones que se deben de cumplir en el sistema antes de iniciarlo. El estado en que se debe encontrar el sistema antes de ejecutarlo. (Ej: Algún catálogo debe estar actualizado, debe estar en conexión con otro sistema, el usuario debe estar conectado con cierto perfil específico)
• Postcondiciones. Te indica como queda el sistema después de ejecutar el caso de uso. Imagina que eres un tester y quieres comprobar si alguien acaba de ejecutar el caso de uso. ¿Qué cosas buscarías en el sistema? Seguramente datos nuevos, modificados, eliminados o la posibilidad de elegir nuevas opciones en el sistema.
• Requerimientos Especiales. Cualquier requerimiento extra del sistema, asociado al caso de uso especificado.
• Puntos de Extensión. Puntos donde se extiende el caso de uso mediante una relación de <<extend>>.

En los cursos prácticos que impartimos de UML una de las inquietudes que nos expresan más frecuentemente los analistas es el hecho de que el cliente no está dispuesto a pagar el esfuerzo requerido para realizar la “documentación” que implica especificar los casos de uso.

El error, en primer lugar, es que no lo deberíamos de ver como “la documentación” del sistema, sino como una herramienta para esclarecer lo que quiere que le construyamos. Si no se especifica claramente qué es lo que quiere/desea/necesita el cliente entonces resulta una adivinanza saber cuánto nos vamos a tardar, y por lo tanto cuánto nos va a costar desarrollarlo.

En este sentido dependerá del contexto del proyecto el nivel de detalle a realizar, y por lo tanto la cantidad de “documentación” generada para especificar los casos de uso. Sólo hay que tomar en cuenta que entre menos precisión y detalle haya mayor será el riesgo de no tener un proyecto exitoso. Así que no nos debe de sorprender que si entra basura, con bastante probabilidad, saldrá basura.