Es decir, es un texto formal que describe cómo se debe comportar el sistema en una situación determinada. Ese comportamiento que es necesario incluir en el sistema que estamos desarrollando es lo que se denomina Requerimiento. Por lo tanto, un Caso de Uso es una descripción textual de un requerimiento.

La técnica de Casos de Usos es una técnica fundamental en la actividad de Gestión de Requerimientos de un proyecto de software.

Nota: Conviene insistir en que se trata de una descripción textual. Un texto escrito formalmente y no un gráfico. Otra cosa es el Diagrama de Casos de Usos que sí es una representación visual de los Casos de Uso de un sistema y las relaciones entre ellos. Pero tiene una utilidad infinitamente inferior a la de los Casos de Uso (textuales).

¿Cuál es su Objetivo?

El Caso de Uso nos ayuda a comprender el comportamiento que el usuario necesita del sistema. Lo hace relacionando cada actor con los objetivos que quiere conseguir. Esta relación se establece en base al proceso de trabajo del actor/es con el sistema.

Vocabulario

Escribir buenos Casos de Uso es complejo. Antes de ver cómo hacerlo, definamos algunos conceptos:

• SuC: Sistema bajo Consideración (System under Consideration).
• Interesado: Cualquier persona, física o jurídica, con intereses en el SuC.
• Actor: Interesado que inicia una acción con el sistema para conseguir un objetivo.

¿Cómo se Elabora?

En su versión más informal, el Caso de Uso consiste en un texto que describe el comportamiento esperado del sistema ante una acción de un actor. Lo más importante, y también lo más complicado a la hora de elaborar un Caso de Uso es expresarlo correctamente, de forma clara y sencilla y prescindiendo de los aspectos técnicos concretos, especialmente del interfaz de usuario.

Los programadores no destacamos por nuestra cdapacidad de expresión escrita, ni siquiera por la oral. Pero es lo que necesitamos para escribir buenos Casos de Uso. Además, los Casos de Uso no son descripciones técnicas del comportamiento del sistema, sino que deben centrarse en los objetivos e intenciones que cada actor persigue con el uso del sistema.

Aunque los Casos de Uso informales compuestos exclusivamente por un texto descriptivo (bien escrito) son útiles en las primeras fases de un proyecto, antes de lanzarnos a diseñar necesitaremos una descripción completa y formal del comportamiento esperado del sistema. Para ello se utiliza el modelo detallado de Casos de Uso. Este modelo, que también es textual, varía de una organización a otra, pero básicamente debe incluir la siguiente información:

Nombre: Nombre del Caso de Uso que debe comenzar con un verbo.

Ámbito: Ámbito al que se refiere el Caso de Uso. Habitualmente será SuC (System under Consideration), pero también es posible utilizar esta técnica para registrar Casos de Uso de Negocio.

Nivel: El nivel del Caso de Uso puede ser uno de los siguientes valores:

• Objetivo de Usuario: El Caso de Uso describe el objetivo de un actor del sistema.
• Global: El Caso de Uso describe globalmente el uso del sistema o de una parte del mismo.
• Detalle: El Caso de Uso detalla una parte concreta de otro Caso de Uso (o compartida por varios casos).

Pongamos un ejemplo para aclarar cada valor: Un Caso de Uso denominado "Consultar el Plan de Ejecución de un Proyecto" será un caso a nivel de "Objetivo de Usuario". Un Caso de Uso que describa el uso general de un sistema, será Global ("el cliente introduce su tarjeta y opera con el cajero electrónico"). Y, como ejemplo de caso de detalle tenemos el login; el login no persigue ningún objetivo de usuario (nadie quiere hacer login), pero es un requerimiento compartido por varios casos de uso del sistema.

Actor: Alguien o algo con comportamiento ante el sistema que inicia una acción para conseguir un objetivo.

Interesados e Intereses: Cualquier persona física o jurídica que tiene intereses en el sistema.

Precondiciones: Condiciones previas requeridas por el caso.

Condiciones de Éxito: Lo que debe cumplirse para considerar que el caso se ha ejecutado con éxito.

Escenario Prinicipal: Secuencia de actuación incondicional que conduce al éxito del caso.

Escenarios Alternativos: También llamados Extensiones. Otras secuencias de actuación, que pueden conducir al éxito o al fracaso del caso.

Requerimientos Especiales: Requerimientos especiales, no funcionales, del caso.

Tecnología y Formatos: Condiciones tecnológicas especiales de entrada y salida de datos y formatos de datos.

Frecuencia: Frecuencia con que se ejecuta el caso (diario, mensual, varias veces al minuto, concurrente...).

Temas Pendientes: Aspectos del caso que todavía están sin resolver.

Otros: Pues eso.

Nota: El objetivo del Caso de Uso es que sea fácil de entender. No hace falta detallar obviedades. Escribiremos únicamente lo que merece la pena.

Nota: Los Casos de Uso se escriben desde la perspectiva de los actores, no son descripciones técnicas. Así que no deben describir cómo se harán las cosas (aquí un SQL, aquí derivamos de esta clase...) sino que deben centrarse en los objetivos que persiguen los actores y cómo los consiguen (o no).

Es el momento de ver un ejemplo.