Ingeniería de Requisitos

Tema 5. Modelando Requisitos Funcionales

con Casos de Uso

Raquel Anaya
ranaya@eafit.edu.co

El proceso de requisitos

Actividad 1. Comprender el problema

Actividad 2. Elicitar requisitos

Actividad 3. Definir requisitos

Actividad 4. Analizar requisitos

Actividad 5. Verificar requisitos

1
 Actividad 1. Comprender el problema

Es conveniente tener un acercamiento global previo del contexto
en el que se va a construir el sistema.

Técnicas como los mapas conceptuales permiten dar claridad al
problema, conocer los términos relevantes del contexto y sus
relaciones con otros términos.

Se pueden utilizar diferentes diagramas de UML que
representan el entendimiento del negocio desde diferentes
perspectivas

Alternativa 1: Modelos de dominio que describe conceptos de
negocio y sus relaciones (vista estructural)

útil para establecer un vocabulario común

Se utiliza el diagrama de clases

¡ no se trata de definir los detalles de representación!

Comprender el problema (1)

Alternativa 2: Modelos que permite comprender los procesos de negocio
de la organización (vista del proceso)

Diagramas UML que pueden ser utilizados:

Diagramas de casos de uso: Describe el contexto del negocio;

unidades organizacionales y los procesos con los cuales

interactúa

Diagramas de secuencia: Describe el flujo de información entre

los involucrados en un proceso. Los objetos se corresponden a

roles responsables

Diagrama de actividades: Describe el flujo que sigue un proceso

de negocio

Diagrama de transición de estados: Describe condiciones

relevantes de un objeto desde la perspectiva del negocio

2
 Comprender el problema (2)

El Modelado del Negocio puede ser un proceso
independiente realizado por los analista de negocio
sin que necesariamente se vaya a construir un
sistema software

En aplicaciones orientadas a servicios para definir
nuevos esquemas de negocio es muy importante

Tener una vista de alto nivel de los recursos de TI en la
organización y sus relaciones: Arquitectura Empresarial

Precisar los procesos de negocio que van a ser
intervenidos y el alcance de la integración

6/14/2009 5

Notación del diagrama de casos de uso

para modelar el negocio

Tomado de:
Business Modeling with the UML and Rational Suite AnalystStudio
A Rational Software White Paper

3
 Actividad 2. Levantar los requisitos
candidatos

2.1 Planear sesiones de interacción con los
usuarios

Seleccionar un grupo de usuarios representativo

Seleccionar la (s) técnica (s) para levantamiento de
requisitos:

Entrevistas

Sesiones JAD (Joint Application Development)

Lluvia de ideas

2.2 Llevar a cabo las sesiones de interacción
con el propósito de obtener lista de requisitos
candidatos

2.2 Obtener lista de requisitos

candidatos

Cada características deseables del sistema es redactada
como un item independiente.

Cada característica definida contiene la siguiente
información:

Código del requisito: El código puede distinguir el tipo de
requisito (RI, RF, RR, RN, RNF). Ejemplo: RI-001, RNF-
110

Versión y Autor

Fuentes de donde se obtuvo

Dependencias del requisito con objetivos, requisitos y

restricciones

Descripción

Importancia: Impacto del requisito en el negocio

Urgencia: Necesidad del requisito para las operaciones

del negocio

Estado: Etapas por las que el requisito evoluciona
(propuesto, aprobado, incluido, validado, eliminado)

Estabilidad:

4
 Plantilla de definición de requisito funcional
(REM)

RF-007 Alquilar película

Versión 1.1
Autores Pedro Pérez
Fuentes Camila Restrepo
Dependencias OBJ-003 Gestión de alquileres
RI-001 información sobre socios
RI-002 Información sobre películas
RN-003 Regla de condiciones de alquiler de la película
Descripción El sistema deberá permitir el alquiler de una o varias películas por parte de un socio:
Importancia Alta
Urgencia Inmediata
Estado Propuesto
Estabilidad Media
Comentario ninguno

