Este documento describe conceptos clave de ingeniería de requisitos como casos de uso, actores, diagramas de casos de uso y especificaciones de casos de uso. Explica cómo modelar requisitos funcionales a través de casos de uso, incluyendo la estructuración y relaciones entre casos de uso como generalización, extensión e inclusión. También cubre temas como pre-condiciones, post-condiciones y la guía para elaborar especificaciones de casos de uso.

1. Ingeniería de Requisitos

2. Temas
 Guía para elaboración de casos de uso
 Modelo de caso de uso
 Especificación de uso
 Estructuración de caso de uso
.

4. La ingeniería de Requisitos
Ingeniería de
Requisitos
Desarrollo de
Requisitos
Gestión de
Requisitos
Inicio
Obtención /
Elicitación
Elaboración/
Modelado de
Análisis
Especificación Negociación Validación
1 2 3 4 5 6

5. Aspectos Generales
● Caso de uso
– Define un conjunto de instancias (o escenarios),
donde cada instancia es una secuencia de
acciones que un sistema realiza, produciendo un
resultado de valor observable para un actor
particular
Rational Unified Process
Artifact: Use Case

6. Aspectos Generales
● Actor (del sistema)
– Define un conjunto coherente de roles que los
usuarios del sistema pueden representar cuando
interactúan con éste.
– Una instancia de actor puede ser representada
tanto por un individuo como por un sistema externo.
Rational Unified Process
Artifact: Actor

7. Elementos de un diagrama de
caso de uso
El diagrama de casos de uso tiene los siguientes
iconos que los representan:
• Actor
• Caso de Uso
• Relaciones entre casos de uso
 Extiende (extend)
 Usa (include)

8. Caso de uso: Características
• Describe el comportamiento del sistema, para lograr una meta
de uno de los grupos de interés, llamado el actor principal; la
meta debe ser un objetivo significativo y medible para el actor
principal.
• Se puede desdoblar en diferentes escenarios.
• Puede requerir, llamados actores secundarios, cumplan ciertas
responsabilidades.
• Se inicia con un evento en particular, por lo general una acción
del actor principal.
• Termina cuando se logra o se abandona la meta, dejando al
sistema en un estado estable.
• Durante su ejecución, el sistema tiene la responsabilidad de
proteger los intereses de todos los grupos de interés.

9. Escenario
o Es una secuencia de interacciones en particular desde el inicio
hasta el final de un caso de uso, que ocurre bajo ciertas
condiciones:
 Cada interacción puede tener lugar entre el actor principal y el
sistema o entre el sistema y un actor secundario.
 Cada interacción puede, a su vez, estar compuesta por una
secuencia de interacciones.
o Cada escenario puede terminar en dos formas: cuando se logra la
meta o cuando se abandona la meta del actor principal.
o En cada caso de uso:
 Hay un escenario principal, que equivale al flujo básico.
 Pueden haber uno o más escenarios alternativos.
o Cada escenario alternativo resulta de la combinación del flujo
básico con uno o más flujos alternativos.

10. Guía para elaboración de Casos
de Uso
Contiene los pasos para la construcción del diagrama,
la especificación de los Casos de Uso (CU) y la forma
en como deben estructurarse para aprovechar las
bondades:
• Reutilización
• Modularización y
• Herencia entre CU.

11. Cuando debemos utilizar Casos de
Uso?
Los casos de uso son un tipo de requerimientos
utilizados para especificar funcionalidad.
En esencia los casos de uso describen los
intercambios entre el sistema que se está
describiendo y las personas o sistemas externos
que interactúan con el primero, por lo tanto son
muy útiles para describir funcionalidades a varios
tipos de usuarios y con muchas interfaces.

12. Para qué sirven los Casos de Uso?
Los CU establecen las bases para los protocolos de
comunicación entre aplicaciones y el diseño de las interfaces
gráficas, entre otros.
La validez de los casos de uso viene dada cuando los
usuarios e involucrados del sistema aceptan el
funcionamiento propuesto en los CU
Los casos de uso son útiles para capturar requerimientos,
ayudar a definir la arquitectura, establecer las pautas para el
diseño y las pruebas funcionales. Por lo tanto ofrecen valor
al equipo de usuarios e involucrados como a los
desarrolladores del proyecto.

