PROVINCIA DE BUENOS AIRES

DIRECCIÓN GENERAL DE CULTURA Y EDUCACIÓN

DIRECCIÓN DE EDUCACIÓN SUPERIOR
INSTITUTO SUPERIOR DE FORMACIÓN TÉCNICA N° 172

TECNICATURA SUPERIOR EN ANÁLISIS DE SISTEMAS

PRÁCTICAS PROFESIONALIZANTES I
UNIDAD 3: HERRAMIENTAS DE MODELADO
UNIDAD TEMÁTICA: CASOS DE USO Y REQUERIMIENTOS

PROFESORES:
JAVIER POZZO
DIEGO VIOLA
PROVINCIA DE BUENOS AIRES
ÍNCIDE
1. INGENIERIA DE REQUISITOS .......................................................................................................................................... 3

2. REQUISITOS ...................................................................................................................................................................... 3

3. REQUISITOS DE SOFTWARE .......................................................................................................................................... 3

4. ELICITACIÓN ..................................................................................................................................................................... 3

5. TIPOS DE REQUISITOS .................................................................................................................................................... 4

5.1. EJEMPLOS DE REQUISITOS FUNCIONALES/NO FUNCIONALES ........................................................................ 4

6. POSIBLES ACTORES EN LOS REQUISITOS DE INGENIERÍA ...................................................................................... 4

7. CASOS DE USOS .............................................................................................................................................................. 5

7.1. DIAGRAMA DE CASO DE USO .................................................................................................................................. 5

7.2. ACTORES DE LOS CASOS DE USOS ...................................................................................................................... 6

7.3. COMO ENCONTRAR LOS ACTORES DE UN SISTEMA .......................................................................................... 6

7.4. CASOS DE USOS Y ESCENARIOS ........................................................................................................................... 6

7.5. RELACIONES DE INCLUDE ....................................................................................................................................... 6

7.6. RELACIONES DE EXTEND ........................................................................................................................................ 8

7.7. GENERALIZACIÓN ..................................................................................................................................................... 9

7.8. CASOS DE USO Y COLABORACIONES ................................................................................................................... 9

7.9. PRE Y POST CONDICIONES ..................................................................................................................................... 9

7.10. LOS CASOS DE USO Y LAS FASES EN EL PROCESO UNIFICADO INTERATIVO E INCREMENTAL .............. 9

8. PROBLEMAS FRECUENTES QUE SUCEDEN AL MOMENTO DE ESCRIBIR CASOS DE USO ................................ 10

8.1. LOS LÍMITES DEL SISTEMA NO ESTÁN DEFINIDOS O SON INCONSISTENTES .............................................. 10

8.2. LOS NOMBRES DE LOS CASOS DE USO ESTÁN ESCRITOS DESDE EL PUNTO DE VISTA DEL SISTEMA .. 10

8.3. LOS NOMBRES DE LOS ACTORES SON INCONSISTENTES .............................................................................. 11

8.4. MUCHOS CASOS DE USO....................................................................................................................................... 11

8.5. LAS RELACIONES ENTRE ACTORES Y CU SE ASEMEJAN A UNA TELARAÑA. ............................................... 11

8.6. LA ESPECIFICACIÓN DEL CASO DE USO ES MUY EXTENSA ............................................................................ 12

8.7. LA ESPECIFICACIÓN DEL CASO DE USO ES CONFUSA .................................................................................... 12

8.8. EL CU NO DESCRIBE CORRECTAMENTE EL REQUISITO FUNCIONAL ............................................................ 13

8.9. EL CLIENTE NO ENTIENDE LOS CASOS DE USO ................................................................................................ 13

8.10. LOS CASOS DE USO NUNCA SE TERMINAN ...................................................................................................... 14

BIBLIOGRAFÍA .......................................................................................................................¡Error! Marcador no definido.

