UNIVERSIDAD NACIONAL AMAZONICA DE MADRE

DE DIOS

Análisis y modelado de
Sistemas de Información
CAPTURA DE REQUISITOS

Jorge Raul Sotomayor Perales

Profesión: Ing. De sistemas
Mgtr. En Ingeniería de Software
Raul.perales@hotmail.es
2018
1.- Introducción
2.- Visión 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
 Capturar requisitos:
 qué sistema debe construirse
◦ Es difícil
 Usuarios no saben qué quieren
◦ Construir sistema correcto
 Usar lenguaje sencillo en vez de
documentos ininteligibles para los usuarios
 2. Visión 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 cómo 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 términos
• 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
 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 Elaboración Construcción Transición
Requisitos

Análisis

Diseño

Implementación

Prueba

ite r. ite r. ite r. ite r. ite r. ite r. ite r.

Iteraciones: #1 #2 #n # n+ 1 # n+ 2 #m #m +1

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 iniciación: identificar la mayoría de los
casos de uso y detallar los más críticos (10%)
• Fase de elaboración: capturar hasta el 80% de
requisitos (y tener el 5-10% implementados)
• Fase de construcción: capturar e implementar el
resto
• Fase de transición: no hay captura de requisitos
 Modelado
del Negocio

Gestión 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)
• descripción de la arquitectura
 Artefacto: actor

• Es tipo de usuario (persona)

• O sistema externo

• Los actores se encuentran fuera

del sistema y colaboran con él
Empleado Sistema Bancario

SÓLO SI ES EXTERNO AL SISTEMA DE

INFORMACIÓN 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 cómo se interacciona con el actor/es
– Requisitos especiales: descripción textual de los
requisitos no funcionales
 Realizar Matrícula

Estudiante

El estudiante DECIDE
EJECUTAR EL C.U.
 Realizar Matrícula
iniciador

Sistema Bancario
Estudiante
 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 están completas
◦ El estudiante escoge las asignaturas que desea
◦ El sistema calcula el precio de la matrícula 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
 Requisitos especiales
◦ El CU “REALIZAR MATRÍCULA” debe ejecutarse en un
tiempo razonablemente corto.
◦ El CU debe indicar durante su ejecución si alguna de
las asignaturas en las que se quiere matricular está
completa
 No es aceptable que después de matricularte en una
asignatura te digan que no puede ser, que la asignatura
estaba completa
◦ Debe poder ejecutarse de manera simultánea por al
menos 20 estudiantes.
◦ …
 Realizar Matrícula
iniciador

Sistema
Estudiante

FLUJO DE EVENTOS:
• El estudiante introduce el DNI, …
• Se almacenan los datos de las matrículas 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 análisis, diseño, implementación y
prueba
 iniciador

Realizar Matrícula

Estudiante

Escoger Asignaturas
Sistema
iniciador Bancario
Pagar Nóminas
Profesor
 iniciador Solicitar Carnet Deportivo

Estudiante Sistema
Bancario
¿ Y si los profesores también
pueden solicitar carnet
deportivo?
 iniciador Solicitar Carnet Deportivo

Estudiante Sistema
iniciador Bancario

NO, ya que eso significa que los 3

actores participan en el caso de
Profesor uso y eso no es lo que queremos
 iniciador Solicitar Carnet Deportivo
Estud.

Estudiante Sistema
Bancario

iniciador Solicitar Carnet Deportivo Prof.

Profesor ¿SOLUCIÓN? 1: CUs distintos

 iniciador Solicitar Carnet Deportivo

Sistema
Universitario Bancario

SOLUCIÓN 2:
(MEJOR)
generalización
Estudiante entre actores
Profesor
 Relaciones entre CU:
includes
<<includes>>
CASO DE CASO DE
USO A USO B

El CASO DE USO A includes al

ACTOR 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 <<extends>> CASO DE
USO B USO A
- cond. C
El CASO DE USO A extends al
ACTOR CASO DE USO B si SIEMPRE que
se ejecuta el caso de uso B, si se
cumple la condición C, entonces se
ejecuta el caso de uso A
 Relaciones entre CU:
generalización

CASO DE CASO DE
USO A USO B

El C.U. A es una especialización (o un

ACTOR
caso particular) del C.U. B. Todo lo que
se haya definido que se va a ejecutar
para B se ejecutará también para A
 Realizar Matrícula

<<includes>>
Estudiante
Escoger Asignatura

<<includes>>

Identificarse
Profesor
 Reservar Libro

<<includes>>
Lector

Buscar Libro
por código

AMBOS CASOS DE USO DEBEN TENER

