4.

Ingeniería de Requerimientos

LABORATORIO N° 04

Diagrama de Casos de Uso

DISEÑO Y DESARROLLO DE SOFTWARE

PROGRAMA DE FORMACIÓN REGULAR
 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 2 de 12

CODIGO DEL CURSO:

Alumno(s) Nota

Grupo
Ciclo
Fecha de entrega
 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 1 de 12

I.- OBJETIVOS:

 Documentar los casos de uso.

 Elaborar el diagrama de casos de uso.

II.- SEGURIDAD:
Advertencia:
En este laboratorio está prohibida la manipulación del
hardware, conexiones eléctricas o de red; así como la
ingestión de alimentos o bebidas.

III.- FUNDAMENTO TEÓRICO:

 Revisar las presentaciones vistas en Clase.

IV.- NORMAS EMPLEADAS:

 No aplica

V.- RECURSOS:

 En este laboratorio cada alumno trabajará con un equipo con Windows 7.

VI.- MARCO TEÓRICO:

Proceso de Ingeniería de requerimientos
 Estudio de viabilidad
 Análisis
 Especificación
 Validación
 Gestión

Gestión de requerimientos
 Proceso para gestionar y controlar cambios en los requerimientos SW de un sistema.

Proceso de desarrollo de requisitos

 Objetivo: Crear y mantener un documento de requerimientos del sistema
 Define el conjunto estructura de actividades para obtener y mantener la especificación de
requerimientos
 El proceso de desarrollo (ingeniería) de requerimientos comprende (en general) 4 etapas:
o Identificación o captura de requerimientos
o Análisis (y negociación) de requerimientos
o Especificación o documentación de requerimientos
o Validación de requerimientos
 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 2 de 12

Estudio de viabilidad
Decide si es viable desarrollar el sistema, es decir responde a las preguntas:
 ¿Contribuye a los objetivos de la organización?
 ¿Es factible con la tecnología actual en costo y tiempo?
 ¿Puede integrarse con otros sistemas de la organización?

Captura y análisis: El equipo trabaja con los usuarios finales para determinar:
 El dominio de la aplicación
 Los servicios a ofrecer
 Rendimiento esperado
 Restricciones

Herramientas y técnicas de análisis de requerimientos

Cuando se necesite Se deberá
Modelar el negocio Combinar entre mapa de relaciones y/o mapa de
procesos.
Entender el alcance Combinar entre diagramas de contexto, tablas de
del proyecto evento-respuesta y/o políticas de negocio.
Adicionar detalle a los Combinar o variación de: tabla de actores, casos
requerimientos de de uso, mapas de diálogo, modelo de datos,
usuario diagramas de estado y/o reglas de negocio.
Negociar la Priorizar requerimientos.
importancia entre los
requerimientos

o Diagrama de casos de uso: Es una forma de diagrama de comportamiento UML mejorado. Los
diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras que los
conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de
casos de uso. El diagrama de casos de uso puede representar uno o varios casos de uso. Hay
que tener en cuenta que cada caso de uso representa una funcionalidad del Software que se va a
construir.

El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema
en desarrollo, además de la forma, tipo y orden en cómo los elementos interactúan (operaciones o
casos de uso).

Los elementos de un diagrama de casos de uso son:

 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 3 de 12

- Caso de uso
- Actor
- Comunicación
- Entorno del sistema

Figura 1. Componentes de Diagrama de Casos de Uso

Figura 2. Ejemplo 1 Diagrama de Casos de Uso

 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 4 de 12

Cada caso de uso se describe utilizando plantillas en lenguaje natural:

Caso de uso
Actores
Resumen
Pre-condiciones
Post-condiciones
Incluye
Extiende
Hereda de
Flujo de eventos
Actor Sistema

Como ejemplo:

Caso de uso Reservar libro

Actores Socio
Resumen El socio puede solicitar la reserva de un libro
para su posterior préstamo, a partir de una
fecha determinada
Pre-condiciones El socio no tiene ninguna reserva
Post-condiciones El socio tiene una reserva y el libro tiene una
nueva reserva a partir de una fecha
Incluye
Extiende
Hereda de
Flujo de eventos
Actor Sistema
Evento 1. El socio Evento 2. El sistema comprueba que el socio
solicita la reserva no tiene reserva.
(código, libro, fecha). Evento 3. El sistema comprueba que el libro
está libre para la fecha solicitada.
Evento 4. El sistema solicita confirmación de
Evento 5. El socio la reserva.
confirma la reserva