1. INGENIERIA DE REQUISITOS
La ingeniería de Requisitos direcciona el proceso de elicitación (inducir), definición, modelado, análisis,
especificación y validación de los requisitos de un sistema y de su software, basado en un enfoque sistemático, separando
el "qué" del "cómo" del diseño.

(Figura número 1, elaboración propia)

2. REQUISITOS
Los requisitos son los Flujo de trabajo fundamentales cuyo propósito esencial es orientar el desarrollo hacia el
sistema correcto. El conjunto de todos los requisitos forma la base para el desarrollo del sistema o el componente de
Sistema.

Esto se lleva a cabo mediante la descripción de los requisitos del sistema de forma tal que se pueda llegar a un
acuerdo entre el cliente (usuario) y los desarrolladores del sistema, acerca de lo que el sistema debe hacer y lo que no.
De aquí la importancia de comprender en forma clara la necesidad del usuario.

Un requerimiento es una condición o capacidad a la que el sistema (siendo construido) debe conformar.

3. REQUISITOS DE SOFTWARE
Un requisito de software es la capacidad que tendrá el sistema para resolver un problema o alcanzar un objetivo
que servirá a los usuarios de este para la toma de decisiones.

Una capacidad del software que debe ser reunida o poseída por un sistema o componente del sistema para
satisfacer un contrato, especificación, estándar u otra documentación formal. En síntesis, un requisito de software es una
descripción completa del comportamiento del sistema que se va a desarrollar y que le servirá de guía para los
desarrolladores.

4. ELICITACIÓN
Es el proceso de adquirir (“eliciting”) [sonsacar] todo el conocimiento relevante necesario para producir un modelo
de los requerimientos de un dominio de problema. Tiene como objetivo entender el dominio del problema en particular.
 Para poder obtener los requisitos funcionales de cualquier sistema debemos acceder a personas o materiales que
nos permitirán recopilar los mismos. Existen técnicas para obtener estos requisitos como:

• Entrevista de comienzo y final abierto.

• Entrevistas estructuradas.
• Brainstorming (Lluvia de Ideas).
• Prototipos.
• Escenarios.
• Observación.

5. TIPOS DE REQUISITOS
Existen varios tipos de requisitos como lo son:

• Requisitos de Usuarios: Necesidades que los usuarios expresan verbalmente.

• Requisitos del Sistema: Son los componentes que el sistema debe tener para realizar determinadas tareas.
• Requisitos Funcionales: Son los servicios que el sistema debe proporcionar. Estos requisitos especifican una
acción que debe ser capaz de realizar el sistema, sin considerar restricciones físicas. Describen la funcionalidad o
los servicios que se espera proveerá el sistema.
• Requisitos no funcionales: Son restricciones que afectan al sistema. Especifican restricciones físicas sobre un
requisito funcional (rendimiento, plataforma, fiabilidad). No se refieren directamente a las funciones específicas que
entrega el sistema, sino a las propiedades emergentes de éste como la fiabilidad, la respuesta en el tiempo y la
capacidad de almacenamiento. Son restricciones a nivel hardware y redes.

5.1. EJEMPLOS DE REQUISITOS FUNCIONALES/NO FUNCIONALES

Sistema de venta de Música Online
Requisitos Funcionales
• Los usuarios comprarán créditos para adquirir
canciones.
• El sistema debe registrar la información de los
usuarios y los créditos que poseen.
• Los usuarios buscarán las canciones que deseen y
las pagarán con créditos.
• El sistema debe almacenar información sobre las
canciones que se pueden adquirir y su precio en
Créditos.
Requisitos NO Funcionales
• El sistema debe cumplir las disposiciones
recogidas en la Ley Orgánica de Datos Personales
y en el Reglamento de medidas de seguridad.
• El sistema no debe tardar más de cinco segundos
en mostrar los resultados de una búsqueda. Si se
supera este plazo, el sistema detiene la búsqueda
y muestra los resultados encontrados.

