Ingeniería de

Software
El Modelo del Negocio y
el Modelo del Sistema
 Lecturas Recomendadas

• JACOBSON, Ivar; BOOCH,

Grady, RUMBAUGH, James,
“El Proceso Unificado de
Desarrollo de Software”.2000.
Addison Wesley.

Requisitos 3
 Lecturas Recomendadas

• RUMBAUGH J., Jacobson I.,

Booch G.. “El Lenguaje
Unificado de Modelado. Manual
de Referencia”. 2000 Addison
Wesley.

Requisitos 4
 Lecturas Recomendadas

• Ayuda Online de Rational Rose

Software- 2003.
• Documento “Modelo de Negocio
Lau.doc”.

Requisitos 5
 Modelo del Negocio: CUN
Dos vistas
• Vista externa (El Qué).
• Vista interna (El Cómo).

Requisitos 6
 Vista externa (El Qué)
El Diagrama de Casos de Uso del
Negocio (DCUN) en sí mismo.
DCUN = Actores + CUN
Define qué es esencial realizar para que
el negocio brinde los resultados deseados
al actor del negocio.
Requisitos 7
 Vista interna (El Cómo)
Define cómo organizar el trabajo para
lograr los resultados deseados
(realización del CUN).
Modelo de Objetos del Negocio:
– trabajadores del negocio
– entidades del negocio que participan en
la ejecución del CUN
– relaciones entre ellos.
Requisitos 8
 Modelamiento del Negocio
• Modelo de CUN (vista externa)
• Modelo de Objetos del Negocio
(vista interna)

(parecido a modelo del sistema)

Requisitos 9
 Modelo de Objetos del negocio
Define cómo
•la gente (trabajadores)
•las cosas (objetos del negocio)
se relacionan al interior de la empresa
para concretar los procesos y lograr lo
esperado.
Requisitos 10
 Modelo de Objetos del negocio

•Los roles (trabajadores del negocio) y

los objetos (entidades del negocio)
juntos deben ser capaces de llevar a cabo
todos los CUN.
•Describe los conceptos que permiten la
realización de los CUN
Requisitos 11
 Modelo de Objetos del Negocio
Elementos que lo componen:
•Trabajadores del negocio
•Entidades del negocio
•Realizaciones de CUN
•Especificación textual
•Diagrama de actividad
•Diagrama de clases
•Diagramas de secuencia
Requisitos 12
 Puntos de chequeo del
Modelo del negocio
• El nombre y la descripción deben ser
claros y comprensibles.
• Cada uno debe tener documentada una
asociación con otro trabajador si se
comunican entre sí.
• Cada uno debe participar en un CUN al
menos.

Requisitos 13
 Puntos de chequeo del
Modelo del negocio
• Cada relación entre trabajadores y otros
trabajadores o entidades del negocio
debe ser usada en el flujo de trabajo de
algún CUN.
• Cada operación de un trabajador del
negocio debe aparecer en el flujo de
trabajo de algún CUN.

Requisitos 14
 Identificar Entidades del Negocio
• Representan “cosas” manipuladas o
usadas por los trabajadores cuando
ejecutan un CUN.
• Comúnmente son un documento o una
parte esencial de un producto.
• Pueden representar cosas no tangibles, ej.
conocimiento importante acerca de un
mercado o cliente.

Requisitos 15
 Puntos de chequeo de
entidades del negocio
• Nombre y descripción claros y com-
prensibles.
• Cada una aparece en al menos un CUN.
• Cada relación de una una entidad con otra o
con un trabajador aparece en algún caso de
uso al menos.

Requisitos 16
 Realizaciones de CUN
Muestran la manera en que colabo-
ran los trabajadores y entidades del
negocio para ejecutar el proceso.
Se documentan con:
Especificación textual
Diagramas de actividad
Diagramas de clase
Diagramas de secuencia
Requisitos 17
 Diagrama de clase del
Modelo de Objetos del Negocio
Muestra la participación de los
trabajadores y entidades del negocio y la
relación entre ellos.
Un diagrama de clases por cada CUN.
Puede ser interesante realizar uno del
negocio completo o por paquetes.

