Tema 3: Captura de

requisitos
De la visin de los requisitos ...

... a su captura como casos de uso

Contenidos
1.- Introduccin
2.- Visin general de la captura de
requisitos
3.- El rol del flujo de trabajo (FT) de
requisitos dentro del ciclo de vida
4.- Artefactos a obtener en los FT captura
requisitos
Anexos: trabajadores y flujo de actividades

1. Introduccin
Capturar requisitos:
qu sistema debe construirse
Es difcil
Usuarios no saben qu quieren
Construir sistema correcto
Usar lenguaje sencillo en vez de
documentos ininteligibles para los
usuarios
2. Visin general de la
captura de requisitos
Listar requisitos candidatos
Entender contexto del sistema
Capturar requisitos funcionales
Capturar requisitos no funcionales

2.1. Listar los requisitos
candidatos
Aportar ideas de cmo cada
uno ve el sistema y
apuntarlas en una lista
Indicar si deben
incorporarse al sistema o no
2.2. Entender el
contexto del sistema
Modelado del dominio
Describir los objetos del dominio
Construir un glosario de trminos
Modelado del negocio
describir los procesos
2.3. Capturar los
requisitos funcionales


Encontrar casos de uso

2.4. Capturar los
requisitos no funcionales
Son propiedades o
restricciones del sistema
no acerca de lo que hay
que hacer
Resumen de la visin
general de los requisitos
HAY QUE CAPTURAR LOS REQUISITOS:

NECESIDADES DE ALMACENAMIENTO DE
DATOS
Modelo del Dominio (o Modelo del Negocio)

NECESIDADES DE FUNCIONALIDADES DEL
SISTEMA
Modelo de Casos de Uso y Requisitos Adicionales

3. Rol del Flujo de Trabajo
de requisitos en el CV







Requisitos
Diseo
Implementacin
Prueba
Anlisis
i t e r .
# 1
i t e r .
# 2
i t e r .
# n
i t e r .
# n + 1
i t e r .
# n + 2
i t e r .
# m
i t e r .
# m + 1
Inicio Elaboracin Construccin Transicin
Iteraciones:
En el PUD lo que se hace
fundamentalmente es obtener el
MODELO DE CASOS DE USO
Rol del FT de requisitos
en el CV
Fase de iniciacin: identificar la mayora de los
casos de uso y detallar los ms crticos (10%)
Fase de elaboracin: capturar hasta el 80% de
requisitos (y tener el 5-10% implementados)
Fase de construccin: capturar e implementar el
resto
Fase de transicin: no hay captura de requisitos
Pero el CV del PUD de
Rational incluye ms FTs
Modelado
del
Negocio
Gestin
del
Proyecto
Existe FT donde se obtiene el Mod. del Negocio
CONSIDERAREMOS QUE
AMBOS FLUJOS DE TRABAJO
SON UNO: FT de CAPTURA DE
REQUISITOS
Se obtiene: MODELO DEL
DOMINIO Y DE CASOS DE USO
4. Artefactos a obtener en
los FT captura requisitos
casos de uso
actores
prototipos de interfaces de usuario
glosario
diagrama de clases (modelo del
dominio)
descripcin de la arquitectura
Artefacto: actor
Es tipo de usuario (persona)
O sistema externo

Los actores se encuentran fuera
del sistema y colaboran con l
Actor en UML
Empleado
Sistema Bancario
SLO SI ES EXTERNO AL
SISTEMA DE INFORMACIN
QUE SE EST MODELANDO
Artefacto: caso de uso
Cada forma en la que un actor
utiliza el sistema
A un caso de uso hay que asociarle:
Flujo de eventos: secuencia de acciones
que indica cmo se interacciona con el
actor/es
Requisitos especiales: descripcin
textual de los requisitos no funcionales
Caso de Uso en UML
Estudiante
Realizar Matrcula
El estudiante DECIDE
EJECUTAR EL C.U.
Caso de Uso en UML
Estudiante
Realizar Matrcula
Sistema Bancario
iniciador
Caso de Uso en UML
Flujo de eventos (o sucesos)
El estudiante proporciona su DNI
El sistema muestra todas las asignaturas en las que puede
matricularse y que, de momento, no estn completas
El estudiante escoge las asignaturas que desea
El sistema calcula el precio de la matrcula y realiza el cobro de la
cuenta del estudiante en el sistema bancario
Flujos de eventos alternativos:
1.- El DNI proporcionado no es el de un estudiante. Fin.
2.- Alguna de las asignaturas est completa. Fin.
NOTA: Esto puede ocurrir porque el CU se ejecuta concurrentemente

