Tema 3: Captura de
requisitos
De la visión de los requisitos ...
... a su captura como casos de uso
Contenidos
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
1. Introducción
• 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
Resumen de la visión
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
Elaboración
Construcción
Transición
Requisitos
Análisis
Diseño
Implementación
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 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
Pero el CV del PUD de
Rational incluye más FTs…
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
Actor en UML
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
Caso de Uso en UML
Realizar Matrícula
Estudiante
El estudiante DECIDE
EJECUTAR EL C.U.
Caso de Uso en UML
Realizar Matrícula
iniciador
Estudiante
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 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
Caso de Uso en UML
• 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.
–…
Errores típicos en CU
Realizar Matrícula
iniciador
Estudiante
Sistema
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
Modelo de CU (MCU) en UML
iniciador
Realizar Matrícula
Estudiante
Escoger Asignaturas
iniciador
Profesor
Pagar Nóminas
Sistema
Bancario
Relaciones entre actores en
UML
iniciador
Solicitar Carnet
Deportivo
Estudiante
Sistema
Bancario
¿ Y si los profesores
también pueden solicitar
carnet deportivo?
Errores típicos 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 ¿SOLUCIÓN? 1: CUs distintos
Relaciones entre actores en
UML
iniciador
Solicitar Carnet
Deportivo
Sistema
Bancario
Universitario
Profesor
Estudiante
SOLUCIÓN 2:
(MEJOR)
generalización
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 condición C, entonces se
ejecuta el caso de uso A
Relaciones entre CU:
generalización
CASO DE
USO A
CASO DE
USO B
El C.U. A es una especialización
ACTOR
(o un 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
Relaciones entre CU en UML
Realizar Matrícula
Estudiante
<<includes>>
Escoger Asignatura
<<includes>>
Identificarse
Profesor
Relaciones entre CU en UML
Reservar Libro
Lector
<<includes>>
Buscar Libro
por código
AMBOS CASOS DE USO DEBEN
TENER SENTIDO EN EL SISTEMA
Relaciones entre CU en UML
Realizar Matrícula
- No identificado
Estudiante
Escoger Asignatura
<<extends>>
- No identificado
<<extends>>
Identificarse
Profesor
Relaciones entre CU en UML
Ingresar Dinero
Cliente
Retirar Dinero
Flujo de eventos de RT:
- Identificar cliente
- Obtener su número de cuenta
- Comprobar que la cuenta no está
bloqueada
Realizar
Transacción
Errores típicos 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 algún RESULTADO o
VALOR a por lo menos un ACTOR.
Errores típicos en CU
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
Errores típicos en CU
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
Posible excepción:
generalización
Ingresar Dinero
Cliente
Retirar Dinero
Flujo de eventos de RT:
- Identificar cliente
- Obtener su número de cuenta
Realizar
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
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.
• 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 UnivX 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.
• …
Ej. prototipo de interfaz de CU
Tomar Préstamo
Copia Libro
- No disponible
<<extends>>
Reservar Libro
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
Ej. prototipo de interfaz de CU
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
Clase UML
VISIBILIDAD:
+ = público
- = privado
# = visible para
subclases
NOMBRE DE LA CLASE
atributo1
atributo2
...
método1 (parámetros): resultado
método2 (parámetros) : 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 métodos
Ejemplo: Clase UML
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
Especialización y
Generalización en UML
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.
Ejemplo de Especialización
y Generalización en UML
INMUEBLE
direccion: String; precio: float…
PISO
numeroHabitaciones: int,…
GARAJE
cerrado: boolean,…
Asociación 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
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 ,…
Ej. de Asociación en UML
propietario
CLIENTE 1
0..*
posee INMUEBLE
Otra opción es dar un único nombre a
la asociación e indicar “cómo se lee”
Posee
CLIENTE
1
0..*
INMUEBLE
Ej. de Asociación en UML
@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
@G1 Hériz 5
@C1
@C2
85000.50 2
15000.50 true
@P1
@P2
@G1
ASOCIACIÓN
Asociación n-aria en UML
CLASE A
Un par <b,c> conocido
puede estar asociado a
los a’s 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 b’s que quiera
Fijados el resto de objetos que participan en la
asociación, ¿con cuántos pueden relacionarse?
Asociación 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 asociación n-aria en UML
Estudiante
0..*
Profesor
0..*
Asignatura
0..*
Información sobre qué profesores imparten
qué asignaturas a qué estudiantes
HAY QUE ESTAR SEGUROS DE QUE SE
NECESITA UNA ASOCIACIÓN TERNARIA
Ej. de asociación n-aria en UML
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
Ej. de asociación 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 asociación 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 SÓLO CON UNO DE LOS
PROFESORES QUE LA IMPARTE, o no
matricularse, claro.
Ej. de asociación 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 asociación 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
Agregación en UML
CLASE A
CLASE B
1..*
0..1
ES UNA ASOCIACIÓN CON LA SEMÁNTICA
“FORMADO POR/FORMA PARTE DE”
CLASE A
formaParteDe
0..1
1..*
formadoPor
CLASE B
Ej. de agregación en UML
Coche
Rueda
0..1
4
1
Motor
Composición en UML
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
esComponenteDe 1..*
1
compuestoPor
CLASE B
Ej. de composición en UML
Coche
Rueda
1
4
1
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 desguace.
Clase Asociación en UML
CLASE A
CLASE B
susA
1..*
suB
0..1
CLASE C
atrib
Clase Asociación
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 Asociación en UML
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 Asociación en UML
CLASE A
CLASE B
susA
1..*
CLASE C
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 asociación sino una clase
(normal) y 2 asociaciones
Ej. de clase Asociación en
UML
Estudiante
Asignatura
matriculadoEn
*
*
Matrícula
numConv,
nota,…
Clase Asociación
Si se desea poder almacenar el
nº de convocatoria, nota
obtenida, curso académico, etc.
Clase asociación 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
…
1
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, 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
Casos de uso críticos
• 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
Descargar

Tema 3: Captura de requisitos