Requisitos 18
 Ejemplo de Diagrama de clases

Empleado Especialiasta
de préstamo

Perfil de Cuenta Préstamo

cliente
Requisitos 19
 Entidades del Negocio
• Contienen atributos y operaciones.
• Se puede especificar herencia.
• Ejemplos: En un restaurante: el menú,
las bebidas, etc. En el aeropuerto: el
boleto, el pase a bordo, etc.

Requisitos 20
 Flujo de trabajo:
Requerimientos o
Requisitos
Cómo identificar los casos de uso del
sistema y los actores del sistema
 Captura de Requisitos (o Requerimentos)
Es el proceso de averiguar, por lo general en
circunstancias difíciles, lo que se debe construir.

Los usuarios deben saber lo que quieren

•Cada uno sabe lo que hace, pero

ninguno tiene una visión global
•No saben cómo puede hacerse más eficiente la
operación en su conjunto.
•No saben qué parte de su trabajo puede
transformarse en software..
Requisitos 22
Percepciones de un proyecto de SW

Requisitos 23
Objetivo del flujo de trabajo de los Requisitos
Guiar el desarrollo hacia Necesidad de definir
el sistema correcto. objetivos generales
concretos

CON BENEFICIOS

Para el negocio
Para los actores
del negocio

Requisitos 24
Flujos de Trabajo (última versión)

Requisitos I t e r a t io n s 25
Objetivo del flujo de trabajo de los Requisitos
Caso Interbank (institución financiera ficticia):

Quiere desarrollar aplicaciones nuevas que soporten los fuertes

cambios en el mercado financiero. Interbank Software decide
diseñar el Sistema de Pagos y Facturación. El sistema utilizará
Internet para el envío de pedidos, facturas y pagos entre
compradores y vendedores.

La motivación del banco es atraer nuevos clientes ofreciendo

comisiones bajas por el proceso de los pagos. El banco también
podrá reducir sus costes laborales procesando las solicitudes de
pago automáticamente por Internet, en lugar de manualmente
mediante cajeros.

Requisitos 26
Objetivo del flujo de trabajo de los Requisitos
Caso Interbank (institución financiera ficticia): (Cont.)

La motivaciones para los compradores y vendedores son reducir

los costes, el papeleo y el tiempo de proceso. Por ejemplo, ya no
tendrán que enviar pedidos o facturas por correo ordinario. El
pago de las facturas se llevará a cabo entre las computadoras del
comprador y del vendedor. Ambos tendrán también una visión
general mejor del estado de sus facturas y pagos.

¡¡¡Beneficios para el negocio y

para los actores del negocio!!!

Fuente del caso: Jacobson, Booch y Rumbaugh. RUP.

Requisitos 27
Objetivo del flujo de trabajo de los Requisitos
Requisitos del sistema:
Son las condiciones o capacidades que el
sistema debe cumplir

Co l es
mp s ib
r en e n
si b m pr
le s Co
Desarrolladores
Requisitos Clientes y Usuarios

Requisitos 28
 Requerimientos funcional
“Una capacidad o condición que el
sistema cumplirá”

Requerimiento no funcional
“Propiedades o cualidades que el producto de
software debe tener”

Requisitos 29
 Clasificación de los
requerimientos

• Objetivos y metas para un sistema.

(Funcional) • Si están presentes  Cliente satisfecho

• Implícitos al sistema.
(No Funcional) • Puede que el cliente no los declare,
pero si no están se siente
insatisfecho.

• Características que van más allá de la

(Funcional y no
expectativas del cliente.
funcionales)
Requisitos 30
 Pasos en el flujo de trabajo
de Requisitos
• Enumerar los requisitos candidatos.
• Comprender el contexto del sistema.
• Capturar los requisitos funcionales.
• Capturar los requisitos no funcionales.

Requisitos 31
1. Enumerar requisitos candidatos
Buenas ideas de los clientes, usuarios y desarrolladores que
pueden convertirse en verdaderos requisitos.

Cada requisito candidato o característica propuesta tiene:

•Nombre corto.
•Breve descripción.
•Estado (propuesto, aprobado, incluido o validado).
•Coste estimado de implementación (por tipos de recurso
y horas-hombre).
•Prioridad (crítico, importante, secundario).
•Nivel de riesgo asociado (crítico, significativo,
ordinario).
Requisitos 32
 2. Comprender el contexto del
sistema
Los desarrolladores requieren un firme conocimiento
del contexto en el que se desarrolla el sistema.
¿Cómo lograrlo? Con el modelado
del negocio

1. Diagrama de casos de uso del negocio.

2. Descripción de los casos de uso.
3. Modelo de objetos del negocio.
4. Glosario.
Requisitos 33
 3. Capturar requisitos funcionales
Identificando los casos de uso del sistema

Para un usuario, un caso de

uso es un modo de utilizar el
sistema

Si sabemos describir todos los casos de

uso que necesita un usuario, entonces
sabemos lo que debe hacer el sistema.

Requisitos 34
 3. Capturar requisitos funcionales
Ejemplos de instancias de un caso de uso
Este caso de uso permite a las
Sacar dinero instancias del actor Cliente de
Cliente de Banco, sacar dinero mediante un
Banco cajero automático.

• Una persona llamada José, introduce su contraseña 1234,

selecciona sacar 220 usd y toma el dinero.
• Una persona llamada José, introduce su contraseña 1234,
selecciona sacar 240 usd y toma el dinero.
• Una persona llamada Enrique, introduce su contraseña
3456, selecciona sacar 480 usd y el sistema no se lo permite
debido a un saldo insuficiente (o una contraseña errónea).
Requisitos 35
3. Capturar requisitos funcionales
¿De dónde partimos para capturar
los requisitos funcionales?

Del modelo del negocio

•Diagrama de casos de uso del negocio.

•Descripción de los casos de uso del negocio.
•Diagrama de actividades de cada caso de uso.

Requisitos 36
4. Capturar requisitos no funcionales
Los requisitos no funcionales especifican
propiedades que debe tener el sistema.

Ejemplos:
•Facilidad de mantenimiento.
•Fiabilidad (disponibilidad, ausencia de fallos,
exactitud).
•Rendimiento (velocidad, tiempo de respuesta).
•Seguridad (dejar huella de confirmación de
operaciones importantes).
•Apariencia (interfaz)
Requisitos 37
4. Capturar requisitos no funcionales
Ejemplos:
Requisitos de plataforma de hardware
Servidores: SUN SPARC 20
Clientes: PC (procesador mínimo P-III)

Requisitos de plataforma de software

Software de sistema
S.O. servidor: Windows NT 4.0.
S.O. cliente: Windows NT 4.0.
Plataforma de software libre PHP-MySQL

Requisitos 38
4. Capturar requisitos no funcionales
Ejemplos:
Requisitos de plataforma de software
Navegadores Internet
Internet Explorer 4.0, o Netscape
Communicator 4.0

Seguridad
La transmisión debe ser segura, los únicos
autorizados para acceder a la información
con el cliente del banco y el administrador
de sistema.
Requisitos 39
4. Capturar requisitos no funcionales
Ejemplos:

Facilidad de aprendizaje
El tiempo de aprendizaje para enviar
pedidos simples y pagar facturas no debe
exceder de 10 minutos para el 90% de los
compradores.

Requisitos 40
 Requerimiento no funcional
• Apariencia o interfaz externa
• Usabilidad • Software
• Rendimiento • Hardware
• Soporte • Restricciones en
• Portabilidad el diseño y la
• Legales implementación
• Políticas culturales
• Confiabilidad
• Interfaz interna
• Ayuda y documentación en línea
• Seguridad
Requisitos 41
4. Capturar requisitos no funcionales
Los requisitos no funcionales
estarán descritos en el caso
de uso al que estén asociados.

Pueden haber requisitos

no funcionales que sean Requisitos
de carácter general. adicionales

Requisitos 42
Pasos y artefactos en el flujo de requisitos
Paso Artefacto resultante

