Teoria_IPP_CU_2008_Parte_1 - Paola Hernández

Vista previa del material en texto

Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 1
1Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Introducción a Requerimientos 
con Casos de Uso
Rosario, agosto de 2008
Luciano Ripani
Enrique Porta
Cátedra Introducción a la 
Práctica Profesional 
UTN - FRRo
Ingeniería en Sistemas de Información
2Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Objetivos de esta presentación
• Conocer los aspectos teóricos relacionados con el 
modelado de requisitos dentro del proceso unificado (RUP)
• Integrar los conceptos de requerimientos con los C.U.
• Proveer una base teórica sobre especificación de 
requerimientos y redacción de casos de uso.
Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 2
3Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Definición requisitos (requerimientos)
Requisito (requerimiento): es algo que el sistema debe hacer o 
una cualidad que el sistema debe tener
Tipos de requisitos(FURPS)
Requisitos Funcionales=> Lo que el sistema debe hacer
• Funcional: Características, capacidades y seguridad (Functional)
Requisitos No Funcionales(atributos de calidad) => Lo que el sistema debe 
tener
• Facilidad de uso: factores humanos, ayuda, documentación (Usability)
• Fiabilidad: frecuencia de fallos, capacidad de recuperación a una falla
(Reliability )
• Rendimiento: tiempos de respuesta, precisión, uso de recursos 
(Performance)
• Soporte: adaptabilidad, facilidad de mantenimiento, internacionalización,
configurabilidad) (Supportability )
4Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Requerimientos (ejemplos)
Ejemplo de requisitos no funcionales de un grifo (Mastering the
Requirements Process)
Facilidad de mantenimiento (maintainability): El producto tendría que permitir 
cualquier mantenimiento de rutina (tal como el cambio de una arandela) para ser completada 
en menos de 4 minutos por un operador hábil.
Seguridad (security):El producto no tendría que ser operado por un niño chico.
Cultural (cultural): El giro tendría que ser en la dirección dictada por la región.
Legal (legal):El producto tendría que conformar al código de instalaciones vigente.
Aspecto y presentación (look and feel): el producto tendría 
que parecer fácil de manejar.
Facilidad de uso o Usabilidad (usability): el producto 
tendría que ser apto para se usado por alguien con las manos 
mojadas.
Rendimiento (performance): El flujo de agua máximo tendría 
que ser alcanzable con dos giros con la mano.
Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 3
5Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Requerimientos (ejemplos)
Ejemplo de Requisitos No Funcionales sistema de 
préstamos en una biblioteca
Facilidad de Uso
· La búsqueda de los libros en el puesto de consulta debe ser amigable al 
usuario y contará con ayuda.
Rendimiento
· Un préstamo o una devolución de un libro deberán realizarse en menos de 30 
segundos.
6Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Requerimientos (ejemplos)
Ejemplo de Requisitos No Funcionales sistema de punto 
de venta (Larman)
Facilidades de uso
• El cliente será capaz de ver la información en un gran monitor del PDV (Punto
de Venta). Por tanto, Se debe ver el texto fácilmente a una distancia de un metro
• Velocidad, comodidad y procesamiento libre de errores.
• Se deben comunicar los avisos con sonido.
Rendimiento
• Conseguir la autorización de pago en menos 
de un minuto, el 90 % de las veces
Soporte -Adaptabilidad
o El sistema se tiene que poder adaptar a las 
diferentes reglas de negocio de los diferentes 
clientes
Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 4
7Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Especificación de Requerimientos: su Importancia
8Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
UML - Definición
El Lenguaje Unificado de Modelado es un lenguaje para 
especificar, visualizar, construir y documentar los artefactos de 
los sistemas software, así como para el modelado del negocio y 
otros sistemas no software.
Integración de 
Grady Booch –
Jim Rumbaugh (OMT) –
Ivar Jacobson (OOSE)
El UML es adoptado como 
estándar por OMG.
OMG � Object Management Group 
www.omg.org
Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 5
9Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Diagramas UML
10Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Historia del UML
Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 6
11Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Contribuciones al UML
12Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Evolución del UML
Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 7
13Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
RUP (Proceso Unificado) - Fases y disciplinas
14Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
RUP – Aspectos clave
• Proceso Dirigido por los Casos de Uso
– Los C.U. expresan requerimientos sobre la funcionalidad del sistema y 
modelan el negocio como contexto del sistema
– Se definen C.U. para el sistema, y se los usa como base para el proceso 
de desarrollo completo
• Proceso Dirigido por Riesgos (Iterativo e Incremental)
– Administración de riesgos integrada al proceso de desarrollo
– Las iteraciones se planean basándose en los riesgos de mayor prioridad
• Proceso Centrado en la Arquitectura
– La arquitectura es el artefacto primario para conceptualizar, construir, 
gestionar, y evolucionar el sistema
– Consiste de múltiples y coordinadas vistas (modelos) de la arquitectura
Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 8
15Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Un proceso define ...
16Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
RUP – Elementos Básicos
Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 9
17Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Workflow overview (requerimientos)
18Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Workflow details
Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 10
19Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Definición de Caso Uso
“ Un C.U. especifica una secuencia de acciones , 
incluyendo variantes , que el sistema puede ejecutar y 
que produce un resultado observable de valor para un 
actor en particular ”
(I. Jacobson – 1999)
C.U. 3: Vender en mostrador1. El vendedor ingresa datos del cliente y de los artículos.
2. El sistema registra los datos y emite la factura en la terminal del cajero.
3. El cajero ingresa la forma de pago, y el sistema registra la factura como paga.
Alternativas:
1.a No hay stock de alguno de los artículos: 
1.a.1 El sistema notifica los artículos con faltante de stock
1.a.2 El vendedor modifica el pedido
3.a El cliente expresa que no le alcanza el dinero:
3.a.1 El cajero ingresa al sistema la orden de anulación de la factura.
3.a.2 El sistema anula la factura
20Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Otras Definiciones
• “Un C.U. cuenta una historia de un actor alcanzando una meta, o un 
conjunto de historias tanto alcanzando como fallando en la meta” (A. 
Cockburn - 1998 parafraseado)
• Un C.U. “describe cómo usa el sistema un actor para lograr una 
meta, y qué hace el sistema por el actor para lograr esa meta. 
Cuenta una historia de cómo el sistema y sus actores colaboran para 
entregar algo de valor para al menos uno de los actores” (K. Bittner –
2003)
• Es una descripción desde el punto de vista del usuario de lo que 
hace el sistema
Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 11
21Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
C.U. – Bibliografía utilizada en la cátedra
Hay distintas corrientes en teoría sobre C.U.; en la cátedra trabajaremos con 
los siguientes autores :
Ivar Jacobson -
Creador de los Casos de 
Uso
Object Oriented Software 
Engineering: A Use Case 
Driven Approach – 1992
Alistair Cockburn -
Writing Effective Use Cases 
– 2001
Craig Larman -
UML y Patrones – 2002 / 2004
Como estos autores no 
dicen exactamente lo 
mismo ...
Hay apuntes de cátedra, y el 
documento de políticas de la 
cátedra (obligatorio para parciales y 
exámenes)
22Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Nuestro Proceso para Especificar Requerimientos
Combinamos
RUP y Cockburn obteniendo lo 
mejor de ambos 
mundos.
Agregando prácticas 
derivadas de
experiencias reales en 
proyectos.
Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 12
23Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Cómo escribir un C.U.
UML no especifica como el texto del caso de uso debe ser 
estructurado, organizado o escrito.
La forma de escribir un caso de uso tendrá gran impacto de la 
facilidad para especificar, diseñar y testearlo (o no) 
Hay distintos formatos de un caso de uso:
• Texto del caso de uso (hay muchas variantes)
• Diagramas de caso de uso
• Diagrama de estados
• Diagrama de actividad
En la descripción de los casos de uso en formato de texto 
adoptamos la forma de escribir los Casos de Uso propuesta de 
Cockburn
24Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
C.U. - Como texto
Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 13
25Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Diagrama de C.U.
26Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
C.U. - Diagrama de Estado
Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 14
27Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
C.U. - Diagrama de Actividad
28Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Stakeholder (interesado) (i)
Cualquiera que es (o podría ser) materialmente afectado por los 
resultados del sistema (RUP – 2003)
Los Stakeholders generalmente caen dentro de las siguientes categorías:
• Usuarios: los más obvios tipos de stakeholders son los usuarios reales de un 
sistema.
• Sponsors: Gerentes de Negocio, financistas, líderes de departamentos,
vendedores, accionistas, y otras personas que invierten en la producción del
sistema. Estos stakeholders son sólo usuarios indirectos del sistema o bien 
están afectados solamente por las salidas de negocio que el sistema induce.
Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 15
29Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Stakeholder (interesado) (ii)
• Desarrolladores: Gerentes de proyecto, Testers, empleados de soporte, de
mantenimiento del sistema, diseñadores, codificadores, y cualquier otro tipo 
de desarrollador involucrado en la producción y soporte del sistema.
• Autoridades: Expertos en un aspecto en particular del dominio del 
problema o la solución. Pueden ser autoridades legislativas, expertos en el 
dominio, expertos en tecnología, etc.
• Clientes: La gente y/o las organizaciones quienes estarán en realidad
adquiriendo el sistema final. Estos pueden ser los compradores, evaluadores,
contadores, y agentes actuando a favor de las organizaciones de compra.
30Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Cómo identificar a los Stakeholders (i)
• ¿Quién se verá afectado por el éxito o fracaso de la solución nueva?
• ¿Quiénes son los usuarios del sistema?
• ¿Quién es el comprador del sistema?
• ¿Quién es el sponsor del desarrollo?
• ¿Quiénes se verán más afectados por el resultado final que produce 
el sistema?
• ¿Quién evaluará y firmará la aprobación del sistema cuando se 
entregue y se despliegue?
• ¿Hay otros usuarios internos o externos del sistema cuyas 
necesidades deben tomarse en cuenta?
Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 16
31Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Cómo identificar a los Stakeholders (ii)
• ¿Hay cuerpos regulatorios o estándares organizacionales los cuales 
el sistema deberá obedecer?
• ¿Quién desarrollará el sistema?
• ¿Quién instalará y mantendrá el nuevo sistema?
• ¿Quién tendrá actividades de soporte y suministrará entrenamiento 
para el nuevo sistema?
• ¿Quién testeará y certificará el nuevo sistema?
• ¿Quién venderá y pondrá en el mercado al nuevo sistema?
• ¿Hay alguien más?
32Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Actor
Define un conjunto de roles que pueden asumir los usuarios del 
sistema, al interactuar con el mismo. (RUP – 2003)
• Es alguna persona o cosa que interactúa con el sistema. 
• Representa un rol y no un individuo particular. 
• Puede ser una persona, otro sistema o un dispositivo
Vender en
mostrador
Vendedor
Cajero
Cliente
Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 17
33Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Un actor, también puede ser un sistema
34Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Clasificación de Actores
Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 18
35Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Ejemplos clasificación – Actores (i)
36Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Ejemplos clasificación – Actores (i)
Introducción a Requerimientoscon Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 19
37Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Ejemplos clasificación – Actores (iii)
38Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Documento Visión
Propósito: capturar el foco del producto, las necesidades del 
stakeholder , las metas y objetivos, los mercados a los que apunta, 
los ambientes de los usuarios , las plataformas apuntadas, y las 
características del producto a construirse. 
• Comunica los “Qué´s y Por qué´s” fundamentales relacionados al 
proyecto
• Provee:
• Una base de alto nivel (a veces contractual) para los requerimientos 
técnicos más detallados.
• Ingresa al proceso de aprobación del proyecto (y así es relacionado 
inmediatamente con el caso de negocio)
• Un vehículo para la extracción inicial de la retroalimentación con el 
cliente.
• Un punto para establecer el alcance y prioridad de las características 
del producto.
Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 20
39Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Documento Visión
Como el documento de visión se usa y se revisa por una amplia 
variedad de personal involucrado , el nivel de detalle deber ser 
bastante general para todos para entenderlo. Sin embargo, suficiente 
detalle debe estar disponible para proveer al equipo la información 
necesaria para crear un modelo de casos de uso y especificaciones 
suplementarias.
• En IPP utilizaremos una versión adaptada del documento Visión, 
basada en RUP.
• Documentos en el eGroup:
– Ejemplo: ART_REQ_11_Vision_Caso_Biblioteca_2008
– Plantilla: ART_REQ_11_Vision_Plantilla_IPP_2008
40Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Documento Visión (secciones)
1 Introducción 
2 Posicionamiento 
2.1 Sentencia que define el problema 
2.2 Sentencia que define la posición del Producto 
3 Descripción de Interesados (Stakeholders) 
3.1 Resumen de Interesados (Stakeholders) 
3.2 Resumen de Usuarios
4 Descripción global del producto 
4.1 Descripción de límites Casos de Uso 
4.1.1 Descripción de límites C.U. de Metas Principales 
4.1.2 Descripción de límites C.U. de Metas Complementarias 
5 Restricciones 
6 Otros Requisitos (Atributos de calidad) 
7 Historia de Versiones
Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 21
41Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Documento Visión (secciones comunes)
1 Introducción 
1.1 Propósito del documento
[Para qué sirve este documento]
1.2 Alcance 
[Ámbito al que se refiere el documento. Ej: a qué pr oyecto, empresa, etc.]
1.3 Definiciones, Acrónimos, y Abreviaciones 
[Otros documentos del proyecto que tienen relación con el Visión. Por ejemplo: Glosario]
1.4 Documentos relacionados 
[Otros documentos del proyecto que tienen relación con el Visión. Por ejemplo: Glosario]
1.5 Visión general del documento
[Describe lo que contiene el resto del documento de Visión y explica cómo está organizado el 
documento]
7 Historia de Versiones
[Describe la historia de cambios realizados al docu mento. Indicando versión, autor, fecha, y 
breve descripción del cambio]
42Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Documento Visión (sección 2)
Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 22
43Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Documento Visión (sección 2)
44Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Documento Visión (sección 3)
Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 23
45Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Documento Visión (sección 4)
46Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Documento Visión (sección 5 y 6)
Ahora veremos el ejemplo sobre el caso de Biblioteca:
– ART_REQ_11_Vision_Caso_Biblioteca_2008
Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 24
47Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Casos de Uso y Escenarios de Uso
• Un escenario es una secuencia específica de acciones e 
interacciones entre los actores y el sistema. Un escenario es una 
historia particular del uso del sistema.
• Un escenario es una instancia del caso de uso. Un caso de uso es
una colección de escenarios.
• Un caso de uso es una colección de escenarios con éxito y fallo 
relacionados, que describe a los actores utilizando un sistema 
para satisfacer una meta o abandonarla.
48Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
C.U. Prestar libros como diagrama de estado
Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 25
49Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
• Se tendrá un escenario para cada una de las combinaciones de pasos que puedan ocurrir
• Camino básico: es el escenario mas frecuente
Detalle de escenarios de uso
50Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Caminos Alternativos
• El camino básico es un escenario que se elige por convención
• Criterios:
• El primero que describe el usuario
• El mas probable o con mayor frecuencia
• El que parezca mas normal
• El escenario del camino básico siempre cumple la meta
• Entre los escenarios descriptos por medio de caminos alternativos habrá
escenarios que terminan alcanzando la meta y escenarios que terminan no 
alcanzando la meta.
• Hay alternativas que retoman el camino básico y otras que terminan el caso de 
uso
Introducción a Requerimientos con Casos de Uso Ago / 2008
Cátedra IPP – UTN Rosario Autores: Luciano Ripani -Enrique Porta 
Pag. 26
51Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Detección de Caminos Alternativos
Como descubrir caminos alternativos:
• Puede haber formas alternativas de alcanzar la meta
• Cualquier paso pude fallar
• Cualquier paso del camino alternativo también puede fallar
52Enrique Porta - Luciano Ripani
D
IS
I 
-
U
T
N
 R
os
ar
io
04/08/2008 v. 1.02 [LRI 2/8/08]
Caminos Alternativos - Ejemplo