Ingeniería de

Pregrado
Sistemas

Ingeniería de Software
Sesión 3: Gestión de los Requerimientos en
la construcción del software
 AGENDA Ingeniería de
Pregrado
Sistemas

Agenda

1. Gestión de requerimientos: IR
2. Modelos de casos de uso (cont)
i. Actores
ii. Casos de uso
iii. Diagrama de casos de uso
3. Requerimientos funcionales (Dominio) y
no funcionales
 Ingeniería de
Pregrado
Sistemas

Ingeniería de Requerimientos
● Entender los requerimientos de una solución basada en software es una de
las tareas mas difíciles para un Ing. de Software
● Debe adaptarse a las necesidades del proceso, proyecto, producto y
gente que hace el software
● Provee de un mecanismo apropiado para entender:
● Qué quiere el cliente

● Analizar sus necesidades

● Valorar la factibilidad de construcción

● Negociar una solución razonable

● Especificar de manera no ambigua una solución

● Validar la especificación

● Administrar los requerimientos conforme se transforman

Referencia: libro de Pressman
 Ingeniería de
Pregrado
Sistemas

Tareas de la Ingeniería de Requerimientos

Extracción
● Actividades involucradas en el descubrimiento de los requerimientos del
sistema
● Los analistas de requerimientos deben trabajar junto al cliente para
descubrir:
● El problema que el sistema debe resolver
● Las diferentes funciones que el sistema debe prestar
● Las restricciones que se pueden presentar, etc.
● Es importante, que la extracción sea efectiva, ya que la aceptación del
sistema dependerá de cuan bien éste satisfaga las necesidades del cliente
 Ingeniería de
Pregrado
Sistemas

Tareas de la Ingeniería de Requerimientos

Análisis
● Se enfoca en descubrir problemas con los requerimientos del sistema
identificados hasta el momento

● Usualmente se hace luego de hacer un bosquejo inicial del documento de

requerimientos

● Se leen los requerimientos, se conceptúan, se investigan, se intercambian

ideas con el resto del equipo, se resaltan los problemas, se buscan
alternativas y soluciones

● Se van fijando reuniones con el cliente para discutir los requerimientos

 Ingeniería de
Pregrado
Sistemas

Tareas de la Ingeniería de Requerimientos

Especificación
● Se documentan los requerimientos acordados con el cliente, en un nivel
apropiado de detalle

● En la práctica, esta etapa se va realizando conjuntamente con el análisis,

es el "pasar en limpio" el análisis realizado previamente

● Se aplican técnicas y/o estándares de documentación, como la notación

UML (Lenguaje Unificado de Modelado ), estándar para el modelado
orientado a objetos, basado en los casos de uso
 Ingeniería de
Pregrado
Sistemas

Tareas de la Ingeniería de Requerimientos

Validación
● Su objetivo es ratificar los requerimientos

● Verificar todos los requerimientos que aparecen en el documento

especificado, para asegurarse que representan una descripción, por lo
menos, aceptable del sistema que se debe implementar

● Consiste en verificar que los requerimientos sean consistentes y que estén

completos
 Ingeniería de
Pregrado
Sistemas

Tareas de la Ingeniería de Requerimientos

● El proceso de ingeniería de requerimientos es un conjunto estructurado

de actividades, mediante las cuales se obtiene, se valida y se logra dar un
mantenimiento adecuado al documento de especificación de
requerimientos, que es el documento final, de carácter formal, que se
obtiene de este proceso

● No existe un proceso único que sea válido de aplicar en todas las

organizaciones

● Cada organización debe desarrollar su propio proceso de acuerdo al tipo

de producto que se esté desarrollando, a la cultura organizacional, y al
nivel de experiencia y habilidad de las personas involucradas en la
ingeniería de requerimientos
 Ingeniería de
Pregrado
Sistemas

Técnicas de la Ingeniería de Requerimientos

● Entrevistas: lo mas común

● Talleres: implicaciones cruzadas

● Forma de contrato: llenar formularios

● Objetivos medibles: determinar los objetivos críticos del funcionamiento y establecer formas
de medir el progreso en el desarrollo

● Prototipos: muestra, de funcionalidad limitada, de cómo sería el producto final, permite

feedback con el cliente-usuario

● Casos de uso: técnica para documentar posibles requerimientos, graficando la relación del
sistema (caja negra) con los usuarios u otros sistemas

● Especificación de requisitos del software: descripción completa del comportamiento del

