Guía para la elaboración y presentación de casos de uso

Objetivo de la Guía

El objetivo de este documento es proporcionar una guía para elaborar especificaciones de requerimientos funcionales bajo el marco de metodologías tradicionales a través de casos de uso, con el propósito de brindar un estándar que permita asegurar que la documentación contenga la necesidad clara del usuario y se oriente su solución a la satisfacción de ésta.

Alcance del Documento

El documento está dirigido tanto a líderes funcionales como a líderes técnicos y a otros funcionarios o contratistas internos o externos que se encuentren involucrados dentro de las actividades propias del ciclo de desarrollo de los sistemas de información.

Términos y Definiciones Clave

• Caso de Uso. Un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas.
• Criterios de aceptación. Son un conjunto preciso y bien definido de condiciones que un producto que se va a adquirir o construir debe satisfacer en el momento de su entrega, para que sea aceptado.
• Especificación de requerimientos. Una especificación puede ser vista como un contrato entre usuarios y desarrolladores de software, que define el comportamiento funcional deseado del artefacto de software y otras propiedades de éste, tales como performance, confiabilidad, etc.
• FA. Corresponde a la abreviatura de flujo alterno.
• FB. Corresponde a la abreviatura de flujo básico.

Introducción a los Casos de Uso

Los casos de uso son una técnica para la especificación de requerimientos funcionales propuesta inicialmente en [Jacobson et al. 1992] y que actualmente forma parte de la propuesta de UML [Booch et al. 1999]. Fueron propuestos como un método para documentar las funcionalidades de un sistema existente o planeado a partir de cómo éste será usado. Un caso de uso es la descripción de una secuencia de interacciones entre el sistema y uno o más actores en la que se considera al sistema como una caja negra y en la que la que los actoresobtienen resultados observables. En conjunto, los casos de uso describen completamente la funcionalidad del sistema.

La combinación de los casos de uso y actores de un sistema forman el modelo de casos de uso el cual ayuda al cliente, a los usuarios, y a los desarrolladores a llegar a un acuerdo sobre cómo utilizar el sistema. Cada tipo de usuario del sistema se representa mediante un actor que define un rol de utilización del sistema. Los actores modelan el entorno del sistema, y los casos de uso especifican el sistema.

Diagrama de Casos de Uso

Los casos de uso tienen una representación gráfica en los denominados diagramas de casos de uso [Booch et al. 1999]. En estos diagramas, los actores se representan en forma de pequeños monigotes o stick, si el actor es un sistema se puede representar ya sea por medio de un rectángulo o una figura con el estereotipo "sistema" y los casos de uso se representan por elipses contenidas dentro de un rectángulo que representa al sistema, el nombre del caso de uso se registra al interior de la elipse. La participación de los actores en los casos de uso se indica por una flecha entre el actor y el caso de uso que apunta en la dirección en la que fluye la información y corresponde a una relación de asociación. Los diagramas de casos de uso sirven para proporcionar una visión global del conjunto de casos de uso de un sistema, así como de los actores y los casos de uso en los que éstos intervienen. Adicionalmente los diagramas de casos de uso también reflejan las relaciones entre los mismos casos de uso.

1 Caso de uso A Actor 1 Caso de uso B Actor 2 K Caso de uso C Sistema

Estructura y Elementos de un Caso de Uso

Los casos de uso son fragmentos de funcionalidades que el sistema ofrece para aportar un resultado de valor para sus actores. Para cada caso de uso debe detallarse su flujo de sucesos donde se describe como interactúa el sistema con los actores cuando se lleva a cabo una acción.

Identificación de Actores

El primer paso para escribir un caso de uso es definir un conjunto de actores que estarán involucrados en la historia. Los actores son personas u otros sistemas que interactúan con el sistema cuyos requerimientos se están describiendo [Scheneider y Winters 1998] con el propósito de completar una tarea. Con una definición más formal, un actor es cualquier cosa que se comunique con el sistema o producto y que sea externo a éste. Todo actor tiene uno o más objetivos cuando utiliza el sistema. Es importante notar que un actor y un usuario final no necesariamente son lo mismo. Un usuario normal puede tener varios papeles diferentes cuando usa el sistema, mientras que un actor representa una clase de entidades externas que sólo tiene un papel en el contexto del caso de uso. Siempre que hay una interacción entre el sistema y una persona o un sistema externo, una abstracción de esta persona o sistema define un actor del sistema.