Enumerar requisitos Lista de características.

candidatos.
Comprender contexto. Modelo del negocio.

Requisitos funcionales Modelo de CU

Requisitos no funcionales. Requisitos adicionales

(muchos aparecen en los
CU).
Requisitos 43
Del Modelo de Negocio hacia el
Sistema

Cómo identificar los casos de uso del

sistema y los actores del sistema
Relación entre los modelos del negocio y los modelos asociados al sistema de información

Modelo de Modelo de
casos de uso Objetos del
del negocio negocio

Modelamiento del
Negocio

Modelo de + otros modelos: diseño

casos de uso implementación, prueba

Desarrollo del sistema

Requisitos 45
 El modelo del negocio y el modelo
del sistema

Trabajador
del negocio
Actor del
sistema

Caso de uso Caso de uso

del negocio del sistema

Requisitos 46
Modelo del negocio y modelo del sistema
de información

Modelo Modelo
de CUN ON
Modelamiento modelos:
del Negocio diseño,
Modelo + implantación,
prueba
de CUSI
Requisitos
Desarrollo del sistema
47
 Lo primero...
Revisar:
•Modelo del Negocio
•Actividades a automatizar

CUN - Requerimientos - CUSI

Requisitos 48
Identificación de CUSI partiendo
de los CUN
Para cada CUN que será soportado
por el sistema automatizado se puede
identificar un subsistema en el modelo
de análisis.

Requisitos 49
 Identificación de CUSI partiendo
de los trabajadores (1 iteración)
ra

1.Decidir si el trabajador del negocio usará el

sistema de información.
2. De ser así, identificarlo como actor del
sistema de información en el modelo de
CUSI, con el mismo nombre del trabajador
del negocio.

Requisitos 50
 Identificación de CUSI partiendo
de los trabajadores (1 iteración)
ra

3. Para cada caso de uso del negocio en el

que participa el trabajador del negocio,
crear un caso de uso del sistema.
4. Repetir todos los pasos para cada
trabajador del negocio.

Requisitos 51
 El modelo del negocio y el modelo
del sistema

Trabajador
del negocio Actor del
sistema

CUN Caso de uso del

sistema (CUSI)
Requisitos 52
 Ejemplo

Modelos de negocios y de
sistema de un banco

Requisitos 53
 DCU Negocio

Transacción
Modelo de Cliente de dinero
casos de uso
del negocio

Requisitos 54
 Modelo de Objetos del Negocio

Empleado Especialiasta
de préstamo

Modelo de
Objetos del Perfil de Cuenta Préstamo
negocio cliente

Requisitos 55
 DCU Sistema

Requisitos 56
Diagrama de Casos de Uso del Negocio

Ejemplo No.1.

Cliente Solicitar Cotización

de Materiales

Requisitos 57
 Cómo identificar los casos de uso
del sistema
Comenzar con los trabajadores del negocio. Para
cada uno:
• Decidir si el trabajador del negocio va a utilizar el sistema
de información.
• De ser así, identificar un actor en el modelo de casos de
uso del sistema.
• Para cada caso de uso del negocio en el que participe el
trabajador del negocio, crear un caso de uso del sistema.
• Repetir estos pasos para todos los trabajadores del
negocio.
Requisitos 58
 Modelo de Objetos del Negocio

Almacenero
Cliente
Vendedor
Solicitud Cotización Orden de Reserva
[revisada] [generada]
Solicitud Cotización
[presentada]
Cotización
[presentada] Prefactura Inventario
[generada]
Requisitos 59
 Modelo de Objetos del Negocio

Almacenero
Cliente
Vendedor
Solicitar Cotización
de Materiales

Almacenero
Vendedor Reservar productos

Requisitos 60
Diagrama de Casos de Uso del Sistema
Versión No.1
Solicitar Cotización
de Materiales

Vendedor
Almacenero
Reservar productos

¿Tiene alguna
interacción con el
sistema?
Requisitos 61
Diagrama de Casos de Uso del Sistema
Versión No.2
Solicitar Cotización
de Materiales

Vendedor
¿Y si queremos que se
automatice completamente
el proceso del negocio?

