Indice

Definimos Caso de Uso como… ............................................................................................ 2

Modelado de Casos de Uso .................................................................................................... 3
Definimos Actor como… ....................................................................................................... 4
Casos de Uso: Flujos de Eventos............................................................................................ 5
Ejemplo de caso de uso .......................................................................................................... 6
Prácticas: Gestión de Requisitos........................................................................................... 10
Control de Calidad: Trazas ................................................................................................... 11

1
Definimos Caso de Uso como…

Hoy en día los casos de uso son la principal forma de capturar los requisitos de los
proyectos de desarrollo de software; y de ahí por tanto que sean el lugar de inicio más
común para los libros que explican métodos de desarrollo. Sin embargo son también quizás,
el concepto peor entendido de todos, probablemente por su sencillez y por estar enfocado a
su tarea de modelar requisitos pero dejar poco lugar para nada más.

Formalmente, para el glosario:

Caso de Uso, Escenario que narra la interacción entre un sistema y una entidad externa a la
que se le provee una funcionalidad. Los casos de uso son principalmente cuerpos de texto
de definición de requisitos funcionales aunque por medio de extensiones pueden ser
utilizados por fuera de este ámbito.

El lenguaje UML incluye en su especificación el soporte para los casos de uso, permitiendo
representar por medios visuales diversas características de estos; complementando así lo
indicado en las especificaciones en formato texto de cada caso de uso.

Considerando que los sistemas de información modernos son altamente interactivos, tanto
por su relación con múltiples operadores humanos como por su necesidad de integrarse e
interactuar con otros sistemas, es necesario entonces que los requisitos sean capturados
respetando esta naturaleza interactiva. Es decir, si bien antes nos bastaba preguntar qué
debe hacer el sistema ahora es necesario agregar para cada uno de sus usuarios.

Por sencillez, llamaremos actor a cada operador externo, tanto si es un sistema aparte del
nuestro como si se trata de un operador humano.

Con el enfoque de los casos de uso, el sistema luce diferente para cada uno de sus actores.
A unos, la funcionalidad que ofrece serán la que se corresponde con su trabajo, en tanto que
a otros, será la que corresponda con la necesidad de estos. Esta organización de la
funcionalidad según el punto de vista de cada actor es clave para poder capturar rápida y
efectivamente, los requisitos funcionales de un sistema altamente interactivo.

En su conjunto, los casos de uso constituyen el llamado Modelo de Requisitos Funcionales

el cual puede ser complementado con documentos que detallen Requisitos No Funcionales
en una forma más tradicional. Es responsabilidad del Analista de Requisitos el construir y
el mantener estos artefactos.

El Modelado de Casos de Uso es hoy por hoy, la principal técnica de captura de requisitos
funcionales, y es una pieza central en los procesos de desarrollo de pruebas, de la interfaz
hombre-maquina, de la documentación de usuario y manuales así como de guiar el análisis
y diseño de la solución técnica del desarrollo. Es decir, que el proceso de desarrollo se
encuentra centrado en casos de uso.

Si bien los casos de uso pueden ser manejados en forma gráfica, con ayuda de los
diagramas de caso de uso del lenguaje UML, la información total que estos contienen va
2
mucho más allá. Entre las propiedades de los casos de uso se encuentran los flujos de
eventos, las pre condiciones, los puntos de extensión y muchos más elementos, solo
posibles de ser representados con ayuda de un documento de texto. En este blog, podrá
encontrar un ejemplo completo.

Modelado de Casos de Uso

La idea de especificar los requisitos de un sistema es simple: indicar lo que el sistema debe
hacer. Sin embargo, dado que los sistemas modernos son altamente interactivos; tanto por
su relación con múltiples operadores como por su integración con otros sistemas – los
llamados actores; hoy por hoy es necesario dar un giro en esa idea inicial. Hoy es necesario
especificar lo que el sistema hace para cada actor.

La organización de un cuerpo de requisitos modernos es pues, una presentación de las

responsabilidades del sistema desde el punto de vista de cada uno de los actores que
requieren los servicios del sistema. A esta forma de documentar los requisitos le llamamos
Caso de Uso.

