Los Casos de Uso fueron introducidos por Jacobson en 1992 [Jacobson92]. Sin embargo, la idea de
especificar un sistema a partir de su interacción con el entorno es original de Mc Menamin y Palmer, dos
precursores del análisis estructurado, que escribieron en 1984 un excelente libro cuya lectura recomendamos
[McMenamin84]. En ese libro, se define un concepto muy parecido al del caso de uso: el evento. Para Mc
Menamin y Palmer, un evento es algo que ocurre fuera de los límites del sistema, ante lo cual el sistema debe
responder. Siguiendo con nuestro ejemplo anterior, nuestro sistema de ventas tendrá un evento “Cliente hace
Pedido”. En este caso el sistema deberá responder al estimulo que recibe procesándolo.
Sin embargo, existen algunas diferencias entre los casos de uso y los eventos. Las principales son:
1) Los eventos se centran en describir qué hace el sistema cuando el evento ocurre, mientras que los casos
de uso se centran en describir cómo es el diálogo entre el usuario y el sistema.
2) Los eventos son “atómicos”: se recibe una entrada, se la procesa, y se genera una salida, mientras que los
casos de uso se prolongan a lo largo del tiempo mientras dure la interacción del usuario con el sistema.
De esta forma, un caso de uso puede agrupar a varios eventos.
3) Para los eventos, lo importante es qué datos ingresan al sistema o salen de él cuando ocurre el evento
(estos datos se llaman datos esenciales), mientras que para los casos de uso la importancia del detalle
sobre la información que se intercambia es secundaria. Según esta técnica, ya habrá tiempo más adelante
en el desarrollo del sistema para ocuparse de este tema.
Los casos de uso combinan el concepto de evento del análisis estructurado con otra técnica de especificación
de requerimientos bastante poco difundida: aquella que dice que una buena forma de expresar los
requerimientos de un sistema es escribir su manual de usuario antes de construirlo. Esta técnica, si bien ganó
pocos adeptos, se basa en un concepto muy interesante: al definir requerimientos, es importante describir al
sistema desde el punto de vista de aquél que lo va a usar, y no desde el punto de vista del que lo va a
construir. De esta forma, es más fácil validar que los requerimientos documentados son los verdaderos
requerimientos de los usuarios, ya que éstos comprenderán fácilmente la forma en la que están expresados.