3. Definir requisitos funcionales por medio de

casos de uso
 Características de los casos de uso
 Modelo que representa las funciones del
sistema y los actores involucrados
 Técnica para capturar información de cómo un
actor interactúa con un sistema
 Descripción de una secuencia de acciones
realizadas por el sistema que representan un
resultado observable para un actor (o actores)
 Originador: Ivar Jacobson

5
 Casos de Uso - Elementos

Actor: Elemento que interactúa con el Sistema

no forma parte del sistema

papeles que desempeñan las personas

sistemas de cómputo

aparatos eléctrico o mecánicos

usuarios receptores de información

Caso de Uso: Forma de usar el sistema

unidad de trabajo del usuario

conjunto de pasos delimitados con un comienzo y un fin

identificables

secuencia de acciones realizadas por un sistema que

produce un resultado observable de valor para un actor

Casos de Uso - ejemplo1

Verificar Situación
Vendedor

Realizar Venta

Secretaria
Cliente

Preparar Catálogo

Supervisor
Establecer Crédito

6
 Pasos para la definición del caso
de uso

Act. 3.1 identificar actores (analista de
sistemas)

Act. 3.2 identificar casos de uso (analista de
sistemas)

Act. 3.3 realizar una descripción de alto nivel

Act. 3.4 definir el glosario de términos

3.1 Encontrando actores

Preguntas claves para encontrar actores

Qué grupos de usuarios necesitan apoyo del sistema informático
para realizar sus tareas?

Qué grupos de usuarios son responsables de ejecutar las funciones
relevantes del sistema

Qué usuarios realizan labores secundarias de mantenimiento y
administración?

Interactuará el sistema con algún dispositivo o sistema externo?

Algunos actores que se caracterizan con estereotipos
especiales

<<system>>: Para representar un sistema externo

<<timer>>: Para representar una actividad interna del sistema

Los actores pueden formar estructuras jerárquicas. Sirve para
simplificar relaciones con los casos de uso

7
 Actores vs Frontera del sistema
El cliente interactúa
con el sistema software
a través de un agente

El cliente interactúa
directamente con el
sistema software

15

3.2 Encontrando caso de uso

El nombre de los casos de uso deben representar acciones en
el contexto del usuario

Evitar en esta etapa la definición de casos de uso CRUD:
concentrarse en acciones que reflejen comportamiento
transaccional

Generalmente el caso de uso representa un comportamiento
observable por el actor

Preguntas claves para encontrar casos de uso

Cuáles son las tareas primarias que el actor desea que el sistema
realice?

Cuales son las operaciones encargadas de crear, modificar, eliminar o
consultar información en el sistema?

Necesitan el actor ser informado acerca de eventos que ocurren en el
sistema?

Necesita el actor informar al sistema acerca de cambios externos?

Necesita el actor realizar operaciones de mantenimiento, auditoria y/o
soporte?

8
 Algunas consideraciones en la notación de
casos de uso
Uso de dirección en la relación:
La dirección de la relación indica el papel
Actor 2 (primario o secundario) del actor
Actor 1

Actor 2
Actor 1

Actor 2
Actor 1

Precisar el papel de actores primarios en el caso de uso:

Alternativa 1: Uno de los actores es el iniciador de la acción: no interactúa
directamente con el sistema software
Alternativa 2: Ambos actores toman parte activa de la interacción: cada uno de
ellos percibe un escenario diferentes de la interacción

3.3 Realizar una descripción inicial del caso

de uso

Definir la información básica del caso de uso

Asegurar que se han identificado todos los
casos de uso relevantes: Ver primero el
bosque y después los árboles

Si es un sistema complejo los casos de uso
deben agruparse por paquetes

Para discutir: Relación entre los casos de uso
y los requisitos funcionales

9
 Información básica del caso de uso - ejemplo