En su forma más simple, un caso de uso es un párrafo de texto que describe un escenario de
interacción entre el actor -o actores- y el sistema. Dicho párrafo contiene la especificación
de la funcionalidad requerida y puede ser considerada la unidad fundamental de un modelo
de requisitos.

En adición a esta descripción de la interacción, es usual encontrar detalles adicionales. La

principal de estas adiciones es el llamado flujo de eventos, que pone en limpio la
interacción entre el actor y el sistema por medio de su presentación en pasos, indicando
tanto la información que viaja de un lado al otro, y el cálculo o proceso que se requiere que
el sistema realice con la información.

Usual también, es encontrar las desviaciones al flujo de eventos típico presentadas como
flujos alternativos. Manejando de esta forma las condiciones de error que se requieren sean
cubiertas por el sistema.

Sin embargo, con mucho la más popular de las extensiones o adiciones que se hacen a los
casos de uso es la de presentarlos en forma gráfica con ayuda del lenguaje de modelado
UML. Sin embargo, es importante dejar en claro que la representación gráfica no es donde
el requisito es capturado. Este papel es cubierto por las descripciones textuales del
escenario y en gran parte también, por los flujos de eventos principales y alternativos.

Un ejemplo rápido de diagrama de caso de uso, quizás parte de un modelo mucho más
grande y complejo es el siguiente:

3
Fig. 1 – Ejemplo de diagrama de casos de uso

Un ejemplo más completo de caso de uso puede ser encontrado en este blog, en la entrada
Ejemplo de Caso de Uso.

Finalmente comento que la técnica de los Casos de Uso fue introducida por primera vez por
Ivar Jacobson a principios de los años noventa. La técnica fue presentada en un contexto en
el que la orientación a objetos era popular; por lo que hoy en día se consideran comúnmente
a los casos de uso como integrantes del análisis y diseño orientado a objetos. Sin embargo
los casos de uso no tienen nada de específicamente orientado a objeto, ya que su objetivo es
la documentar requisitos de sistemas interactivos y estos por razones obvias no tienen
porqué ser objetos. Así que ya sea que se desarrolle un sistema orientado a objeto o no, los
casos de uso son apropiados para capturar los requisitos del sistema; siempre y cuando,
digo de nuevo, el sistema sea fuertemente interactivo.

Definimos Actor como…

En teatro, un actor representa un papel según las indicaciones de un guión. Nosotros

tomamos esa metáfora para indicar que un agente externo realiza una acción sobre el
sistema, acción esta que puede ser capturada como un guión que sea parte de un caso de
uso.

Es interesante observar que llamamos actor a toda entidad externa que demanda
funcionalidad del sistema, ya sea un ser humano o un sistema de software; por lo cual el
término usuario puede ser un poco limitado.

Normalmente representamos a los actores de nuestro sistema por medio de la simple

imagen de una figura humana de rayas. pero dada la flexibilidad del UML es posible
representarlo también como una clase estereotipada o bien, con una imagen provista por
nosotros según algún criterio artístico.

4
La siguiente imagen ilustra las tres formas que he mencionado:

Fig. 1 – Tres formas de representar un Actor en un diagrama de UML

La especificación UML lidía con el lenguaje visual pero como en otras ocasiones esta no es
más que una fracción de lo que queremos decir sobre nuestros modelos, en este caso, es de
interes capturar información adicional de nuestros actores, para lo cual podemos pensar en
tener una tabla como la siguiente para cada uno de ellos:

Nombre: Actor
Representado por: Nombre y datos de contacto del stakeholder que puede responder
preguntas sobre este actor
Facilidades de comunicación: Protocolos o estilos de comunicación que el actor entiende.
Relación con otros actores: Relaciones de herencia o dependencia entre actores

Tabla 1 – Definición de un Actor

La definición anterior la podemos llevar en el cuerpo de comentarios de nuestro modelador

UML y exportarlo a un documento de texto cada vez que sea necesario.