Evento 6. El sistema realiza la reserva.

Las relaciones (o dependencias) entre casos de uso son:

- Inclusión
- Extensión
- Herencia

Las relaciones entre los actores son:

- Herencia
 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 5 de 12

Relaciones entre casos de uso – Inclusión: Un caso de uso A depende de un caso de uso B
para completar su objetivo. El caso de uso A no puede estar completo hasta que el caso de uso B
no esté completo. En este caso, A incluye (include) B.

Figura 3. Relación de Inclusión

Siempre que se ejecute “Baja Socio”, se ejecutará “Buscar Socio”.

Relaciones entre casos de uso – Extensión: Un caso de uso B extiende a un caso de uso A, si
en la descripción de A figura una condición cuyo cumplimiento origina la ejecución de todos los
eventos que aparecen descritos en B. Esta relación es opcional.

Figura 4. Relación de Extensión

 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 6 de 12

Relaciones entre casos de uso – Herencia: Se definen casos de uso “hijos” y casos de uso
“padres”, donde el “hijo” va a tener cosas en común con el “padre”, pero también tendrán tareas
específicas que solamente el “hijo” puede hacer. A este tipo de relación se le conoce también
como “generalización”.

Figura 5. Relación de Herencia

Relaciones entre actores:

Actor antecesor

Actores
descendientes

Figura 6. Relación de Herencia entre Actores

 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 7 de 12

Como ejemplo se tiene el siguiente:

Figura 7. Diagrama de Casos de Uso

VI.- METODOLOGÍA PARA EL DESARROLLO DE LA TAREA:

 El desarrollo del laboratorio es Individual.

VII.- PROCEDIMIENTO:
Nota:
Las secciones en cursivas son demostrativas, pero sirven para que usted pueda instalar las herramientas de
desarrollo en un equipo externo.

1. Lea el siguiente texto:

Se desea desarrollar un nuevo sistema para la gestión de los préstamos de libros de una biblioteca. En
el sistema se incluirán exclusivamente el funcionamiento de las peticiones y devoluciones de libros.
Petición de libros:
Un usuario puede realizar una petición de uno o más libros a la biblioteca. Para ello, es necesario
presentar el carnet de usuario de la biblioteca y una ficha en la que se detallan los libros pedidos. Puede
haber varios tipos de préstamo (préstamo sala, colaborador, proyecto fin carrera, doctorado) en función
de los cuales el usuario puede disponer de los ejemplares durante un período de tiempo específico,
como se indica en la siguiente tabla:

El día de la petición

COLABORADOR Una semana

PROYECTO FIN Quince días

CARRERA
 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 8 de 12

DOCTORADO Un mes

Una vez entregados el carnet y la ficha, el sistema comprobará y aceptará la petición de los libros
solicitados, siempre que pueda satisfacer la petición, es decir, cuando haya ejemplares disponibles. Si se
acepta la petición, se actualiza el número de unidades de los libros de la biblioteca y se guarda la ficha
de préstamo.
Devoluciones de libros:
Un usuario no puede realizar más peticiones hasta que no haya efectuado todas las devoluciones de la
petición anterior. El usuario, para hacer la petición, necesita el carnet, que no se le entrega hasta que no
haya devuelto todos los libros. Sí puede hacer una devolución parcial de los libros. Cuando un usuario
realice una devolución, el sistema actualizará el stock de libros y comprobará la fecha de devolución de
cada ejemplar para estudiar, en el caso que la devolución se haga fuera de tiempo, la imposición de una
sanción que tiene un coste de X unidades monetarias por cada ejemplar y días de retraso en la
devolución. En este caso, la sanción se mite cuando el usuario entrega el último ejemplar.
El bibliotecario se encargará de las altas y bajas de los libros de la biblioteca.

2. En base al caso anterior, desarrolle lo siguiente:

a. Identificación y especificación de requerimientos funcionales y no funcionales del
sistema, de acuerdo a la plantilla IEEE 830

REQUERIMIENTOS FUNCIONALES
Identificación del RF01
requerimiento:
Nombre del Registro de Usuarios
Requerimiento:
Características: Debe permitir el registro de usuarios t asignarles un carne de biblioteca cuando
no tengan libros pendientes de devolución.
Descripción del El sistema permite registrar usuarios y consultar por cada uno d estos.
requerimiento:
Requerimiento  RNF01
NO funcional:  RNF02
Prioridad del requerimiento:
Alta

Identificación del RF02

