PROCESO UNIFICADO

CAPTURA DE REQUISITOS
El proceso unificado de desarrollo, Ivar Jacobson, Grady Booch,
James Rumbaugh, Ed. Addison Wesley, 1999

The unified software development process, Ivar Jacobson, Grady

Booch, James Rumbaugh, Ed. Addison Wesley, 1999
Captura de requisitos

Wor kf low Concepción Elabor ación Const r ucción Tr ansición

Ver if icación

5HTXLVLWRV

$QiOLVLV

'LVHxR

,PSODQWDFLyQ

3UXHED

I t er ación-es I t er . I t er . I t er . I t er . I t er . I t er . I t er .
I nicial-es #1 #2 #3 #4 #5 #6 #7

(Adapt ado de J acobson, 1999)

Ingeniería del software 2

Diagramas de casos de uso

• Caso de uso:
– Descripción de un conjunto de secuancias de acciones que
ejecuta un sistema produciendo un resultado de interés para
un actor.
• Describen el comportamiento para cada actor
• Instancia de caso de uso
• Se lleva a cabo mediante colaboraciones de objetos
• Colaboración:
– Define las interacciones que han de producirse entre los
objetos con el fin de que estos puedan desempeñar su papel.

Ingeniería del software 3

Diagramas de casos de uso

• Elementos estructurales:

Actor Caso de uso Colaboración

• Relaciones:
– Dependencia
Elemento dependiente Elemento independiente
– Asociación

Actor Caso de uso

Ingeniería del software 4

Diagramas de casos de uso

• Relaciones

– Realización

Caso de uso Colaboración

Ingeniería del software 5

Captura de requisitos

TAREA PRODUCTOS (artifact)

Enumerar requisitos Lista de características
candidatos
Entender el contexto Modelo de negocio o de
del sistema dominio
Capturar requisitos Modelo de casos de uso
funcionales Prototipo IU
Capturar requisitos no Requisitos suplementarios
funcionales o casos individuales

Ingeniería del software 6

Captura de requisitos

TAREA PRODUCTOS (artifact)

Enumerar requisitos Lista de características
candidatos
Entender el contexto Modelo de negocio o de
del sistema dominio
Capturar requisitos Modelo de casos de uso
funcionales Prototipo IU
Capturar requisitos no Requisitos suplementarios
funcionales o casos individuales

Ingeniería del software 7

Captura de requisitos
Modelo del dominio
• ¿Qué es?
– Tipos de objetos (especificación o entrevistas)
– “Cosas” y eventos
– Diagramas de clases y glosario
• Desarrollar el modelo del dominio
– Técnicas de comunicación
– Solo contexto
• Usar el modelo del dominio
– Al describir los casos de uso
– Conceptos sugieren clases de análisis y diseño

Ingeniería del software 8

Captura de requisitos
Modelo de negocio
• ¿Qué es?
– Procesos de negocio
– Cómo se realiza un proceso por un conjunto de trabajadores
que usan unas entidades y unidades de trabajo
• Desarrollar el modelo de negocio
– Identificar casos de negocio y sus actores
– Desarrollar modelo de objetos de negocio con: trabajadores,
entidades de negocio y unidades de trabajo
• Usar el modelo de negocio
– Un actor por trabajador
– Identificar sus papeles en distintos casos

Ingeniería del software 9

Captura de requisitos

TAREA PRODUCTOS (artifact)

Enumerar requisitos Lista de características
candidatos
Entender el contexto Modelo de negocio o de
del sistema dominio
Capturar requisitos Modelo de casos de uso
funcionales Prototipo IU
Capturar requisitos no Requisitos suplementarios
funcionales o casos individuales

Ingeniería del software 10

Capturar requisitos funcionales

• Basado en casos de uso

• CU para el actor: forma de utilizar el sistema
• Objetivos:
– Capturar el comportamiento, sin especificar
– Comprensión común
– Validar arquitectura y sistema

Ingeniería del software 11

Capturar requisitos funcionales

1. Identificar actores y casos de uso

2. Priorizar casos de uso
3. Detallar casos de uso
4. Prototipo de IU
5. Estructurar el modelo

Ingeniería del software 12