Los actores nos sirven para capturar a los usuarios del sistema pero también, son la forma
en la que podemos expresar el contexto del mismo. Es decir, que los actores toman el lugar
de cualquier entidad de interes con la que nuestro sistema interactua.

Pese a lo anterior, ciertas cosas generalmente vistas como externas al sistema no son
considerados buenos actores. Los sistemas de persistencia como las bases de datos o los
archivos, si bien externos, no son actores. Entre otras cosas, debido a que estos no
demandan funcionalidad del sistema (son pasivos respecto a él) además, es de interes que
estos elementos estén bajo la definición del diseño de nuestro sistema, por lo que puede
resultar de más provecho considerarlos parte del mismo.

Casos de Uso: Flujos de Eventos

Un caso de uso es un escenario de interacción entre el sistema y un ente externo; es decir:

es la descripción de una funcionalidad del sistema, visto desde el punto de vista de un ente
externo que demanda dicha funcionalidad.

Al ente externo le llamamos actor por cuanto un caso de uso puede ser visto también como
un guión, que a la manera de los guiones de una obra de teatro, dice paso a paso lo que el
actor ha de hacer.

5
Es mucho lo que podemos decir de un caso de uso: nombre, descripción, pre condiciones,
etc. Sin embargo, el aspecto más interesante de un caso de uso luego de la descripción del
mismo es sin duda el flujo de eventos.

Al flujo de eventos lo podemos relacionar con un dialogo. Línea a línea, el flujo de eventos
indica quien habla y qué dice. La secuencia se suele iniciar con algo dicho por el actor, y se
continua intercalando sucesivamente lo hecho por el sistema con lo dicho por el actor. A
cada una de estas líneas o indicaciones, le podemos llamar paso.

Un buen flujo de eventos recoge con detalle la identidad de quien realiza el paso,
expresando sin ambigüedad la acción realizada. Es decir, que un buen paso ha de ser
siempre una oración con sentido completo, escrita en voz activa, iniciando con el nombre
del actor o bien del sistema que realiza la acción e indicando exhaustivamente los
elementos de información que se intercambian.

Dichas oraciones con sentido completo, sin ambigüedad y demás características ya

mencionadas, no son difíciles de redactar. Son de hecho la forma más directa de decir lo
que hay que decir. Y es que a la hora de redactar un flujo de eventos debemos evitar
recurrir a formas de redacción en prosa típicas de nuestros textos comunes. No vale
sustituir el nombre del actor por un pronombre o demostrativo que le haga referencia. A la
larga, dicha omisión del nombre del actor va a ser una fuente de ambigüedad y nos puede
traer problemas.

Si bien para quienes acostumbran a redactar con estilo, estas normas para los flujos de
eventos pueden sonar extrañas, son normas muy comunes para cuando queremos redactar
documentos de requisitos. Básicamente estamos aplicando aquí los mismos consejos que se
dan para redactar bien un requisito tradicional, del estilo “el sistema debe…” por lo que en
Internet abundan los detalles sobre este particular.

Finalmente, la prosa tiene su refugio en la descripción breve de un caso de uso; y dado que
es esta descripción breve la parte más importante del caso de uso, podemos decir que a la
final todos vamos a poder estar contentos. Quienes quieren una redacción con estilo van a
encontrar lo que buscan en la descripción breve y quienes necesitan los detalles operativos
del caso de uso lo van a encontrar en los pasos del flujo de eventos

Ejemplo de caso de uso

Considerando lo vital que es la gestión de requisitos y lo populares y útiles que son los
casos de uso, nunca esta de más intentar una explicación de la técnica. Así que supongamos
a un sistema pequeño que nos sirva de ejemplo: el teléfono de un hogar promedio. En dicho
sistema, es de interés realizar llamadas de voz, o en otras palabras, el sistema tiene entre sus
objetivos el de permitir al usuario del mismo comunicarse remotamente por medio de
conexiones de voz.

Primero hemos de identificar al actor. En este caso es claramente el operador o usuario del
teléfono. Tendremos en cuenta siempre que cada actor admite solamente cierto tipo de
comunicación, impone sus propios requisitos sobre el sistema y exige una funcionalidad
6
bajo ciertas condiciones. Pero para facilitar las cosas podemos simplemente indicarlo;
quizás incluso recurriendo a un formalismo gráfico tomado de UML.