13. Caso de Uso y Modelo de CU
Los casos de uso describen secuencias de acciones que
realiza un sistema y que lleva a un resultado de valor a un
actor específico.
Un modelo de CU está compuesto por dos partes, un
diagrama (gráfico) y una parte textual.

14. Actor del Sistema
Las siguientes preguntas permitirán identificar a
los actores que interactúan con el Sistema:
i. ¿Quién o qué utiliza el Sistema?
ii. ¿Qué roles toman en la interacción?
iii. ¿Quién toma información del Sistema?
iv. ¿Quién provee información al Sistema?
v. ¿En qué parte de la empresa es utilizado el
Sistema?
vi. ¿Quién inicia y termina la ejecución del
sistema?

15. Del modelo de negocio al
modelo del sistema
Modelo de Negocio Modelo del Sistema
Actor de negocio
Actor
Empleado de Negocio
Actividad en caso de uso del
negocio Caso de Uso
Entidad del negocio
Atributo de entidad del negocio Clases de Análisis

16. Diagrama de Caso de Uso
• El diagrama de CU ofrece la visión global que muestra lo que
ocurre fuera del sistema y lo que ocurre al interior del
sistema. Es decir, especifica las fronteras del sistema.
• El diagrama de CU no debe reflejar ni el flujo de control ni
el flujo de datos, sino de asociaciones que son canales de
comunicación.
• Los casos de uso reflejan las relaciones entre los actores y
los casos de uso.
• Los casos de uso no es el diseño

17. Diagrama de Caso de Uso
• Cuando la comunicación es iniciada por el actor, la relación de
comunicación contiene una flecha hacia el lado del CU.
• Si no la contiene entonces el CU es quien solicita al actor de la
interacción.
• Que un sistema invoque a un actor para alguna función solo ocurre
con el caso de actores no humanos (otros sistemas), y nunca
ocurre que el CU por sí solo invoca al actor, siempre tiene que
haber un actor que solicite su activación.

18. Casos de Uso
• Los Casos de Uso representa lo que el actor desea que
realice el Sistema.
• Los casos de uso definen una secuencia de acciones
ejecutadas por un sistema que producen un resultado
observable de valor para un actor.
• Los casos de uso, se define como: la especificación de
secuencia de acciones, incluyendo variaciones a la secuencia
y secuencia de los errores, que un sistema, subsistema o
clase realizan con la interacción de actores externos. Libro
“The UML Reference Manual” de RUMBAUGH
• Los casos de uso son siempre iniciados por un actor y
son elaborados desde el punto de vista del actor.

19. Casos de Uso
La siguiente es la lista de preguntas que permiten identificar los casos
de uso dentro de las fronteras de un sistema:
i. ¿Qué funciones del sistema son requeridas por un actor
específico?
ii. ¿El sistema guarda o recupera información? Si es así ¿Qué
actores disparan esta acción?
iii. ¿Qué ocurre cuando el sistema cambia de estado? ¿Algún actor
es notificado?
iv. ¿Algún evento externo afecta al sistema? ¿Qué notifica el sistema
respecto de estos eventos?
v. ¿El sistema interactúa con algún sistema externo?
vi. ¿El sistema genera algún reporte?
vii. ¿Cómo especificar Casos de Uso?

20. Especificaciones de
Casos de Uso
.

21. Especificación de Caso de Uso
La especificación de los casos de uso se refiere a la
explicación de cada una de las partes definidas para
lograr su descripción completa.
La especificación de los Caso de Uso se deberá
desarrollar según el formato presentado a continuación.

22. Especificación de Caso de Uso
Caso de Uso CU.#
Fuentes <Stakeholders que proporcionaron información de esta
funcionalidad>
Actor Act.# <nombre de los actores> [(<Pseudónimos>)]
Descripción <Descripción del caso de uso>
Flujo básico Descripción
Flujos alternos Descripción
Pre-condiciones Descripción del PRC
Post-condiciones Descripción de la PTC
Requisitos
Asociados
Título del requisito
Porqué se enlaza a el requisito desde este caso de
uso
Puntos de inclusión Descripción del punto de inclusión
Puntos de extensión Descripción del punto de extensión
Notas Descripción de la nota