6. POSIBLES ACTORES EN LOS REQUISITOS DE INGENIERÍA

• Usuario Final: Son personas que utilizarán el sistema en desarrollo. Quienes utilicen las interfaces y manuales de
usuario.
• Usuario Líder: Son las personas que comprenden el ambiente del sistema y el dominio del problema. Proporcionan
información al equipo técnico (detalles de los requerimientos, interfaces, etc).
• Personal de mantenimiento: Son quienes administran los cambios y mejoran los procesos.
• Analistas y Programadores: Son los responsables del desarrollo del producto.
 • Personal de pruebas: Son quienes elaboran y ejecutan los planes de pruebas.
• Administradores de proyectos: Personas que planifican, organizar y controlan un proyecto informático. Gestiona
todos los recursos necesarios para logran el fin perseguido.

7. CASOS DE USOS
• Los casos de uso son una técnica para la especificación de requisitos funcionales propuesta inicialmente por
Jacobson en 1992.
• Los casos de uso presentan una ventaja sobre la descripción textual de los requisitos funcionales.
• Los casos de uso son, ante todo, requisitos funcionales.
• Esta técnica es ampliamente aceptada y existen múltiples propuestas para su realización.
• Los casos de uso se utilizan para documentar los requerimientos funcionales de un sistema desde el punto de vista
de los usuarios que responden a la pregunta: ¿Qué se supone que el sistema debe hacer para los usuarios?
• Los casos de uso se han vuelto muy populares para establecer el esquema de la lógica de negocios. En el desarrollo
se representa la secuencia de eventos que suceden entre el actor y el sistema como si fuera una caja negra, donde
se muestra el “qué” y no el “cómo”. Los casos de usos guían el proceso de desarrollo.
• Es importante aclarar que los Casos de Uso no son “orientados a objetos”.

7.1. DIAGRAMA DE CASO DE USO

El valor de los casos de uso está en una descripción detallada (no en el dibujo).

(Figura número 2, elaboración propia)

• Describe tanto lo que hace el actor como lo que hace el sistema cuando interactúa con él.
• Están acotados al uso de una determinada funcionalidad, claramente diferenciada, del sistema.
• Un caso de uso realiza cierto trabajo cuyo efecto es tangible para un actor.

(Figura número 3, elaboración propia)

7.2. ACTORES DE LOS CASOS DE USOS
Un actor es alguien o algo que interactúa con el sistema (una persona, una organización, un programa o sistema
de hardware o software). Un actor estimula al sistema con algún evento o recibe información del sistema y este siempre
externo al mismo. Un actor cumple un rol definido por Ejemplo un Cliente, un Banco o un empleado.

Tipos de Actores:

• Actores primarios: Usuarios (humanos o no) que participan del caso de uso y cuyo objetivo o intención está
directamente relacionado con el objetivo del caso de uso. Si el caso de uso culmina exitosamente y se alcanza
el estado de la postcondición, la intención del actor primario queda satisfecha. Generalmente son los actores que
inician el caso de uso.
• Actores secundarios: Usuarios (humanos o no) que participan de un caso de uso proveyendo un servicio que les
es solicitado. Deben participar del caso de uso para que éste pueda llevarse a cabo, pero su intención no está
directamente relacionada con el objetivo del caso de uso. No inician el caso de uso pero reciben o aportan
información en algún punto del flujo principal o alternativo.

7.3. COMO ENCONTRAR LOS ACTORES DE UN SISTEMA

Una buena técnica para encontrar posibles actores es responder las siguientes preguntas:

• ¿Quién usa el sistema?

• ¿Quién instala o mantiene al sistema?
• ¿Qué otros sistemas utilizan al sistema?
• ¿Quién recibe información del sistema?
• ¿Quién le provee información al sistema?

7.4. CASOS DE USOS Y ESCENARIOS

