You are on page 1of 76

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

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.

Capturar los requisitos funcionales • Encontrar casos de uso .2.3.

Capturar los requisitos no funcionales • Son propiedades o restricciones del sistema – no acerca de lo que hay que hacer .2.4.

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 .

# n+ 1 ite r. # n+2 it e r.3. #1 ite r. #m +1 En el PUD lo que se hace fundamentalmente es obtener el MODELO DE CASOS DE USO . #n ite r. Rol del Flujo de Trabajo de requisitos en el CV Inicio Requisitos Análisis Diseño Implementación Prueba Elaboración Construcción Transición Iteraciones: ite r. #m it e r. #2 ite r.

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 .

del Negocio .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.

CONSIDERAREMOS QUE AMBOS FLUJOS DE TRABAJO SON UNO: FT de CAPTURA DE REQUISITOS Se obtiene: MODELO DEL DOMINIO Y DE CASOS DE USO .

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

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 .

.U.Caso de Uso en UML Realizar Matrícula Estudiante El estudiante DECIDE EJECUTAR EL C.

Caso de Uso en UML Realizar Matrícula iniciador Estudiante Sistema Bancario .

– 2. Fin.Alguna de las asignaturas está completa.. 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. • NOTA: Esto puede ocurrir porque el CU se ejecuta concurrentemente . Fin..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.El DNI proporcionado no es el de un estudiante.

Caso de Uso en UML • Requisitos especiales – El CU “REALIZAR MATRÍCULA” debe ejecutarse en un tiempo razonablemente corto. que la asignatura estaba completa – Debe poder ejecutarse de manera simultánea por al menos 20 estudiantes. –… . – 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.

… NO SE TRATA DE UN SISTEMA EXTERNO SINO DEL PROPIO SISTEMA (EL C. … • Se almacenan los datos de las matrículas en el sistema. ES PARTE DE ÉL) .U.Errores típicos en CU Realizar Matrícula iniciador Estudiante Sistema FLUJO DE EVENTOS: • El estudiante introduce el DNI.

implementación y prueba . CUs y sus relaciones • Con el MCU. clientes y desarrolladores se ponen de acuerdo • Entrada al análisis. diseño.Artefacto: Modelo de CU • Modelo que contiene todos los actores.

Modelo de CU (MCU) en UML iniciador Realizar Matrícula Estudiante Escoger Asignaturas iniciador Sistema Bancario Profesor Pagar Nóminas .

Relaciones entre actores en UML iniciador Solicitar Carnet Deportivo Estudiante Sistema Bancario ¿ Y si los profesores también pueden solicitar carnet deportivo? .

ya que eso significa que los 3 actores participan en el caso de uso y eso no es lo que queremos .Errores típicos en CU iniciador Solicitar Carnet Deportivo Estudiante iniciador Sistema Bancario Profesor NO.

Estudiante Sistema Bancario Solicitar Carnet Deportivo Prof. iniciador Profesor ¿SOLUCIÓN? 1: CUs distintos .Relaciones entre actores en UML iniciador Solicitar Carnet Deportivo Estud.

Relaciones entre actores en UML iniciador Solicitar Carnet Deportivo Universitario Sistema Bancario Estudiante Profesor SOLUCIÓN 2: (MEJOR) generalización 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 . si se cumple la condición C.cond. entonces se ejecuta el caso de uso A . 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.

A es una especialización ACTOR (o un caso particular) del C.Relaciones entre CU: generalización CASO DE USO A CASO DE USO B El C.U. B.U. 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 <<includes>> Lector 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 <<extends>> Estudiante Escoger Asignatura .No identificado <<extends>> Identificarse Profesor .

Comprobar que la cuenta no está bloqueada Realizar Transacción .Relaciones entre CU en UML Ingresar Dinero Cliente Retirar Dinero Flujo de eventos de RT: .Obtener su número de cuenta .Identificar cliente .

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

Realizar Transacción

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 .