Caso de uso: Comprar Producto
Actores: Cliente, Cajero
Descripción: Un cliente llega a la caja registradora con los artículos
que comprará. El cajero registra los artículos y cobra el importe.
Al terminar la operación el cliente se marcha con los productos
Precondición: El producto se encuentra en el inventario
Postcondición: Se ha registrado un compra y se ha disminuido el
inventario
Requisitos / Objetivos relacionados

Ver plantillas de definición de casos de uso

Según propuesta de REM
Según propuesta de RUP

Efecto del caso de uso

Estado del mundo

antes de ejecutar
el caso de uso

Ejecución Estado del mundo

Precondiciones del CU después de ejecutar
el caso de uso

Postcondiciones
6/14/2009 20

10
 Actividad 4. Analizar requisitos

Objetivo del análisis de requisitos: Profundizar sobre los
requisitos definidos con el propósitos de

Detectar conflictos

Definir las fronteras del software y su interacción con el

contexto

El análisis de requisitos funcionales utilizando casos de uso
puede verse como una siguiente iteración sobre el modelo de
casos de uso definido en la actividad anterior

Act. 4.1 Priorizar los casos de uso (arquitecto)

Act. 4.2 Detallar el caso de uso (especificador de casos de uso)

Act. 4.3 Estructurar el modelo de casos de uso (analista de
sistemas)

Act. 4.4 Definir la primera versión de los casos de prueba

Act. 4.5 Definir operaciones del sistema

4.1 Priorizar los casos de uso

Lograr un acuerdo en la relevancia del caso de uso en
la arquitectura del sistema y su prioridad de
desarrollo

Objetivo: Desarrollar los casos de uso de acuerdo a su
relevancia en la definición de la arquitectura

Casos de uso complejos pueden ser planificados para
ser desarrollados en mas de una iteración

Aspectos que se deben considerar de un caso de uso para encontrar su
impacto en la arquitectura

Prioridad: Crítico, importante, secundario

Nivel de riesgo asociado a la implementación: crítico, significativo,
normal

Relevancia del caso de uso: (a) desde la perspectiva del cliente (b)
desde la perspectiva del arquitecto

11
 4.2 Detallar un caso de uso

Descripción extendida del caso de uso: Contiene mayores detalles.
Describe el curso flujo de eventos o diálogo que se sucede entre el
actor y el sistema

Se precisa el comportamiento observable del sistema por parte de los
actores (qué) sin detallar la manera como el sistema realiza las
operaciones (cómo)

Un caso de uso representa un conjunto de escenarios

Cada escenario es representado por medio de flujos de eventos

Flujo básico: Representa la secuencia normal de eventos. Flujo

de excepción: Representa una secuencia que interrumpe la

interacción; generalmente involucra la emisión de un mensaje de
error para el usuario

Flujo alternativo: Representa caminos alternos que se siguen por

condiciones propias de la interacción

Enfrentando la complejidad de un caso de

uso
Inicio proceso
Flujo básico

Flujo alternativo 3
Flujo alternativo 1

Flujo alternativo 4 Flujo alternativo 2

Fin proceso Fin proceso

Fin proceso
Flujo básico. Representa el escenario simple del caso de uso (el
escenario del día feliz)
Flujo alterno. Representa comportamiento opcional o excepcional

12
 Algo acerca de los escenarios…

Los escenarios tienen diferentes propósitos y se pueden
utilizar en diferentes puntos del proceso de desarrollo

Escenarios reales: Como herramienta para entender el

sistema actual y la forma como las personas realizan las

acciones dentro de un proceso de negocio

Escenarios visionarios: Como herramienta para describir el

flujo de eventos de un sistema futuro: son los escenarios

utilizados para instanciar un caso de uso

Escenarios de evaluación: Describen las tareas del usuario

contra las que se va a evaluar el sistema. Útiles para definir

los casos de prueba

Escenarios de entrenamiento: Descripciones que guían a los

usuarios en el uso del nuevo sistema.

Detallando el caso de uso: una segunda

iteración

Identificación del caso de uso

Título

Actores que participan (destacar el actor iniciador)

Requerimientos funcionales que soporta el caso de uso

Precondiciones: condiciones que deben ser ciertas al iniciar el
caso de uso