sistema a desarrollar. Incluye un conjunto de casos de uso que describen todas las
interacciones que se prevén que los usuarios tendrán con el software y también contiene los
requerimientos no funcionales.
 Ingeniería de
Pregrado
Sistemas

Modelo de Requerimientos
 Ingeniería de
Pregrado
Sistemas

Modelo de Casos de Uso

 Ingeniería de
Pregrado
Sistemas

Modelado de Casos de Uso

● Un caso de uso especifica un comportamiento deseado del

sistema
● Representan los requisitos funcionales del sistema

“Un caso de uso especifica un conjunto de secuencias de

acciones, incluyendo variantes, que el sistema puede
ejecutar y que produce un resultado observable de valor
para un particular actor.” (Definición en
UML)

● Describen qué hace el sistema, no cómo lo hace

 Ingeniería de
Pregrado
Sistemas

Modelado de Casos de Uso

● Partes de un caso de uso

○ Conjunto de secuencias de acciones; cada secuencia
representa un posible comportamiento del sistema

○ Actores, roles que pueden jugar los usuarios

○ Variantes: versiones especializadas, un cu que extiende a otro

o un cu que incluye a otro

○ Un caso de uso realiza un trabajo tangible.

 Ingeniería de
Pregrado
Sistemas

Ejemplo de Caso de Uso

actor caso de uso

Gestionar Préstamos
Responsable
Prestamos

asociación
 Ingeniería de
Pregrado
Sistemas

Actores

Un actor representa un conjunto coherente de roles

que juegan los usuarios de los casos de uso al
interaccionar con el sistema.

● Roles jugados por personas, dispositivos, u otros

sistemas.
● El tiempo puede ser un actor (“procesos iniciados
automáticamente por el sistema”).
● No forman parte del sistema.
 Ingeniería de
Pregrado
Sistemas

Actores

● Un usuario puede jugar diferentes roles.

● En la realización de un caso de uso pueden intervenir
diferentes actores.
● Un actor puede intervenir en varios casos de uso.
● Identificar casos de uso mediante actores y eventos
externos.
● Un actor necesita el caso de uso y/o participa en él.
 Ingeniería de
Pregrado
Sistemas

Actores

● Dos tipos de actores:

○ Principal:

Requiere al sistema el cumplimiento de un objetivo

○ Secundarios:

El sistema necesita de ellos para satisfacer un objetivo

 Ingeniería de
Pregrado
Sistemas

Escenarios y Casos de Uso

● Un caso de uso describe un conjunto de

secuencias de interacciones entre actores y el
sistema (escenarios): flujo principal y flujos
alternativos o excepcionales.

● Un escenario es una instancia de un caso de uso

● Un escenario es una historia particular de uso de un

sistema.

● Escenarios principales vs. Escenarios secundarios

 Ingeniería de
Pregrado
Sistemas

Propiedades de los casos de uso

● Son iniciados por un actor con un objetivo en mente

y es completado con éxito cuando el sistema lo
satisface.
● Puede incluir secuencias alternativas que llevan al
éxito y fracaso en la consecución del objetivo.
● El sistema es considerado como una “caja negra” y
las interacciones se perciben desde fuera.
● El conjunto completo de casos de uso especifica
todas las posibles formas de usar el sistema, esto es
el comportamiento requerido.
 Ingeniería de
Pregrado
Sistemas

Descripción de un caso de uso

● Son documentos de texto, no son diagramas.
○ El modelado de casos de uso consiste en escribir texto, no
en dibujar diagramas.
● Describir el flujo de eventos
○ Texto estructurado informal

○ Texto estructurado formal (plantillas)

○ Pseudocódigo

○ Notaciones gráficas: diagramas de secuencia

● Debe ser legible y comprensible para un usuario no

experto.
● Debe indicar: actores, flujos principal y excepcionales.
 Ingeniería de
Pregrado
Sistemas

Diagrama de un caso de uso

 Ingeniería de
Pregrado
Sistemas

Descripción de un caso de uso: textual

Realizar Venta (en un Terminal de Punto de Venta

(TPV))

Actor Principal: Cajero

Flujo Principal: Un cliente llega al TPV con un conjunto de artículos. El
Cajero registra los artículos y se genera un ticket. El cliente paga en
efectivo y recoge los artículos.

1. El cliente llega al TPV con los artículos.

2. El cajero registra el identificador de cada artículo.
3. El sistema obtiene el precio de cada artículo y añade la información a la
transacción de venta.
4. Al acabar el cajero indica la finalización de la introducción de artículos.
 Ingeniería de