Fig. 1 – Ejemplo sencillo de un Actor

Ahora podemos identificar cual es la actividad precisa que queremos expresar en nuestro
modelo. Digamos que estamos hablando de las llamadas de voz. Así que decimos:
“El usuario del teléfono levanta el auricular y marca el número de destino. Al completar la
secuencia de dígitos la conexión se realiza. Por medio de tonos particulares el sistema
indica el estado de error y de progreso en la conexión”.

El párrafo previo contiene la esencia de la situación de llamar por teléfono. A esta breve
descripción le llamamos Caso de Uso por cuanto describe la interacción entre un actor -el
usuario- y el sistema -el teléfono- indicando el requisito funcional que se exige al sistema.

Ahora bien, ciertamente es difícil referirse a este caso de uso diciendo cada vez el párrafo
completo. Por esto le vamos a poner un nombre y un código de identificación. Digamos que
le llamamos llamada de voz y que le colocamos el código CS-0100.

Además es claro que antes de hacer la llamada de voz es necesario que el teléfono este
colgado así que podemos pensar en una precondición: el teléfono ha de estar colgado.
Armados con estos datos, podemos construir una tabla que resuma lo que tenemos en
nuestro caso de uso:

Código: CS-0100.
Nombre: Llamada de voz.
Actores: Usuario.
Descripción: El usuario del teléfono levanta el auricular y marca el número de destino. Al
completar la secuencia de dígitos la conexión se realiza. Por medio de tonos particulares el
sistema indica el estado de error y de progreso en la conexión.
Precondición: El teléfono está colgado.
Postcondición: Ninguna.
Tabla 1 – Detalle de un sencillo Caso de Uso

Y aún más, podemos construir un atractivo diagrama con el fin de comunicar lo que hemos
hecho con los clientes.

7
Fig. 2 – Sencillo ejemplo de un Modelo de Casos de Uso

Si bien en la representación gráfica no aparecen ni la precondición ni la descripción, si en

cambio nos ha permitido indicar que el caso de uso (el ovalo) esta en el alcance del
proyecto, al haberlo colocado dentro del rectángulo que define los límites del sistema. Por
cierto, a dicho rectángulo lo llamamos sujeto en la especificación de UML.

Si en la revisión con los stakeholders identificamos que el caso de uso CS-0100 (el del
ejemplo) merece ser detallado más cuidadosamente, entonces y solo entonces, podemos
invertir algo de tiempo en la creación de los flujos de eventos. Observemos aquí, que la
línea que une al actor con el caso de uso en el modelo gráfico quiere justamente hacer
referencia al flujo de eventos.

Al flujo de eventos lo construimos como una tabla, indicando el número del paso el sujeto
que realiza la acción y el paso de información que se hace. En aquellos pasos en que
estemos hablando del sistema también vamos a indicar la operación o cálculo que este ha
de efectuar con los datos. Por otra parte, el flujo de eventos lo vamos a iniciar, casi sin
excepción, con el actor.

Flujo Principal:
Paso 1 – Usuario: Levanta el auricular.
Paso 2 – Sistema: Da el tono de marcado.
Paso 3 – Usuario: Indica el número de teléfono.
Paso 4 – Sistema: Realiza la conexión. Da tono de aviso en tanto se levanta el teléfono del
lado contrario de la conexión. Permite la conversación al hacerse efectiva la conexión.
Paso 5 – Usuario: Conversa y al finalizar esta, tranca el teléfono.
Paso 6 – Sistema: Termina la conexión.
Tabla 2 – Flujo principal del Caso de Uso

8
Claro que no siempre las llamadas de voz se corresponden con este flujo de eventos. Sin
embargo en un día feliz, cuando todo sale sin problemas, es de esta manera en que sucede.
A lo que ocurre en todos los demás casos los vamos a tratar por medio de los flujos
alternativos.

