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

Inicio
Requisitos Anlisis Diseo Implementacin Prueba

Elaboracin

Construccin

Transicin

Iteraciones:

ite r. #1

ite r. #2

ite r. #n

ite r. # n+ 1

ite r. # n+2

it e r. #m

it e r. #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 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

Realizar Matrcula

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 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
Realizar Matrcula

iniciador

Estudiante

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

Realizar Matrcula

Estudiante
Escoger Asignaturas
iniciador

Sistema Bancario

Profesor

Pagar Nminas

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
iniciador

Solicitar Carnet Deportivo

Estudiante
iniciador

Sistema Bancario

Profesor

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

Sistema Bancario
Solicitar Carnet Deportivo Prof.

iniciador

Profesor SOLUCIN? 1: CUs distintos

Relaciones entre actores en UML

iniciador

Solicitar Carnet Deportivo

Universitario

Sistema Bancario

Estudiante Profesor

SOLUCIN 2: (MEJOR) generalizacin entre actores

Relaciones entre CU: includes

<<includes>>
CASO DE USO A
CASO DE USO B

ACTOR

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

<<extends>> CASO DE
USO A

ACTOR

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

Identificarse

Profesor

Relaciones entre CU en UML

Reservar Libro
<<includes>>

Lector

Buscar Libro por cdigo

AMBOS CASOS DE USO DEBEN TENER SENTIDO EN EL SISTEMA

Relaciones entre CU en UML

Realizar Matrcula
- No identificado
<<extends>>

Estudiante

Escoger Asignatura
- No identificado <<extends>>

Identificarse

Profesor

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
<<includes>>

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

Empleado
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 - Comprobar que la cuenta no est bloqueada

Realizar Transaccin

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

SIGNATURA LIBRO: NMERO SOCIO:

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

GARAJE
cerrado: boolean,

numeroHabitaciones: int,

Asociacin en UML
CLASE A susA suB CLASE B

1..*

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 con cero, uno o varios

0..1 con uno o ninguno 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 1 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
@G1 Hriz 5

85000.50 2

15000.50 true

@C1
@C2

@P1 @P2
@G1

ASOCIACIN

Asociacin n-aria en UML

CLASE A Un par <b,c> conocido puede estar asociado a los as que quiera CLASE B

CLASE C

0..*

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

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
@b1

@c1 @c2

@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

Profesor

0..* 0..* 0..*

Asignatura

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

* 0..*
Profesor *

Estudiante matriculadoEn * imparte

* *

Asignatura

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

0..1

ES UNA ASOCIACIN CON LA SEMNTICA FORMADO POR/FORMA PARTE DE

CLASE A
formaParteDe

1..*

CLASE B

0..1

formadoPor

Ej. de agregacin en UML

Coche
4

Rueda

0..1

Motor

Composicin en UML
CLASE A 1..* nica cardinalidad posible CLASE B

ES UNA ASOCIACIN CON LA SEMNTICA COMPUESTO POR/ES COMPONENTE DE

Si se borra el a, se borran los b

CLASE A
esComponenteDe 1..*

CLASE B

compuestoPor

Ej. de composicin en UML

Coche 4 Motor Rueda

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 susA suB CLASE B

1..*

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 Objetos de la clase C

@c1 @c2 @c3 v1 v2 v3

Clase Asociacin en UML

CLASE A susA suB CLASE B

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

CLASE A
susA 1..* CLASE C suB 0..1

CLASE B

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 matriculadoEn * Matrcula * Asignatura

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

CLASE C

0..*

CLASE B

0..1

0..*

CLASE D

Diagrama de clases en UML

Clase A

Clase D atrD1 ..

susA 0..* suB 1

Clase B

0..5

Clase E atrE1

Clase C

0.. *

Clase BD atrBD1 ..

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