Pregrado
Sistemas

Descripción de un caso de uso: textual

Realizar Venta (en un Terminal de Punto de Venta o TPV)

5. El sistema calcula el total de la compra y lo muestra.

6. El cajero le dice al cliente el total.
7. El cliente realiza el pago.
8. El cajero registra la cantidad de dinero recibida.
9. El sistema muestra la cantidad a retornar al cliente y genera un recibo.
10. El cajero deposita el dinero recibido y saca la cantidad a devolver que
entrega al cliente junto al ticket de compra.
11. El sistema almacena la compra completada.
12. El cliente recoge los artículos comprados.
 Ingeniería de
Pregrado
Sistemas

Ejemplo diagrama de casos de uso

Reservar Libro Prestamo Revista

Profesor

Prestamo Libro Devolver Revista

Socio

Devolver Libro Actualizar Catalogo

Bibliotecario

Extender Prestamo
Consultar Socio
 Ingeniería de
Pregrado
Sistemas

Ejemplo diagrama de casos de uso

Registrar venta
 Ingeniería de
Pregrado
Sistemas

Organización de Casos de uso

● Tres tipos de relaciones:

○ Generalización

■ Un CU hereda el comportamiento y significado de otro.

○ Inclusión

■ Un CU base incorpora explícitamente el comportamiento

de otro en algún lugar de su secuencia.

○ Extensión

■ Un CU base incorpora implícitamente el comportamiento

de otro CU en el lugar especificado indirectamente por
este otro CU
 Ingeniería de
Pregrado
Sistemas

Ejemplo

Extensión
«extend»
Hacer Pedido
Hacer Pedido Urgente
(establecer
prioridad)
«include»
Comprobar clave
Inclusión
Validar Usuario
Generalización
«include»

Seguir Pedido Examinar retina

 Ingeniería de
Pregrado
Sistemas

Relación de inclusión

● Permite factorizar un comportamiento en un caso

de uso aparte y evitar repetir un mismo flujo en
diferentes casos de uso.
● Ejemplo:
Hacer Pedido:
Obtener y verificar el número de
pedido;
Incluir “Validar usuario”;
Recoger los ítem del pedido del
usuario;
…
 Ingeniería de
Pregrado
Sistemas

Relación de extensión

● El caso de uso base incluye una serie

de puntos de extensión.
● Sirve para modelar:
○ la parte opcional del sistema, o

○ un subflujo que sólo se ejecuta bajo ciertas condiciones.

 Ingeniería de
Pregrado
Sistemas

Relación de extensión

● Ejemplo:
Hacer Pedido:

Incluir “Validar usuario”;

Recoger los ítem del pedido del usuario;

Establecer prioridad: punto de extensión

Enviar pedido para ser procesado según

la prioridad.
 Ingeniería de
Pregrado
Sistemas

Obtención de casos de uso

1) Identificar los usuarios del sistema.

2) Encontrar todos los roles que juegan los usuarios y
que son relevantes al sistema.
3) Para cada rol identificar todas las formas
(objetivos) de interactuar con el sistema.
4) Crea un caso de uso por cada objetivo.
5) Estructurar los casos de uso.
6) Revisar y validar con el usuario.
 Ingeniería de
Pregrado
Sistemas

Plantilla usecases.org (Larman)

● Resumen
● Actores Principales y Secundarios
● Personas involucradas e Intereses
● Precondiciones
● Poscondiciones
● Escenario Principal (Flujo Básico)
● Extensiones (Flujos Alternativos)
● Requisitos de Interfaz de Usuario
● Requisitos No-Funcionales
● Cuestiones Pendientes
 Ingeniería de
Pregrado
Sistemas

Caso de uso “Realizar Venta”

● Resumen: Un cliente llega al TPV con un conjunto de artículos. El

cajero registra los artículos y se genera un ticket. El cliente paga en
efectivo y recoge los artículos.
● Actores: Cajero (principal), Sistema (secundario)
● Personal Involucrado e Intereses:

○ Cajero: quiere entradas precisas, rápidas y sin errores de pago.

○ Compañía: quiere registrar transacciones y satisfacer clientes.

○ ...

● Precondición: El cajero se identifica y autentifica.

● Postcondiciones: Se registra la venta. Se calcula el impuesto.
Se actualiza la contabilidad y el inventario.
 Ingeniería de
Pregrado

Caso de uso “Realizar Venta”

Sistemas

● Escenario Principal (Flujo Básico):

1. El cliente llega al TPV con los artículos.