SENTIDO EN EL SISTEMA
 Realizar Matrícula
- No identificado

<<extends>>
Estudiante Escoger Asignatura

- No identificado

<<extends>>

Identificarse
Profesor
 Ingresar Dinero

Cliente Retirar Dinero

Flujo de eventos de RT:

- Identificar cliente Realizar
- Obtener su número de cuenta Transacción
- Comprobar que la cuenta no está bloqueada
 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 algún
RESULTADO o VALOR a por lo menos un
ACTOR.
 Realizar Matrícula

<<includes>>
Estudiante
Seleccionar asignatura

Si al realizar la matrícula, se van seleccionando

(en la interfaz) asignaturas en las que
matricularse NO ES CASO DE USO
 Imprimir informes

<<includes>>
Empleado
Imprimir informe

Un posible flujo de eventos sería:

• El empleado proporciona su identificador

• Se seleccionan los informes del empleado aún no impresos
• Se imprime cada uno de ellos
 Ingresar Dinero

Cliente
Retirar Dinero

Flujo de eventos de RT:

- Identificar cliente Realizar
- Obtener su número de cuenta Transacción
- Comprobar que la cuenta no está bloqueada

En este caso no parece que “Realizar Transacción” sea un CASO DE USO

REAL, pero PUEDE resultar ÚTIL para no repetir muchos flujos de eventos.
Puede ocurrir en el caso de GENERALIZACIÓN
 Artefactos: glosario y
prototipo de interfaz
• GLOSARIO: Documento donde se definen los términos
más 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
 ASIGNATURA: …

 ESTUDIANTE: es una persona que está estudiando una carrera en

la universidad XXXX. Necesariamente debe estar matriculado en
por lo menos una ASIGNATURA.

 MATRÍCULA: 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 XXXX y que imparte al

menos una asignatura de una determinada TITULACIÓN. 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.
 …
 Tomar Préstamo <<extends>>
Copia Libro Reservar Libro
- No disponible

Socio
Flujo de eventos:
El socio da su número de socio y la signatura del libro que desea tomar en
préstamo
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 número máximo de libros en
préstamo
Se registra el nuevo préstamo con la fecha actual
CASO DE USO: TOMAR COPIA LIBRO EN PRÉSTAMO

SIGNATURA LIBRO:

NÚMERO SOCIO:

Área de texto donde aparecerá el número de copia del libro que se

ha tomado en préstamo.

Si no hay ninguna libre o si el socio ha sobrepasado su número

máximo de préstamos entonces se indicará aquí mismo.

TOMAR EN PRÉSTAMO 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 aparecerán en el
GLOSARIO
 NOMBRE DE LA CLASE
atributo1
atributo2
VISIBILIDAD: ...
+ = público
- = privado método1 (parámetros): resultado
método2 (parámetros) : void
# = visible para ...
subclases
-- 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 métodos
 Cliente
- nombre, dirección, 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
 NOMBRE DE LA SUPERCLASE

atributo1, atributo2 ...

método1 (parámetros),…

NOMBRE DE LA SUBCLASE

atribSubClase1, atribSubClase2 ...

metSubc1 (parámetros),…

La SUBCLASE hereda todos los ATRIBUTOS y los

MÉTODOS de la SUPERCLASE.
 INMUEBLE

direccion: String; precio: float…

PISO GARAJE
numeroHabitaciones: int,… cerrado: boolean,…
 CLASE A CLASE B

susA suB

1..* 0..1

cardinalidades

Almacenar pares <objeto de A, objeto de B>

Indicando CARDINALIDAD

@a1 @b1

Objetos de la clase A @a2 @b2

Objetos de la clase B
@a3
@a4
 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  mínimo con n y máximo con m
Nota: n y m son números naturales
Ejemplo: 8 , 17 , 7..9 ,…
 propietario 0..*
CLIENTE INMUEBLE
1 posee

Otra opción es dar un único nombre a la

asociación e indicar “cómo se lee”
Posee
0..*
CLIENTE INMUEBLE
1
@C1 P. Pérez Mayor 13 943112232 3/3/89 Leer, Fútbol

@C2 K. Sola Mayor 3 943222232 4/3/89 Mus, Monte

@P1 Matia 12, 1A 90000.00 3

@P2 Hériz 1, 2A 85000.50 2

@G1
Hériz 5 15000.50 true

@P1
@C1
@P2
ASOCIACIÓN
@C2
@G1
 CLASE A Un par <b,c> conocido puede
estar asociado a los a’s que
quiera

CLASE C 0..* CLASE B

0..1 0..*

Un par <a,b> conocido puede estar Un par <a,c> conocido puede estar asociado a los
asociado a los sumo con un solo c b’s que quiera