Los flujos alternativos pueden ser vistos como una forma de manejo de errores o bien,
como un medio para especificar el comportamiento del sistema en caso de un error. Siendo
así el caso, una forma de indicarlo es decir una aserción sobre un paso y la acción a tomar
cuando esta se viola. Entre las posibles acciones podríamos tener: terminar el caso de uso,
saltar a otro paso, presentar un reporte y continuar, etc.
Digamos entonces para efectos del ejemplo, que queremos especificar el comportamiento
del sistema cuando el operador a indicado un número inexistente. El siguiente flujo
alternativo trata esa situación:

Flujo alternativo: Número incorrecto

Paso 3 – El sistema: Presenta tono de error y el caso de uso termina.
Tabla 3 – Flujo alternativo del Caso de Uso

Aceptando que claramente es posible indicar tantos flujos alternativos como sean
necesarios, además de especificar post condiciones y requisitos no-funcionales
relacionados, tenemos entonces un caso de uso sencillo modelado quizás más
completamente que lo que en realidad vale la pena. Pongamos todo junto:

Código: CS-0100.
Nombre: Llamada de voz.
Actores: Usuario.
Descripción: El usuario del teléfono levanta el auricular y marca el número de destino. Al
completar la secuencia de dígitos la conexión se realiza. Por medio de tonos particulares el
sistema indica el estado de error y de progreso en la conexión.
Precondición: El teléfono está colgado.
Postcondición: Ninguna.
Diagrama:

Flujo Principal:
Paso 1 – Usuario: Levanta el auricular.
Paso 2 – Sistema: Da el tono de marcado.

9
Paso 3 – Usuario: Indica el número de teléfono.
Paso 4 – Sistema: Realiza la conexión. Da tono de aviso en tanto se levanta el teléfono del
lado contrario de la conexión. Permite la conversación al hacerse efectiva la conexión.
Paso 5 – Usuario: Conversa y al finalizar esta, tranca el teléfono.
Paso 6 – Sistema: Termina la conexión.

Flujo alternativo: Número incorrecto

Paso 3 – El sistema: Presenta tono de error y el caso de uso termina.
Tabla 4 - Caso de Uso completo

Un modelo de casos de uso es entonces una especificación de funcionalidad desde el punto

de vista de la interacción del sistema con sus actores, apoyada en la representación gráfica
para facilidad de comunicación pero constituida principalmente por texto.
De momento es todo. Mucho más se puede decir sobre los casos de uso: características
avanzadas como la relación de extensión y la relación de inclusión; pero en casi todos los
casos priva que mientras más sencillo mantengamos la especificación mejor, lo sencillo se
entiende más, y la especificación de requisitos ha de entenderse bien. Que tan sofisticado lo
hagamos no es ni de lejos, tan importante como la claridad.
Prácticas: Gestión de Requisitos
Todos los proyectos tienen requisitos que cumplir. Todos los proyectos debieran contar por
lo tanto, con una gestión profesional de dichos requisitos. Dicha gestión ha de contar con
una descripción explicita y manejable de cada requisito elicitado, agrupados según el
alcance y presentados en forma tal que sea posible contrastar en cualquier momento, el
estado del proyecto en sus planes y artefactos, contra los susodichos requisitos.

La Gestión de Requisitos ha de capturar tanto los requisitos funcionales como los no-
funcionales, así como los requisitos no técnicos, tales como las exigencias que sobre el
proceso de desarrollo se deban cumplir. Además, la Gestión de Requisitos debe contar con
medios para determinar en forma objetiva cuando un requisito a sido satisfecho y cuando en
cambio, ha sido pasado por alto. Por ultimo, es necesario también contar con medios para
elicitar nuevos detalles y resolver malos entendidos que puedan originarse.

En adición a lo anterior, dos puntos de suma importancia son: el seguimiento de los

cambios en los requisitos y el control sobre las trazas que dan fe del fiel cumplimiento de lo
requerido durante el desarrollo.

