Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.

Ramire

QUINTA UNIDAD

EL MODELADO DE REQUERIMIENTOS Y CASOS DE USO

¿Qué es un requerimiento?, ¿Cómo se clasifican?

¿Qué es un modelo de casos de uso? ¿Cuáles son sus elementos?
¿Cómo se construye un modelo de casos de uso?

72
72
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire

Lección 10

Conceptos asociados los requerimientos

La importancia de la especificación y análisis de requerimientos en un proyecto de
desarrollo de software es evidente; pues, sirve de base para planificación del proyecto y
para verificar si el producto software es de calidad, en otras palabras, si se han cubierto o
no las necesidades de los usuarios/clientes.
Muchos proyectos fracasan por una mala definición, especificación y administración de
requerimientos; la experiencia ha demostrado que las actividades relacionadas con los
requerimientos es compleja, por la falta de participación de los usuarios, lenguaje
distinto entre desarrolladores y usuarios, requerimientos cambiantes, entre otras
razones.
Por ello, es importante para el profesional involucrado en proyectos de desarrollo de
software poseer las suficientes competencias para la captura y administración de los
requerimientos a fin de afrontar con éxito esta tarea.
En esta lección se define y caracteriza el concepto de requerimientos y se describen
técnicas para la captura de los mismos.

1.1 ¿Qué es un requerimiento?

“Un requerimiento es una condición o capacidad a la que debe ajustarse el sistema que
se construye.” (Jacobson, 2000)
De acuerdo con la IEEE Std. 610.12-1990, “un requisito es: (1) Una condición o capacidad
necesaria para un usuario para resolver un problema o conseguir un objetivo. (2) Una
condición o capacidad que debe reunir o poseer un sistema o componente de un sistema
para satisfacer un contrato, estándar, especificación, u otro documento formalmente
impuesto. (3) Una representación documentada de una condición o capacidad como las
definidas en (1) o (2)” (IEEE, 1990).
“Un requerimiento es simplemente una declaración abstracta de alto nivel de un servicio
que debe proporcionar el sistema o una restricción de éste” (Somerville, 2005).

1.2 Tipos de Requerimientos

Los requerimientos se pueden dividir en dos tipos: Requerimientos Funcionales y
Requerimientos No funcionales.

1.2.1 Requerimiento Funcional

Un Requerimiento funcional es un requerimiento que especifica una acción que debe ser
capaz de realizar el sistema, sin considerar restricciones físicas; es un requisito que
especifica comportamiento de entrada / salida del sistema (Jacobson, 2000).
El requerimiento o requisito funcional describe que debe hacer el sistema respecto a su
entorno. En otras palabras, refleja las necesidades de los usuarios o la interacción con otros
sistemas.
Por ejemplo, los usuarios de un Sistema de Gestión Académica para la Universidad
pueden ser profesores y alumnos, algunos requerimientos funcionales son:

73
73
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire

El sistema permitirá a los profesores: Consultar los horarios de sus cursos, Consultar la
programación de los exámenes, Actualizar y ver su información personal, Registrar y
modificar las notas de los estudiantes a su cargo, Cerrar un curso
El sistema permitirá a los estudiantes: Consultar los horarios de sus cursos, Consultar la
programación de los exámenes, Actualizar y ver su información personal, Consultar notas
de un curso.

1.2.2 Requerimiento No funcional

Un Requerimiento No funcional es un requerimiento que especifica propiedades del
sistema, como restricciones del entorno o de implementación, rendimiento, dependencia
de la plataforma, mantenibilidad, extensibilidad o fiabilidad; especifica restricciones
físicas sobre un requisito funcional (Jacobson, 2000).
Un requerimiento no funcional describe atributos del sistema o del ambiente en donde
éste se desarrolla.
Algunos ejemplos de requerimientos no funcionales son:
El sistema debe brindar una interfaz de usuario intuitiva y sencilla, con un buen
mecanismo de ayuda on-line.
El sistema debe disponer de una documentación adecuada que facilite las tareas
de mantenimiento..
La tasa de disponibilidad del sistema debe ser de un 99%.

1.3 Clasificación de Requerimientos: Modelo FURPS