Postcondiciones: condiciones que deben ser ciertas al finalizar
el caso de uso

Relaciones con otros casos de uso

Requerimientos no funcionales asociados

Flujo de evento básico

Flujo de eventos alternos

Relaciones entre casos de uso

13
 Ejemplo de descripción de un escenario

Flujo Básico para el caso de uso Retirar Dinero en Cajero

1. El caso de uso inicia cuando el cliente se acerca al cajero para realizar una operación

2. El sistema pide al cliente el número de identificación personal (PIN)

3. El cliente introduce el PIN y confirma la entrada

4. El sistema comprueba la validez del PIN

5. El sistema muestra lista de operaciones disponibles

6. El cliente selecciona la operación de retiro de fondos

7. El sistema muestra ventana para capturar cantidad a retirar

8. El cliente digita valor a retirar y da la opción de continuar

9. El sistema verifica que tenga la cantidad de dinero solicitada por el cliente

10. El sistema verifica que se cumpla la regla de Tope de Retiro Permitido (RN-002)

11. Si el valor a retirar es mayor que el saldo de la cuenta realiza el caso de uso
Retiro con Sobregiro

12. El sistema actualiza el saldo de la cuenta y genera el movimiento de impuesto de
acuerdo a regla RN-001 del documento de especificaciones.

13. El sistema activa el dispensador de billetes

14. El cliente retira el dinero

15. El sistema entrega recibo de la transacción y muestra mensaje de finalización

Ejemplo de descripción de un escenario… continuación

Flujo Alterno: Clave Inválida

3a. Si el cliente introduce un PIN inválido, el caso de uso vuelve a
empezar. Si esto ocurre tres veces en la sesión, el sistema cancela
la transacción completa, impidiendo que el cliente utilice el cajero
durante 60 segundos

Flujo Alterno: Cajero Sin Dinero

9a. Si el dispensador de billetes no tiene suficiente dinero se emite
mensaje “Temporalmente fuera de servicio... Intente mas tarde”.

9b. El sistema envía notificación del evento al sistema Monitor del
Cajero

9c. Fin del flujo

Flujo Alterno: Retiro Mayor que Monto Permitido

10a. Si el valor a retirar es mayor que el monto permitido para retiro
desde cajero (ver regla de negocio RN-002) se emite mensaje
“Monto excede el máximo permitido desde el cajero”. Fin del flujo.

10b. Si en el mismo día ya el cliente ha retirado el tope diario
permitido (ver regla de negocio RN-002) se emite mensaje “Monto
excede el máximo permitido de retiro diario”. Fin del flujo.

14
 Ejemplo de descripción de un escenario… continuación

Retiro con sobregiro (Caso de uso que extiende)

Resumen: Este caso de uso inicia cuando es invocado por
otro con el propósito de controlar un retiro mayor que el
saldo actual

Flujo básico:

1. El sistema verifica si el cliente tiene crédito automático.

2. El sistema emite mensaje para confirmación del crédito

3. El usuario aprueba la activación del crédito automático

4. El sistema continua el flujo normal en el siguiente paso

Flujo de excepción

1a. Si el cliente no tiene crédito automático emite mensaje
“Fondos insuficientes” Fin del flujo

Consideraciones en la descripción
de flujos

El primer paso del caso de uso debe contener la acción del
contexto que da inicio a la interacción:

Este caso de uso se inicia cuando…

Las reglas del negocio se describen en un documento

independiente : no es conveniente describirlas al detalle en la
descripción de un paso; se hace la referencia donde sea
necesario

Ejemplo: El sistema valida que el cliente pueda hacer el

préstamo de acuerdo a la regla de negocio RN-005: Regla de

Validez del Cliente

Evitar la descripción detallada de todos los datos que son
reportados por el usuario: hacer uso de referencia a un requisito
de información. Ejemplo: El cliente digita la información
asociada a la venta del vehículo de acuerdo al RI-004

15
 4.3 Estructurar el modelo de casos