23. Especificación CU: Formato
Caso de Uso
El nombre del CU debe comenzar por un verbo y ser lo más
corto posible, pero al mismo tiempo, describa con claridad
el CU.
El nombre del CU comienza por su identificación CU.#
donde # es el número asignado a este CU. Puede ser un
correlativo.
Fuentes
Son las personas que conocen del negocio y las que
proporcionan información para la descripción de la
funcionalidad.

24. Especificación CU: Formato
Actores
Los actores que interactúan directamente con el sistema.
Quienes inician el CU. Como los que interactúan con el
sistema luego que este ha iniciado.
Cuando se nombran los actores en la sección de actores
del CU se coloca el código asignado en la sección de
actores ejemplo Act.#.
El nombre del actor puede contener al lado una lista de
pseudónimos, estos son utilizados en el CU para describir
su funcionamiento con el empleo del pseudónimo en vez
del nombre del actor (o rol) que puede ser muy largo

25. Especificación CU: Formato
Descripción
Es un párrafo que resume el objetivo del caso de uso. Sin
dar detalles del cómo.
La descripción del caso de uso resume todo lo que el caso
de uso hace, que es el valor que da al actor (o actores).
Ejemplo:
El caso de uso permite al usuario Cliente obtener la
información sobre su estado de cuenta del Sistema de
Gestión de Clientes

26. Especificación CU: Formato
Flujo básico
El flujo básico (FB) describe los pasos que se sucederían
en el escenario del “mundo perfecto”. El flujo básico es
un camino simple, sin ramificaciones y en él suelen hacerse
una serie de presunciones, las alternativas a estos
presuntos son los flujos alternos.
Cada paso del flujo básico contiene
1. Un número de paso o flujo. Es un consecutivo que inicia
con el número 1 en el primer paso.
2. La descripción del paso. La descripción del paso contiene
el detalle de lo que se espera que ocurra en el paso.

27. Especificación CU: Formato
Flujo básico
Es obligatorio que cada paso contenga el número del paso y
la descripción.
Los pasos de los flujos básicos no contienen referencias a
los flujos alternos o flujos básicos.

28. Especificación CU: Formato
Flujos alternos
• Los flujos alternos (FA) se definen como flujos independientes, no
como subflujos, permitiendo hacer que un flujo alterno aplique de
manera global a todo el CU, o a varios flujos básicos u alternativos.
• Mantener los FA de forma plana facilita su lectura, su escritura y su
comprensión.
• Todos los FA deben indicar (en este orden):
¿Dónde comienzan? Desde donde parte este FA, puede ser un FB o
un FA.
¿Qué los dispara? Que hace que este FA inicie
¿Qué sucede? Lo que pasa cuando el FA es invocado, análogo al FB.
¿A dónde regresa? Una vez que termina de ejecutarse el flujo alterno,
¿A dónde regresa la ejecución del caso de uso?
• Los FA cuentan con un número de flujo y una descripción

29. Especificación CU: Formato
Pre-condiciones
Son elementos opcionales de los CU, cada precondición tiene:
1) Número.-Es un consecutivo.
2) La descripción puede dar detalles de cómo la condición es
evaluada, o el rango de valores que pueden ser aceptados
para la condición.
Las precondiciones no son eventos que activan el CU en el
sistema. Sin embargo son declaraciones en las cuales el caso
de uso puede comenzar.
Las precondiciones son necesariamente ciertas para que el
CU pueda comenzar, pero no suficientes. El CU sólo puede ser
comenzado por el actor cuando las precondiciones son ciertas.

30. Especificación CU: Formato
Post-condiciones
Las postcondiciones son elementos opcionales de los CU. Los
elementos y patrones para describir postcondiciones son
iguales a las precondiciones.
Las postcondiciones son importantes puesto que dan las luces
sobre las condiciones que garantizan que siempre que termine
el CU y 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 este CU aseguren que estas
condiciones se darán al salir.