Requisitos 62
Diagrama de Casos de Uso del Sistema
Versión No.3
Solicitar Cotización
de Materiales

Vendedor

Requisitos 63
Diagrama de Casos de Uso del Sistema
Versión No.3
Solicitar Cotización
de Materiales

Cliente Este es el caso en que un actor del

negocio pasa a ser actor del sistema,
cosa que puede suceder, pero no es lo
más común.

Requisitos 64
 Observaciones
•Cada entidad del negocio, que se registra
en el modelo de objetos del negocio, sugiere
la creación de una clase en el modelo de
análisis del sistema.
•Es decir, una entidad del negocio que va a
gestionarse por el sistema de información
debe corresponder a una entidad en el
modelo de análisis del sistema de
información.
Requisitos 65
 Observaciones
Cuenta
No. Cuenta
Propietario
Saldo
cuenta ....
Clase en el modelo
de análisis

Requisitos 66
 Observaciones
La forma que se sugiere para obtener
una aproximación al modelo de casos
de uso del sistema es sólo un punto de
partida que posteriormente debe
refinarse.

Requisitos 67
 Instancias de Actores

Pepe se Luis se
comporta Inserte comporta
como Actor
Tarjeta 1
4
2
5
3
6
como Actor
del Sistema 7 8 9 del Sistema
* 0 #

Modelo de Caso de Uso

Actor Caso de Uso

Requisitos
 Un usuario desempeña el rol de varios
actores

Inserte
Pepe es
tarjeta 1 2 3 Operador
4 5 6
7 8 9
* 0 #

Pepe Operador
Pepe también
es Cliente
Cliente

Requisitos
 Dos actores pueden realizar iguales
tareas

Inserte Luis es
Pepe es Tarjeta
1 2 3
4 5 6 un
un cliente
7 8 9 operador
* 0 #

• Tanto el cliente como el operador

pueden efectuar transacciones en un Usuario Efectuar
cajero automático Transacciones
• El cliente y el operador son usuarios del
cajero automático. Cliente Operador
• El usuario puede efectuar transacciones Generalización-
enRequisitos
un cajero automático especialización
 Tabla Resumen
(Rational Rose)

Relaciones entre Modelos del Negocio

y Modelos del Sistema.

Requisitos 71
Relación entre Modelos del Negocio y Modelos del Sistema (1)

Modelos Candidatos obtenidos de los Modelos del

del modelos del negocio Negocio
Sistema
Actores  Los actores candidatos se Trabajadores
encuentran entre los del Negocio
trabajadores del negocio.

 Otros actores candidatos se

encuentran entre diferentes Actor del
actores del negocio (clientes, Negocio
socios, etc.) que directamente
usarán el sistema de información

Casos de Casos de uso candidatos se Actividades

uso encuentran entre las actividades de de
los trabajadores del negocio. Trabajadores
Buscar las operaciones y áreas de del Negocio
responsabilidad que involucren
interacciones con el sistema de
información.
Requisitos 72
 Tabla Resumen
(Rational Rose)
• Actores y trabajadores del Negocio ....
pueden ser... Actores del Sistema.

•Actividades del negocio ... pueden ser ....

Casos de Uso del Sistema

Requisitos 73
Relación entre Modelos del Negocio y Modelos del Sistema (2)

Modelo del Candidatos obtenidos del modelo del Modelos

Sistema negocio del
Negocio
Clase  Clases de entidad candidatas se Entidades
entidad encuentran entre las entidades del del
negocio. Buscar entidades del Negocio
negocio que deben mantenerse o
representarse en el sistema de
información.

 Clases de entidad candidatas se

encuentran entre atributos en el
modelo de objetos del negocio. Atributos
Buscar atributos que deben
mantenerse o representarse en el
sistema de información.

Relaciones Relaciones entre Entidades del Relaciones

entre Negocio muchas veces indican una entre
clases de relación correspondiente entre las Entidades
entidad clases en el modelo del sistema de del
información. Negocio
Requisitos 74
 Tabla Resumen