2. El cajero inicia una nueva venta.

3. El cajero introduce el identificador de cada artículo.

4. El sistema registra la línea de venta y presenta descripción del

artículo, precio y suma parcial.

El cajero repite los pasos 3 y 4 hasta que se indique.

5. El sistema presenta el total.

6. El cajero le dice al cliente el total a pagar .

7. El cliente paga y el sistema gestiona el pago.

8. El sistema registra la venta completa y actualiza el inventario.

9. El sistema presenta recibo.

 Ingeniería de
Pregrado
Sistemas
Caso de uso “Realizar Venta”
● Extensiones (Flujos Alternativos):
A1: Identificador no válido
La secuencia A1 comienza en el punto 3.
4. El sistema señala el error y rechaza la entrada.
El escenario vuelve al punto 3.
A2: El cliente pide eliminar un artículo de la compra.
La secuencia A2 puede ocurrir entre los puntos 3-6.
1. El cajero introduce identificador a eliminar.
2. El sistema actualiza la suma.
El escenario continúa en el punto 6.
A3: Pago en efectivo
La secuencia A3 ocurre en el punto 7.
1. El cajero introduce la cantidad entregada por el cliente.
2. El sistema muestra cantidad a devolver.
El escenario continúa en el punto 8.
…
 Ingeniería de
Pregrado
Sistemas

Caso de uso “Realizar Venta”

● Requisitos de Interfaz de Usuario:

- Pantalla táctil en un monitor de pantalla plana.
- El texto debe ser visible a un metro de distancia.
● Requisitos No-Funcionales:
- El identificador del producto podría ser cualquier esquema
de código de barras UPC, EAN-8, EAN-13, ...
- El tiempo de respuesta para autorizar el pago con la tarjeta
de débito o de crédito es de 30 segundos.
● Cuestiones Pendientes:
- Explorar cuestiones de recuperación de accesos a servicios
remotos.
- ¿Qué adaptaciones son necesarias en un TPV para
diferentes negocios?
 Ingeniería de
Pregrado
Sistemas

Utilidad de los casos de uso

● Hay consenso en considerar casos de uso como

esenciales para capturar requisitos y guiar el
modelado.
● Pero todavía existe mucha confusión sobre
cómo usarlos.

○ ¿Cuál es el número de casos de uso apropiado en un

proyecto?

○ ¿Qué casos de uso hay en el sistema?

 Ingeniería de
Pregrado
Sistemas

Granularidad

● Diferente granularidad

○ Casos de uso del negocio

■ Procesos de Negocio: Objetivo estratégico de la empresa

■ Ej. Vender productos

○ Casos de uso del sistema

■ Objetivo de un usuario

■ Ej. Realizar una compra

○ Casos de uso de inclusión

■ Forman parte de otro, son como subfunciones

■ Ej. Buscar, Validar, Login

 Ingeniería de
Pregrado
Sistemas

Casos de Uso

Casos de uso
Modelado del
Negocio

Casos de uso de
Requerimientos

Casos de uso
Análisis y Diseño
 Ingeniería de
Pregrado
Sistemas

Recomendaciones

● Especificar casos de uso no es una actividad de dibujar

diagramas sino de escribir con el detalle necesario el flujo
principal y los flujos alternativos: “centrado en la escritura
en vez del dibujo”

● El objetivo inicial es identificar los actores y a partir de sus

objetivos encontrar los casos de uso, ya que el diagrama de
casos de uso es una ayuda visual

● Los actores deben interactuar con el sistema

 Ingeniería de
Pregrado
Sistemas

Recomendaciones

● No incluir como caso de uso las operaciones CRUD sobre un objeto

de negocio (alta, consulta, borrado, actualización). CRUD es el
acrónimo de Crear, Obtener, Actualizar y Borrar (Create, Retrieve,
Update y Delete en inglés)

● La excepción es si se trata de operaciones relevantes para el sistema,

como “Registrar Cliente” en un sistema de venta por Internet

● Cuidado con el empleo de la relación “include”

¡NO HACER UNA DESCOMPOSICION FUNCIONAL!

● Los casos de uso sólo consideran los requisitos funcionales del

proyecto, hay que añadir los no-funcionales
 Ingeniería de
Pregrado
Sistemas

Requerimientos Funcionales y No Funcionales

 Ingeniería de
Pregrado
Sistemas

Entrevista con Directivos

Encontrar los requerimientos funcionales y no funcionales y desarrolle el modelo casos de uso de sistemas.

