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:
debe construirse

qu sistema

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
Inicio

Elaboracin

Construccin

Transicin

Requisitos
Anlisis
Diseo
Implementacin
Prueba

Iteraciones:

ite r.
#1

ite r.
#2

ite r.
#n

ite r.
# n+ 1

ite r.
# n+ 2

ite r.
#m

En el PUD lo que se hace

fundamentalmente es obtener el
MODELO DE CASOS DE USO

ite r.
#m +1

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

Realizar Matrcula

Estudiante

El estudiante DECIDE
EJECUTAR EL C.U.

Caso de Uso en UML

iniciador

Estudiante

Realizar Matrcula

Sistema Bancario

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

iniciador

Estudiante

Realizar Matrcula

Sistema

FLUJO DE EVENTOS:
El estudiante introduce el DNI,
Se almacenan los datos de las matrculas en el sistema,

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

iniciador

Estudiante

Realizar Matrcula

Escoger Asignaturas
iniciador

Profesor

Pagar Nminas

Sistema
Bancario

Relaciones entre actores en

UML
iniciador

Solicitar Carnet
Deportivo

Estudiante

Sistema
Bancario

Y si los profesores
tambin pueden solicitar
carnet deportivo?

Errores tpicos en CU
Solicitar Carnet
Deportivo

iniciador

Estudiante
iniciador

Profesor

Sistema
Bancario

NO, ya que eso significa que

los 3 actores participan en
el caso de uso y eso no es
lo que queremos

Relaciones entre actores en

UML
iniciador

Solicitar Carnet
Deportivo Estud.

Estudiante

iniciador

Sistema
Bancario
Solicitar Carnet
Deportivo Prof.

Profesor SOLUCIN? 1: CUs distintos

Relaciones entre actores en

UML
iniciador

Solicitar Carnet
Deportivo

Sistema
Bancario

Universitario

Profesor

Estudiante

SOLUCIN 2:
(MEJOR)
generalizacin
entre actores

Relaciones entre CU:

includes
<<includes>>
CASO DE
USO A

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 B
- cond. C

ACTOR

<<extends>> CASO DE
USO A

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

CASO DE
USO B

El C.U. A es una especializacin

ACTOR
(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

Relaciones entre CU en UML

Realizar Matrcula

Estudiante

<<includes>>

Escoger Asignatura
<<includes>>

Profesor

Identificarse

Relaciones entre CU en UML

Reservar Libro

Lector

<<includes>>

Buscar Libro
por cdigo

AMBOS CASOS DE USO DEBEN

TENER SENTIDO EN EL SISTEMA

Relaciones entre CU en UML

Realizar Matrcula
- No identificado

Estudiante

Escoger Asignatura

<<extends>>

- No identificado
<<extends>>

Profesor

Identificarse

Relaciones entre CU en UML

Ingresar Dinero

Cliente

Retirar Dinero

Flujo de eventos de RT:

- Identificar cliente
- Obtener su nmero de cuenta
- Comprobar que la cuenta no est
bloqueada

Realizar
Transaccin

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.

Errores tpicos en CU
Realizar Matrcula

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

Errores tpicos en CU
Imprimir informes

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

Cliente
Retirar Dinero
Flujo de eventos de RT:
- Identificar cliente
- Obtener su nmero de cuenta

Realizar
Transaccin

- 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

Tomar Prstamo
Copia Libro
- No disponible

<<extends>>
Reservar Libro

Socio

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

SIGNATURALIBRO:
NMEROSOCIO:
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.

TOMAR EN PRSTAMO

RESERVAR LIBRO

Cancel

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
VISIBILIDAD:
+ = pblico
- = privado
# = visible para
subclases

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.

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),

NOMBRE DE LA SUBCLASE
atribSubClase1, atribSubClase2 ...
metSubc1 (parmetros),

La SUBCLASE hereda todos los ATRIBUTOS y los

MTODOS de la SUPERCLASE.

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
susA
1..*

suB
0..1

cardinalidades

Almacenar pares <objeto de A, objeto de B>

Indicando CARDINALIDAD
Objetos de la
clase A

@a1
@a2
@a3
@a4

@b1
@b2

Objetos de la
clase B

Cardinalidades en UML

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
CLIENTE 1

0..*
posee INMUEBLE

Otra opcin es dar un nico nombre a