(Rational Rose)
•Entidades del Negocio y sus atributos .... pueden
ser... Clases Entidad del Sistema.

• Relaciones entre Entidades del Negocio ...

pueden ser .... Relaciones entre Clases Entidad del
Sistema

Requisitos 75
 Plantilla de descripción de casos
de uso en alto nivel

Ejemplo

Requisitos 76
Ejemplo de Caso de uso del Sistema de Gestión para Galerías de
Artes.

<Extend> Enviar e-mail Agente de

Correo
Electrónico

<Include>

Recepcionista Controlar solicitudes Asignar especialista

de arte Sistema
de obras de arte RRHH
<Extend>

Registrar artista
Requisitos 77
Especificación de alto nivel
Caso de uso Controlar solicitudes de obras de arte
Actores Anfitrión (Inicia)
Descripción:
El caso de uso se inicia cuando la Recepcionista de la Galería registra una nueva solicitud
de exposición de un artista para que se expongan sus obras y asigna un especialista de arte
para que las evalúe. En caso de que no estén registrados los datos del artista, se hace en
ese momento. La Recepcionista también puede eliminar una solicitud, siempre que no
tengan obras evaluadas, o modificar las obras que contiene, informando de ello al
especialista asignado. El caso de uso finaliza cuando el sistema, de forma automática, le
envía un correo electrónico al especialista asignado con la información de la solicitud.
Referencias R1, R2, R3, R4, R5 y R6
Casos de uso asociados:
 Enviar e-mail ().
 Asignar especialista de arte (Include).
 Registrar artista (Extend).
Precondiciones Existe un maestro con los tipos de técnicas.
Poscondiciones Se registra(n) la(s) nueva(s) solicitud(es) o el(los) cambio(s) producidos
informando al(los) Especialista(s) de arte involucrado(s). En el caso de las
nuevas, se registra la solicitud y se envía el e-mail, sólo si fue posible
asignar especialistas.
Requisitos 78
 Otro Modelo de Casos de Uso
Reservar Cita inicial

Paciente
Operador Cancelar Cita
Admisión

Registrar Resultado
de Consulta
Modificar Cita

Médico

Generar reporte de
solicitud de citas vs
especialidad Gerente

Sistema de
Almacén Generar reporte de
ingresos vs gastos Generar reporte de
Requisitos tipos de 79
complementarios
 Flujo de trabajo:
Requerimientos

El modelo de casos de uso

 Artefacto: Actor de sistema
El modelo de casos de uso
Sacar dinero describe lo que hace el
sistema para cada tipo de
Cliente de
Banco usuario.

Un usuario Uno o varios actores

Un sistema externo Uno o varios actores

Requisitos 81
 Artefacto: Actor de sistema

¿Dónde encontramos a
los actores del sistema?

Actores del negocio Actores del

sistema
Trabajadores del negocio

Requisitos 82
 Artefacto: Caso de uso

• Cada forma en que los actores usan el sistema se

representa con un caso de uso
• Los CU son fragmentos de funcionalidad que el
sistema ofrece para aportar un resultado de valor para
los sus actores.
• Un CU especifica una secuencia de acciones que el
sistema puede llevar a cabo interactuando con sus
actores, incluyendo alternativas dentro de la
secuencia.

Requisitos 83
 Casos de Uso
Establece un acuerdo entre clientes y
desarrolladores sobre las condiciones y
posibilidades (requisitos) que debe
cumplir el sistema.
Artefacto narrativo que describe, bajo la forma de
acciones y reacciones, el comportamiento del sistema
desde el punto de vista del usuario (Jacobson).

Descripciones de la funcionalidad del sistema

independientes
Requisitos
de la implementación. 84
Identificación de los CU del sistema a
partir del modelo del negocio

CASO DE USO = PROCESO QUE OBTIENE

UN RESULTADO DE
Requisitos
VALOR 85
Artefacto: Descripción de la Arquitectura

Descripción de Vista del modelo de

la arquitectura casos de uso con las
funcionalidades más
importantes ó críticas

A desarrollar en las
primeras iteraciones

