Politcnico GranColombiano.

Asignatura Estructura de Datos.

Docente Nelson Orlando Prez Echeverry.
Integrantes:
Paulo vila
Adriana Mara Heincke
Nelba Fandio
Vladimir Ceballos
1 Casos de Uso.
Introduccin
Los casos de uso modelan comportamiento, interaccin.
No tiene sentido usarlos si lo que se quiere modelar no es un comportamiento
interactivo.
El caso de uso comprende los pasos necesarios para alcanzar un objetivo de su
actor principal. Debe proveer una especificacin funcional completa, independiente
de la tecnologa.
El caso de uso no describe el procesamiento interno del sistema, slo la
interaccin y los resultados de valor para el usuario.
Un caso de uso es una interaccin tpica entre un usuario y un sistema de
cmputo.
El caso de uso capta alguna funcin visible para el usuario.
El caso de uso puede ser pequeo o grande.
El caso de uso logra un objetivo discreto para el usuario. Una buena fuente para
identificar los casos de uso son los eventos externos. Pensar en todos los eventos
externos ante los cuales se quiere reaccionar.
Concepto de casos de uso.
Un caso de uso es una secuencia de transacciones que son desarrolladas por un
sistema en respuesta a un evento que inicia un actor sobre el propio sistema.
Ningn sistema se encuentra aislado puesto que el sistema interacta con actores
humanos o mecnicos que lo utilizan con un objetivo de funcional para que el
sistema responda de forma predecible. Los casos de uso bien estructurados
muestran comportamientos esenciales del sistema o de un subsistema, y no
deben ser excesivamente genricos ni demasiado especficos.
Actores
Un actor es una agrupacin uniforme de personas, sistemas o mquinas que
interactan con el sistema que estamos construyendo de la misma forma. Por
ejemplo, para una empresa que recibe pedidos en forma telefnica, todos los
operadores que reciban pedidos y los ingresen en un sistema de ventas, si pueden
hacer las mismas cosas con el sistema, son considerados un nico actor:
Empleado de Ventas. Los actores son externos al sistema que vamos a
desarrollar. Por lo tanto, al identificar actores estamos empezando a delimitar el
sistema, y a definir su alcance. Definir el alcance del sistema debe ser el primer
objetivo de todo analista, ya que un proyecto sin alcance definido nunca podr
alcanzar sus objetivos. Es importante tener clara la diferencia entre usuario y

actor. Un actor es una clase de rol, mientras que un usuario es una persona que,
cuando usa el sistema, asume un rol. De esta forma, un usuario puede acceder al
sistema como distintos actores. La forma ms simple de entender esto es pensar
en perfiles de usuario de un sistema operativo. Una misma persona puede
acceder al sistema con distintos perfiles, que le permiten hacer cosas distintas.
Los perfiles son en este caso equivalentes a los actores. Otro sistema que
interacta con el que estamos construyendo tambin es un actor. Por ejemplo, si
nuestro sistema deber generar asientos contables para ser procesados por el
sistema de contabilidad, este ltimo sistema ser un actor, que usa los servicios
de nuestro sistema. Tambin puede ocurrir que el actor sea una mquina, en el
caso en que el software controle sus movimientos, o sea operado por una
mquina. Por ejemplo, si estamos construyendo un sistema para mover el brazo
de un robot, el hardware del robot ser un actor, asumiendo que dentro de nuestro
sistema estn las rutinas de bajo nivel que controlan al hardware. Los actores se
representan con dibujos simplificados de personas, llamados en ingls stick man
(hombres de palo).

Las flechas, que existan en la propuesta original de Jacobson, pero

desaparecieron del modelo semntico de UML, pueden usarse para indicar el flujo
de informacin entre el sistema y el actor. Si la flecha apunta desde el actor hacia
el sistema, esto indica que el actor est ingresando informacin en el sistema. Si
la flecha apunta desde el sistema hacia el actor, el sistema est generando
informacin para el actor. Identificar a los actores es el primer paso para usar la
tcnica de casos de uso. Por ejemplo, en el sistema de pedidos nombrado
anteriormente, sin conocer prcticamente ningn detalle sobre cmo funcionar,
podemos decir que:
1) El grupo de usuarios que ingrese pedidos al sistema ser un actor.
2) El grupo de usuarios que haga otras operaciones con los pedidos, como por
ejemplo autorizarlos, cancelarlos y modificar sus plazos de entrega, ser un actor.
3) Todo grupo de usuarios que reciba ciertos informes del sistema, como por
ejemplo estadsticas de ventas, ser un actor. Es comn que los distintos actores
coincidan con distintas reas de la empresa en la que se implementar el sistema,
o con jerarquas dentro de la organizacin (empleado, supervisor y gerente son

distintos actores, si realizan tareas distintas). Todos los actores participan de los
casos de uso. Ahora bien, es lgico que existan intersecciones entre lo que hacen
los distintos actores. Por ejemplo, un supervisor puede autorizar pedidos, pero
tambin puede ingresarlos.