• Los casos de uso describen un conjunto de secuencias, no una única secuencia. Es conveniente separar el flujo
principal de los flujos alternativos.
• Por ejemplo el caso de uso Contratar Empleado podría tener variantes contratar externos (Escenario más frecuente),
traslado dentro de la misma empresa, contratar extranjeros Cada una de estas variantes se puede expresar en una
secuencia diferente.
• Cada secuencia específica del caso de uso se denomina Escenario.
• Un escenario es una secuencia específica de acciones entre los actores y el sistema (es una instancia de un caso
de uso).

7.5. RELACIONES DE INCLUDE

Una relación de inclusión entre casos de uso especifica que un caso de uso base incorpora explícitamente el
comportamiento de otro caso de uso en el lugar establecido en el caso de uso base. Una relación de inclusión se representa
como una dependencia. Una dependencia es una relación de uso que declara que un caso de uso utiliza información y
servicios de otro.
 El caso de uso B es parte esencial del CU A

(Figura número 4, elaboración propia)

Las ventajas de esta asociación son:

• Las descripciones de los casos de uso son más cortas y se entienden mejor.
• La identificación de funcionalidad común puede ayudar a descubrir el posible uso de componentes ya existentes en
la implementación.

Las desventajas son:

• La inclusión de estas relaciones hace que los diagramas sean más difíciles de leer, sobre todo para los clientes.

(Figura número 5, elaboración propia)

¿Cómo se utiliza el include?

• Cuando un caso de uso incorpora explícitamente el comportamiento de otro caso de uso.

• Para evitar repeticiones de descripción de flujos de eventos.
• Cuando distintos casos de uso poseen un conjunto de eventos con la misma funcionalidad, estos eventos se pueden
factorizar en un nuevo caso de uso, el cual se relacionará con los anteriores mediante la relación de inclusión.
• Cuando un caso de uso es muy extenso y difícil de leer.
• Se entiende que algunos de los pasos en una situación dentro de un Caso de Uso son los mismos que los de otro
Caso de Uso, y en lugar de listar los mismos pasos, tan sólo indicamos el Caso de Uso de donde provienen.

Cuando debemos usar “Include”:

 • Al incorporar explícitamente el comportamiento de otro caso de uso.
• Para evitar repeticiones de descripción de flujos de eventos.
• Cuando distintos eventos se pueden factorizar en un nuevo caso de uso.
• Cuando un caso de uso es muy extenso y difícil de leer.

7.6. RELACIONES DE EXTEND

Una relación de extensión entre casos de uso especifica que un caso de uso base incorpora implícitamente el
comportamiento de otro caso de uso en el lugar especificado por el caso de uso base que extiende. Se representa mediante
una dependencia. La funcionalidad de un caso de uso incluye un conjunto de pasos que ocurren sólo en algunas
oportunidades. La excepción consiste en interrumpir el caso de uso B y pasar a ejecutar otro caso de uso A.

El caso de uso B (caso de uso base) incluye en su funcionalidad (opcionalmente) el caso uso A.

(Figura número 6, elaboración propia)

• Extiende su funcionalidad gracias al agregado implícito de comportamiento.

• Depende de puntos de extensión y una condición.
• ¿Quién nombra a quién?.
• Desde el punto de vista del usuario: los dos flujos parecen uno.
• El CU base normalmente no depende del caso de uso que extiende para cumplir su objetivo.

Se entiende que se agregan pasos a un Caso de Uso existente, y esto se hace creando un nuevo Caso de Uso, que
enriquece al existente, pero no lo modifica.

Cuando debemos usar “Extend”:

• Cuando se desea describir una variación del comportamiento normal de un caso de uso.
• Para conjuntos de eventos que son ejecutados solamente en ciertos casos.
• Cuando la sección de flujos alternativos de un caso de uso se torna muy grande y difícil de leer, es conveniente crear
nuevos casos de usos a partir de estos flujos alternativos que extiendan al caso de uso original.

(Figura número 7, elaboración propia)

