6.- Flujo de Requisitos Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA

1. 6.- Flujo de Requisitos Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA

2. Contenidos • Introducción • Documentos de entrada • Por qué es complicado • Cómo lo conseguimos • Importancia de los requisitos en el ciclo de vida • Modelado de casos de uso • Qué es un caso de uso • Tipos de relación • Consejos • Identificación de casos de uso • Errores de utilización • Actividades de Requisitos • Encontrar actores y casos de uso • Priorizar casos de uso • Detallar un caso de uso • Prototipado de interfaz de usuario • Estructurar el modelo de casos de uso

3. Introducción • Estamos en el proceso de encontrar -generalmente bajo circunstancias complicadas- lo que ha de construirse. • Se construye o se recibe del cliente una lista de características deseadas para el software. • Si es necesario: modelo de negocio. • Una vez capturados los requisitos, se modelan como casos de uso. Por lo tanto tenemos dos partes: • Captura de requisitos. • Modelo de casos de uso. • En la primera iteración de la fase de concepción sirve también como estudio de viabilidad.

4. Estudio de Viabilidad • Se verá con más detalle en el segundo cuatrimestre. • Análisis técnico, operacional y económico previos a la realización de un proyecto para determinar si es rentable. • Viabilidad técnica. • Viabilidad económica. • Viabilidad legal. • Alternativas.

5. Documentos de Entrada • Lista de características • Modelo de negocio

6. Por qué es complicado • Capturar requisitos es muy complicado: • no haces sw para ti sino para otros • se supone que los “otros” saben EXACTAMENTE lo que quieren • se supone que los “otros” te van a explicar perfectamente lo que quieren • se supone que los “otros” hablan tu mismo idioma • El analista debe hablar el mismo idioma que el usuario, lo cuál implica: • conocer el modelo de negocio • tener cuidado a la hora de formalizar información

7. Cómo lo conseguimos (I) • Lista de requisitos candidatos • Para cada requisito: • Descripción. • Estado -propuesto, aprobado, incorporado, validado- • Coste estimado para implantarlo -en términos de recursos y hora/persona- • Prioridad. • Nivel de riesgo. • Comprender el contexto del sistema • Modelo de dominio: describe los conceptos importantes del contexto como objetos del dominio, y los enlaza entre sí. • Modelo de negocio: en ocasiones puede ser necesario conocer el “proceso de negocio” en el que estamos involucrados -p.e. “renta fija” para la realización de una aplicación de tiempo real- • Este es el concepto clásico de “consultor”.

8. Cómo lo conseguimos (y II) • Capturar los requisitos funcionales • Aquí es donde modelamos nuestros casos de uso. • Capturar los requisitos no funcionales • Especificación de propiedades del sistema -entorno, restricciones de implementación, prestaciones, dependencias de plataforma, …-

9. Tipos de Requisitos • Funcionales: diferentes tareas del sistema futuro. • De Interfaz: de usuario, entre módulos SW, … • Operacionales: uso futuro del sistema -backups, recuperaciones, …- • De Documentación. • De Seguridad: protección, niveles de acceso, históricos, … • De mantenibilidad y portabilidad. • De recursos: limitaciones de memoria, discos, … • De verificación y fiabilidad: qué errores se pueden producir, cuáles soporta, … • De rendimiento. • De comportamiento.

10. Resultados

11. Importancia de los requisitos en el ciclo de vida

12. Modelado de Casos de Uso

13. Qué es un caso de uso • Definición: • Diagrama de casos de uso: • es un grafo de actores, un conjunto de casos de uso, quizá alguna interfaz y las relaciones entre esos elementos: • Asociaciones entre actores y casos de uso. • Generalizaciones entre actores. • Generalizaciones, extensiones e inclusiones entre los casos de uso. • Caso de uso: • Representa una unidad coherente de funcionalidad provista por un sistema, subsistema, etc., manifestada por secuencias de mensajes intercambiados entre el sistema y uno o más elementos externos (actores) y acciones internas del sistema. • Actor: • Define un conjunto coherente de roles que los usuarios de una entidad pueden desarrollar cuando interactúan con ella. • Un actor puede desempeñar un rol diferente dependiendo del caso de uso con el que se comunica.

14. Tipos de relación • Tipos de relación • Asociación: única relación posible entre actores y casos de uso. • Extensión: entre casos de uso. A extends B significa que una instancia del caso de uso B puede ser aumentada por el comportamiento del caso A. Este comportamiento se inserta en el Extension Point definido por el caso de uso B –puede ser algo tan simple como “aquí se puede utilizar el caso de uso A cuando se cumpla x e y”. • Generalización: • Entre casos de uso: A -> B significa que A es una especialización de B. • Entre actores: A -> B significa que una instancia de A se puede comunicar con los mismos tipos de instancias de casos de uso que una actor B. • Inclusión (o utilización): A “incluye” B significa que una instancia del caso A contiene el comportamiento especificado por B. Este comportamiento se incluye en la localización definida en A.

15. Ejemplo (I)

16. Ejemplo (y II)