de uso

Objetivo: Analizar la complejidad del caso de uso y
detectar secuencias repetitivas u opcionales en su
descripción

El caso de uso se describe como un conjunto de
secuencias relacionadas: un caso de uso base y uno o
mas casos de uso alternos

Tipo de relaciones entre los casos de uso

Relaciones de inclusión / uso (<<include>>) entre casos de uso

Relación de extensión (<<extend>>) entre casos de uso

Relación de generalización entre casos de uso o entre actores

Relaciones entre casos de uso:

Relación de inclusión

El caso de uso base incorpora explícitamente el comportamiento de otro
caso de uso.

El caso de uso incluido no se encuentra aislado: se instancia sólo a partir
de un caso de uso base.

Uno de los pasos del caso de uso base debe realizar la invocación del
caso de uso incluido

Una vez ejecutada la secuencia del caso de uso incluido, retorna control
al paso siguiente del flujo base

Caso de uso base

<<Include>>

Caso de uso incluido

16
 Relaciones entre casos de uso:
Relación de extensión

Se amplia el comportamiento del caso de uso base con otro
comportamiento

Describe comportamiento opcional del sistema

El flujo base define de manera precisa la condición que hace que se
ejecute el caso de uso que extiende

Una vez ejecutada la secuencia del caso de uso incluido, retorna control
al mismo paso de donde fue llamado
Flujo de eventos
Caso de uso base

ReservarLibro

Punto de extensión
<<Extend>>

DenegarReserva Caso de uso que extiende

Relaciones entre casos de uso:

Relación de generalización

El caso de uso hijo hereda el comportamiento y el
significado del caso de uso padre

El hijo añade o redefine el comportamiento del padre

validar
usuario

Comprobar
huella

17
 Casos de Uso Estructurado - ejemplo2

Cajero Electrónico
pedir saldo
<include> validar
usuario
retirar <include>
Cliente
<extend>
Comprobar
Retiro con huella
sobregiro
cargar
Supervisor

Características de un buen caso

de uso

Agrupa los casos de uso por paquetes (por rol de usuario final,
por área funcional, por puesto de trabajo)

Hace referencia a un comportamiento simple, identificable y
razonablemente atómico

Describe el flujo de eventos de manera que sea entendible por
personas externas al sistema

Desglosa casos de uso complejos en los siguientes casos

Factoriza el comportamiento común, factorizando este

comportamiento desde otro caso de uso que incluye

Factoriza las variantes, colocando ese comportamiento en

otros casos de uso que lo extienden

Parametriza comportamiento genéricos en casos de uso

abstractos a partir de los cuales se especializan los casos

de uso concretos

18
 Guías para estructurar los casos de uso

Pasos

Identificar funcionalidad básica que ya ha sido descrita en un

caso de uso más general (relación de especialización)

Extraer descripciones de funcionalidad generales y

compartidas que pueden ser utilizadas por descripciones más

específicas (relación de inclusión)

Extraer descripciones de funcionalidad adicionales y

opcionales que pueden extender descripción más específicas

(relaciones de extensión)

nota: Esta estructuración permitirá definir el alcance de
implementación de casos de uso complejo en cada una de las
iteraciones

Estructuración de casos de uso - ejemplo

Definición inicial Definición refinada

EjecutarTransaccion

comprador
Pagar Factura comprador
vendedor
Pagar Factura

<<extiende>>

PagarCuotasVencida

19
 Algo mas sobre la generalización de casos de
uso…

La generalización de CU es una estrategia útil si se desea

introducir la reutilización en las fases tempranas del
desarrollo

Objetivo: expresar el caso de uso específico de una
aplicación en términos de un caso de uso más genérico
ofrecido por la biblioteca de componentes (assets)

Hasta cierto punto los requisitos se negocian para
adecuarlos a los activos ya existentes en la biblioteca

Caso de uso abstracto

Los casos de uso padre pueden ser componentes
abstractos que definen comportamiento parametrizable.

Transferencia
Monetaria