la asociacin e indicar cmo se lee
Posee
CLIENTE

0..*

INMUEBLE

Ej. de Asociacin en UML

@C1 P. Prez Mayor 13 943112232 3/3/89 Leer, Ftbol
@C2 K. Sola

Mayor 3 943222232 4/3/89 Mus, Monte

@P1 Matia 12, 1A

90000.00 3

@P2 Hriz 1, 2A

85000.50 2

@G1 Hriz 5
@C1
@C2

15000.50 true
@P1
@P2
@G1

ASOCIACIN

Asociacin n-aria en UML

CLASE A

Un par <b,c> conocido

puede estar asociado a
los as que quiera

0..*

CLASE C
0..1
Un par <a,b> conocido
puede estar asociado a los
sumo con un solo c

CLASE B
0..*

Un par <a,c> conocido puede estar

asociado a los bs que quiera

Fijados el resto de objetos que participan en la

asociacin, con cuntos pueden relacionarse?

Asociacin n-aria en UML

@a1
@a2
@a3
@a4

@c1
@c2

@b1
@b2

<@a1,@c1,@b1>
<@a1,@c1,@b2>
<@a3,@c2,@b2>
<@a4,@c2,@b2>
cardinalidad 0..1 en el lado de C

<@a1,@c1> @b1 y @b2

<@a3,@c2> @b2
<@a4,@c2> @b2
cardinalidad 0..* en el lado de B

<@a1,@b1>
<@a1,@b2>
<@a3,@b2>
<@a4,@b2>

@c1
@c1
@c2
@c2

cardinalidad 0..* en el lado de A

<@c1,@b1> @a1
<@c1,@b2> @a1
<@c2,@b2> @a3 y @a4

Ej. de asociacin n-aria en UML

Estudiante

0..*

Profesor
0..*

Asignatura
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

* 0..*

matriculadoEn
*

Profesor

Asignatura

imparte
*

*
*

Los estudiantes se matriculan en asignaturas

Los profesores imparten asignaturas

ASOCIACIN TERNARIA SLO SI HAY

QUE DISTINGUIR CON QU
PROFESOR/ES SE HA MATRICULADO

Ej. de asociacin n-aria en UML

Estudiante

Profesor
*

Asignatura
*

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

Profesor
0..1

Asignatura
*

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

Profesor
0..1

Asignatura
*

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

Profesor
0..1

Asignatura
*

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
CLASE A

CLASE B
1..*

0..1

ES UNA ASOCIACIN CON LA SEMNTICA

FORMADO POR/FORMA PARTE DE
CLASE A
formaParteDe

0..1

1..*

formadoPor

CLASE B

Ej. de agregacin en UML

Coche

Rueda

0..1

Motor

Composicin en UML
CLASE A

CLASE B
1..*

nica cardinalidad posible

ES UNA ASOCIACIN CON LA
SEMNTICA
COMPUESTO POR/ES COMPONENTE
Si se borra el a, se borran los b
DE
CLASE A
esComponenteDe

1..*

compuestoPor

CLASE B

Ej. de composicin en UML

Coche

Rueda

Motor

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

Clase Asociacin en UML

CLASE A

CLASE B
susA
1..*

suB
0..1

CLASE C
atrib

Clase Asociacin

Para almacenar
<objeto de A, objeto de B, Atrs. PROPIOS>
Objetos de la
clase A

@a1
@a2
@a3
@a4

@b1
@b2

Objetos de la
clase B

@c1 @c2 @c3

v1
v2
v3

Objetos de la
clase C

Clase Asociacin en UML

CLASE A

CLASE B
susA
1..*

suB
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

CLASE A
susA
1..*

CLASE C

CLASE B
suB
0..1

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

Ej. de clase Asociacin en

UML
Estudiante

Asignatura

matriculadoEn
*

*
Matrcula
numConv,
nota,

Clase Asociacin

Si se desea poder almacenar el

n de convocatoria, nota
obtenida, curso acadmico, etc.

Clase asociacin n-aria en

UML
CLASE A

0..*

CLASE C
0..1

CLASE B
0..*

CLASE D

Diagrama de clases en UML

Clase A

susA
0..*

Clase D
atrD1 ..
Clase E
atrE1

0..
*

suB
1

0..5

Clase BD
atrBD1 ..

Clase B

Clase C

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

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