17. Consejos • Se debe utilizar para capturar los requisitos funcionales de alto nivel del usuario. • No son útiles para capturar requisitos no funcionales. • Cuidado: es una técnica de modelado imprecisa e informal (el lenguaje utilizado es natural). • No se captura ninguna funcionalidad en la que el actor no participe • Si hay un gran número de casos de uso, deberían de ser agrupados en paquetes.

18. Identificación de Casos de Uso • Identificación de casos de uso: • Qué hace el actor con el sistema. • Para cada caso de uso, qué pasos suelen ocurrir normalmente: basic course. • Considerar alternativas. Esto puede dar paso a nuevos casos de uso que extiendan los ya existentes. Atención: utilizamos la cláusula “extends” para indicar alternativas. • Considerar casos de uso que utilicen otros: relaciones “include” (o “uses”). • Cuidado con las descomposiciones. No hay que pasarse. • En el diagrama de casos de uso no se suele tener en cuenta información detallada o formal. Eso se deja para diagramas posteriores.

19. Errores de Utilización • Es decir, la cláusula “uses” no sirve para capturar descomposición funcional. Para eso ya utilizaremos el diagrama de clases. • Cuidado con reutilizar casos de uso que son accedidos directamente por un actor (recordamos que esto no es descomposición funcional). • Normalmente un caso de uso “utilizado” o “incluído” (con la cláusula “include”) proviene del camino básico, pues no es condicional, siempre se va a cumplir, mientras que un caso de uso “que extiende” no formará parte nunca de un flujo básico.

20. Actividades de Requisitos • Encontrar actores y casos de uso • Priorizar casos de uso • Detallar un caso de uso • Prototipado de interfaz de usuario • Estructurar el modelo de casos de uso

21. Actividad: Encontrar actores y casos de uso (I) • Actividad realizada por el analista. • Encontrar actores • Habrá típicamente un actor por cada tipo de usuario del sistema y por cada sistema externo que interactue con él. • Para cada actor, debe haber al menos un usuario real. • Encontrar casos de uso • Si no hay modelo de negocio (lo habitual), el analista identifica los casos de uso mediante reuniones de trabajo con los actores.

22. Actividad: Encontrar actores y casos de uso (II) • Describir brevemente cada caso de uso • Precondiciones, flujos alternativos, postcondiciones, etc. • El caso de uso ha de ser: • Correcto • No ambiguo • Verificable • Clasificable • Realista.

23. Actividad: Encontrar actores y casos de uso (y III) • Describir el modelo de casos de uso global • El objetivo es explicar cómo se relacionan los casos de uso entre ellos y con los actores. • Si hay muchos casos de usos pueden agruparse en paquetes. • No se trata sólo de listar casos de uso. Hay que identificar casos de uso contenidos en otros (y probablemente compartidos en otros), generalizaciones y extensiones de caso de uso. • El modelo ha de ser: • Completo • Consistente

24. Actividad: Priorizar casos de uso • Actividad realizada por el arquitecto. • En las primeras iteraciones, los casos de uso relevantes para la arquitectura tienen mayor prioridad. • En la priorización se tienen en también en cuenta aspectos económicos, de negocio, etc.

25. Actividad: Detallar un caso de uso • Actividad realizada por el especificador de casos de uso. • Datos por cada caso de uso: • Precondiciones • Postcondiciones • Secuencia de acciones: • Flujo básico. • Flujos alternativos. • Describir exactamente qué hace el sistema y qué hacen los actores. • Los requerimientos no funcionales (eficiencia, etc.) se añaden en una sección aparte.

26. Actividad: Prototipado de interfaz de usuario • Actividad realizada por el diseñador de interfaz de usuario. • El objetivo es decidir la interfaz de usuario detalladamente para cada actor. • Esta actividad no va a ser generalmente requerida, aunque en proyectos innovadores puede ser necesario.

27. Actividad: Estructurar el modelo de casos de uso • Actividad realizada por el analista. • La idea es básicamente : • Encontrar comportamientos comunes en diferentes casos de uso, de manera que podamos agrupar ese comportamiento común en un caso de uso reutilizado por otros (caso de uso abstracto). • Encontrar casos de uso que son extensiones de otros casos de uso. Por ejemplo, si en un caso de uso de una transferencia bancaria no hay fondos en la cuenta origen, se “inicia” el caso de uso de reclamar a un moroso. Es decir un caso de uso B aparece cuando en la ejecución de un caso de uso A ocurren unas ciertas condiciones.

28. Ejemplo • Aplicación de realización de Tests por ordenador • Cliente: Público • Objetivo: pruebas de comprobación de prerrequisitos para las asignaturas. • Premisas: • El proyecto ha sido aceptado financieramente. • Se parte de una reunión informal con el cliente, a partir del cual hay que establecer la lista de requisitos. Se supone que la lista básica de requisitos ya existe. • A partir de la lista de requisitos, hay que construir el sistema software utilizando el proceso unificado.

29. Bibliografía • OMG Unified Modeling Language Specification (v1.3 June 1999). OMG. • Introduction to UML: Structural and Use Case Modeling. Cris Kobryn. Co-chair UML Revision Task Force. 2001.