7.7. GENERALIZACIÓN
En un diagrama de casos de uso también pueden mostrarse generalizaciones (relaciones de herencia) para
mostrar que diferentes elementos están relacionados como tipos de otros. Son aplicables a actores o casos de uso, pero
para estos últimos la semántica es muy similar a las relaciones “extend”.

(Figura número 8, elaboración propia)

7.8. CASOS DE USO Y COLABORACIONES

• Un caso de uso captura el comportamiento esperado del sistema sin tener que especificar cómo se implementará.
• Es importante separar el análisis (que especifica un comportamiento) de la implementación (que especifica cómo se
lleva a cabo ese comportamiento).
• De todas maneras, un caso de uso deberá implantarse y esto lo hará mediante una sociedad de clases (incluyendo
su estructura estática y dinámica) que se modela como una colaboración.
• Una realización especifica un contrato entre el caso de uso y su colaboración.

(Figura número 9, elaboración propia)

7.9. PRE Y POST CONDICIONES

• Precondiciones: Establecen lo que siempre debe cumplirse antes de comenzar un caso de uso. No se prueban en
el caso de uso, se asumen que son verdaderas.
• Postcondiciones: Establecen qué debe cumplirse cuando el caso de uso se completa con éxito.

7.10. LOS CASOS DE USO Y LAS FASES EN EL PROCESO UNIFICADO INTERATIVO E INCREMENTAL
• En la fase de inicio se reconocen las mayoría de los casos de uso, pero no su descripción detallada.
• En la fase de elaboración, se refinan en las sucesivas iteraciones.
• En la fase de construcción se escriben casos de uso menores.
• En la fase de transición no se describen casos de uso Metodología.
(Figura número 10, elaboración propia)

8. PROBLEMAS FRECUENTES QUE SUCEDEN AL MOMENTO DE ESCRIBIR CASOS DE USO

8.1. LOS LÍMITES DEL SISTEMA NO ESTÁN DEFINIDOS O SON INCONSISTENTES
Síntoma: No se entiende “el sistema” Mirando el modelo de casos de uso no queda del todo claro que hay dentro y que
hay fuera.

Cura: Ser explicito acerca del contexto, dibujar el diagrama de contexto aunque sea sencillo, identificar el mismo acorde
a su descripción. Documentar y entender alcances, límites y objetivos.

(Figura número 11, elaboración propia)

8.2. LOS NOMBRES DE LOS CASOS DE USO ESTÁN ESCRITOS DESDE EL PUNTO DE VISTA DEL SISTEMA
Síntomas:

• Los nombres describen lo que el sistema hace, en lugar de describir lo que el actor tiene como objetivo.
 • Los pasos de la especificación describen la funcionalidad interna en lugar de la interacción a través de la frontera
del sistema.
• El modelo parece un diagrama de flujos.

Cura:

• Nombrar los casos de uso desde la perspectiva del actor.

• Enfocarse en lo que el Sistema tiene que hacer para lograr los objetivos, en lugar de como lo va a hacer.
• Optimizar la descomposición functional y prestart atención al as relaciones (extend, include, use) cuando no hay
actores.

Ejemplo: Procesar la orden de entradas Vs. Reserva de entradas

8.3. LOS NOMBRES DE LOS ACTORES SON INCONSISTENTES

Síntomas: Diferentes Nombres describen el mismo Rol, ya que muchas veces los requisitos vienen de diversas fuentes.
Cuanto más grande es el problema, más personas colaboran en la solución.

Cura: Establecer un glosario al principio del proyecto y utilizarlo para describir los actores, donde se especifique el Nombre
del Actor, su significado, y los posibles alias del mismo.

8.4. MUCHOS CASOS DE USO

Síntomas: El modelo de Casos de Uso tiene un gran número de CU.

Cura:

• Unir CU triviales que sean fragmentos de otros CU Reales.

• Eliminar CU que describan puramente procesos “internos”, con respecto a los límites del Sistema.