Requisitos 86
 Artefacto: Glosario

Términos importantes en la
Glosario descripción del sistema

Concenso

Requisitos 87
 Artefacto: Prototipo de interfaz

Ayuda a comprender y
especificar la interacción
entre:

Sacar dinero

Actores
Sistema
Requisitos 88
 Trabajadores del flujo

Puesto al cual se puede

asignar una persona real

•Analista de sistemas
•Especificador de casos de uso.
•Diseñador de interfaz de usuario
•Arquitecto.

Requisitos 89
 Trabajadores

Analista de Arquitecto Especificador Diseñador de

Sistemas interfaces

Encontrar
actores y CU Priorizar
los CU Detallar
Un CU
Prototipar
Estructurar la interfaz
El modelo CU

Requisitos 90
Actividad: Encontrar actores y CU
Artefactos de Pasos:Artefactos de
entrada Analista de• Encontrar
salida los actores.
Sistemas • Encontrar los CU
• Describir brevemente
cada CU
Modelo del negocio • Describir el modelo de
Modelo de CU
CU completo
Requisitos Adic. Encontrar• (esbozado)
Glosario de términos
actores y CU
Lista de Caract. Glosario

¡¡¡ Esta es la actividad más importante

para unos buenos requisitos !!!
Requisitos 91
Actividad: Encontrar actores y CU
Paso: Encontrar actores: Consideraciones adic.
•No olvidar los actores que representan sistemas
externos.
•Identificar al menos a un usuario representante
del actor candidato.
•No queremos actores que desempeñan los
mismos roles.
•Nombres relevantes para los actores.

Requisitos 92
Actividad: Encontrar actores y CU
Paso: Encontrar CU: Consideraciones adic.
•Crear CU fáciles de modificar, revisar, probar y
manejar unitariamente.
•Nombre que corresponda con la secuencia de
acciones que añade valor a un actor.
•Nombre que comience con un verbo: Pagar
factura, Solicitar Bienes.

Requisitos 93
Actividad: Encontrar actores y CU
Paso: Encontrar CU: Consideraciones adic.
•Un caso de uso entrega un resultado que añade
valor a un actor en concreto.

A usuarios
Al actor iniciador individuales reales

Evita CU muy grandes

Evita CU muy pequeños

Requisitos 94
Actividad: Encontrar actores y CU
Paso: Describir brevemente cada CU.
CU Pagar Factura:

El Comprador ya ha recibido una factura y también

ha recibido los bienes demandados:

1. El comprador estudia la factura a pagar y verifica

que se corresponda con el pedido original.
2. El comprador planifica el pago de la factura por
banco.

Requisitos 95
Actividad: Encontrar actores y CU
Paso: Describir el modelo de CU completo.

• Se explica el modelo de CU como un todo.

• Describe cómo interactúan los actores y los CU y

cómo se relacionan entre sí los CU.

Requisitos 96
Actividad: Encontrar actores y CU
Paso: Describir el modelo de CU completo.

Ejemplo:
El comprador utiliza el CU Solicitar Bienes y Servicios
para buscar los productos y precios, para realizar un
pedido y después enviarlo.

Tarde o temprano, los bienes le llegarán al comprador

junto con una factura.

El comprador activa el CU Pagar Factura para dar el

visto bueno a la factura ……
Requisitos 97
 Actividad: Priorizar los CU
Artefactos de Artefactos de
entrada Arquitecto salida

Modelo de CU
(esbozado) Descripción de la
Priorizar arquitectura
Requisitos Adic. los CU (vista del
Modelo de CU)
Glosario

Requisitos 98
 Actividad: Priorizar los CU

Determinar cuáles son los CU necesarios

para el desarrollo en las primeras
iteraciones.

Se verá más adelante

Requisitos 99
 Actividad: Detallar un CU
Artefactos de Artefactos de
entrada Especificador salida
de CU

Modelo de CU
(esbozado)
Detallar CU detallado
Requisitos Adic. un CU

Glosario

Requisitos 100
 Actividad: Detallar un CU

Objetivo: Describir el flujo de sucesos en