Caso de Uso en UML
Requisitos especiales
El CU REALIZAR MATRCULA debe ejecutarse en un
tiempo razonablemente corto.
El CU debe indicar durante su ejecucin si alguna de las
asignaturas en las que se quiere matricular est completa
No es aceptable que despus de matricularte en una asignatura
te digan que no puede ser, que la asignatura estaba completa
Debe poder ejecutarse de manera simultnea por al
menos 20 estudiantes.

Errores tpicos en CU
FLUJO DE EVENTOS:
El estudiante introduce el DNI,
Se almacenan los datos de las matrculas en el sistema,
Estudiante
Realizar Matrcula
Sistema
iniciador
NO SE TRATA DE UN SISTEMA EXTERNO
SINO DEL PROPIO SISTEMA (EL C.U. ES PARTE DE L)
Artefacto: Modelo de CU
Modelo que contiene todos los
actores, CUs y sus relaciones
Con el MCU, clientes y
desarrolladores se ponen de
acuerdo
Entrada al anlisis, diseo,
implementacin y prueba
Modelo de CU (MCU) en UML
Estudiante
Realizar Matrcula
Sistema
Bancario
iniciador
Escoger Asignaturas
Profesor
Pagar Nminas
iniciador
Relaciones entre actores en
UML
Estudiante
Solicitar Carnet
Deportivo
Sistema
Bancario
iniciador
Y si los profesores
tambin pueden solicitar
carnet deportivo?
Errores tpicos en CU
Estudiante
Solicitar Carnet
Deportivo
Sistema
Bancario
iniciador
Profesor
NO, ya que eso significa que
los 3 actores participan en
el caso de uso y eso no es
lo que queremos
iniciador
Relaciones entre actores en
UML
Estudiante
Solicitar Carnet
Deportivo Estud.
Sistema
Bancario
iniciador
Profesor
Solicitar Carnet
Deportivo Prof.
iniciador
SOLUCIN? 1: CUs distintos
Relaciones entre actores en
UML
Universitario
Solicitar Carnet
Deportivo
Sistema
Bancario
iniciador
Profesor
Estudiante
SOLUCIN 2:
(MEJOR)
generalizacin
entre actores
Relaciones entre CU:
includes
CASO DE
USO A
<<includes>>
ACTOR
CASO DE
USO B
El CASO DE USO A includes
al CASO DE USO B si
SIEMPRE que se ejecuta el
caso de uso A, se ejecuta
el caso de uso B
Relaciones entre CU:
extends
CASO DE
USO A
<<extends>>
ACTOR
CASO DE
USO B
- cond. C
El CASO DE USO A extends
al CASO DE USO B si
SIEMPRE que se ejecuta el
caso de uso B, si se cumple
la condicin C, entonces se
ejecuta el caso de uso A
Relaciones entre CU:
generalizacin
CASO DE
USO A
ACTOR
CASO DE
USO B
El C.U. A es una especializacin
(o un caso particular) del C.U.
B. Todo lo que se haya definido
que se va a ejecutar para B se
ejecutar tambin para A
Realizar Matrcula
Escoger Asignatura
Profesor
Relaciones entre CU en UML
Estudiante
Identificarse
<<includes>>
<<includes>>
Reservar Libro
Buscar Libro
por cdigo
Relaciones entre CU en UML
Lector
<<includes>>
AMBOS CASOS DE USO DEBEN
TENER SENTIDO EN EL SISTEMA
Realizar Matrcula
Escoger Asignatura
Profesor
Relaciones entre CU en UML
Estudiante
Identificarse
<<extends>>
<<extends>>
- No identificado
- No identificado
Ingresar Dinero
Retirar Dinero
Relaciones entre CU en UML
Cliente
Realizar
Transaccin
Flujo de eventos de RT:
- Identificar cliente
- Obtener su nmero de cuenta
- Comprobar que la cuenta no est
bloqueada
Errores tpicos en CU
Definir CU que no lo son
No hay actor que lo ejecute
Es un procedimiento interno del sistema
Ocurre normalmente al buscar includes o
extends
REGLA DE ORO: Un CU es funcionalidad del
sistema que proporciona algn RESULTADO o
VALOR a por lo menos un ACTOR.
Realizar Matrcula
Errores tpicos en CU
Estudiante
<<includes>>
Seleccionar
asignatura
Si al realizar la matrcula, se van
seleccionando (en la interfaz)
asignaturas en las que matricularse
NO ES CASO DE USO
Imprimir informes
Errores tpicos en CU
Empleado
<<includes>>
Imprimir
informe
Un posible flujo de eventos sera:

El empleado proporciona su identificador
Se seleccionan los informes del empleado
an no impresos
Se imprime cada uno de ellos
Posible excepcin:
generalizacin
Ingresar Dinero
Retirar Dinero
Cliente
Realizar
Transaccin
Flujo de eventos de RT:
- Identificar cliente
- Obtener su nmero de cuenta
- Comprobar que la cuenta no est bloqueada
En este caso no parece que Realizar Transaccin
sea un CASO DE USO REAL, pero PUEDE resultar
TIL para no repetir muchos flujos de eventos.
Puede ocurrir en el caso de GENERALIZACIN
Artefactos: glosario y
prototipo de interfaz
GLOSARIO: Documento donde se definen
los trminos ms comunes e importantes
utilizados
PROTOTIPO DE INTERFAZ DE USUARIO:
ayudan a entender las interacciones entre
los actores y el sistema
conseguir mejores interfaces de usuario

Ejemplo de GLOSARIO
ASIGNATURA:
ESTUDIANTE: es una persona que est estudiando una
carrera en la universidad UnivX. Necesariamente debe estar
matriculado en por lo menos una ASIGNATURA.
MATRCULA: es el resultado de un proceso administrativo por
el cual un ESTUDIANTE adquiere el derecho a ser evaluado en
dos convocatorias de una ASIGNATURA. Se le asocia a un
GRUPO. Tiene derecho a asistir a las clases del PROFESOR
responsable de dicha ASIGNATURA en el GRUPO asignado.
PROFESOR: es una persona que trabaja en UnivX y que
imparte al menos una asignatura de una determinada
TITULACIN. Se encarga de evaluar a todos los estudiantes
matriculados en la asignatura y asignados a sus grupos. El
profesor no puede ser estudiante en la misma carrera en la que
imparte clases, pero s en otras.