Es importante notar que el nombre del caso siempre est expresado desde el
punto de vista del actor y no desde el punto de vista del sistema. Por eso el
segundo caso de uso se llama Recibiendo informacin de pedidos y no
Generando informacin de pedidos. Los casos de uso tienen las siguientes
caractersticas:
1) Estn expresados desde el punto de vista del actor.
2) Se documentan con texto informal.
3) Describen tanto lo que hace el actor como lo que hace el sistema cuando
interacta con l, aunque el nfasis est puesto en la interaccin.
4) Son iniciados por un nico actor.
5) Estn acotados al uso de una determinada funcionalidad claramente
diferenciada del sistema. El ltimo punto es tal vez el ms difcil de definir. Uno
podra, despus de todo, decir que todo sistema tiene un nico caso de uso
Usando el Sistema. Sin embargo, la especificacin resultante sera de poca
utilidad para entenderlo; sera como implementar un gran sistema escribiendo un
nico programa. La pregunta importante es: Qu es una funcionalidad
claramente diferenciada? Por ejemplo, ingresar pedidos es un caso de uso y
autorizarlos es otro? Cancelar los pedidos, es otro caso de uso, o es parte del
caso de uso referido al ingreso de pedidos? Si bien se pueden encontrar
argumentos vlidos para cualquiera de las dos alternativas, en principio la
respuesta a todas estas preguntas es que son todos casos de uso distintos.
Lamentablemente, si en la programacin los criterios para dividir la funcionalidad
en programas suelen ser difusos, los criterios para dividir la funcionalidad de un
sistema en casos de uso son an ms difusos, y por esto se hace importante usar
el sentido comn en estas decisiones.
Restricciones, Requisitos y Escenarios
Requisitos.
Son los requisitos funcionales formales que el Caso de Uso debe proveer al
usuario final. Ellos corresponden a las especificaciones funcionales de las

metodologas estructuradas. Un requisito es un contrato de que el Caso de Uso

realizar alguna accin o proveer algn valor al sistema.
Restricciones.
Estas son las reglas formales y las limitaciones bajo las que opera un Caso de
Uso e incluyen las pre-condiciones, las post-condiciones y las invariantes. Una
precondicin especifica qu debe haber ocurrido o estar cumplido antes de que el
Caso de Uso pueda iniciarse. Una post-condicin documenta qu ser verdadero
una vez que el Caso de Uso se complete. Una invariante especifica qu ser
verdadero durante el tiempo en que opere el Caso de Uso.
Escenarios.
Son descripciones formales del flujo de eventos que ocurre durante una instancia
de un Caso de Uso. Usualmente se describen con texto y corresponden a una
representacin textual del diagrama de secuencia.
Organizacin de los Casos de Uso
Los casos de uso pueden organizarse agrupndolos en paquetes, de la misma
manera que se organizan las clases. Los casos de uso tambin pueden
organizarse especificando relaciones de generalizacin, inclusin y extensin
entre ellos. Estas relaciones se utilizan para factorizar el comportamiento comn y
para factorizar variantes (poniendo ese comportamiento en otros casos de uso que
lo extienden). La generalizacin entre casos de uso es como la generalizacin
entre clases. Donde el caso de uso de un hijo hereda el comportamiento y
significado del caso de uso padre; el hijo puede aadir o redefinir el
comportamiento del padre; el hijo puede ser colocado en cualquier lugar donde
aparezca el padre (tanto el padre como el hijo pueden tener instancias concretas).
Por ejemplo, en el sistema de biblioteca puede tenerse el caso de uso Gestin de
Prstamos, responsable del manejo de los prstamos de libros. Adems, podra
haber dos hijos especializados de este caso de uso (Gestin de Prstamos a
Investigadores y Gestin de Prstamos a Estudiantes), los cuales se comportaran
como Gestin de Prstamos, aunque ambos tengan su propio comportamiento.