El Gerente de Servicios en las entrevista describió los requisitos que debería tener el nuevo sistema.

R1. El encargado de Cuenta tiene la posibilidad de registrar al cliente en el catalogo.

R2. El Encargado de Cuenta Tiene la posibilidad de registrar las cartas de aceptación o rechazo en el sistema.

R3. Nuestro Sistema deberá ser instalado en nuestro servidor Web que manejara la seguridad de acceso para los
clientes y los empleados.

R4. El Empleado de Inscripción de Cliente debe actualizar estado de la carta al momento de entregarla, los datos a
ingresar son fecha y hora de recepción.

R5. El Cliente debe tener la posibilidad de Consultar su estado en el sistema.

R6. El cliente debería tener una pantalla para registrar el pedido de solicitud de servicio.

R7. El sistema debería tener una pantalla para registrar la orden de servicio que es registrada por el Ejecutivo de
Cuenta.

R8. El sistema deberá ser desarrollado en PHP y como gestor de base de datos MySql.

R9. El empleado de Mantenimiento debería tener una pantalla en donde consulte las órdenes de mantenimientos
pendientes.

R10. El Cliente debe tener la posibilidad de Consultar la condición del servicio de mantenimiento en el sistema.
 Ingeniería de
Pregrado
Sistemas

Entrevista con Directivos

Requerimiento funcionales
El Gerente de Servicios en las entrevista describió los requisitos que debería tener el nuevo sistema.

R1. El encargado de Cuenta tiene la posibilidad de registrar al cliente en el catalogo.

R2. El Encargado de Cuenta Tiene la posibilidad de registrar las cartas de aceptación o rechazo en el sistema.

R3. Nuestro Sistema deberá ser instalado en nuestro servidor Web que manejara la seguridad de acceso para los
clientes y los empleados.

R4. El Empleado de Inscripción de Cliente debe actualizar estado de la carta al momento de entregarla, los datos a
ingresar son fecha y hora de recepción.

R5. El Cliente debe tener la posibilidad de Consultar su estado en el sistema.

R6. El cliente debería tener una pantalla para registrar el pedido de solicitud de servicio.

R7. El sistema debería tener una pantalla para registrar la orden de servicio que es registrada por el Ejecutivo de
Cuenta.

R8. El sistema deberá ser desarrollado en PHP y como gestor de base de datos MySql.

R9. El empleado de Mantenimiento debería tener una pantalla en donde consulte las órdenes de mantenimientos
pendientes.

R10. El Cliente debe tener la posibilidad de Consultar la condición del servicio de mantenimiento en el sistema.
 Ingeniería de
Pregrado
Sistemas

Entrevista con Directivos

Requerimiento No funcionales
El Gerente de Servicios en las entrevista describió los requisitos que debería tener el nuevo sistema.

R1. El encargado de Cuenta tiene la posibilidad de registrar al cliente en el catalogo.

R2. El Encargado de Cuenta Tiene la posibilidad de registrar las cartas de aceptación o rechazo en el sistema.

R3. Nuestro Sistema deberá ser instalado en nuestro servidor Web que manejara la seguridad de acceso para los
clientes y los empleados.

R4. El Empleado de Inscripción de Cliente debe actualizar estado de la carta al momento de entregarla, los datos a
ingresar son fecha y hora de recepción.

R5. El Cliente debe tener la posibilidad de Consultar su estado en el sistema.

R6. El cliente debería tener una pantalla para registrar el pedido de solicitud de servicio.

R7. El sistema debería tener una pantalla para registrar la orden de servicio que es registrada por el Ejecutivo de
Cuenta.

R8. El sistema deberá ser desarrollado en PHP y como gestor de base de datos MySql.

R9. El empleado de Mantenimiento debería tener una pantalla en donde consulte las órdenes de mantenimientos
pendientes.

R10. El Cliente debe tener la posibilidad de Consultar la condición del servicio de mantenimiento en el sistema.
 Ingeniería de
Pregrado
Sistemas