Una manera de categorizar los requerimientos está descrita en el modelo FURPS (Larman,
2002): Functionality (Funcionalidad), Usability (Capacidad de Uso), Reliability (Fiabilidad),
Performance (Desempeño) y Supportability (Capacidad de Soporte).
Functionality (Funcionalidad), son aquellos requerimientos que reflejan las características
fundamentales (requerimiento funcional o funcionalidades del sistema), además de
capacidades y seguridad.
Usability (Capacidad de Uso), son aquellos requerimientos que representan facilidad o nivel
de uso del producto; es decir, el grado en el que el diseño de un elemento facilita o dificulta
su manejo. Se incluyen: Factores humanos, Estética, Consistencia de la interfaz de
usuario, Ayudas en línea, Agentes y wizards, Documentación de usuario y material de
entrenamiento. Por ejemplo, Visibilidad del texto a una cierta distancia y Combinación de
colores del texto.
Reliability (Fiabilidad), son aquellos que muestran la capacidad de un sistema o
componente para ejecutar sus funciones requeridas bajo condiciones normales en un
periodo de tiempo especifico. Tiene siguientes sub-categorías: Disponibilidad, especifica
el porcentaje de tiempo disponible, horas de uso, acceso para mantenimiento, etc.; Tiempo
medio entre fallas; Tiempo medio para reparación, cuánto tiempo es posible que el sistema
esté inoperante después que falla; Exactitud: se especifica la precisión y exactitud (según
algún estándar conocido) que se requiere para las salidas del sistema; Cantidad máxima de
errores o porcentaje de defecto, generalmente expresado en términos de errores por miles
de líneas de código o errores por punto funcional; Errores o porcentaje de defecto,
categorizados en términos de errores menores, significantes y críticos (se debe definir
que significa error “crítico”, por ejemplo pérdida completa de dato o imposibilidad de
uso de ciertas funcionalidades del sistema.

74
74
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
Performance (Desempeño), se refieren a las características de rendimiento del sistem.
Incluye tiempos de respuesta específicos. Por ejemplo: Tiempo de respuesta para una
transacción (promedio, máximo); Transacciones por segundo; Capacidad, como por
ejemplo el número de clientes o transacciones que el sistema puede soportar; Modos de
degradación, esto es, cual es el modo aceptable de funcionamiento cuando el sistema ha
sido degradado de alguna manera; Utilización de recursos: memoria, disco,
comunicaciones, etc.
Supportability (Capacidad de Soporte), son requerimientos que refuerzan el soporte y
mantenimiento del sistema que está siendo construido, incluyendo normas de codificación,
convenciones de nombres, librerías, acceso para mantenimiento, utilidades de
mantenimiento si las hay. Como requerimiento que ayuda al mantenimiento se debe hacer
referencia al uso de nomenclatura común para el desarrollo del sistema, y a la metodología
de desarrollo.

ALGUNOS REQUERIMIENTOS FUNCIONALES DEL SISTEMA DE GESTION DE HORARIOS PARA LA FACULTAD

DE INGENIERIA DE SISTEMAS, CÓMPUTO Y TELECOMUNICACIONES
El sistema permitirá al secretario académico, introducir las asignaturas que se imparten en el semestre
académico, los datos del docente asignado a cada sección, de teoría y práctica, de la asignatura, los datos
de las aulas de teoría (ubicación y aforo) y de prácticas (ubicación, sistemas operativos, software,...).
La configuración del horario se lleva a cabo directamente sobre una plantilla horaria semanal, en la que
cada casilla representará una hora en un determinado día de la semana. Cuando el Secretario pulsa esa
casilla se mostrarán las asignaturas del curso que se esté configurando en ese momento. Una vez escogida
las asignaturas se mostrarán las secciones de teoría y práctica a los que todavía no se les ha asignado un
horario. Al escoger una sección se muestran las aulas disponibles (si es un grupo de teoría) o los
laboratorios que cumplen las restricciones de sistemas operativos establecidas para esa materia y que no
están ocupados a esa hora.
El sistema podrá ser consultado por cualquier usuario, que podrá consultar el horario de una asignatura,
un ciclo, o de un aula o laboratorio concretos.

ALGUNOS REQUERIMIENTOS NO FUNCIONALES DEL SISTEMA DE GESTION DE HORARIOS PARA LA

FACULTAD DE INGENIERIA DE SISTEMAS, CÓMPUTO Y TELECOMUNICACIONES
La tasa de disponibilidad del sistema debe ser de un 99%. El sistema debe tener una interfaz de uso intuitiva
y sencilla, complementada con un buen sistema de ayuda. El sistema debe disponer de una documentación
fácilmente actualizable que permita realizar operaciones de mantenimiento con el menor esfuerzo posible.

1.4 Características de los Requerimientos

Un requerimiento debe ser:
Especificado por escrito, como todo contrato o acuerdo entre dos partes.
Posible de probar o verificar, si un requerimiento no se puede comprobar,
entonces, ¿cómo se sabe si se cumplió con él o no?

75
75
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire

Conciso, un requerimiento es conciso si es fácil de leer y entender. Su redacción

debe ser simple y clara para aquello que vayan a consultarlo en el futuro.
Completo, un requerimiento esta completo si no es necesario ampliar detalles en
su redacción, es decir si se proporciona la información suficiente para su
comprensión.
Consistente, un requerimiento es consistente si no es contradictorio con otro
requerimiento.
No ambiguo, un requerimiento no es ambiguo cuando tiene una sola interpretación.
El lenguaje usado en su definición, no debe causar confusión en el lector.

1.5 Dificultades para definir los Requerimientos

Los requerimientos no son obvios y vienen de muchas fuentes
Son difíciles de expresar en palabras (el lenguaje es ambiguo)
La cantidad de requerimientos en un proyecto puede ser difícil de manejar
Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
El usuario no puede explicar lo que hace.
El usuario tiende a recordar lo excepcional uy olvidar lo rutinario
Hablan de lo que no funciona
Los usuarios tienen distinto vocabulario que los desarrolladores
Usan el mismo término con distinto significado

1.6 Técnicas para obtener Requerimiento

1.6.1 Entrevistas
Esta técnica es adecuada para la primera toma de contacto. Es conveniente comenzar por
preguntas de contexto libre, para entender: el problema, a las personas interesadas en la
solución, naturaleza de ésta, y lograr efectividad de la reunión.
Ejemplos de preguntas centradas en el cliente, los objetivos globales y beneficios
¿Quién solicita el trabajo?
¿Quién utilizará la solución?
¿Cuál será el beneficio económico de una buena solución?
¿Existen otras alternativas a esta solución?

Ejemplos de preguntas sobre el problema y la solución

¿Qué entiende el cliente por una solución “correcta”?
¿Qué problemas afrontará esta solución?
¿En qué entorno se va a implantar la solución?
¿Existen restricciones o aspectos de rendimiento importantes?

76
76
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire

Ejemplo de preguntas sobre la efectividad de la reunión

¿Es usted la persona adecuada para responder a estas preguntas? ¿Sus respuestas
son “oficiales”?
¿Son relevantes mis preguntas para su problema?
¿Hay alguien más que pueda proporcionar información adicional?
¿Hay algo más que debería preguntar?

Problemas de las entrevistas:

Pueden surgir malentendidos
Omisión de información
Mala relación de trabajo (“nosotros-ellos”)

1.6.2 JAD
El Diseño en Conjunto de Aplicaciones (JAD, “Joint Application Design”) fue desarrollado
por IBM a finales de los setenta. Es una sesión de trabajo con participación de todos los
involucrados. El resultado de la sesión es un documento de especificación que incluye
definiciones de elementos de datos, flujos de trabajo y pantallas de interfaz.
El resultado de una sesión JAD representa un acuerdo entre usuarios, clientes y
desarrolladores y minimiza los cambios posteriores de requerimientos.
Las actividades de la sesión JAD son: Definición del proyecto, Investigación, preparación,
Sesión, preparación del documento final.
Definición del proyecto: el coordinador se entrevista con gerentes y clientes para
determinar objetivos y alcance del proyecto. Se elabora la “guía de definición
administrativa”.
Investigación: se entrevista a usuarios y se recopila información del dominio, descripción
de flujos de trabajo y asuntos a tratar en la reunión. Se elabora la “agenda de sesión” y la
“especificación preliminar”.
Preparación: el coordinador elabora un “documento de trabajo” o primer borrador del
documento final.
Sesión: el coordinador guía al equipo para crear la especificación del sistema en una
reunión que puede durar varios días. Se definen los flujos de trabajo, elementos de datos,
pantallas, informes,... Las decisiones se documentan en unos formularios.
Preparación de documento final: el coordinador prepara el “documento final” usando los
“formularios” y se distribuye a los asistentes para su revisión. Se realiza una reunión para
discutir revisiones y finalizar el documento.

77
77
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire

Lección 11

Conceptos asociados al Modelo de casos de uso

Se han establecido diversas técnicas para la especificación de requerimientos. La técnica de
casos de uso (Jacobson, 93) se ha constituido en el estándar universal para capturar
requerimientos de sistemas software. Los casos de uso no solo sirven para captura
requerimientos de sistemas software, sino que tienen gran influencia sobre todas las
fases del proceso de desarrollo.

11.1 ¿Qué es el modelo de casos de uso?

El Modelo de Casos de uso es un modelo que describe los requerimientos funcionales del
sistema en forma de Casos de uso. Su objetivo es comunicar la funcionalidad y el
comportamiento al cliente y usuario.
El modelo de casos de uso esta compuesto por actores, casos de uso, descripción de cada
caso de uso y el diagrama de casos de uso.

11.2 Actor
Un actor define un conjunto coherente de roles que los usuarios del sistema pueden jugar
cuando interactúan con él. Una instancia de actor puede ser un individuo o un sistema
externo. La notación UML para el actor se muestra en la figura 11.1.
Por ejemplo, en el Sistema de Académico de la universidad, los actores pueden ser:
Secretario Académico, Alumno y Docente. Todos ellos interactúan con el sistema a través
de alguna de sus funcionalidades. Nótese que el nombre del actor represente el rol que
desempeñan grupos de usuarios, por ejemplo el rol alumno representa a todos los
alumnos; un alumno particular representa una instancia del actor alumno.

Figura 11.1 Actor

11.3 Caso de Uso

Un caso de uso define un conjunto de escenarios de casos de uso. Un escenario es una
secuencia de acciones e interacciones entre el actor y el sistema, que proporciona valor a
un actor particular (Jacobson, 93). La figura 11.2 muestra la notación UML de caso de uso.
Por ejemplo, consideremos el siguiente escenario para realizar el Retiro de Dinero de un
Cajero Automático:
Escenario Normal
1. E cliente inserta su tarjeta en la ranura del cajero automático
2. El cajero automático solicita ingreso de clave secreta
3. El cliente ingresa su clave secreta
4. El cajero automático muestra menú de opciones
5. El cliente selecciona opción “Retiro”

78
78
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire

6. El cajero automático muestra relación de cuentas del cliente

7. El cliente eligen cuenta
8. El cajero automático solicita cantidad
9. El cliente ingresa cantidad a retirar
10. El cajero automático dispensa el dinero y termina.
Esta secuencia de interacciones entre el cliente y el cajero automático termina, de forma
normal, se dispensa el dinero del cliente.
Otras secuencias que no siguen este flujo normal, pueden ser:
Escenario: clave incorrecta
1. E cliente inserta su tarjeta en la ranura del cajero automático
2. El cajero automático solicita ingreso de clave secreta
3. El cliente ingresa su clave secreta
4. El cajero automático muestra mensaje de error “Clave incorrecta”
Escenario: Saldo insuficiente
1. E cliente inserta su tarjeta en la ranura del cajero automático
2. El cajero automático solicita ingreso de clave secreta
3. El cliente ingresa su clave secreta
4. El cajero automático muestra menú de opciones
5. El cliente selecciona opción “Retiro”
6. El cajero automático muestra relación de cuentas del cliente
7. El cliente eligen cuenta
8. El cajero automático solicita cantidad
9. El cliente ingresa cantidad a retirar
10. El cajero automático muestra mensaje de error “Saldo Insuficiente”.
Podemos decir que este conjunto de escenarios corresponde al caso de uso Retiro de
Cajero Automático.
En conclusión, un caso de uso proporciona uno o más escenarios que indica como debe
interactuar el usuario con el sistema o con otro sistema para conseguir un objetivo
particular.

Figura 11.2 Caso de uso

11.4 Descripción de caso de uso

Se han establecido diversas plantillas para describir un caso de uso. Larman (2002) señala
que la descripción de un caso de uso, básicamente, debe contener: Nombre del caso de
uso, Actor, Precondiciones, Poscondiciones, Flujo básico y Flujos alternativos.
El nombre del caso de uso debe ser claro e indicar la función requerida que el sistema debe
proveer a los actores. Por ejemplo, Registrar Matricula de estudiante.
El nombre del Actor, por ejemplo Estudiante

79
79
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire

Las precondiciones, son las restricciones que deben cumplirse para que el caso de uso se
inicie, se definen relativas al sistema no a su entorno, debe ser estados observables por el
actor. Establecen lo que siempre debe cumplirse antes de comenzar un escenario en un
caso de uso. Normalmente implica que un escenario de otro caso de uso se ha
completado exitosamente. Estas deben redactarse en tiempo verbal pasado. Por ejemplo:
El usuario ha sido aceptado en el sistema con el rol de profesor.
Las poscondiciones, son las condiciones que deben cumplirse para indicar que el caso de
uso ha terminado con éxito; establecen lo que debe cumplirse cuando el caso de uso
termina, son la garantía de éxito. Estas deben redactarse en tiempo verbal pasado. Por
ejemplo: Se ha registrado en el sistema las notas de los alumnos.
El flujo básico, es la descripción narrativa de lo que debe ocurrir cuando los actores
interactúan con el sistema para satisfacer la meta u objetivo propuesto, se consideran los
pasos normales, no incluye las alternativas o variaciones.
Los flujos alternativos, refleja las diferentes situaciones que provocan una desviación del
flujo básico de eventos, se consideran, condiciones anormales, extremas, ocasionales,
condiciones de error o violaciones de reglas.
Ejemplo de flujo básico:
1. El Caso de uso comienza cuando el profesor indica “registrar notas.”
2. El sistema muestra un formulario de validación de ingreso al sistema.
3. El usuario ingresa su código y su contraseña.
4. El sistema muestra los cursos asignados al profesor.
5. El profesor selecciona el curso.
6. El sistema muestra un listado de los estudiantes con sus notas.
7. El profesor selecciona el estudiante e ingresa la nota de práctica, del parcial, del
examen final y la nota final. Se repite para cada estudiante.
8. El profesor indica “guardar”.
9. El sistema valida toda la información y muestra un mensaje de confirmación y el
Caso de uso finaliza.

Ejemplos de flujos alternativos:

Código o Contraseña errados:
En el paso 4, si código o contraseña digitados por el usuario son erradas, el sistema
muestra mensaje de error y vuelve a solicitar código y contraseña.
Profesor sin cursos asignados:
En el paso 4, si el sistema determina que el profesor no tiene cursos asignados,
muestra mensaje de error y el caso de uso finaliza.

11.5 Diagrama de casos de uso

Un diagrama de caso de uso muestra los actores los casos de uso y las relaciones entre
ellos. La figura 11.3 muestra un ejemplo de diagrama de casos de uso, para un sistema de
gestión académica. Se observa dos actores: profesor y alumno, mediante la relación de
generalización se puede afirmar que el profesor y el alumno son dos tipos de usuarios,
Los casos de uso comunes para ambos son: consultar horarios, validar acceso y consultar
horario de exámenes. Particularmente, el estudiante puede consultar notas de un curso y

80 Sistema a Distancia
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire

mantener información del estudiante. El profesor puede mantener información de

profesor, registrar notas de un curso y cerrar un curso.

Figura 11.3 Diagrama de casos de uso

Consultar notas de un curso

Estudiante
Consultar horarios de cursos (f rom Actors)

Mantener información del estudiante

Cerrar un curso
Validar acceso

U suario
Mantener información del profesor
(f rom Actors )

Consultar horario de exámenes

Profesor
Registrar notas de un curso
(f rom Actors)

Relaciones entre casos de uso

Entre dos casos de uso puede haber las siguientes relaciones: Extend e includes. Una
relación extend se cuando un caso de uso especializa a otro extendiendo su
funcionalidad. Una relación include se usa cuando un caso de uso incluye a otro. Se
representan como una línea que une a los dos casos de uso relacionados, con una flecha
en forma de triángulo y con una etiqueta <<extiende>> o <<include>> según sea el tipo de
relación.
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire

Lección 12

Proceso de construcción del modelo de casos de casos de uso

En esta lección se presentan los pasos a seguir para la construcción de un modelo de
casos de uso; para tal efecto, consideremos la siguiente descripción de requerimientos:

La Empresa AIRTRANS, dedicada al servicio de transportes aéreos, necesita un sistema de información

para gestionar y mantener los datos de unidades, vuelos, pilotos, pasajeros y reservas.
Después de haber dialogado con el Encargado de Vuelos se concluyó que es responsable de Mantener
la información de las distintas unidades: el número, el tipo de avión, la fecha de compra, el modelo,
la capacidad de carga y la capacidad de pasajeros. Determina los vuelos que llevan carga, para los
mismos necesita guardar la fecha, el piloto, el lugar de origen, el destino, el peso de la carga y el monto
del vuelo. Define los vuelos de pasajeros: fija la fecha, el piloto y su tripulación, origen, destino y
capacidad de pasajeros.
El gerente nos informó que: Mantiene la información de los pilotos que trabajan en la empresa, para
el mismo guarda el número de piloto, el nombre, dirección, habilitación, fecha del último control
médico. Necesita que el sistema le devuelva dado un piloto, los vuelos que ha realizado en un periodo
dado.
El empleado de ventas nos explicó que: Mantiene información de los pasajeros de los diferentes
vuelos, para cada uno se le incorpora un número de identificación, el nombre, profesión, el teléfono
y la dirección. Los pasajeros realizan reservas para los distintos vuelos, si no hay espacio disponible,
se rechaza el pedido de reserva para ese vuelo. Confirma los pasajeros que toman los vuelos. Sólo se
admiten pasajeros que hayan realizado reservas previas. Necesita un reporte con los pasajeros que
tomaron un vuelo.

12.1 Identificando actores

Para identificar actores, podemos preguntar ¿Quién está interesado en cierto
requerimiento o se beneficia o se ve afectado por algún servicio del sistema?, ¿Dónde en
la organización será usado el sistema?, ¿Quienes usan, eliminan o suministran
información en el sistema?, ¿Quién usa una determinada función del sistema?. Las
respuestas a estas preguntas pueden considerar grupo de personas, departamentos u otros
sistemas.
En nuestro caso, los actores identificados son:

Encargado de Gerente Empleado de

vuelos ventas

12.2 Identificando casos de uso

Para identificar casos de uso se sugiere preguntar: ¿Cuáles son las tareas que realiza el
actor?, ¿Qué objetivos concretos necesita alcanzar un actor?, ¿Puede el actor crear,
almacenar, remover o leer información en el sistema?, El actor, ¿necesita estar informado
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire

acerca de las ocurrencias del sistema? Las respuestas a estas preguntas reflejan
funcionalidades del sistema para cada actor.
En nuestro caso, el actor Encargado de vuelo debe: Mantener información de unidades,
Registrar vuelo de carga y Registrar vuelo de pasajeros. El Gerente debe: Mantener
información de pilotos y Consultar vuelos por piloto. El Empleado de Ventas: Mantener
información de pasajeros, Registrar reserva de vuelo, Registrar confirmación de vuelo y
Consultar pasajeros que tomaron vuelo.

Mantener información de unidades Registrar vuelo de carga Registrar vuelo de pasajeros

Mantener información de pilotos Consultar vuelos por pilotos Mantener información de pasajeros

Registrar reservas de vuelo

Registrar confirmación de vuelo Consultar pasajeros que tomaron
vuelo

12.3 Elaborando la descripción de casos de uso

Por cada caso de uso se elabora su descripción. En nuestro caso, solo desarrollaremos
descripción de algunos casos de uso.

Nombre C.U.S. Consultar Vuelos por Piloto

Actor Gerente
Precondición El usuario ha sido admitido en el sistema con el rol de Gerente
Poscondición El sistema muestra los vuelos realizados por piloto
Flujo Básico
1. El caso de uso se inicia cuando el Gerente indica “Vuelos Realizados”.
2. El sistema muestra, en una ventana, relación de pilotos, en otra ventana el calendario
para escoger el periodo (fecha inicio y fecha de fin) y un botón “Aceptar”.
3. El Gerente escoge el nombre de piloto de la relación mostrada.
4. El Gerente escoge el periodo (fecha inicio y fecha de fin).
5. El Gerente indica “Aceptar”.
6. El sistema muestra los datos del piloto, los vuelos realizados por piloto en el periodo
escogido.
7. El sistema habilita botones “Regresar” y “Imprimir”
8. El Gerente indica “Regresar”
9. El caso de uso finaliza.
Flujos Alternativos
Imprimir
En el paso 7, si el gerente indica “Imprimir”, el sistema imprime la información consultada.
Nohayvuelosenperiodo
En el paso 6, si no existen vuelos del piloto en el periodo seleccionado, el sistema muestra
mensaje “Piloto no tiene registrado vuelos en el periodo” y regresa a solicitar información.
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire

Nombre C.U.S. Mantener información de unidades

Actor Encargado de vuelos
Precondición El usuario ha sido admitido en el sistema con el rol de Encargado de vuelos
Poscondición Se ha registrado información de unidades
Flujo Básico
Ingresar
1. El caso de uso comienza cuando el Encargado de Vuelo indica “Mantener Información
de unidad”.
2. El Sistema muestra las opciones: “Ingresar”, “Modificar” y “Eliminar”.
3. El Encargado de Vuelo elige la opción “Ingresar”.
4. El Sistema muestra el formulario para llenar datos de una nueva unidad.
5. El Encargado de Vuelo ingresa datos de la unidad: el número, el tipo de avión, la fecha
de compra, el modelo, la capacidad de carga y la capacidad de pasajeros.
6. El Encargado de Vuelo indica “Guardar”.
7. El Sistema registra la información de la nueva unidad.
8. El caso de uso finaliza.
Flujos Alternativos
Modificar
1. El flujo se inicia cuando el Encargado de Vuelo elige la opción “Modificar”.
2. El Sistema muestra relación de unidades
3. El Encargado de Vuelo selecciona unidad cuyo datos desea modificar
4. El Sistema muestra formulario con los datos de la unidad a modificar
5. El Encargado de Vuelo realiza modificaciones
6. El Encargado de Vuelo indica “Guardar”.
7. El Sistema registra las modificaciones.
8. El caso de uso finaliza.
Eliminar
1. El flujo se inicia cuando el Encargado de Vuelo elige la opción “Eliminar”.
2. El Sistema muestra relación de unidades.
3. El Encargado de Vuelo selecciona unidad que desea eliminar.
4. El Sistema muestra formulario con datos de unidad a eliminar.
5. El Encargado de Vuelo indica “Confirmar”
6. El Sistema registra la eliminación de la unidad.
7. El caso de uso finaliza.
Cancelar
1. En cualquier momento, el usuario indica “Cancelar”, entonces,
2. El sistema no registra dato alguno y el caso de uso finaliza.
CódigoRepetido
1. En el paso 7 de ingresar y 7 de modificar, si el número de unidad se repite,
2. El sistema muestra un error y regresa a solicitar datos
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire

12.4 Elaborando el diagrama de casos de uso

Se asocia cada actor con su caso de uso, obteniéndose el siguiente diagrama de casos de
uso

Registrar vuelo de carga

Mantener información de unidades
Encargado de
vuelos

Registrar vuelo de pasajeros

Consultar vuelos por pilotos

Gerente
Mantener información de pilotos

Mantener información de pasajeros

Registrar reservas de vuelo
Empleado de
ventas

Consultar pasajeros que tomaron

vuelo
Registrar confirmación de vuelo
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire

Resumen
Conceptos asociados a los requerimientos
Un requerimiento es una condición o capacidad a la que debe ajustarse el sistema que se
construye. Un requerimiento es simplemente una declaración abstracta de alto nivel de un servicio
que debe proporcionar el sistema o una restricción de éste
El requerimiento o requisito funcional describe que debe hacer el sistema respecto a su entorno.
Un requerimiento no funcional describe atributos del sistema o del ambiente en donde éste se
desarrolla. Pueden ser de: usabilidad, fiabilidad, desempeño, capacidad de soporte.
La entrevista es una técnica para obtener requerimientos usados en la primera toma de
contactos con los usuarios-clientes.
El diseño conjunto de aplicaciones, Joint Application Design (JAD) es una sesión con
participación de todos los involucrados, cuyo resultado es un documento de
especificación.
Conceptos asociados al modelo de casos de uso
El Modelo de Casos de uso es un modelo que describe los requerimientos funcionales del
sistema en forma de Casos de uso.
Un actor define un conjunto coherente de roles que los usuarios del sistema pueden jugar
cuando interactúan con él.
Un caso de uso define un conjunto de escenarios de casos de uso. Un escenario es una
secuencia de acciones e interacciones entre el actor y el sistema, que proporciona valor a
un actor particular.
Las precondiciones, son las restricciones que deben cumplirse para que el caso de uso se
inicie, se definen relativas al sistema no a su entorno, debe ser estados observables por el
actor
Las poscondiciones, son las condiciones que deben cumplirse para indicar que el caso de
uso ha terminado con éxito; establecen lo que debe cumplirse cuando el caso de uso
termina, son la garantía de éxito.
Los flujos alternativos, refleja las diferentes situaciones que provocan una desviación del
flujo básico de eventos, se consideran, condiciones anormales, extremas, ocasionales,
condiciones de error o violaciones de reglas.
Un diagrama de caso de uso muestra los actores los casos de uso y las relaciones entre ellos.
Proceso de construcción del modelo de casos de uso
Identificación de actores
Identificación de casos de uso
Elaboración de descripción de casos de uso
Elaboración de diagrama de casos de uso

86 Sistema a Distancia
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire

Lectura
Crear el diseño lógico de una interfaz de usuario (*)
Cuando los actores interactúan con el sistema, utilizaran y manipularan elementos de interfaces
de usuario que representan atributos (de los casos de uso). A menudo estos son términos del
glosario (por ejemplo, balance de cuenta, fecha de vencimiento y titular de cuenta). Los actores
pueden experimentar estos elementos de las interfaces de usuario como iconos, listas de elementos
u objetos en un mapa 2D, y pueden manipularlos por selección, arrastre o hablando con ellos. El
diseñador de interfaces de usuario identifica y especifica estos elementos actor por actor,
recorriendo todos los casos de uso a los que el actor puede acceder, e identificando los elementos
apropiados de la interfaz de usuario para cada caso de uso. Un único elemento de interfaz de usuario
puede intervenir en muchos casos de uso, desempeñando un papel diferente en cada uno. Así, los
elementos de la interfaz de usuarios pueden diseñarse para jugar varios roles. Deberíamos
responder a las siguientes preguntas por cada actor:
¿Qué elementos de interfaz de usuario se necesitan para posibilitar el caso de uso?
¿Cómo deberían relacionarse unos con otros?
¿Cómo se utilizaran en los diferentes casos de uso?
¿Cuál debería ser su apariencia?
¿Cómo deberían manipularse?
Para determinar qué elementos de interfaz de usuario necesitan ser accesibles al actor en cada caso
de uso, podemos contestar las siguientes preguntas:
¿Qué clases de dominio, entidades del negocio o unidades de trabajo son adecuados
como elementos de la interfaz de usuario para cada caso de uso?
¿Con qué elementos de la interfaz de usuario va a trabajar el actor?
¿Qué acciones puede invocar el actor, y qué decisiones puede tomar?
¿Qué guía o información va a necesitar el actor antes de invocar cada acción de los casos
de uso?
¿Qué información debe proporcionar el actor al sistema?
¿Qué información debe proporcionar el sistema al actor?
¿Cuáles son los valores medios de todos los parámetros de entrada o salida? Por ejemplo,
¿Cuántas facturas manejarán habitualmente un actor durante una sesión y cuál es el saldo
medio de la cuenta? Necesitamos estimaciones aproximadas de estas cosas porque así se
optimizará la interfaz gráfica de usuario para ellas (incluso aunque tengamos que permitir
un rango suficientemente grande).
Una forma práctica de trabajo es representar los elementos de la interfaz de usuario mediante notas
adhesivas, pegadas en una pizarra, y ordenadas para ilustrar la apariencia de la interfaz de usuario.
Seguidamente, los diseñadores de interfaces de usuario describen cómo pueden utilizar los actores
estos elementos cuando trabajen con los caso de uso. La ventaja de utilizar notas adhesivas es que
pueden representar la cantidad necesario a de datos. Además, las notas adhesivas tampoco parecen
permanentes .es fácil moverlas o simplemente eliminarlas-, lo que hace que el usuario se sienta
cómodo proponiendo cambios.

(*) Jacobson (2000).

87 Sistema a Distancia
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire

Actividades

1. Desarrollar el modelo de casos de uso para el siguiente sistema para una agencia de alquiler
de autos

Inicialmente, entrevistamos al dueño de la agencia, quien es el que impulsó el proyecto. Él

está, especialmente, interesado en controlar los gastos de la empresa. Necesita obtener
del sistema información del tipo: Dado un intervalo de tiempo, todas las reparaciones
realizadas por un monto superior al que él imponga.
El Empleado de Atención al Público, nos contó que por cada nuevo alquiler actualiza la
ficha registro del cliente. En caso de tratarse de un nuevo cliente, abre una nueva ficha
con los siguientes datos: apellido y nombre, dirección personal, localidad, provincia, tipo y
número de documento, profesión y número de licencia de conductor. De acuerdo con las
restricciones que impone el cliente, se busca si existe un vehículo disponible. Una vez que
el cliente seleccionó un coche, se crea una ficha para el nuevo alquiler: fecha del alquiler,
cantidad de días por los que se alquila, importe del alquiler y kilometraje del vehículo al
momento de ser alquilado. No se debe autorizar alquileres a clientes que no devolvieron
en el plazo o en buen estado el vehículo que se les prestó.
El Encargado de Autos es el único autorizado a actualizar la ficha registro de cada auto. Cada
vehículo tiene su propia información: código, descripción, marca (por ej: Ford Fiesta),
modelo (por ej: 1996), estado (alquilado, disponible para alquilar o en reparación). Por cada
vehículo lleva nota de todas las reparaciones que recibió. De cada reparación mantiene la
fecha, motivo, costo de la reparación, cantidad de días que el auto no estuvo disponible.
También atiende a los clientes que traen los vehículos. Controla que el mismo se entregue
en buen estado y en termino, si no es así le informa al encargado de atención al público
para que no autorice nuevos alquileres a ese cliente y registra en la ficha del alquiler el
kilometraje final con que se devuelve el coche. Le gustaría poder consultar los autos mas
alquilados.

2. Continuar el desarrollo con lo que se indica:

Para la segunda etapa de este proyecto se van a incorporar, al sistema, facilidades para
hacer reservas telefónicas. En este caso, el Empleado de Atención al Público tomará los
datos del cliente, la fecha del alquiler, días por los que se va a alquilar y vehículo que reserva.
Una reserva puede ser cancelada con hasta 48 horas de anticipación. Los clientes que hagan
reservas y no retiren el alquiler, no podrán efectuar nuevas reservas ni alquileres.
Al final de cada jornada, el Encargado de Autos lanzara un proceso que analizase las reservas
para el próximo día y marque los autos que corresponda como reservados.

88 Sistema a Distancia
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire

Autoevaluación
1. Un requerimiento es:
2. Las diferencias entre un requerimiento funcional y no funciona son:
3. Los requerimientos se caracterizan por:
4. Cuando usaría las técnicas de entrevista y JAD
5. El modelo de casos de uso representa
6. El actor es
7. El caso de uso es
8. Un escenario de caso de uso es
9. Una precondición es
10. Una poscondición es
11. La diferencia entre flujo básico y flujo normal es

Exploración on-line
Sitio de Alistair Cockburn, sobre recursos e información de casos de uso
http://alistair.cockburn.us/

Referencias bibliográficas
IEEE (1990), IEEE Std 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology
–Description.
http://standards.ieee.org/reading/ieee/std_public/description/se/610.12-1990_desc.html.
Jacobson, I., Booch, G. y Rumbaugh, J. (2000), El Proceso Unificado de Desarrollo de Software.
Madrid. Pearson Educación S.A.
Jacobson,I., et al, (1993). Object-Oriented Software Engineering: A Use case Driven Approach.
USA. Addison Wesley.
Larman, C. (2002). UML y patrones: introducción al análisis y diseño orientado a objetos.
Segunda Edición. Madrid. Pearson Educación S.A.
Sommerville, Ian (2005), Ingeniería de Software. Sétima edición. Mexico D.F. Editorial Pearson.
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire

GLOSARIO
Actividad Es una unidad de trabajo que debe ser ejecutada en un proceso de desarrollo de
software.
Artefacto Es una pieza de información que es producida, modificada o usada en un proceso
de desarrollo de software.
Flujo de trabajo Es una secuencia de actividades que produce un resultado valioso, define una
lista de actividades, trabajadores y artefactos.
Metodología Es el conjunto de procedimientos, técnicas, herramientas, y un soporte
documental que ayuda a los desarrolladores a realizar nuevo software
Modelo de análisis de negocios Describe la realización de los casos de uso del negocio
mediante la interacción de los trabajadores del negocio y las entidades del negocio.
Modelo de casos de uso Es un modelo que describe los requerimientos funcionales del
sistema en forma de casos de uso.
Modelo de casos de uso del negocio Es una representación de la forma en que la empresa
interactúa con su entorno.
Modelo de dominio Es un modelo conceptual que muestra clases conceptuales de objetos
significativos en un dominio de problema. Las clases conceptuales no muestran componentes
software, ni clases software, ni responsabilidades
Organización Sistema compuesto por un conjunto de personas, actividades y recursos,
distribuidas de alguna forma (generalmente en departamentos o funciones) con arreglo a
ciertas reglas de división del trabajo y comunicación que interactúan para producir bienes o
servicios
Proceso de desarrollo Es una guía acerca de las actividades y tareas necesarias para construir
un sistema de información.
Proceso de negocio Conjunto de actividades que toman uno o más imputs crean un outputs
de valor para el cliente.
RUP (Rational Unified Process, Proceso Unificado de Rational) es un proceso de desarrollo de
software, es una forma disciplinada de asignar tareas y responsabilidades en una empresa de
desarrollo, es decir define quién hace qué, cuándo y cómo.
Trabajador Es un rol que debe ser realizada por una persona o equipo dentro de un proceso de
desarrollo de software..
Sistema de información Conjunto de componentes hardware, software, base de datos,
procedimientos y personas, que permiten capturar, procesar, almacenar y distribuir
información para una organización.
UML (Unified Modeling Language, Lenguaje de Modelado Unificado) es un lenguaje, basado
en una notación gráfica, que permite: especificar, construir, visualizar y documentar los
elementos de un sistema software, así como para modelar los procesos de negocios u otros
sistemas no software.

90 Sistema a Distancia
90
Análisis de Sistemas - Unidad V César Luza Montero

BIBLIOGRAFIA
1 Davenport, Thomas (1996). Innovación de Procesos: Reingeniería del trabajo a través de la
tecnología de la información. España. Díaz Santos.
2 Hammer, Michel y James Champy (1993), Reengineering the Corporation: A Manifesto for
Business Revolution. USA. Collins Business Essentials.
3 Harris, David (1996). Creating a Knowledge Centric Information Technology Environment. USA.
Editorial Harris Training & Consulting Services Inc.
4 IEEE (1990), IEEE Std 610.12-1990 IEEE Standard Glossary of Software Engineering
Terminology –Description.
http://standards.ieee.org/reading/ieee/std_public/description/se/610.12-1990_desc.html.
5 Jacobson, I., Booch, G. y Rumbaugh, J. (2000), El Proceso Unificado de Desarrollo de Software.
Madrid. Pearson Educación S.A.
6 Jacobson, I., Booch, G. y Rumbaugh, J. (2006), El Lenguaje Unificado de Modelado UML.
Segunda edición. Madrid. Pearson Educación S.A.
7 Larman, C. (1999). UML y patrones: introducción al análisis y diseño orientado a objetos.
Mexico D.F. Prentice-Hall Hispanoamericana.
8 Larman, C. (2002). UML y patrones: introducción al análisis y diseño orientado a objetos.
Segunda Edición. Madrid. Pearson Educación S.A.
9 Laudon, Jane y Kenneth P. Laudon, J. (2004) Sistemas de Información Gerencial. 8ª Ed. México
D.F. Pearson Educación.
10 Laudon, Jane y Kenneth (2006). Sistemas de información gerencial, Administración de la
empresa digital. México D.F. Pearson Educación- Prentice Hall.
11 Pressman , Roger S. (2002) Ingeniería de Software. Un enfoque práctico. 5ta.Ed. Mc Graw Hill,
España.
12 Rumbaugh, J. et. al. (1996). Modelado y diseño orientados a objetos. Metodología OMT.
Mexico D.F. Prentice Hall Hispanoamericana.
13 Sommerville, Ian (2005), Ingeniería de Software. Sétima edición. Mexico D.F. Editorial
Pearson.

91 Sistema a Distancia
91