Como se muestra en la figura anterior, la generalizacin entre casos de uso se

representa con una lnea continua con una punta de flecha. Una relacin de
inclusin entre casos de uso significa que un caso de uso base incorpora
explcitamente el comportamiento de otro caso de uso en el lugar especificado en
el caso base. El caso de uso incluido nunca se encuentra aislado, sino que es
instanciado slo como parte de algn caso de uso ms amplio que lo incluye. La
inclusin puede verse como que el caso de uso base toma el comportamiento del
caso de uso proveedor.
Un Caso de Uso puede incluir la funcionalidad de otro como parte de su
procesamiento normal. Generalmente se asume que los casos de uso incluidos se
llamarn cada vez que se ejecute el camino base. Un ejemplo puede ser listar un
conjunto de rdenes de clientes de las cules poder elegir antes de modificar una
orden seleccionada; en este caso, el Caso de Uso se puede incluir en el Caso de
Uso cada vez que ste se ejecute. Un Caso de Uso puede ser incluido por uno o
ms casos de uso, ayudando as a reducir la duplicacin de funcionalidad al
factorizar el comportamiento comn en los casos de uso que se reutilizan muchas
veces.
Un Caso de Uso puede extender el comportamiento de otro Caso de Uso;
tpicamente cuando ocurren situaciones excepcionales. Por ejemplo, si antes de
modificar un tipo particular de orden de cliente, un usuario debe obtener la
aprobacin de alguna autoridad superior, entonces el Caso de Uso puede
extender opcionalmente el Caso de Uso normal.
Tipos de Casos de Uso
A partir de la aplicacin de los casos de uso en la prctica, aparecen distintas
clasificaciones, que son tiles segn el tipo de sistema o el modelo de ciclo de
vida utilizado.
Esenciales o de Trazo Grueso vs. de Implementacin o de Trazo Fino

Uno de los modelos de ciclo de vida de desarrollo de sistemas que ms

popularidad ha ganado en los ltimos aos es el llamado modelo incremental, en
el cual se van entregando versiones parciales del sistema, que implementan una
parte de su funcionalidad. La recomendacin en este caso pasa siempre por
identificar todos los requerimientos que uno pueda, definir sus prioridades, y
seleccionar cules se van a ir implementado en cada versin. Sin embargo, no se
pueden especificar en detalle todos los requerimientos: debemos tener apenas el
nivel de detalle suficiente para poder definir sus prioridades y comprenderlos en
trminos generales. Para aplicar los casos de uso a desarrollos incrementales,
empezamos por identificar todos los casos de uso del sistema, slo al nivel de su
nombre. Una vez que los identificamos, los expresamos en trazo grueso, esto es:
Ignoramos detalles sobre la forma de la interaccin entre el actor y el sistema.
Slo incluimos las alternativas ms relevantes, ignorando la mayora de los errores
que aparecen en el uso del sistema. No entramos en detalle sobre las acciones
que realiza el sistema cuando el usuario interacta con l. Por ejemplo, si la
empresa tuviera una poltica de descuentos para sus clientes, no es necesario
especificar cmo es esa poltica: nos alcanza con saber que existe una y que debe
ser tenida en cuenta. De esta forma, terminamos con una descripcin gruesa de
todos los casos de uso. Esto me sirve para tomar mejores decisiones, junto con
los usuarios, sobre qu casos de uso implementar en cada fase. Por otro lado,
permite analizar los principales aspectos de todos los casos que afectan al diseo.
Los casos de uso de trazo fino son aquellos que se especifican una vez que se ha
tomado la decisin de implementarlos. En este momento debemos completar
todos los detalles que dejamos pasar: A medida que vamos haciendo prototipos
de las interfaces con los usuarios, incluimos detalles sobre la forma de la interfaz
en la descripcin del caso. Por ejemplo, podemos incluir detalles como: el
operador puede en cualquier momento pasar de la ventana de datos del cliente a
la ventana de datos del pedido. Si bien esto implica anticiparse al diseo, esto no
es negativo, ya que es prcticamente imposible y perjudicial hablar con los
usuarios siempre en trminos de un sistema abstracto. Incluimos otras
alternativas. En particular especificamos todos los errores o excepciones que
provienen de requerimientos de los usuarios. Para esto debemos tener en cuenta
que un sistema tiene dos tipos de errores o excepciones: las que provienen de las
definiciones del negocio y las que provienen del procesamiento interno del
sistema. Por ejemplo, pensemos en un requerimiento del tipo: si un cliente hace
un pedido por un monto mayor al autorizado, se debe rechazar el pedido. Esta
excepcin es claramente un requerimiento, y debe ser incluida en las alternativas
de los casos de uso. Por el contrario, una excepcin del tipo: Si el usuario ingresa
una letra en el lugar del cdigo del producto se le informa que el cdigo de
producto debe ser numrico no debe ser incluida en esta etapa del anlisis.
Especificamos con ms detalle el comportamiento interno del sistema. En nuestro
ejemplo de los descuentos, deberamos especificar cmo es esa poltica, en un
nivel de detalle suficiente para luego poder disear una forma de implementarla
dentro del sistema.
Casos de Uso Temporales