requerimiento:
Nombre del Peticion de Libros
Requerimiento:
Características: Los usuarios deben poder realizar peticiones de libros. Para ello, deben
presentar su carnet de usuario y una ficha que detalle los libros
solicitados.
Descripción del El sistema da la facilidad de realizar peticiones de libros con anticipación
requerimiento:
Requerimiento
NO funcional:
Prioridad del requerimiento:
Alta

Identificación del RF03

requerimiento:
Nombre del Tipos de prestamos
Requerimiento:
Características: El sistema debe ofrecer diferentes tipos de préstamo (sala, colaborador, proyecto
fin carrera, doctorado) con períodos de tiempo específicos para cada uno.
Descripción del El sistema tiene la capacidad de ofrecer prestamos
 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 9 de 12

requerimiento:
Requerimiento
NO funcional:
Prioridad del requerimiento:
Alta

Identificación del RF04

requerimiento:
Nombre del Verificacion de Disponibildiad
Requerimiento:
Características: Antes de aceptar una petición, el sistema debe comprobar la disponibilidad de
los ejemplares solicitados en la biblioteca.
Descripción del El sistema tiene la capacidad de ofrecer prestamos
requerimiento:
Requerimiento
NO funcional:
Prioridad del requerimiento:
Alta

Identificación del RF05

requerimiento:
Nombre del Actualizacion de Stock
Requerimiento:
Características: Cuando se acepta una petición, el sistema debe actualizar el número de unidades
de los libros en la biblioteca.
Descripción del El sistema esta en constante cambio ya que si se agota el stock pueden
requerimiento: hacer una petición.
Requerimiento
NO funcional:
Prioridad del requerimiento:
Alta

Identificación del RF06

requerimiento:
Nombre del Ficha de prestamos
Requerimiento:
Características: El sistema debe guardar una ficha de préstamo que registre la información
relevante de la petición, incluyendo el tipo de préstamo, la fecha de solicitud y la
fecha de devolución estimada.
Descripción del El sistema lo tiene todo registrado y guardado en una ficha de préstamo.
requerimiento:
Requerimiento
NO funcional:
Prioridad del requerimiento:
Alta

Identificación del RF07

requerimiento:
Nombre del Devoluciones Parciales
Requerimiento:
Características: Los usuarios deben poder realizar devoluciones parciales de libros prestados.
Descripción del El sistema concede el permiso de ejecutar devoluciones de los libros
requerimiento: que fueron prestados.
Requerimiento
NO funcional:
Prioridad del requerimiento:
Alta
 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 10 de 12

Identificación del RF08

requerimiento:
Nombre del Sanciones por retraso
Requerimiento:
Características: El sistema debe calcular sanciones en caso de devoluciones fuera de
tiempo y aplicar un coste por cada ejemplar y días de retraso, si
corresponde. La sanción se aplica al entregar el último ejemplar.
Descripción del El sistema dispone de un regulamientos en el cual se aplicang
requerimiento:
Requerimiento
NO funcional:
Prioridad del requerimiento:
Alta

Identificación del RNF01

requerimiento:
Nombre del Seguridad
Requerimiento:
Características: Permite guardar la información de los usuarios y que sea segura.
Descripción del El sistema debe garantizar la seguridad de la información de los usuarios
requerimiento: y de las transacciones de préstamo, incluyendo la protección de datos
personales.
Prioridad del requerimiento:
Alta

Identificación del RNF02

requerimiento:
Nombre del Rendimiento
Requerimiento:
Características: El sistema debe ser capaz de manejar un número significativo de
peticiones de préstamo y devolución de libros de manera eficiente.
Descripción del Permite que el sistema trabaje de manera efectiva para satisfacer las
requerimiento: necesidades
Prioridad del requerimiento:
Alta

Identificación del RNF03

requerimiento:
Nombre del Disponibilidad
Requerimiento:
Características: El sistema esta disponible mientras este en funcionamiento la
biblioteca.
Descripción del El sistema debe estar disponible para los usuarios durante las horas de
requerimiento: funcionamiento de la biblioteca.
Prioridad del requerimiento:
Alta
 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 11 de 12

b. Elaborar un diagrama de caso de uso

c. En base al diagrama anterior, documentar los casos de uso

Puede hacer uso de cualquier herramienta que vea por conveniente.

 Nro. DD-106
Laboratorio de Ingeniería de Requerimientos Página 12 de 12

OBSERVACIONES Y CONCLUSIONES
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________
________________________________________________________________________________________