Transferenci
Retirar Depositar a
Dinero Dinero entre
cuentas

20
 Caso de uso abstracto (2)

Plantilla que permite definir colaboraciones
con {puntos de variación} claramente
determinados

Ejemplo: Descripción de alto nivel de
Transferencia de Instrumentos:

Operación que permite transferir {instrumento}
de un {portafolio} a otro {portafolio}

Descripción de alto nivel de Transferencia
Monetaria: Operación que permite transferir
moneda de un {portafolio} a otro {portafolio}

Caso de uso abstracto… ejemplo

(3)
Caso Uso: Retirar dinero

Descripción de alto nivel: Operación que permite transferir moneda de una
{cuenta} a otro {deposito de salida}

Descripción extendida:

1. El Cliente es identificado

2. El cliente escoge la cantidad a retirar y de cual {cuenta}

3. El sistema verifica la cantidad a retirar de la {cuenta} dependiendo del
tipo de {cuenta}

4. El sistema {entrega el dinero} y deduce la cantidad de la {cuenta} si la
deducción genera un sobregiro, este se maneja de acuerdo a {Sobregiro
Cuenta}

Requerimientos Especiales: El máximo tiempo de respuesta permitido en el
sistema es:

Para verificar la identidad del cliente: {tiempo identificación}

Para entregar la cantidad y deducir la cantidad del {cuenta} : {tiempo
entrega}

Si el servidor no responde en {time out} segundos el cliente considera que el
servidor esta fuera de servicio y cancela la operación

No puede haber mas de {instancias} de la operación Retiro de dinero,
ejecutando en paralelo en el servidor

21
 Caso de uso abstracto: ejemplo(4)
Retiro de
Dinero
Descripción extendida de RetiroDigicash:
Reutiliza la descripción dada en el caso
de uso padre con la variaciones que
fueren necesarias:
Retiro
Digicash 4. El sistema {entrega el dinero} y deduce
la cantidad de la {cuenta} si la deducción
genera ...

Es reemplazada por

4. El sistema {entrega el dinero utilizando

web browser seguro} y deduce
la cantidad de la {cuenta} si la deducción
genera ...

4.4 Definir los casos de prueba (primera

versión )

Objetivo de la actividad:

Definir casos de prueba que permitirán verificar la
consistencia de sistema una vez este desarrollado.

Permitir que el usuario precise en la fase de levantamiento de
requisitos, situaciones reales asociadas a los diferentes
flujos de eventos

Validar los escenarios representados por los casos de uso

Estrategia:

Los casos de prueba van a ser deducidos a partir de los flujos
de eventos ya definidos

22
 Definición de los casos de
prueba

Tarea 1. Definir escenarios posibles a probar como

combinatoria de flujos básicos / flujos alternos

No. Esc FB FA1 FA2 FA3 ...

1 x
2 x x
3 x x x
4 x x x

Definición de los casos de

prueba (2)

Tarea2. Definir casos de prueba para cada escenario

Caso de Escenario Condición Resultado esperado

prueba

CPa Escenario 4 Paso 2 Retomar flujo en paso 2

Retiro > Saldo

CPb Escenario 4 Paso 2 No ejecutar flujo alternativo

Retiro < Saldo 3, tomar flujo básico

CPc Escenario 4 Paso 2 No ejecutar flujo alternativo

Retiro = Saldo 3, tomar flujo básico

23
 Definición de los casos de
prueba (3)

Tarea3. Definir condiciones de prueba para cada caso
de prueba
Caso de Escenario / Datos de Resultado esperado
prueba Condicion entrada
Pin Valido Retiro Normal
CPa Escenario 4 Cta Valida
Retiro Normal Monto valido

CPb Escenario 4 Pin Valido Mensjae Fondos

Cta Valida Insuficiente
Retiro sin Monto Invalido
fondos
CPc Escenario 4 Pin Valido Temporalmente fuera de
Cta Valida servicio
Cajero sin Monto valido
dinero Saldo Cajero < Monto

Definición de los casos de