Los casos de uso tienen un actor que los inicia, y uno o ms actores que participan de l. En
muchos casos, el inicio de una determinada funcionalidad del sistema es provocado
exclusivamente por el paso del tiempo. Supongamos que nuestro sistema de ventas debe
generar en forma automtica un conjunto de estadsticas para ser entregadas al directorio de
la empresa el ltimo da hbil de cada mes. En este caso, el paso del tiempo es el que inicia
el caso de uso, y el directorio es el actor del sistema. Sin embargo, para expresar claramente
que es el paso del tiempo el que inicia el caso, podemos incluir un smbolo representando
un reloj en el grfico de casos de uso, o usar una lnea punteada en el borde del valo del
caso.

Casos Primarios Vs. Casos Secundarios

la diferencia entre los casos de uso primarios del sistema y aquellos que no se
corresponden con procesos del negocio y cuya ejecucin slo es necesaria para
que el sistema funcione normalmente.
Supongamos que nuestro sistema requiere de un proceso de depuracin de los
pedidos que ya han sido cumplidos hace ms de 5 aos, para evitar que se
acumulen indefinidamente. El caso de uso por el cual se depuran estos pedidos,
cuyo actor es un Administrador del Sistema, es considerado un caso secundario,
ya que no es central al sistema, sino que es necesario para que el sistema pueda
funcionar sin problemas. En la experiencia se ve que no todos los casos de uso
secundarios se pueden identificar en la etapa de requerimientos, ya que muchos
de ellos dependen de decisiones de implementacin que se toman en la etapa de
diseo.
Caso de uso en un sistema de administracin de una biblioteca comunitaria.
En la perspectiva Orientada a Objetos el principal bloque de todos los sistemas
software es el objeto o clase.
Por ejemplo, considrese una arquitectura sencilla de tres capas para un sistema
de administracin de datos, que involucre una interfaz de usuario, una capa
intermedia y una base de datos.
En esta relacin existe una conexin entre los elementos del modelo, por ejemplo,
la relacin y la generalizacin son relaciones permitiendo que un usuario o entidad
externa al sistema que se modela y que puede interactuar con l, en la interfaz del
usuario aparecen objetos tales como botones, menes, y cuadros de dilogos. En
la base de datos aparecen objetos concretos como tablas que representan
entidades del dominio del problema. En la capa intermedia aparecen objetos como

transacciones y reglas del programa, as como vistas de ms alto nivel de las

