Unidad temática III: Requerimientos de software para las metodologías agiles

28 de noviembre al 16 de diciembre
3.1 Artefactos XP
3.1.1 Historias de usuario
3.1.2Tarjetas CRC
3.2 Artefactos RAD
3.3 Reglas de negocio

Especificaciones de Caso de Uso. Lo que Bien Comienza, Bien

Acaba.

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 es bien sabido, la mayoría de las fallas en los proyectos de software se debe a 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 consciente 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 de 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

®
Todos los Derechos Reservados. Nacira Mendoza
Prohibida la reproducción total o parcial, incluyendo cualquier medio electrónico o magnético
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 de excepción.
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 el usuario está acostumbrado. Sobre todo te interesa poder validar con éste que
lo documentado en las especificaciones de casos de uso es lo que requiere para su
sistema, así que si no los entiende no cumplirán su propósito principal.

Vale la pena recalcar que 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.

He aquí el ejemplo de la descripción del flujo para el caso de uso “Registrar

venta”: iFlujo 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.

®
Todos los Derechos Reservados. Nacira Mendoza
Prohibida la reproducción total o parcial, incluyendo cualquier medio electrónico o magnético
 • 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 de parte del cliente.

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

Generalmente se recomiendan varios elementos adicionales para documentar los casos de uso.
Sin embargo, puedo asegurarte de que la esencia es lo mencionado anteriormente. Algunos de
esos elementos extra con los que puedes complementar tu plantilla para documentar tus
especificaciones de casos de uso son:

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

®
Todos los Derechos Reservados. Nacira Mendoza
Prohibida la reproducción total o parcial, incluyendo cualquier medio electrónico o magnético
 • 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 <>.

En los cursos prácticos de UML que impartimos, 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.

i
Debido a las limitantes de espacio, este ejemplo es una versión simplificada de la especificación de un caso de uso, ya que sólo incluye el
flujo principal y uno de los flujos alternos. La versión completa de la especificación se encuentra disponible en
www.milestone.com.mx/EjemplosUML/EspecificacionCU.htm

®
Todos los Derechos Reservados. Nacira Mendoza
Prohibida la reproducción total o parcial, incluyendo cualquier medio electrónico o magnético