• … . pero sí en otras. Necesariamente debe estar matriculado en por lo menos una ASIGNATURA. El profesor no puede ser estudiante en la misma carrera en la que imparte clases. Se le asocia a un GRUPO. • 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.Ejemplo de GLOSARIO • ASIGNATURA: … • ESTUDIANTE: es una persona que está estudiando una carrera en la universidad UnivX. Tiene derecho a asistir a las clases del PROFESOR responsable de dicha ASIGNATURA en el GRUPO asignado. • 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.

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 . prototipo de interfaz de CU Tomar Préstamo Copia Libro .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. TOMAR EN PRÉSTAMO RESERVAR LIBRO Cancel . Si no hay ninguna libre o si el socio ha sobrepasado su número máximo de préstamos entonces se indicará aquí mismo.Ej.

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 .

= privado # = visible para subclases NOMBRE DE LA CLASE atributo1 atributo2 .texto que indica qué hace. etc.Clase UML VISIBILIDAD: + = público . restricciones especiales de uso.. método1 (parámetros): resultado método2 (parámetros) : void . Los objetos de dicha clase pueden almacenar valores en los atributos y ejecutar sus métodos .. -.responsabilidades de la clase -...

..Aficiones: Vector(String) . Se suelen usar los del LP que se escoja ..nombre. .) NO son definidos por UML.… + setNombre(n: String): void + addAficion(a:String): void .. void. dirección.almacena datos de clientes Los tipos (String. tfno: String .Ejemplo: Clase UML Cliente . + getNombre(): String.fechaNac: Date .. Date...

método1 (parámetros)..Especialización y Generalización en UML NOMBRE DE LA SUPERCLASE atributo1. . metSubc1 (parámetros).. atributo2 . atribSubClase2 .… NOMBRE DE LA SUBCLASE atribSubClase1...… La SUBCLASE hereda todos los ATRIBUTOS y los MÉTODOS de la SUPERCLASE.

… . precio: float… PISO GARAJE cerrado: boolean.Ejemplo de Especialización y Generalización en UML INMUEBLE direccion: String.… numeroHabitaciones: int.

1 cardinalidades Almacenar pares <objeto de A.* 0..Asociación en UML CLASE A susA suB CLASE B 1.. objeto de B> Indicando CARDINALIDAD Objetos de la clase A @a1 @a2 @a3 @a4 @b1 @b2 Objetos de la clase B .

*  con uno o varios n  con n exactamente n.. uno o varios 0.1 con uno o ninguno 0.… . 17 . 7..*  con cero.9 .Cardinalidades en UML 1 *  con uno  con cero..m  mínimo con n y máximo con m Nota: n y m son números naturales Ejemplo: 8 .. uno o varios 1..

.Ej. de Asociación en UML propietario CLIENTE 1 0..* INMUEBLE .* posee INMUEBLE Otra opción es dar un único nombre a la asociación e indicar “cómo se lee” Posee CLIENTE 1 0.

Monte @P1 Matia 12. Pérez Mayor 13 943112232 3/3/89 Leer. 1A 90000.50 true @C1 @C2 @P1 @P2 @G1 ASOCIACIÓN . Fútbol @C2 K.00 3 @P2 Hériz 1.Ej. de Asociación en UML @C1 P. 2A @G1 Hériz 5 85000.50 2 15000. Sola Mayor 3 943222232 4/3/89 Mus.

* 0.* Un par <a.c> conocido puede estar asociado a los a’s que quiera CLASE B CLASE C 0.1 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..Asociación n-aria en UML CLASE A Un par <b.b> conocido puede estar asociado a los sumo con un solo c 0.. ¿con cuántos pueden relacionarse? ..

@c2> @b2 cardinalidad 0.@b1>  @a1 <@c1.@b2> <@a4.@b1> <@a1.@b2> <@a4.@c1.@c1.Asociación n-aria en UML @a1 @a2 @a3 @a4 @b1 @c1 @c2 @b2 <@a1.@b2>  @a1 <@c2.@c2..@b2> <@a3.@c1> @b1 y @b2 <@a3.* en el lado de B <@a1..@b2>  @a3 y @a4 .@b2> cardinalidad 0..@b2> <@a3.@c2> @b2 <@a4.1 en el lado de C <@a1.@c2.@b1> <@a1.@b2> @c1 @c1 @c2 @c2 cardinalidad 0.* en el lado de A <@c1.

Ej.* Asignatura Información sobre qué profesores imparten qué asignaturas a qué estudiantes HAY QUE ESTAR SEGUROS DE QUE SE NECESITA UNA ASOCIACIÓN TERNARIA ..* 0.. de asociación n-aria en UML Estudiante Profesor 0..* 0.

* Profesor * Estudiante matriculadoEn * imparte * * Asignatura 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 * ≡ 0.

. de asociación n-aria en UML Estudiante Profesor * * * Asignatura Los estudiantes se matriculan en asignaturas. Los profesores imparten asignaturas.Ej. NO todos los profesores que la imparten son sus profesores. Cuando un estudiante se matricula en una asignatura.

1 * Asignatura par <est.Ej. o no matricularse. claro. Un estudiante se puede matricular en una asignatura SÓLO CON UNO DE LOS PROFESORES QUE LA IMPARTE.. . de asociación n-aria en UML Estudiante Profesor * 0.asig> conocido  con 0 ó 1 prof.

.1 * Asignatura par <est.Ej.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. . de asociación n-aria en UML Estudiante Profesor * 0.

Ej..asig> conocido con 0 ó varios est Un profesor puede impartir o no una asignatura. de asociación n-aria en UML Estudiante Profesor * 0.1 * Asignatura par <prof. entonces puede tener VARIOS estudiantes . y si la imparte.

* CLASE B 0..Agregación en UML CLASE A 1....1 ES UNA ASOCIACIÓN CON LA SEMÁNTICA “FORMADO POR/FORMA PARTE DE” CLASE A formaParteDe 1.1 formadoPor .* CLASE B 0.

de agregación en UML Coche 4 Rueda 0..1 1 Motor .Ej.

..Composición en UML CLASE A 1.* Única cardinalidad posible CLASE B 1 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.* CLASE B 1 compuestoPor .

. no se permite tener “motores” ni “ruedas” sueltos. se borra todo… Seguro que no se trata de un desguace. de composición en UML Coche 4 Motor Rueda 1 1 En este S.I. y al borrar el coche.Ej.

Clase Asociación en UML CLASE A susA suB CLASE B 1. 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 . objeto de B..1 CLASE C atrib Clase Asociación Para almacenar <objeto de A..* 0. Atrs.

.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 .* 0.Clase Asociación en UML CLASE A susA suB CLASE B 1..

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 asociación sino una clase (normal) y 2 asociaciones ...* CLASE C suB 0.Clase Asociación en UML CLASE A susA 1.

de clase Asociación en UML Estudiante matriculadoEn * Matrícula * Asignatura numConv. curso académico. etc. nota obtenida.Ej. nota. .… Clase Asociación Si se desea poder almacenar el nº de convocatoria.

* CLASE D .* CLASE B 0.1 0.Clase asociación n-aria en UML CLASE A CLASE C 0....

.. sólo interesan los ATRIBUTOS de las clases y NO SUS MÉTODOS .Diagrama de clases en UML Clase A … Clase D atrD1 ..5 Clase E atrE1 … … Clase C 1 0. * Clase BD atrBD1 . susA 0.* suB 1 Clase B 0... De momento. … Durante la captura de requisitos se utiliza para representar el MODELO DEL DOMINIO.

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.) . etc. tiempo de respuesta.

Son los siguientes: – – – – Analista de sistema Especificador de casos de uso Diseñador del interfaz del usuario Arquitecto .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.

asegurarse de que el conjunto es completo y consistente (con el glosario). – Especificador de casos de uso: • detalla específicamente casos de uso. No es responsable de especificar en detalle cada caso de uso.Trabajadores (2) – Analista de sistema: • es responsable del modelo de casos de uso (el conjunto de requisitos). encontrar actores y casos de uso. – 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 . Necesita trabajar estrechamente con los usuarios reales.

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

.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 .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..Actividades en el FT de requisitos • 4.