entidades del problema.
Visualizar, especificar, construir y documentar y automatizar su construccin.
Trataremos de ejemplificar en trminos generales las caractersticas principales e
introducir los conceptos principales de los diagramas de casos de uso.
Para presentar los conceptos principales se utilizarn ejemplos en donde se ver
cmo se puede modelar un diagrama de contexto y un diagrama de requisitos
utilizando los casos de uso. Estos modelos estn basados en una descripcin en
donde se puede observar la necesidad de automatizacin de una biblioteca que
pertenece a una Comunidad. En dicha automatizacin se destacarn ciertas
necesidades como prstamos, devoluciones y mantenimiento de los libros entre
otros.
Es clave al definir los casos de uso el no especificar como implementarlos. Por
ejemplo, se especifica cmo debera comportarse el Sistema de Administracin de
una Biblioteca Comunitaria mediante casos de uso y la interaccin de los usuarios
con el sistema.
Los casos de uso especifican un comportamiento deseado, mediante un conjunto
de secuencial de acciones, incluyendo las variantes ejecutadas por el sistema,
cada secuencia representa la interaccin de los elementos externos al sistema
(sus actores) con el propio sistema (y sus abstracciones clave). En realidad, estos
comportamientos son funciones a nivel del sistema que se utilizan durante la
captura de requisitos y el anlisis para visualizar, especificar, construir y
documentar el comportamiento del sistema. Por ejemplo, un caso de uso
fundamental en el Sistema de Gestin de Bibliotecas es el procesamiento de
Prstamos de libros para producir el resultado observable, para el usuario.
Un caso de uso involucra la interaccin de actores y el sistema. Un actor
representa un conjunto coherente de roles que juegan los usuarios de los casos
de uso al interactuar con estos. Los actores pueden ser personas o pueden ser
sistemas mecnicos. Un caso de uso puede tener variantes. En cualquier sistema
se pueden encontrar casos de uso que son versiones especializadas de otros
casos de uso, casos de uso incluidos como parte de otros, y casos que extienden
el comportamiento de otros casos de uso bsicos. Se puede factorizar el
comportamiento comn y reutilizable de un conjunto de casos de uso
organizndolos segn estos tres tipos de relaciones. Por ejemplo, cuando se
modela una biblioteca aparecen muchas variaciones del caso de uso bsico de
procesar un prstamo, tales como las diferencias entre procesar un prstamo de
un libro frente a un prstamo que involucre gran cantidad de libros.
Cada opcin, sin embargo, estos casos de uso comparten algo de
comportamiento, como el caso de uso de aprobar el prstamo para muchos libros,
un comportamiento que es parte del procesamiento de cualquier tipo de prstamo.
Los casos de uso se pueden aplicar al sistema completo o se pueden aplicar a
partes del sistema, incluyendo subsistemas e incluso clases e interfaces
individuales. En cada caso, estos casos de uso no solo representan el
comportamiento esperado de estos elementos, sino que tambin pueden utilizarse
como base para establecer casos de pruebas para estos elementos mientras
evolucionan durante el desarrollo del sistema.

Un actor representa un conjunto coherente de roles que los usuarios de los casos
de uso juegan al interactuar con estos. Normalmente, un actor representa un rol
que es realizado por una persona, un dispositivo hardware o incluso otro sistema
al interactuar con nuestro sistema. Se pueden definir categoras generales de
actores (como Lector) y especializarlos (como Estudiante) a travs de relaciones
de generalizacin.
Modelado de los Requisitos de un Sistema
Los requisitos se pueden expresar de varias formas, desde texto sin estructura
hasta expresiones en un lenguaje formal, y en cualquier otra forma intermedia. La
mayora de los requisitos funcionales de un sistema, si no todos, se pueden
expresar con casos de uso, y los diagramas de casos de uso son fundamentales
para manejar esos requisitos.
Para modelar los requisitos de un sistema:
Hay que identificar el contexto del sistema, identificando los actores a su alrededor
Gestin de Consultas- Lector-Gestin de Prstamos-Gestin de Mantenimiento de
Libros-Gestin de Devoluciones-Sistema de Gestin de Biblioteca-EncargadoUsuario.
Caso de uso: Ingresando Bsqueda
Actor: Usuario Biblioteca o Encargado de Biblioteca.
Curso Normal
Alternativas
1 El usuario se comunica con el
sistema y le pide sus preferencias.
2 el sistema obtiene la informacin Si no hay disponibilidad el sistema
mostrando el estado y la disponibilidad. indica cuando est disponible.
3 El usuario realiza la seleccin del
material.
4 El sistema asigna el material.
5 El Encargado entrega material
6 El sistema repite el paso 2

Considerar el comportamiento que cada actor espera del sistema o requiere que
ste le proporcione.
Nombrar esos comportamientos comunes como casos de uso.
Factorizar el comportamiento comn en nuevos casos de uso que puedan ser
utilizados por otros; hay que factorizar el comportamiento variante en nuevos
casos de uso que extiendan los flujos principales.
Modelar esos casos de uso, actores y relaciones en un diagrama de casos de
uso. Adornar esos casos de usos con notas que enuncien los requisitos no
funcionales.
La figura muestra un diagrama de casos de uso. Aunque omite algunas de las
relaciones entre los actores y los casos de uso como as tambin entre casos de

uso debido a las limitaciones de tamao y espacio de este documento, aade