detalle.
Elementos importantes:
• Definir cómo comienza el CU.
• Cómo termina el CU.
• Cómo el CU interactúa con los actores.

Requisitos 101
 Actividad: Detallar un CU

• Hacer una descripción precisa, pero fácil de leer.

• Describir todas las alternativas.
• Describir todas las excepciones.
• El actor puede elegir entre diferentes caminos en
el CU. En Pagar Factura puede decidir pagarla, o
rechazarla.
• El sistema puede detectar entradas erróneas de
los actores.
• El camino básico debe ser el “normal”.
• Deben incluirse las pre y postcondiciones.
Requisitos 102
 Actividad: Detallar un CU

Precondiciones:
El comprador ha recibido los bienes y servicios y
al menos una factura del sistema.

Postcondiciones:
La instancia del CU termina cuando la factura ha
sido pagada, o cuando el pago se ha cancelado y
no se hace ninguna transferencia.

Requisitos 103
 Actividad: Detallar un CU

Leer en “Proceso Unificado de Desarrollo”

páginas 149 a la 158 sobre los tópicos:

• ¿Qué incluir en una descripción de CU?

• Formalización de la descripción de CU.
• Actividad: Prototipar la interfaz de usuario.

Requisitos 104
 Ejemplo

Caso de Uso Pagar Factura

Actores Comprador (Iniciador)
Propósito Pagar las facturas a través de
la cuenta del comprador
Resumen El comprador planifica el pago
de las facturas y si hay
suficiente dinero en la cuenta,
el pago se realiza por
mediación de la transferencia
correspondiente
Requisitos 105
 Curso Básico
Acción del actor Respuesta del sistema
1 El comprador invoca al caso de 2 Verifica que las facturas sean
uso para hojear las facturas en consistentes con las
la interfaz Web del cliente del confirmaciones de pedido
comprador recibidas almacenadas en las
tablas Facturas y confirmación de
3 El comprador decide planificar Pedido respectivamente
una factura para pagarla por 4 Genera una petición de pago para
banco y lo informa al sistema transferir el dinero a la cuenta del
presionando el boton de vendedor
5 Si hay suficiente dinero se realiza
el pago
6 Notificar resultado a comprador y
vendedor
Requisitos 106
 Actividad: Estructurar el modelo CU
Artefactos de Artefactos de
entrada Analista de salida
Sistemas

•Modelo de CU
(esbozado)

•Requisitos Adic. Estructurar Modelo CU

Modelo CU (estructurado)
•Glosario

•CU descritos
Requisitos 107
Actividad: Estructurar el modelo CU
Caso de Caso de uso
uso real Ejecutar transacción abstracto

Pagar factura

Comprador Vendedor

Caso de uso
concreto

Requisitos 108
Actividad: Estructurar el modelo CU

Ejecutar transacción

Pagar factura

Comprador <<extend>> Vendedor

Pagar cargos
saldo deudor

Requisitos 109
 Modelado del Negocio
• Describe los procesos de una organización
• Usado para identificar requerimientos
• Consiste de actores del negocio y casos de uso del
negocio
• El resultado es un modelo de casos de uso del negocio

Requisitos 110
 Requerimientos
• Describe lo que el sistema debe hacer
• El resultado es un modelo de casos de uso
• Pasos
– Analizar el Problema
– Entender las Necesidades
– Definir el Sistema
– Administrar el Alcance del Sistema
– Refinar la Definición del Sistema
– Administrar Cambios de Requerimientos

Requisitos 111
 Conclusiones

• Requisitos: tarea difícil!

• Modelo de Negocio es valioso
para definir sistema.
• La vista externa del sistema y
del negocio se parecen
estructuralmente (Actores, CU)
Requisitos 112
 Conclusiones

• Artefactos de Requisitos:
Diagrama de Casos de Uso de
Sistema, Casos de Uso de
Sistema, Lista de Requisitos.

Requisitos 113
 Estudio Independiente

• Para la próxima actividad

preparar a partir del Modelo de
Negocio simple, algunas
actividad a automatizar y derive
el DCUSI.

Requisitos 114