8.5. LAS RELACIONES ENTRE ACTORES Y CU SE ASEMEJAN A UNA TELARAÑA.

Síntomas (casos de abuso):

• Demasiadas Relaciones entre Actores y CU.

• Un actor interactúa con cada CU / Un CU interactúa con cada actor.

Cura:

• Examinar los actores para descubrir distintos niveles de abstracción para encontrar los más explícitos, los cuales
participarían en un conjunto más limitado de tareas.
(Figura número 12, elaboración propia)

• Cuando se arrastran prácticas de métodos estructurados.

• Un modelo tiene muchas inclusiones y extensiones a veces innecesarias.
• No hay que hacer descomposición funcional sino representar de forma gráfica las cosas que el usuario podrá hacer
en el sistema.
• No hay que representar navegabilidad de funciones por medio de casos de uso.

Imaginar un botón “consultar promociones” dentro de un proceso de venta.

(Figura número 13, elaboración propia)

8.6. LA ESPECIFICACIÓN DEL CASO DE USO ES MUY EXTENSA

Síntomas:

• Demasiadas Relaciones entre Actores y CU.

• Un actor interactúa con cada CU / Un CU interactúa con cada actor.

Cura:

• Definir casos de uso más específicos y definidos con el fin de bajar la granularidad de los pasos.
• Quitar los pasos que describan funcionamiento interno (de implementación).
• Volver a escribir el caso de uso centrado en la interacción esencial.

8.7. LA ESPECIFICACIÓN DEL CASO DE USO ES CONFUSA

Síntomas:

• El CU carece de Contexto,“no cuenta una historia”.

• Un actor interactúa con cada CU / Un CU interactúa con cada actor.
• Los pasos se ven como un programa de computadora.

Cura:

• Especificar donde el CU es relevante.

• Reescribir la secuencia centrado en las interacciones esenciales.
 • Romper los flujos donde exista la palabra “si” en flujos alternativos, dejando el flujo principal más fácil de entender y
más corto.
• No describir los algoritmos con el CU (usar arboles de decisión, tablas de decisión, pseudocódigo, etc).
• Asegurarse que ningún paso especifique implementación.

8.8. EL CU NO DESCRIBE CORRECTAMENTE EL REQUISITO FUNCIONAL

Síntomas

• Las relaciones entre Actores y CU no describen que puede hacer quien con el Sistema.
• Se confunden los casos de uso CRUD, mezclando en muchas oportunidades creación y edición dentro de un mismo
caso de uso.

Cura:

• Asegurarse que cada actor asociado a un CU este autorizado para llevarlo a cabo.

(Figura número 14, elaboración propia)

8.9. EL CLIENTE NO ENTIENDE LOS CASOS DE USO

Síntomas

• El cliente no sabe nada de CU, pero se le ha dado un documento funcional para su aprobación.
• Los casos de Uso no cuentan una historia.
• La organización de los CU no coincide como el cliente piensa el problema.
• La especificación está escrita en lenguaje técnico y específico.
• El cliente odia los CU.

Cura:

• Enseñar lo suficiente para entender cada documento funcional.

• Agregar información necesaria para que sea una historia. Escribir contexto.
• Escribir en vocabulario del cliente.
 • Entregar la documentación que el cliente quiere, aunque se usen CU para elicitar y documentar requisitos
funcionales.

8.10. LOS CASOS DE USO NUNCA SE TERMINAN

Síntomas:

• Los CU deben cambiar con cada cambio de la UI.

• Demasiados flujos alternativos posibles.
• Requisitos desconocidos.

Cura:

• Desacoplar detalles de la interfase de usuario en la especificación.

• No poner diseño en los CU.
• Definir bien el alcance y contextualizar los CU con otros.

8. DIAGRAMA DE CONTEXTO

Permite determinar las fronteras del sistema:

(Figura número 15, elaboración propia)