1 / 76

Tema 3: Captura de requisitos

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

liuz
Download Presentation

Tema 3: Captura de requisitos

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 Inicio Elaboración Construcción Transición Requisitos Análisis Diseño Implementación i t e r . i t e r . i t e r . i t e r . i t e r . i t e r . i t e r . # 1 # 2 # n # n + 1 # n + 2 # m # m + 1 Prueba Iteraciones: 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. Empleado Sistema Bancario 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. Estudiante Realizar Matrícula Caso de Uso en UML El estudiante DECIDE EJECUTAR EL C.U.

  19. Caso de Uso en UML Realizar Matrícula Estudiante Sistema Bancario 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. Realizar Matrícula Estudiante 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 <<includes>> 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 <<extends>> 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. Identificarse Relaciones entre CU en UML Realizar Matrícula <<includes>> Estudiante Escoger Asignatura <<includes>> Profesor

  33. Relaciones entre CU en UML Reservar Libro <<includes>> Lector Buscar Libro por código AMBOS CASOS DE USO DEBEN TENER SENTIDO EN EL SISTEMA

  34. Identificarse Relaciones entre CU en UML Realizar Matrícula - No identificado <<extends>> Estudiante Escoger Asignatura - No identificado <<extends>> 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. Seleccionar asignatura Errores típicos en CU Realizar Matrícula <<includes>> Estudiante Si al realizar la matrícula, se van seleccionando (en la interfaz) asignaturas en las que matricularse NO ES CASO DE USO

  38. Imprimir informe Errores típicos en CU Imprimir informes <<includes>> 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. 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 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 <<extends>> 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. 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. 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(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

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

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

  49. susA suB 1..* 0..1 CLASE A CLASE B cardinalidades @a1 @b1 @a2 @b2 @a3 @a4 Asociación en UML Almacenar pares <objeto de A, objeto de B> 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 ,…

More Related