Ej. prototipo de interfaz de CU
Socio
Tomar Prstamo
Copia Libro
Reservar Libro
<<extends>>
- No disponible
Flujo de eventos:
El socio da su nmero de socio y la signatura del
libro que desea tomar en prstamo
El sistema comprueba si existe alguna copia no
prestada de dicho libro
Si no hay copias disponibles: EXTENDS
RESERVAR LIBRO
Se comprueba que el socio no se pasa de su
nmero mximo de libros en prstamo
Se registra el nuevo prstamo con la fecha actual
Ej. prototipo de interfaz de CU
CASO DE USO: TOMAR COPIA LIBRO EN PRSTAMO
rea de texto donde aparecer el nmero de copia del libro que se
ha tomado en prstamo.
Si no hay ninguna libre o si el socio ha sobrepasado su nmero
mximo de prstamos entonces se indicar aqu mismo.
Cancel
TOMAR EN PRSTAMO RESERVAR LIBRO
SIGNATURA LIBRO:
NMERO SOCIO:
Artefacto: modelo del
dominio
Captura los tipos de objetos en el
contexto del sistema y sus relaciones.
cosas que existen
eventos que suceden
Seguramente aparecern en el
GLOSARIO
Clase UML
NOMBRE DE LA CLASE
atributo1
atributo2
...
mtodo1 (parmetros): resultado
mtodo2 (parmetros) : void
...
-- responsabilidades de la clase
-- texto que indica qu hace,
restricciones especiales de uso, etc.
VISIBILIDAD:
+ = pblico
- = privado
# = visible para
subclases
Los objetos de dicha clase pueden almacenar
valores en los atributos y ejecutar sus mtodos
Ejemplo: Clase UML
Cliente
- nombre, direccin, tfno: String
- fechaNac: Date
- Aficiones: Vector(String) ...
+ getNombre(): String,
+ setNombre(n: String): void
+ addAficion(a:String): void ...
- - almacena datos de clientes
Los tipos (String, Date, void,..) NO son definidos
por UML. Se suelen usar los del LP que se escoja
Especializacin y
Generalizacin en UML
NOMBRE DE LA SUPERCLASE
atributo1, atributo2 ...
mtodo1 (parmetros),
La SUBCLASE hereda todos los ATRIBUTOS y los
MTODOS de la SUPERCLASE.
NOMBRE DE LA SUBCLASE
atribSubClase1, atribSubClase2 ...
metSubc1 (parmetros),
Ejemplo de Especializacin
y Generalizacin en UML
INMUEBLE
direccion: String; precio: float
PISO
numeroHabitaciones: int,
GARAJE
cerrado: boolean,
Asociacin en UML
CLASE A CLASE B
suB susA
1..* 0..1
cardinalidades
Almacenar pares <objeto de A, objeto de B>
Indicando CARDINALIDAD
@b1
@b2
@a1
@a2
@a3
@a4
Objetos de la
clase A
Objetos de la
clase B
Cardinalidades en UML
1 con uno
0..1 con uno o ninguno
* con cero, uno o varios
0..* con cero, uno o varios
1..* con uno o varios
n con n exactamente
n..m mnimo con n y mximo con m
Nota: n y m son nmeros naturales
Ejemplo: 8 , 17 , 7..9 ,
Ej. de Asociacin en UML
propietario 0..*
CLIENTE INMUEBLE
posee 1
Posee
0..*
CLIENTE INMUEBLE
1
Otra opcin es dar un nico nombre a
la asociacin e indicar cmo se lee
Ej. de Asociacin en UML
P. Prez Mayor 13 943112232 3/3/89 Leer, Ftbol
K. Sola Mayor 3 943222232 4/3/89 Mus, Monte
Matia 12, 1A 90000.00 3
Hriz 1, 2A 85000.50 2
Hriz 5 15000.50 true
@C1
@C2
@P1
@P2
@G1
@C1
@C2
@P1
@P2
@G1
ASOCIACIN
Asociacin n-aria en UML
CLASE A
CLASE B
0..* 0..1
CLASE C
0..*
Un par <a,b> conocido
puede estar asociado a los
sumo con un solo c
Un par <a,c> conocido puede estar
asociado a los bs que quiera
Un par <b,c> conocido
puede estar asociado a
los as que quiera
Fijados el resto de objetos que participan en la
asociacin, con cuntos pueden relacionarse?
Asociacin n-aria en UML
<@a1,@c1,@b1>
<@a1,@c1,@b2>
<@a3,@c2,@b2>
<@a4,@c2,@b2>
@b1
@b2
@a1
@a2
@a3
@a4
@c1
@c2
<@a1,@b1> @c1
<@a1,@b2> @c1
<@a3,@b2> @c2
<@a4,@b2> @c2
cardinalidad 0..1 en el lado de C
<@c1,@b1> @a1
<@c1,@b2> @a1
<@c2,@b2> @a3 y @a4
cardinalidad 0..* en el lado de A
<@a1,@c1> @b1 y @b2
<@a3,@c2> @b2
<@a4,@c2> @b2
cardinalidad 0..* en el lado de B
Ej. de asociacin n-aria en UML
Estudiante
Asignatura
0..* 0..*
Profesor
0..*
Informacin sobre qu profesores imparten
qu asignaturas a qu estudiantes
HAY QUE ESTAR SEGUROS DE QUE SE
NECESITA UNA ASOCIACIN TERNARIA
Ej. de asociacin n-aria en UML
Estudiante
Asignatura
*
*
Profesor
Los estudiantes se matriculan en asignaturas
Los profesores imparten asignaturas
ASOCIACIN TERNARIA SLO SI HAY
QUE DISTINGUIR CON QU
PROFESOR/ES SE HA MATRICULADO
imparte
matriculadoEn
*
*
* 0..*
Ej. de asociacin n-aria en UML
Estudiante
Asignatura
* *
Profesor
*
Los estudiantes se matriculan en asignaturas.
Los profesores imparten asignaturas.
Cuando un estudiante se matricula en una
asignatura, NO todos los profesores que la
imparten son sus profesores.
Ej. de asociacin n-aria en UML
Estudiante
Asignatura
* 0..1
Profesor
*
par <est,asig> conocido con 0 1 prof.
Un estudiante se puede matricular en una
asignatura SLO CON UNO DE LOS
PROFESORES QUE LA IMPARTE, o no
matricularse, claro.
Ej. de asociacin n-aria en UML
Estudiante
Asignatura
* 0..1
Profesor
*
par <est,prof> conocido en 0 o varias asig

Un estudiante se puede matricular con el
mismo profesor en DISTINTAS asignaturas
o puede que no le corresponda ese profesor.
Ej. de asociacin n-aria en UML
Estudiante
Asignatura
* 0..1
Profesor
*
par <prof,asig> conocido con 0 varios est