Capturar requisitos funcionales

1. Identificar actores y casos de uso

– Para:
• Delimitar el sistema
• Actores y funcionalidad
• Glosario
– Pasos:
• Descubrir los actores
• Descubrir los casos de uso
• Describir brevemente cada caso de uso
• Describir el modelo de casos de uso

Ingeniería del software 13

Ejemplo. Cajero automático
Lista de requisitos candidatos

FUNCIONES BÁSICAS
R1. El usuario podrá consultar el saldo de su cuenta
R2. Si el usuario intenta sacar una cantidad que supera el saldo de
su cuenta, el cajero le avisará de que no es posible sacar esa
cantidad
R3. Si el usuario intenta sacar una cantidad que supera el límite
diario, el cajero le avisará de que no es posible y volverá a
solicitar una cantidad
R4. El cliente del banco podrá hacer una transferencia a otra cuenta
.....................

REQUISITOS NO FUNCIONALES
Fácil de usar
Tiempo de respuesta inferior a 30 seg.
................
Ingeniería del software 14
Ejemplo. Cajero automático
Casos de uso. Descripción inicial
Caso de uso: 6DFDUGLQHUR
Actores: Cliente (iniciador)
Tipo: ??
Descripción: El caso de uso comienza con la identificación del
usuario. El cliente usa el caso de uso para acceder a
su cuenta. El caso de uso le devuelve el dinero
solicitado, un aviso de que no tiene saldo o de que
ha excedido el límite diario.

Caso de uso: &RQVXOWDUVDOGR

Actores: Cliente
Tipo: ??
Descripción: El caso de uso comienza con la identificación del
usuario. El usuario consulta el saldo de su cuenta.

Ingeniería del software 15

Capturar requisitos funcionales

2. Priorizar los casos de uso

– Visión de la arquitectura
– Casos de uso a desarrollar en las primeras iteraciones
– Casos de uso significativos

Ingeniería del software 16

Capturar requisitos funcionales

3. Detallar casos de uso

– Objetivo: flujo de sucesos (o eventos):
• Cómo comienza y termina el caso de uso
• Cómo interactúa con los actores
• Objetos que se intercambian
– Veremos:
• Cómo estructurar la descripción de un CU
• Qué incluir en una descripción de un CU
• Cómo formalizar la descripción del CU
– Antes...

Ingeniería del software 17

Diagramas de estado

• Un diagrama de estados representa un elemento como

una máquina de estados finita
• Un diagrama de estado, representa la vida de un único
elemento
• Consta de: Estados, Transiciones, Eventos y
Actividades
• Permite visualizar el comportamiento (dinámico) de un
elemento

Ingeniería del software 18

Diagramas de estado