Existen algunas preguntas claves en la identificación de actores de un sistema.

• ¿Quiénes o qué inicia eventos con el sistema?
• ¿Quiénes proveen, utilizan o eliminan información?
• ¿Quiénes soportan y mantienen el sistema?
• ¿A quiénes les interesa cierto requerimiento?
• ¿ Con qué otros sistemas interactúa?
• ¿ Existe algún dispositivo de hardware o software adicional que interactúe con el sistema?
• Si ocurre un evento dentro del sistema ¿Quién debería ser informado?

Se debe tener en cuenta que el nombre del actor debe expresar claramente su papel. Los buenos nombres de los actores describen sus responsabilidades de forma implícita según el contexto, por ejemplo: tarjeta-habiente, pasajero, asegurado, entre otros.

Identificación y Especificación de Casos de Uso

Una vez identificados los actores, es posible identificar y especificar los casos de uso y para ello se sugieren algunas preguntas:

• ¿Cuáles son los objetivos de los actores?
• ¿ Qué precondiciones deben existir antes de comenzar la historia?
• ¿Qué tareas o funciones principales son realizadas por el actor?
• ¿ En qué orden deben ejecutarse las acciones?
• ¿Qué excepciones deben considerarse al describir el caso de uso?
• ¿Cuáles variaciones son posibles en la interacción del actor y que generen caminos alternos?
• ¿Qué información del sistema adquiere, produce o cambia el actor?
• ¿Tendrá que informar el actor al sistema acerca de cambios en el ambiente externo?
• ¿Qué información o postcondiciones desea obtener el actor del sistema?
• ¿Quiere el actor ser informado sobre cambios inesperados?

Documentación de un Caso de Uso

La documentación de un caso de uso más allá de la plantilla o formato utilizado debe incluir:

• Identificador y nombre descriptivo. El identificador debe comenzar con CU00X donde X corresponde al No. consecutivo asignado al caso y debe ser único dentro del sistema. El nombre descriptivo suele coincidir con el objetivo que los actores esperan alcanzar al realizarlo. No se debe confundir este objetivo con los objetivos del sistema. El objetivo que los actores esperan alcanzar al realizar un caso de uso es de más bajo nivel, por ejemplo, registrar un nuevo socio o consultar los pedidos pendientes. El nombre del caso de uso debe iniciar con un verbo en infinitivo, evitando el uso de verbos ambiguos como "hacer", "analizar" o "comprender" y en su lugar hacer uso de verbos de proceso como "aprobar", "notificar" o "consultar.
• Descripción. Corresponde a un texto breve donde se refleje el propósito del caso de uso. Debe indicar la acción que da inicio a su ejecución y en caso de estar relacionado con otros casos de uso, se deberán indicar dichos casos de uso.
• Actores. El actor se describe con un nombre y una breve descripción. El nombre debe ser un sustantivo singular que represente el rol que el actor juega en el sistema. Ejemplo, Estudiante: Cualquier estudiante activo de la universidad que tiene la posibilidad de inscribirse a los cursos ofrecidos para el semestre actual. Adicionalmente deberá tenerse en cuenta como guía de calidad para la definición de actores que:
  • Cada actor debe participar por lo menos en un caso de uso.
  • Evitar la definición excesiva de actores. Los actores que jueguen roles similares pueden unirse en uno solo.
  • Usar nombres intuitivos. Todos los interesados en un proyecto deben poder entender los nombres de los actores.