casos de usos adicionales que son invisibles para un usuario normal, aunque son
comportamientos fundamentales del sistema, como son: Gestin de Usuarios y
Gestin de Validacin de tipo de Usuario. El comportamiento de un caso de uso se
puede especificar describindolo de forma textual, se muestra algunas
descripciones de los casos de uso ms importantes para poder relacionar el
enunciado del problema con el diagrama de requisitos.
Las especificaciones de los casos de usos se pueden completar con un flujo de
eventos detallado para una mejor descripcin, comprensin y refinamiento.
Especificacin de Gestin de Consultas: El sistema debe permitir a los lectores
acceder a la informacin sobre los libros que estn disponibles y que posean una
determinada palabra en su ttulo, o que pertenezcan a un cierto autor.
Especificacin de Gestin de Mantenimiento de Libros: El sistema debe permitir al
encargado de la biblioteca poder introducir informacin para gestionar el
mantenimiento de los libros. Dicha informacin debe tener en cuenta que
biblioteca clasifica los libros como libros de texto, de referencia.
El prstamo de los libros puede ser de sala o para sacarlos de la Biblioteca. Los
libros de referencia no se pueden sacar de la biblioteca.
El encargado debe poder dar de altas y bajas de libros.
Especificacin de Gestin de Interfaz de Usuario: El sistema debe proveer una
interfaz de usuario que debe ser reutilizable y fcil de usar. Para esto, la interfaz
debe estar formada por los siguientes elementos: menes, ventanas de dilogos y
ventanas de salida. El men permitir al usuario elegir entre varios sub-menes.
Los sub-menes a su vez estarn formados por opciones o tems. Las diversas
opciones permitirn ejecutar las funciones o acciones de la aplicacin que utilice la
interfaz. Las ventanas de dilogos servirn para que el usuario introduzca una
informacin de entrada en la aplicacin. Un dilogo tendr una o ms lneas de
entrada para introducir informacin. Las ventanas de salida permitirn mostrar
resultados y mensajes a los usuarios. Se pueden tener abiertas varias ventanas,
cada una de ellas identificada por un ttulo. Especificacin de Gestin de
Validacin Tipo de Usuario: El sistema debe poder validar e identificar el tipo de
usuario que se conecta al sistema. Los tipos de usuarios son: Lectores y
Encargados de biblioteca. Los lectores de la biblioteca se clasifican en dos
categoras Interno y Externo. Especificacin de Gestin de Usuarios: El sistema
debe poder gestionar las altas, bajas y modificaciones de usuarios teniendo en
cuenta las caractersticas de estos. La gestin de usuarios la realiza el usuario
encargado de la biblioteca. Especificacin de Gestin de Prstamos: El sistema
debe poder gestionar los prstamos de los libros teniendo en cuenta las
caractersticas de los libros y de los lectores. Adems, es de especial inters que
la aplicacin controle las fechas del prstamo. La gestin de prstamos debe ser
realizada por el usuario encargado de la biblioteca. Especificacin de Gestin de
Devoluciones: El sistema debe poder gestionar las devoluciones teniendo en
cuenta controlar las fechas del prstamo y devolucin. La gestin de devoluciones
debe ser realizada por el usuario encargado de la biblioteca.

2 Calidad de las soluciones Planteadas.

La funcin principal en la construccin o implementacin de la aplicacin,
mediante unos requisitos que permita interpretar y documentar las necesidades
del cliente y el usuario en cuanto a la bsqueda y gestin de material bibliogrfico
siendo una aplicacin amigable, relevante y funcional.
Para la realizacin de la aplicacin se requiere identificar las necesidades del
usuario para proponer soluciones que satisfagan dichas necesidades.
Encontrar el alcance de los requisitos funcionales, las restricciones del sistema, el
anlisis y la validacin del documento de requerimientos para asegurar la
consistencia, complecin y viabilidad de la aplicacin.
Documentar las soluciones planteadas mediante prototipos, casos de uso,
atributos y requisitos del sistema.
Verificable de acuerdo con las restricciones de tiempo y recursos disponibles.
.

Bibliografia.
Ivar Jacobson y otros. Object Oriented Software Engineering. A Use Case Driven
Approach.
Addison Wesley, 1992
Doug Rosenberg with Kendall Scott, Use Case Driven Object Modeling with UML.
ISBN: 0-201-43289-7. Publisher:
Addison-Wesley Geri Scheider, Jason P. Winters, Applying Use Cases ISBN: 0201-30981-5. Publisher: Addison-Wesley