Computers">
Especificaciones de Casos de Uso
Especificaciones de Casos de Uso
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.
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.
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.
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.