Los Casos de Uso y el Valor del Sistema

A quién no le ha pasado que siente la necesidad de comprar algo sólo para terminar con
ese producto en un rincón sin jamás ser utilizado. Nos pudo haber pasado porque no
alcanzó nuestras expectativas, o porque resultó demasiado complicado de utilizar, o
porque en realidad no era una verdadera necesidad sino simplemente un capricho. Sea
cual fuera la razón, la realidad es que hicimos un gasto inútil e innecesario.
Con el software, y en particular con el desarrollo de software a la medida ocurre con
bastante frecuencia algo similar. Pues, no es raro encontrarse con empresas que contratan
un desarrollo de software sólo para darse cuenta de que desperdiciaron su dinero y su
tiempo, pues no obtuvieron lo que ellos esperaban o necesitaban. En otras palabras, no
obtuvieron el valor que esperaban recibir para su negocio con el software adquirido.

La Administración de Requerimientos

Una de las razones principales por las cuales se da esta situación, y de hecho, una de las
causas principales por las cuales los proyectos de desarrollo fracasan o por lo menos no
tienen el éxito que deberían, se debe a una mala administración de requerimientos. Esto
generalmente se da por falta ya sea de habilidades en el personal responsable o de
técnicas apropiadas utilizadas para llevar a cabo esta labor.

La administración de requerimientos, de acuerdo a CMM, abarca actividades como la

recopilación, documentación, validación y control de los requerimientos y sus cambios.
UML, como estándar integrador de las buenas prácticas de desarrollo nos ofrece en este
sentido los casos de uso como una técnica excelente para administrar los requerimientos
de nuestros proyectos.

¿Consultoría o Manufactura?

Si queremos realizar una verdadera consultoría de software entonces nos corresponde

algo más que escuchar la lista de funciones que el cliente cree que debería de tener su
sistema (a menos que nuestro cliente tenga un área con la capacidad de realizar una
buena recopilación y análisis de requerimientos).
Si nos limitáramos a lo primero entonces en lugar de llamarle consultoría a nuestro
trabajo, deberíamos llamarle manufactura de software, donde uno implementa las
funciones exactamente como se las solicita el cliente, cuestionando nada o muy poco, tal
como se haría en una planta manufacturera donde se reciben las especificaciones del
producto a construir.

El Sistema y su Misión

Si queremos desarrollar el mejor sistema posible debemos realizar un trabajo serio para
identificar, en primer lugar, cuál es el valor que el sistema debe proporcionar al negocio.
Para lo cual habrá que preguntárselo a las personas que obtendrán alguna clase de
beneficio cuando se ponga en operación. Una buena parte de estas personas
probablemente vayan a ser usuarios del sistema; en UML los conocemos como Actores
(más adelante veremos otros tipos de Actores que también tendremos que identificar).

Buscando los Beneficios del Sistema

Una vez identificados los usuarios del sistema (actores primarios) habrá que preguntarles
en qué situaciones valdrá la pena para ellos utilizarlo. La lista identificada de dichas
situaciones no debería de tener pequeñas funciones, sino flujos completos que le
proporcionen suficiente valor tanto a ellos como al negocio, de manera que “valga la
pena usar el sistema” en dichas situaciones.
Ejemplo: un vendedor en cierto sistema de ventas querrá “Registrar venta”, “Registrar
pedido”, “Consultar comisiones”, “Administrar prospectos”, “Generar factura” y
“Administrar clientes”. Todas ellas son ejemplos de situaciones u objetivos importante
que podría necesitar un vendedor para llevar a cabo su trabajo, conocidas y modeladas
como casos de uso en UML, tal como se muestra en el diagrama.

Diagrama de casos de uso para el sistema de venta

Los Requerimientos Funcionales

Normalmente los casos de uso son iniciados por algún actor, conocido como actor
primario. Lo inicia con algún evento, que podría ser tan simple como elegir una opción
en el sistema, y continúa como una serie de eventos o interacciones entre actores y
sistema, hasta que el objetivo del caso de uso se cumple (el objetivo principal del caso de
uso es lo que le da el nombre al mismo). Por lo tanto los casos de uso describen la
funcionalidad del sistema para alcanzar objetivos importantes.

Lo que estamos obteniendo así es una especificación de requerimientos funcionales

mediante un análisis top-down (de lo general a lo particular), es decir, primero
obtenemos los objetivos que hay que cumplir en el sistema descritos con el nombre del
caso de uso (p. ej: Realizar una venta) y después buscamos cuáles son las funciones o
requerimientos funcionales precisos y ordenados para que el actor cumpla dicho objetivo
al utilizar sistema. Esto nos lleva a identificar requerimientos realmente relevantes para
alcanzar la misión del sistema.

Resumen para recopilar los requerimientos funcionales adecuados del sistema mediante
casos de uso:

1. Especificar la misión del sistema

2. Identificar quiénes utilizarán el sistema (actores primarios)
3. Averiguar cuáles objetivos desean cumplir los actores al usar el sistema (casos de
uso)
4. Identificar los pasos o eventos de cada caso de uso (especificación del caso de uso)

Las Interfases del Sistema

Hay otro tipo de actores que también hay que modelar; los actores secundarios. Suelen
ser otros sistemas, componentes externos o dispositivos con los cuales interactúa nuestro
sistema. A diferencia de los actores secundarios, éstos no son los que inician o requieren
del caso de uso, sino que nuestro sistema, al llevar a cabo un caso de uso requiere tener
algún tipo de interacción con él.
En el diagrama de casos de uso también suele ser apropiado mostrar a este tipo de
actores, en cuyo caso aparecerán asociados a los casos de uso durante los cuales tienen
que intervenir con algún tipo de interacción con el sistema a modelar.

Ejemplo de Actor Secundario

Nuestro sistema de ventas podría requerir enviarle información al sistema de

contabilidad cuando se ejecuta la funcionalidad del caso de uso “Generar factura”. En
dicha situación el sistema de contabilidad aparecerá como un actor secundario
asociado a dicho caso de uso. De esta forma estamos mostrando las interfases
requeridas con otros sistema en cada momentos.

Por experiencia sabemos que, en los modelos de UML, el buen uso de pocos elementos
da mejores resultados que el uso de muchos elementos mal aplicados. La esencia de los
modelos radica en la simplicidad, ya que facilita el análisis, entendimiento y
comunicación entre quienes solicitan el sistema y los que participan en su desarrollo.
En otras oportunidades veremos elementos adicionales para modelar los casos de uso,
pero podemos asegurar que la sencillez es parte importante del modelado, y esto implica
que en ocasiones, y sobre todo cuando el analista no tiene tanta experiencia en UML, es
mejor limitarnos a los elementos más básicos.