Un profesor puede impartir o no una
asignatura, y si la imparte, entonces puede
tener VARIOS estudiantes
Agregacin en UML
ES UNA ASOCIACIN CON LA SEMNTICA
FORMADO POR/FORMA PARTE DE
CLASE A CLASE B
1..*
0..1
CLASE B
CLASE A
formadoPor
formaParteDe
1..*
0..1
Ej. de agregacin en UML
Coche Rueda
4
0..1
Motor
1
Composicin en UML
CLASE A CLASE B
1..*
1
CLASE B
CLASE A
compuestoPor
esComponenteDe
1..*
1
ES UNA ASOCIACIN CON LA SEMNTICA
COMPUESTO POR/ES COMPONENTE DE
nica cardinalidad posible
Si se borra el a, se borran los b
Ej. de composicin en UML
Coche Rueda
4
1
Motor
1
En este S.I. no se permite tener
motores ni ruedas sueltos, y al
borrar el coche, se borra todo
Seguro que no se trata de un desguace.
Clase Asociacin en UML
CLASE A CLASE B
suB susA
1..* 0..1
Para almacenar
<objeto de A, objeto de B, Atrs. PROPIOS>
@b1
@b2
@a1
@a2
@a3
@a4
Objetos de la
clase A
Objetos de la
clase B
CLASE C
Clase Asociacin
atrib
@c1
v1
@c2
v2
@c3
v3
Objetos de la
clase C
Clase Asociacin en UML
CLASE A CLASE B
suB susA
1..* 0..1
CLASE C
Clase Asociacin
Cada objeto de C se refiere
a un nico objeto de A y a
un nico objeto de B
Clase Asociacin en UML
Si se quisiera que uno de C pudiera
asociarse con varios de A y con 0
1 de B entonces no se puede usar
una clase asociacin sino una clase
(normal) y 2 asociaciones
CLASE A CLASE B
suB susA
1..*
0..1
CLASE C
Ej. de clase Asociacin en
UML
Estudiante Asignatura
* *
Matrcula
Clase Asociacin
Si se desea poder almacenar el
n de convocatoria, nota
obtenida, curso acadmico, etc.
matriculadoEn
numConv,
nota,
Clase asociacin n-aria en
UML
CLASE A
CLASE B
0..* 0..1
CLASE C
0..*
CLASE D
Diagrama de clases en UML
Durante la captura de requisitos se utiliza
para representar el MODELO DEL DOMINIO.
De momento, slo interesan los ATRIBUTOS
de las clases y NO SUS MTODOS
1
0..
*
susA
suB
0..*
1
0..5
Clase A
Clase B
Clase C
Clase D
Clase E
atrE1

atrD1 ..



Clase BD
atrBD1 ..
Artefacto: descripcin
de la arquitectura
Hay que realizar una descripcin
preliminar de la arquitectura
Por lo menos debe dar cabida a los
casos de usos con funcionalidad crtica

El Proceso Unificado de Desarrollo de Software es:
Guiado por casos de uso
Centrado en la arquitectura
Con un ciclo de vida iterativo e incremental
Casos de uso crticos
Son los casos de uso importantes para
los usuarios del sistema
que ayudan a encontrar el esqueleto del
sistema (la arquitectura) sobre el que
aadir el resto de las funciones
requeridas
Tambin son casos de uso con requisitos
no funcionales importantes (rendimiento,
tiempo de respuesta, etc.)
Anexo: Trabajadores
Son las personas responsables de obtener los
artefactos anteriores. En realidad se trata ms
bien de puestos que de personas ya que una
misma persona podra desempear ms de un
puesto o trabajo. Son los siguientes:
Analista de sistema
Especificador de casos de uso
Diseador del interfaz del usuario
Arquitecto
Trabajadores (2)
Analista de sistema:
es responsable del modelo de casos de uso (el conjunto
de requisitos), encontrar actores y casos de uso,
asegurarse de que el conjunto es completo y consistente
(con el glosario). No es responsable de especificar en
detalle cada caso de uso.
Especificador de casos de uso:
detalla especficamente casos de uso. Necesita trabajar
estrechamente con los usuarios reales.
Diseador del interfaz del usuario
define los prototipos de los interfaces de usuario
Arquitecto
describe la vista arquitectural del modelo de casos de uso
Anexo: Actividades en el
FT de requisitos
1.- Encontrar actores y casos de uso
Encontrar actores
Encontrar casos de uso
Describir brevemente cada caso de uso
Describir el modelo de casos de uso como un todo
2.- Priorizar los casos de uso
3.- Detallar un caso de uso
Estructurar la descripcin de un caso de uso
Qu incluir en la descripcin de un caso de uso
Formalizar las descripciones de casos de uso
Actividades en el FT de
requisitos
4.- Prototipo de interfaz de usuario
Crear diseo lgico de interfaz de usuario
Crear prototipo y diseo fsico de interfaz de usuario
5.- Estructurar el modelo de casos de uso
Identificar descripciones compartidas de funcionalidad
Identificar descripciones de funcionalidad adicionales y
opcionales
Identificar otras relaciones entre casos de uso