Tema 3: Captura de requisitos

1
Tema 3 Captura de requisitos

• De la visión de los requisitos ...
• ... a su captura como casos de uso

2
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

3
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

4
2. Visión general de la captura de requisitos

• Listar requisitos candidatos
• Entender contexto del sistema
• Capturar requisitos funcionales
• Capturar requisitos no funcionales

5
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

6
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

7
2.3. Capturar los requisitos funcionales

• Encontrar casos de uso

8
2.4. Capturar los requisitos no funcionales

• Son propiedades o restricciones del sistema
• no acerca de lo que hay que hacer

9
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

10
3. Rol del Flujo de Trabajo de requisitos en el CV
En el PUD lo que se hace fundamentalmente es
obtener el MODELO DE CASOS DE USO
11
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

12
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
13
CONSIDERAREMOS QUE AMBOS FLUJOS DE TRABAJO SON
UNO FT de CAPTURA DE REQUISITOS Se obtiene
MODELO DEL DOMINIO Y DE CASOS DE USO
14
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

15
Artefacto actor

• Es tipo de usuario (persona)
• O sistema externo
• Los actores se encuentran fuera del sistema y
  colaboran con él

16
Actor en UML
SÓLO SI ES EXTERNO AL SISTEMA DE INFORMACIÓN QUE
SE ESTÁ MODELANDO
17
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

18
Caso de Uso en UML
El estudiante DECIDE EJECUTAR EL C.U.
19
Caso de Uso en UML
iniciador
20
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

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

22
Errores típicos en CU
iniciador
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)
23
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