prueba (4)

Tarea4. Definir datos de prueba para cada
caso de prueba

Condiciones de entrada

Valores de entrada

Estado del sistema antes de la ejecución del caso de
prueba

Resultados Esperados

Resultados de salida (observables por el usuario)

Estado del sistema después de la ejecución del caso de
prueba

24
 4.4 Definir operaciones del sistema

Objetivo: Derivar los servicios que debe ofrecer el
software para satisfacer la funcionalidad requerida
de los casos de uso

Guías para definir las operaciones del sistema a partir
de la descripción del flujo de evento para un caso de
uso

Representar aquellas acciones que indican una interacción directa
entre el usuario y el sistema

Detallar los parámetros involucrados en cada mensaje

Agregar como comentarios o restricciones las respuesta o
excepciones que son el resultados de cada interacción

En situaciones complejas, separar en diferentes diagramas el flujo
básico de los flujos alternos

Diagram UML a utilizar: Diagrama de Secuencias

Diagramas de interacción
(generalidades)

Útiles para describir la manera como los objetos
colaboran para satisfacer una funcionalidad de
mayor nivel

UML contiene dos tipos de diagrama con una
semántica equivalente:

Diagrama de Secuencia: Énfasis en la ordenación temporal
(2 dimensiones). Muy utilizados para representar los
escenarios de los casos de uso

Diagrama de Colaboración: Énfasis en la estructura de los
objetos

25
 Uso del diagrama de secuencia para describir
operaciones del sistema

• Primer nivel: Metas de usuario

– Dialogo entre el usuario y el sistema (estimulo
/ respuesta)
– Sistema como caja negra
– Recibe el nombre de diagrama de
operaciones del sistema
• Segundo nivel: Interacciones del sistema (en
análisis y diseño)
– La forma como los objetos colaboran para
satisfacer un requerimiento del entorno

Diagrama de operaciones del sistema - ejemplo

: Sistema
Ventas
: cajero introducirProducto(CUP,cantidad)
Mq existian
productos

finalizarVenta()
devuelve el
total a pagar
efectuarPago(monto)
emite la
factura de

26
 Consideraciones adicionales...

Cómo agregar mayor significado

A través de notas

A través de restricciones

A través de texto

Casos importantes para documentar

Para representar multiplicidad

Para representar opcionalidad

Para representar ciclos

Todo evento al sistema implica un mensaje de retorno, sin

embargo a veces es conveniente hacer explícita esta
respuesta

Actividad 5. Validación de
Requisitos

Tiene como objetivo asegurar que el ingeniero
de software ha entendido los requerimientos y ha
dado respuesta a las necesidades del usuario

La validación debe involucrar al usuario / cliente de la
solución

Consideraciones a tener en cuenta

Qué tipo de artefacto se entrega al usuario para que los
valide?

Casos de uso

Prototipo de usuario: Este prototipo puede ser derivado de
manera natural a partir de la descripción detallada de los casos
de uso.

27
 Definición del Prototipo de usuario

Reglas de derivación de la interfaz

El nombre de las operación debe indicar una acción concreta
originada por eventos externos que se traducirán en botones /
opciones de menú / teclas de función, etc.

Las relaciones entre casos de uso (base y alternos) originan
navegación entre despliegues

navegación explícita: opciones que pueden ser activadas por el
usuario

navegación implícita: condiciones que originan la navegación

Diseño de la lógica vs. Diseño de la presentación

Definición esencial vs. definición real del caso de uso

esencial: sin describir los elementos de la interfaz

real: involucrando los elementos de la interfaz

Consideraciones en la construcción del

prototipo

El flujo de comunicación (actor/sistema) debe

diseñarse de acuerdo a la plataforma en la que
será implementado el sistema (diálogo por
campo / diálogo por forma)

En aplicaciones multinivel...

la naturaleza del diálogo origina de decisión de tipo
de página estática y/o página dinámica

separación de funcionalidad de validación en el nivel
de presentación (lenguaje de script) o en el nivel de
lógica

28