• Elementos
– (VWDGR: situación en la vida de un elemento durante la cual se
satisface alguna condición, se realiza alguna actividad o se
espera algún suceso
• Inicial, Intermedio, Final
– 7UDQVLFLyQ: relación entre dos estados que indica que un
elemento que esté en un primer estado realizará ciertas
acciones y entrará en el segundo estado cuando se produzca
un suceso especificado y se satisfacen las condiciones
indicadas
– 6XFHVRRHYHQWR: especificación de algún acontecimiento que
ocupa espacio y tiempo. Es la aparición de un estímulo que
puede disparar la transición de un estado a otro

Ingeniería del software 19

Diagramas de estado

E.Inicial Estado Estado

E.Final Transición

contratar
en el paro en activo

perder empleo
jubilarse Suceso
jubilarse
Estado
jubilado

T. autom.

Ingeniería del software 20

Diagramas de estado

• Actividad: ejecución no atómica en curso, dentro de

una máquina de estados. Lo que se hace en el estado
– do: operación que toma un tiempo en el estado. Puede
interrumpirse por un suceso, externo o interno, o terminar en
transición automática
• Acción: computación atómica ejecutable que produce
un cambio de estado del modelo o devuelve algún
valor (deben ser operaciones de la clase)
– entry: instantáneamente a la entrada del estado
– exit: instantáneamente a la salida del estado
– eventos

Ingeniería del software 21

Diagramas de estado

• La acción se considera instantánea

• Ejemplos:

Evento/acción
a b

estado A

entry: acción por entrar

exit: acción por salir
do: actividad mientras en estado

Ingeniería del software 22

Capturar requisitos funcionales

3. Detallar casos de uso (cont.)

– Cómo estructurar un CU
• Camino básico: “normal”
• Alternativas:
– El actor puede elegir diferentes caminos
– Si está implicado más de un actor, las acciones de uno
pueden influir el camino de otro
– El sistema detecta entradas erróneas
– Algunos recursos funcionan mal
• Gráficamente: diagrama de transición de estados

Ingeniería del software 23

Capturar requisitos funcionales

3. Detallar casos de uso (cont.)

– Qué incluir (descripción textual)
• Estado inicial como precondición (condiciones previas)
• Cómo y cuándo comienza el caso de uso
• Orden de acciones (flujo de sucesos)
• Cómo y cuándo termina el caso de uso
• Estados finales como postcondiciones (cond. posteriores)
• Caminos no permitidos
• Descripción caminos alternativos (incluida o no con el c. básico)
• Interacción del sistema con los actores y cambios que producen
• Uso de objetos, valores y recursos del sistema
• Qué hace el sistema. Separar responsabilidades. “el sistema...”
• Requisitos especiales
– Validar los casos de uso

Ingeniería del software 24

Capturar requisitos funcionales

3. Detallar casos de uso (cont.)

– Para casos de uso sencillos es suficiente texto
– Casos de uso complejos: necesitan estructuración y técnicas
visuales
– Formalismos: diagramas de
• transición de estados
• actividad
• interacción

Ingeniería del software 25

Diagramas de estado

• Diagrama de estados para un caso de uso: modificar

datos alumno

Cancelar

[datos
Datos modificar Datos aceptar Comprobar Válidos] Datos
personales corregidos datos modificados

[datosNoVálidos]

Ingeniería del software 26

Caso de uso “Sacar dinero”
Flujo de eventos
ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA
1. Este caso de uso empieza cuando 2. Pide la clave de identificación
un Cliente introduce una tarjeta en
el cajero

3. Introduce la clave 4. Comprueba la clave.

5. Presenta las opciones de operaciones

disponibles

6. Selecciona la operación de 7. Pide la cantidad a retirar.

Reintegro

8. Introduce la cantidad requerida 9. Procesa la petición y da el dinero

solicitado.
Devuelve la tarjeta y genera un recibo
10. Recoge la tarjeta.
11. Recoge el recibo
12. Recoge el dinero y termina el
caso de uso
Ingeniería del software 27
Caso de uso “Sacar dinero”
Flujo de eventos
ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA
(VWHFDVRGHXVRHPSLH]D 3LGHODFODYHGHLGHQWLILFDFLyQ
FXDQGRXQ&OLHQWHLQWURGXFH
XQDWDUMHWDHQHOFDMHUR

,QWURGXFHODFODYH &RPSUXHEDODFODYH

3UHVHQWDODVRSFLRQHVGH
RSHUDFLRQHVGLVSRQLEOHV

6. Selecciona la operación de 7. Pide la cantidad a retirar.

Reintegro

8. Introduce la cantidad requerida 9. Procesa la petición y da el dinero

solicitado.
Devuelve la tarjeta y genera un recibo
10. Recoge la tarjeta.
11. Recoge el recibo
12. Recoge el dinero y termina el
caso de uso
Ingeniería del software 28
Caso de uso “Validar usuario”
Flujo de eventos

ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA

1. Este caso de uso empieza cuando 2. Pide la clave de identificación
un Cliente introduce una tarjeta en el
cajero

3. Introduce la clave 4. Comprueba la clave

5. Si es válida presenta las opciones

disponibles y se termina el caso de uso

CAMINOS ALTERNATIVOS

Evento 3. El cliente cancela la transacción

Evento 4. La clave no es válida y se reinicia el caso de uso. Si

ocurre tres veces se cancela la transacción y no se devuelve la
tarjeta

££+$<48('(),1,5(6726'26)/8-26'((9(1726
Ingeniería del software 29
Caso de uso “Sacar dinero”
Flujo de eventos

ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA

1. Este caso de uso empieza cuando 2. Pide la cantidad a retirar.

se han presentado las opciones de
operaciones disponibles.
Selecciona la operación de
Reintegro
4. Procesa la petición y da el dinero
3. Introduce la cantidad requerida
solicitado.
Devuelve la tarjeta y genera un recibo

5. Recoge la tarjeta.
6. Recoge el recibo
7. Recoge el dinero y termina el CU

Ingeniería del software 30

Caso de uso “Sacar dinero”
Flujo de eventos
CAMINOS ALTERNATIVOS

· Evento 4: La cantidad solicitada supera el saldo. Se indica el error y

se cancela la operación.
· Evento 4: La cantidad solicitada supera el límite diario. Se indica el
error y se vuelve a pedir otra cantidad.
· Evento 4: En el cajero no hay dinero.

££+$<48('(),1,5(672675(6)/8-26'((9(1726

Podríamos definir diagramas de estados

5HTXLVLWRQRIXQFLRQDO asociado al caso de uso Sacar dinero:

El tiempo de respuesta para un cliente debe ser <30 sg en el 90% de
los casos

Ingeniería del software 31

Caso de uso “Validar usuario”
Flujo de eventos

tarjeta_introducida

Leyendo datos
do: visualizar (login)

enviar( nº tarjeta, clave )/n=0

Validando clave
do: validar (nºtarjeta, clave) [ NO datos_correctos AND n<3 ]
exit: n=n+1

[ datos_correctos ]
[ NO datos_correctos AND n=3 ]/tragar_tarjeta
cancelar

Ingeniería del software 32

Capturar requisitos funcionales

4. Prototipo de IU
– A partir de las descripciones de los casos de uso.
– Pasos:
• Diseño lógico: qué necesita cada actor de la interfaz para que se
pueda ejecutar el caso de uso
• Descripción y construcción del prototipo ejecutable pero acciones
nulas (validación y depuración)

Ingeniería del software 33

Capturar requisitos funcionales

5. Estructurar el modelo de casos de uso

– Identificar funcionalidad compartida
• Generalizaciones
– Identificar funcionalidad adicional y opcional
• extend
– Identificar otras relaciones
• include

Ingeniería del software 34

Diagramas de Casos de Uso

• Relaciones

– Generalización Identificar
Usuario
Usuario
Caso de
uso
Identificar
Adm

Caso de
uso Alta
Usuario
Administrador

Baja
Usuario

Ingeniería del software 35

Diagramas de Casos de Uso

• Relaciones
– Inclusión
Hacer
transfer. <<include>>
Consultar
saldo

Cliente Sacar <<include>>

– Extensión dinero

Corrección
automática. <<extend>>
Indicar
progreso
<<extend>>

Cliente Presentar
resultados

Ingeniería del software 36

Ejemplo. Cajero automático

Sacar
con visa
<<extends>>
Sacar
dinero
Reparar
<<include>>
Ingresar
Encargado
dinero mantenimiento
<<include>> <<include>>
Transf.
Cliente <<include>> Validar
del banco
<<include>> usuario
Consultar
saldo

Reponer <<include>>
dinero
<<include>>
Empleado Recoger
sucursal dinero

Ingeniería del software 37

Ejemplo. Cajero automático

Validar
R2, R3,...
usuario
Usuario
Sacar <<extends>>
dinero Sacar
con visa

Ingresar
dinero
Transf. R4,...
Cliente
del banco
Consultar
saldo

Reponer
dinero
R1
Empleado Recoger
sucursal dinero

Ingeniería del software 38

Captura de requisitos

TAREA PRODUCTOS (artifact)

Enumerar requisitos Lista de características
candidatos
Entender el contexto Modelo de negocio o de
del sistema dominio
Capturar requisitos Modelo de casos de uso
funcionales Prototipo IU
Capturar requisitos no Requisitos suplementarios
funcionales o casos individuales

Ingeniería del software 39

Ejemplo. Curso Virtual

Identificar
usuario
Usar chat
Usuario
Asistir
Comprobar al foro
copias
Consultar
Profesor
alumnos
Recomendar
Realizar test
<<extend>>
<<extend>>
Mostrar lecciones
Descargar apuntes
Alumno <<extend>>
Modificar datos
alumno
<<extend>> Consultar
bibliografía
Matricularse

Ingeniería del software 40

Ejemplo. Punto de venta
Lista de requisitos candidatos
FUNCIONES BÁSICAS
R1.1. Grabar la venta actual (productos comprados por el cliente)
R1.2. Calcular el total de la venta actual incluidos los impuestos
R1.3. Capturar información del producto usando el código de barras o
tecleando el código del producto.
R1.4. Reducir la cantidad en inventario cuando se realice la venta
R1.5. Registrar ventas realizadas
R1.6. El dependiente debe iniciar una sesión con identificador y clave para
usar el sistema
R1.7. Dar un mecanismo de almacenamiento
R1.8. Dar mecanismos de comunicación con otros procesos y sistemas
R1.9. Mostrar descripción y precio del producto almacenado NO
FUNCIONAL 5 seg, color

Ingeniería del software 41

Ejemplo. Punto de venta
Lista de requisitos candidatos

FUNCIONES DE PAGO
R2.1. Manejar pagos en metálico, tomar cantidad ofrecida y calcular el
cambio
R2.2. Manejar pagos con tarjeta, capturar información de la tarjeta con un
lector o manualmente y autorizar el pago vía modem.

OTRAS FUNCIONES
R3.1. Es necesario dar de alta dependientes nuevos en el puesto de venta
y dar de baja aquellos que dejan el puesto de venta.
R3.2. El puesto de venta es encendido y apagado cada día por el
encargado de la sección, que comprueba que el puesto funciona
correctamente y comprueba la fecha y la hora

REQUISITOS NO FUNCIONALES
Fácil de usar, Tiempo de respuesta corto, Plataforma, Precio al público
Interfaz (gráfica, con colores, ventanas, facilitar navegación por teclado,…)

Ingeniería del software 42

Ejemplo. Punto de venta

Punto de venta
R1.1, R1.2, R1.3, Comprar
R1.7, R1.9, R2.1, productos
R2.2, R2.3, R2.4

Iniciar sesión Cliente

Dependiente

Devolver
productos

Comenzar

Cerrar Encargado

Gestionar
usuarios
Admin.

Ingeniería del software 43

Caso de uso “Acceder al sistema”

ACCIÓN DEL ACTOR RESPUESTA DEL SISTEMA

1. El actor rellena los campos de DNI 2. El sistema comprueba que el formato

y clave (la clave se la dió la de ambos campos es el adecuado; es
Universidad) en una pantalla que le decir, que el DNI es un string de 8
ha presentado el sistema y pulsa dígitos y que la clave es una secuencia
sobre el botón HQYLDU de 4 dígitos
3. El sistema verifica que la clave
tecleada se corresponde con el DNI
tecleado; es decir, que la clave es la
correcta para ese DNI.
4. El sistema verifica que la fecha actual
es la que le corresponde al actor para
matricularse.
5. El sistema comprueba que el actor no
&DPLQRVDOWHUQDWLYRV: adeuda ningún importe a la Universidad
Evento 1: el actor cancela la operación
Evento 2: existe error en el formato del DNI y/o de la clave
Evento 3: existe error en la clave
Evento 4: la fecha actual no es la asignada al actor para matricularse
Ingeniería
Evento 5:delelsoftware
actor es moroso 44
Caso de uso “Acceder al sistema”
ejecutarAplicación / ejecuta
{ejecuta.startTime > 5 and ejecuta.stopTime < 2}
{ejecuta.numero_de_usuarios < 50}

Leer datos
do/ visualizar (login) aqui
aqui enviar( NIF, clave )

clave incorrecta Datos incorrectos

do/ visualizar (login.error.clave) do/ visualizar (login.error.datosIncorrectos)

[ clave incorrecta ] [ datos incorrectos ]

Validar datos
do/ validaDatos (NIF, clave)
[ dia incorrecto ]
[ moroso ]
[ datos correctos ]
clave incorrecta
Moroso
do/ visualizar (login.error.clave)
do/ visualizar (login.error.deudor)
salir salir
salir
Ingeniería del software 45