Fijados el resto de objetos que participan en la

asociación, ¿con cuántos pueden relacionarse?
 @a1
<@a1,@c1,@b1>
@a2
<@a1,@c1,@b2>
@a3 <@a3,@c2,@b2>
@b1
@a4 @c1 <@a4,@c2,@b2>
@b2
@c2
cardinalidad 0..1 en el lado de C
<@a1,@b1> @c1
<@a1,@b2> @c1
<@a3,@b2> @c2
<@a4,@b2> @c2

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

<@a3,@c2> @b2 cardinalidad 0..* en el lado de A
<@a4,@c2> @b2 <@c1,@b1>  @a1
<@c1,@b2>  @a1
cardinalidad 0..* en el lado de B <@c2,@b2>  @a3 y @a4
 Estudiante

Profesor 0..* Asignatura

0..* 0..*

Información sobre qué profesores imparten

qué asignaturas a qué estudiantes
HAY QUE ESTAR SEGUROS DE QUE SE
NECESITA UNA ASOCIACIÓN TERNARIA
 Estudiante

* ≡ 0..* matriculadoEn

*
Profesor Asignatura
imparte *
*
*

Los estudiantes se matriculan en asignaturas

Los profesores imparten asignaturas

ASOCIACIÓN TERNARIA SÓLO SI HAY QUE

DISTINGUIR CON QUÉ PROFESOR/ES SE
HA MATRICULADO
 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.
 Estudiante

Profesor * Asignatura

0..1 *

par <est,asig> conocido  con 0 ó 1 prof.

Un estudiante se puede matricular en una
asignatura SÓLO CON UNO DE LOS
PROFESORES QUE LA IMPARTE, o no
matricularse, claro.
 Estudiante

Profesor * Asignatura

0..1 *

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.
 Estudiante

Profesor * Asignatura

0..1 *

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

1..*
0..1

ES UNA ASOCIACIÓN CON LA SEMÁNTICA

“FORMADO POR/FORMA PARTE DE”

CLASE A
CLASE B
formaParteDe 1..*

0..1 formadoPor
Coche Rueda

4
0..1

Motor
1
 CLASE A CLASE B

1..*
1
Única cardinalidad posible

ES UNA ASOCIACIÓN CON LA SEMÁNTICA

“COMPUESTO POR/ES COMPONENTE DE”

Si se borra el a, se borran los b

CLASE A CLASE B
esComponenteDe 1..*
1 compuestoPor
 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 A CLASE B

susA suB

1..* 0..1

CLASE C
Clase Asociación
atrib

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

Objetos de la clase A @a2 @b2

@a3
@a4 @c1 @c2 @c3 Objetos de la clase C
v1 v2 v3
 CLASE A CLASE B

susA suB

1..* 0..1

CLASE C
Clase Asociación

Cada objeto de C se refiere a un

único objeto de A y a un único
objeto de B
CLASE A CLASE B
CLASE C
susA suB

1..* 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
asociación sino una clase (normal) y 2
asociaciones
 Estudiante Asignatura
matriculadoEn

* *

Matrícula
Clase Asociación
numConv,
nota,…

Si se desea poder almacenar el nº de

convocatoria, nota obtenida, curso
académico, etc.
 CLASE A

CLASE C 0..* CLASE B

0..1 0..*

CLASE D
Diagrama de clases en UML
Clase A
…
susA
0..*

suB
Clase D 1 Clase B
0..5
atrD1 .. …
Clase E
atrE1
1 0.. Clase BD
* atrBD1 ..
… Clase C
…

Durante la captura de requisitos se utiliza

para representar el MODELO DEL DOMINIO.
De momento, sólo interesan los ATRIBUTOS
de las clases y NO SUS MÉTODOS
 Artefacto: descripción
de la arquitectura
• Hay que realizar una descripción
preliminar de la arquitectura
• Por lo menos debe dar cabida a los
casos de usos con funcionalidad crítica

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
 Son los casos de uso importantes para
los usuarios del sistema
 que ayudan a encontrar el esqueleto
del sistema (la arquitectura) sobre el
que añadir el resto de las funciones
requeridas
 También 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 más
bien de “puestos” que de “personas” ya que una
misma persona podría desempeñar más de un
puesto o trabajo. Son los siguientes:
– Analista de sistema
– Especificador de casos de uso
– Diseñador 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 específicamente casos de uso. Necesita trabajar
estrechamente con los usuarios reales.
– Diseñador 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 descripción de un caso de uso
• Qué incluir en la descripción 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 diseño lógico de interfaz de usuario
• Crear prototipo y diseño físico 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