Computers">
Nothing Special   »   [go: up one dir, main page]

Especificaciones de Casos de Uso

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 3

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 especificaciones 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.

Flujo principal del caso de uso “Registrar Venta”

 El vendedor solicita el registro de una nueva venta.


 El sistema solicita los datos de cada uno de los productos de la venta.
 El vendedor registra la cantidad y clave de cada uno de los productos.
 El sistema muestra la lista de productos con su cantidad, clave, descripción,
subtotal, IVA y total.
 El sistema solicita el tipo de pago.
 El vendedor indica pago al contado o con tarjeta de crédito.
 Dependiendo de la selección comienza el flujo alterno “Pago al contado” o “Pago
con tarjeta de crédito”.
 Una vez realizado el pago se registra la venta, se actualiza el inventario e
imprime el ticket correspondiente.
 Termina el caso de uso.

Flujo Alterno: Pago al Contado

 El vendedor registra el monto recibido por el cliente.


 El sistema calcula y muestra el cambio a devolver.
 El vendedor devuelve el cambio al cliente.

El ejemplo que mostramos es una versión simplificada de la especificación de un caso


de uso con el flujo principal y uno de los flujos alternos.

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.

También podría gustarte