• Precondición. En este campo se expresan en lenguaje natural las condiciones necesarias para que se pueda realizar el caso de uso. Estas condiciones se establecen bien sobre el entorno en el que opera el sistema, y que por lo tanto quedarán fuera de su control o bien sobre el estado del propio sistema. El CU sólo puede ser comenzado por el actor cuando las precondiciones sean ciertas y como no son evaluadas en el flujo básico (FB) ni en los flujos alternos (FA), se asumen como ciertas. Para identificar las precondiciones de un caso de uso se pueden formular las siguientes preguntas:
  • ¿ En qué estado debe encontrarse el sistema para que el CU pueda iniciar?
  • ¿ Qué elementos deben estar presentes para que el CU pueda iniciar?
  • ¿ Cuáles son los supuestos asumidos para iniciar el CU?
  • ¿ Qué restricciones se deben cumplir para iniciar el CU por parte de los actores?
• Reglas de Negocio. Su identificador debe comenzar con RN0X donde X corresponde al No. consecutivo único asignado Incluyen políticas corporativas, regulaciones de gobierno, estándares industriales, prácticas contables, entre otros. Estas reglas no son en sí requerimientos de software porque estas existen fuera de los límites de cualquier especificación del sistema de software.
• Flujo básico. Se denota como FB y su nombre debe iniciar con un verbo en infinitivo siguiendo las mismas recomendaciones dadas para nombrar el caso de uso. Contiene la secuencia normal de interacciones del caso de uso que se deben cumplir para lograr su objetivo o el escenario feliz del proceso. En cada paso, un actor o el sistema realiza una o más acciones. Se espera que, después de realizar el último paso, el caso de uso termine. Para representar estructuras condicionales complejas se puede recurrir a añadir información aparte; por ejemplo, una tabla de decisión, y referenciarla desde el paso correspondiente. En el caso de estructuras iterativas, su uso puede evitarse con un uso cuidadoso del lenguaje natural; por ejemplo, para indicar que se procesan todos los artículos de un pedido se puede optar por frases como "el sistema procesa todos los artículos del pedido introducidos por el usuario". Cada paso debe contener el número del paso que corresponde, el primer paso debe indicar la acción que da inicio a la ejecución del caso de uso y el último paso debe indicar que el caso de uso finaliza.
• Flujo alterno. Se denotan como FA, su identificador debe comenzar con FA0X donde X corresponde al No. consecutivo único asignado y su nombre debe iniciar con un verbo en infinitivo siguiendo las mismas recomendaciones dadas para nombrar el caso de uso. Representan los diferentes escenarios o variantes que pueden darse a nivel de negocio diferentes al escenario principal descrito en el flujo básico. Deben contener información que indique desde donde parte el FA, cuál es la acción que da inicio al FA, los pasos de la ejecución que realiza y una vez que termine su ejecución deberá indicar a qué paso regresa la ejecución del caso de uso en el flujo principal o básico. Al enumerar sus pasos se sugiere la estructura X.X, donde la primera X corresponde al número del paso del FB desde donde se invocó el FA y la segunda X corresponde al consecutivo dado. Ejemplo 5.1 donde 5 corresponde al paso del FB y 1 al consecutivo que se sigue en el FA.
• Postcondición. En este campo, se expresan en lenguaje natural las condiciones que se deben cumplir después de la terminación normal del caso de uso. Al igual que en el caso de las precondiciones, las postcondiciones se pueden establecer tanto sobre el entorno del sistema como sobre el estado del propio sistema. Las postcondiciones son importantes puesto que guían acerca de las condiciones que garantizan que siempre que termine el CU el sistema queda en un estado válido y los datos inherentes (en caso de existir) se encuentran consistentes. Las postcondiciones son igualmente útiles para verificar que las pruebas que se realicen sobre el CU aseguren que estas condiciones se cumplan. Para identificar las postcondiciones de un caso de uso se pueden formular las siguientes preguntas:
  • ¿ En qué estado debe quedar el sistema luego que termina el CU?
  • ¿ Qué debe garantizarse cuando termine el CU para que el sistema no registre información inconsistente?
  • ¿ Cuáles son las únicas condiciones válidas en las que puede acabar una ejecución del CU?
• Criterios de Aceptación. Los criterios de aceptación son una serie de condiciones que validan la implementación de un requerimiento y son fundamentales porque ayudan a orientar la implementación de la solución de forma correcta y a identificar los sets de pruebas funcionales mínimos con resultado exitoso que la solución debe asegurar para aprobar su paso a producción.