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

6.- Flujo de Requisitos6.- Flujo de RequisitosJusto N. Hidalgo SanzJusto N. Hidalgo Sanz

DEPARTAMENTO DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA INFORMÁTICAINFORMÁTICA

Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)

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


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.


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.


Documentos de Entrada

Lista de características

Modelo de negocio


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


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


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


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.


Resultados

TRABAJO A REALIZAR ARTEFACTOS RESULTANTES

Listar requisitos candidatos Lista de características

Comprender el contexto delsistema

Modelo de negocio o de dominio

Capturar requisitos funcionales Modelo de casos de uso

Capturar requisitos nofuncionales

Requisitos suplementarios ocasos de uso individuales


Importancia de los requisitos en el ciclo de vida


Modelado de Casos de Uso


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.


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.


Ejemplo (I)


Ejemplo (y II)


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.


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.


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.


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


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.


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.


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


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.


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.


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.


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.


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.


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.

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

Documents

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