Dividir procesos
El Gerente de Servicios en las entrevista describió los requisitos que debería tener el nuevo sistema.
Inscripción de Clientes:
● R1. El encargado de Cuenta tiene la posibilidad de registrar al cliente en el catalogo.
● R2. El Encargado de Cuenta Tiene la posibilidad de registrar las cartas de aceptación o rechazo en
el sistema.
● R4. El Empleado de Inscripción de Cliente debe actualizar estado de la carta al momento de
entregarla, los datos a ingresar son fecha y hora de recepción.
● R5. El Cliente debe tener la posibilidad de Consultar su estado en el sistema.
Servicio de Mantenimiento
● R6. El cliente debería tener una pantalla para registrar el pedido de solicitud de servicio.
● R7. El sistema debería tener una pantalla para registrar la orden de servicio que es registrada por
el Ejecutivo de Cuenta.
● R9. El empleado de Mantenimiento debería tener una pantalla en donde consulte las órdenes de
mantenimientos pendientes.
● R10. El Cliente debe tener la posibilidad de Consultar la condición del servicio de mantenimiento
en el sistema.
 Ingeniería de
Pregrado
Sistemas

Diagrama de Arquitectura

Inscripcion de Servicios de
Clientes Mantenimiento
 Ingeniería de
Pregrado
Sistemas

Encontrar Actores del Sistema

Inscripción de Clientes:
● R1. El encargado de Cuenta tiene la posibilidad de registrar
al cliente en el catalogo.
● R2. El Encargado de Cuenta Tiene la posibilidad de registrar
las cartas de aceptación o rechazo en el sistema.
● R4. El Empleado de Inscripción de Cliente debe actualizar
estado de la carta al momento de entregarla, los datos a
ingresar son fecha y hora de recepción.
● R5. El Cliente debe tener la posibilidad de Consultar su
estado en el sistema.
 Ingeniería de
Pregrado
Sistemas

Encontrar Actores del Sistema

 Ingeniería de
Pregrado
Sistemas

Encontrar Caso de Usos del Sistema

Inscripción de Clientes:
● R1. El encargado de Cuenta tiene la posibilidad de registrar al
cliente en el catalogo.
● R2. El Encargado de Cuenta Tiene la posibilidad de registrar
las cartas de aceptación o rechazo en el sistema.
● R4. El Empleado de Inscripción de Cliente debe actualizar
estado de la carta al momento de entregarla, los datos a
ingresar son fecha y hora de recepción.
● R5. El Cliente debe tener la posibilidad de Consultar su
estado en el sistema.
 Ingeniería de
Pregrado
Sistemas

Encontrar Casos de Uso del Sistema

 Ingeniería de
Pregrado
Sistemas

Diagrama de Casos de Uso

 Ingeniería de
Pregrado
Sistemas

Tarea
Encuentre los actores, los casos de uso de sistema y el diagrama de casos
de uso
Servicio de Mantenimiento
● R6. El cliente debería tener una pantalla para registrar el pedido de
solicitud de servicio.
● R7. El sistema debería tener una pantalla para registrar la orden de
servicio que es registrada por el ejecutivo de cuenta.
● R9. El empleado de mantenimiento debería tener una pantalla en
donde consulte las órdenes de mantenimientos pendientes.
● R10. El cliente debe tener la posibilidad de consultar la condición del
servicio de mantenimiento en el sistema.
 Ingeniería de
Pregrado
Sistemas

Encontrar Actores del Sistema

Servicio de Mantenimiento
R6. El cliente debería tener una pantalla para registrar el pedido de solicitud
de servicio.
R7. El sistema debería tener una pantalla para registrar la orden de servicio
que es registrada por el ejecutivo de cuenta.
R9. El empleado de mantenimiento debería tener una pantalla en donde
consulte las órdenes de mantenimientos pendientes.
R10. El cliente debe tener la posibilidad de Consultar la condición del
servicio de mantenimiento en el sistema.
 Ingeniería de
Pregrado
Sistemas

Encontrar Actores del Sistema

 Ingeniería de
Pregrado
Sistemas

Encontrar Caso de Sistema

Servicio de Mantenimiento
● R6. El cliente debería tener una pantalla para registrar el pedido de
solicitud de servicio.
● R7. El sistema debería tener una pantalla para registrar la orden de
servicio que es registrada por el Ejecutivo de Cuenta.
● R9. El empleado de Mantenimiento debería tener una pantalla en donde
consulte las órdenes de mantenimientos pendientes.
● R10. El Cliente debe tener la posibilidad de Consultar la condición del
servicio de mantenimiento en el sistema.
 Ingeniería de
Pregrado
Sistemas

Encontrar Casos de Uso del Sistema

 Ingeniería de
Pregrado
Sistemas

Diagrama de Casos de Uso

 Ingeniería de
Pregrado
Sistemas

Actividades prácticas

Realizar los dos ejercicios de la Guía de Laboratorio 3

 Ingeniería de
Pregrado
Sistemas

Gracias por su participación