El control sobre los cambios en los requisitos demanda el mantener un buen control sobre
las expectativas del cliente, así como de haber completado correctamente la identificación
de las necesidades en etapas tempranas del proyecto. Cuando esto no se realiza
apropiadamente, surgen “requerimientos urgentes e ineludibles” en las ultimas semanas del
proyecto que lo alargan y pueden incluso, llevarlo al fracaso.

Por otro lado, el disponer de un sistema de trazas bidireccionales es necesario por cuanto en
un enfoque iterativo, los artefactos iniciales que contienen los requisitos pueden sufrir
actualizaciones en etapas posteriores, obligando a identificar los elementos del análisis y
del diseño que deben ser revisados para satisfacer aquello que ha cambiado en el requisito.

10
La ultima faceta de la Gestión de Requisitos es quizás obvia: procurar el compromiso en
torno a lo especificado. Es necesario que tanto el cliente como los restantes stakeholders del
proyecto sientan que sus necesidades han sido identificadas y que van a ser satisfechas.

Control de Calidad: Trazas

La moderna practica de la ingeniería del software se basa en la construcción de modelos
que capturen progresivamente, el avance desde los requisitos al diseño y eventualmente, a
la implementación y despliegue de la solución final. Esto representa un reto importante
desde el punto de vista de la calidad ya que ha de existir alguna manera de seguir la pista de
como se ha elaborado lo requerido a través de los múltiples modelos, hasta esa deseada
implementación ejecutable.

La solución a este reto son las llamadas Trazas. A lo largo de los modelos, mantendremos
notas y relaciones de realización de los casos de uso; de manera de seguir la pista de como
se han dado solución a lo planteado como requisito. Es de observarse que las trazas son
quizás, la única forma sistemática de comprobar que el proceso de desarrollo no ha tomado
un camino propio y terminado por desarrollar algo diferente a lo solicitado.
Entonces, para el glosario:

Trazas. Indicaciones sobre la realización de los artefactos de un proyecto; indican la forma

en que los artefactos se han elaborado respetando la información contenida en otros
artefactos, generalmente de requisitos o previos en el proceso de desarrollo.

Las trazas son pues, un artificio de control que sigue la elaboración de modelos y artefactos
a partir de lo indicado en algún otro documento. Es responsabilidad de todos en el proyecto
de asegurar el fiel y cabal cumplimiento de lo requerido, por lo que también es necesario
que todos se involucren en mantener las trazas entre los artefactos.

En lo que a los modelos se refiere, las trazas pueden adoptar la forma de un diagrama de
paquetes, que muestre las trazas como dependencias estereotipadas de UML entre los
modelos, aquí representados a su vez, como paquetes estereotipados. El siguiente diagrama
ilustra el punto:

Fig. 1 – Ejemplo de Trazas entre Modelos UML

11
Por otra parte, en cuanto a los documentos, la forma más simple es la de mantener un anexo
o apartado en cada documento, donde se indique cual documento con su número de versión
y fecha, a sido tomado como insumo y a su vez, cuales son los documentos derivados que
están en uso en el proyecto. La siguiente tabla muestra un ejemplo de esto:

Título del documento: Documento de Visión – v2.0 al 15 de mayo de 2008.

Responsable del documento: Iván Garcerant.
Documentos de insumo: Términos de Referencia – v1.0 al 20 de enero de 2008.
Documentos derivados: Modelo de Casos de Uso y Especificación de Requisitos
Suplementarios.
Tabla 1 – Ejemplo de Trazas de Documento

Lo ultimo que vale la pena comentar, es que las trazas son auditadas por el equipo de
Control de Calidad[*] (Software Quality Control – SQC) quienes se guían por estas para
comprobar el buen estado del proyecto, en tanto que el sistema de trazas es diseñado por el
equipo de Aseguramiento de Calidad[*] (Software Quality Assurence – SQA) como parte
del diseño del proceso de desarrollo.

Entonces una vez más como conclusión: Las trazas son dependencias entre los artefactos,
que indican la forma en que la información fluye por ellos, desde los requisitos hasta el
diseño y la implementación; en UML podemos indicar trazas por medio de dependencias
estereotipadas en tanto que en los documentos podemos hacer un aparte o anexo con esta
información.

12