24
Modelo de CU (MCU) en UML
iniciador
Realizar Matrícula
Estudiante
Escoger Asignaturas
Sistema Bancario
iniciador
Pagar Nóminas
Profesor
25
Relaciones entre actores en UML
Solicitar Carnet Deportivo
iniciador
Estudiante
Sistema Bancario
Y si los profesores también pueden solicitar
carnet deportivo?
26
Errores típicos en CU
Solicitar Carnet Deportivo
iniciador
Estudiante
Sistema Bancario
iniciador
NO, ya que eso significa que los 3 actores
participan en el caso de uso y eso no es lo que
queremos
Profesor
27
Relaciones entre actores en UML
Solicitar Carnet Deportivo Estud.
iniciador
Estudiante
Sistema Bancario
Solicitar Carnet Deportivo Prof.
iniciador
SOLUCIÓN? 1 CUs distintos
Profesor
28
Relaciones entre actores en UML
Solicitar Carnet Deportivo
iniciador
Sistema Bancario
Universitario
SOLUCIÓN 2 (MEJOR) generalización entre actores
Estudiante
Profesor
29
Relaciones entre CU includes
ltltincludesgtgt
CASO DE USO B
CASO DE USO A
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
ACTOR
30
Relaciones entre CU extends
ltltextendsgtgt
CASO DE USO B - cond. C
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
ACTOR
31
Relaciones entre CU generalización
CASO DE USO B
CASO DE USO A
El C.U. A es una especialización (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
ACTOR
32
Relaciones entre CU en UML
Realizar Matrícula
ltltincludesgtgt
Estudiante
Escoger Asignatura
ltltincludesgtgt
Profesor
33
Relaciones entre CU en UML
Reservar Libro
ltltincludesgtgt
Lector
Buscar Libro por código
AMBOS CASOS DE USO DEBEN TENER SENTIDO EN EL
SISTEMA
34
Relaciones entre CU en UML
Realizar Matrícula
- No identificado
ltltextendsgtgt
Estudiante
Escoger Asignatura
- No identificado
ltltextendsgtgt
Profesor
35
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
36
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.

37
Errores típicos en CU
Realizar Matrícula
ltltincludesgtgt
Estudiante
Si al realizar la matrícula, se van seleccionando
(en la interfaz) asignaturas en las que
matricularse NO ES CASO DE USO
38
Errores típicos en CU
Imprimir informes
ltltincludesgtgt
Empleado

• 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

39
Posible excepción generalización
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
40
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

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

42
Ej. prototipo de interfaz de CU
ltltextendsgtgt
Tomar Préstamo Copia Libro
Reservar Libro
- No disponible
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
43
Ej. prototipo de interfaz de CU
44
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

45
Clase UML
VISIBILIDAD público - privado visible
para subclases
Los objetos de dicha clase pueden almacenar
valores en los atributos y ejecutar sus métodos
46
Ejemplo Clase UML
Cliente
- nombre, dirección, tfno String - fechaNac
Date - Aficiones Vector(String) ...
getNombre() String, setNombre(n String)
void addAficion(aString) void ...
- - almacena datos de clientes
Los tipos (String, Date, void,..) NO son
definidos por UML. Se suelen usar los del LP que
se escoja
47
Especialización y Generalización en UML
La SUBCLASE hereda todos los ATRIBUTOS y los
MÉTODOS de la SUPERCLASE.
48
Ejemplo de Especialización y Generalización en UML
49
Asociación en UML
Almacenar pares ltobjeto de A, objeto de Bgt
Indicando CARDINALIDAD
Objetos de la clase A
Objetos de la clase B
50
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 ,
51
Ej. de Asociación en UML
Otra opción es dar un único nombre a la
asociación e indicar cómo se lee
Posee
0..
52
Ej. de Asociación en UML
_at_C1
_at_C2
_at_P1
_at_P2
_at_G1
ASOCIACIÓN
53
Asociación n-aria en UML
Un par ltb,cgt conocido puede estar asociado a los
as que quiera
Un par lta,bgt conocido puede estar asociado a los
sumo con un solo c
Un par lta,cgt conocido puede estar asociado a los
bs que quiera
54
Asociación n-aria en UML
lt_at_a1,_at_c1,_at_b1gt lt_at_a1,_at_c1,_at_b2gt lt_at_a3,_at_c2,_at_b2gt lt_at_a4,_at_c2
,_at_b2gt
55
Ej. de asociación n-aria en UML
0..
0..
0..
HAY QUE ESTAR SEGUROS DE QUE SE NECESITA UNA
ASOCIACIÓN TERNARIA
56
Ej. de asociación n-aria en UML
0..
matriculadoEn

imparte



ASOCIACIÓN TERNARIA SÓLO SI HAY QUE DISTINGUIR
CON QUÉ PROFESOR/ES SE HA MATRICULADO
57
Ej. de asociación n-aria en UML
58
Ej. de asociación n-aria en UML
par ltest,asiggt 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.
59
Ej. de asociación n-aria en UML
par ltest,profgt 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.
60
Ej. de asociación n-aria en UML
par ltprof,asiggt conocido ?con 0 ó varios est Un
profesor puede impartir o no una asignatura, y si
la imparte, entonces puede tener VARIOS
estudiantes
61
Agregación en UML
ES UNA ASOCIACIÓN CON LA SEMÁNTICA FORMADO
POR/FORMA PARTE DE
62
Ej. de agregación en UML
63
Composición en UML
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
64
Ej. de composición en UML
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.
65
Clase Asociación en UML
suB
susA
1..
0..1
CLASE C
Clase Asociación
atrib
Para almacenar ltobjeto de A, objeto de B, Atrs.
PROPIOSgt
Objetos de la clase B
Objetos de la clase A
Objetos de la clase C
66
Clase Asociación en UML
Cada objeto de C se refiere a un único objeto de
A y a un único objeto de B
67
Clase Asociación 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 asociación sino una clase (normal)
y 2 asociaciones
68
Ej. de clase Asociación en UML
matriculadoEn


Matrícula
Clase Asociación
numConv, nota,
Si se desea poder almacenar el nº de
convocatoria, nota obtenida, curso académico,
etc.
69
Clase asociación n-aria en UML
0..
0..
0..1
70
Diagrama de clases en UML
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
71
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

72
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.)

73
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

74
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

75
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

76
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