31. Especificación CU: Formato
Requisitos asociados
Los requisitos son formas de enlazar los CU o
especificaciones funcionales con el resto de las
especificaciones no funcionales.
Estas especificaciones deben encontrarse en el repositorio de
requisitos con la información completa de los atributos
definidos.
Se debe especificar el número y la descripción del requisito

32. Especificación CU: Formato
Puntos de inclusión y extensión
Los puntos de inclusión son los enlaces para incluir un
funcionamiento específico del CU que es empleado por más de
un CU.
Los puntos de extensión son los enlaces que permiten
extender la funcionalidad de un CU en un punto específico de
flujo básico.

33. Especificación CU: Formato
Notas
Las notas son elementos opcionales muy importantes de los
CU pues reflejan el análisis y la comprensión del
funcionamiento del sistema, más allá de la descripción de las
interacciones entre los usuarios.
Las notas son características muy importantes de los CU
puesto que permiten capturar conocimientos propios del
sistema que no se está describiendo, que son útiles a la hora
de hacer el diseño y la implementación, sin embargo, no
representan una funcionalidad propia del CU que se está
especificando.

34. Estructuración de Casos
de Uso
.

35. Estructuración: Caso de Uso
Es un paso posterior a la construcción del modelo inicial del
modelo de CU.
La primera construcción del modelo de CU nunca incluye la
estructuración, ello ocurre producto de la especificación
cuando se comienza a ver que los casos de uso tienen
definiciones semejantes, compartidas o dependientes.
La estructuración de CU busca simplificar la explicación del
funcionamiento del sistema y es el primer acercamiento para
contemplar la reutilización y la modularización en la
definición del diagrama de clases.

36. Estructuración: Caso de Uso
La estructuración de CU consta de cuatro casos posibles que
se listan a continuación:
1. Generalización de actores
2. Generalización de casos de uso
3. Extensión de casos de uso
4. Inclusión de casos de uso

37. Estructuración: Caso de Uso
1. Generalización de actores
De A

38. Estructuración: Caso de Uso
2. Generalización de Casos de Uso
La generalización de CU, al igual que en los actores, permite
extraer factor común de dos o más casos de uso que
comparten características.
En la generalización de CU existe un CU padre (o base, o
general) y un CU hijo que es una especialización del base.
En estos casos el hijo hereda todas las características del
padre, puede agregar nuevas características, y puede
modificar (sobrescribir) características del padre excepto por
las relaciones y los puntos de extensión.

39. Estructuración: Caso de Uso
2. Generalización de Casos de Uso

40. Estructuración: Caso de Uso
3. Extensión de Casos de Uso
La extensión de CU se utiliza para agregar nuevas funcionalidades o
comportamientos a un CU.
Cuando se extiende un CU, el CU base indica el punto en los que se hace
la extensión.
Los puntos de extensión en la especificación del CU debe incluir, un título
que es el nombre del CU que se extiende, y un texto que indica:
1) El paso del flujo básico que se extiende con esta funcionalidad o grupo
de funcionalidades
2) Opcionalmente la condición que establece que esta funcionalidad esté
disponible para el actor, y
3) La acción que realiza el actor para que el flujo de eventos se curse
hacia el CU extendido.

41. Estructuración: Caso de Uso
3. Extensión de Casos de Uso

42. Estructuración: Caso de Uso
4. Inclusión de Casos de Uso
La inclusión de CU se utiliza para extraer como factor común una serie
de pasos que son repetidos en diferentes CU, permitiendo incluirlos
múltiples veces sin necesidad de volverlos a escribir.
Los puntos de inclusión se emplean en los CU base para indicar el punto
exacto donde se incluye su funcionamiento, la interpretación es que una vez
que el punto de inclusión es alcanzado, el control pasa al CU de inclusión,
luego que este termina, la ejecución retorna al CU base. Por lo tanto el flujo
nunca se inicia por el CU de inclusión solo, a diferencia de lo que ocurren
en las generalizaciones.
El error más común es que un include se encuentre solo en un CU.

43. Estructuración: Caso de Uso
4. Inclusión de Casos de Uso