tema 7: elicitación de requisitos - kybele · tema 7: elicitación de requisitos departamento de...

Tema 7: Elicitación de Requisitos

Departamento de Lenguajes y Sistemas Informáticos II

www.kybele.urjc.es

Elicitación de requisitos www.kybele.urjc.es

Contenidos

Técnicas de recolección de información

Captura de requisitos: Modelo de Casos de Uso

2


Contenidos



3



Proceso mediante el que se consigue que los usuarios descubran los requisitos que desean en la aplicación. Son un medio para mejorar la comunicación entre usuarios/clientes y desarrolladores del Software. El proceso de análisis debe seguir 5 pasos:

Identificar las fuentes de información relevantes para el proyecto y planificar las actividades de investigación

Realizar las preguntas apropiadas

Analizar la información para detectar aspectos poco claros

Confirmar con los usuarios lo que se ha comprendido de los requisitos

Sintetizar los requisitos en un documento de especificación

5



Técnicas principales utilizadas:Entrevistas

Desarrollo conjunto de aplicaciones (JAD)

Prototipado

Otras Observación

Estudio de documentación

Tormenta de ideas (Brainstorming)

Cuestionarios

…

Combinación

6



EntrevistasIntento sistemático de recoger información de otra persona a través de una comunicación interpersonal que se lleva a cabo por medio de una conversación estructurada.

Fases: Preparación:

• Documentarse, investigar la situación, analizar documentación disponible

• Minimizar nº de entrevistados, entrevistas de cortesía, analizar el perfil de los entrevistados, definir el objetivo y el contenido de la entrevista

• Planificar el lugar y la hora en la que se va a desarrollar, conveniencia de enviar previamente un cuestionario y un pequeño documento de introducción al proyecto

Realización

7



EntrevistasFases: Preparación

Realización:• Apertura: presentarse e informar, acuerdo en notas/grabación

• Desarrollo:

» Comenzar con preguntas abiertas

» Utilizar palabras y frases adecuadas, evitar tecnicismos

» Asentir y muestras de escucha

» Repetir las respuestas

» Pausas

• Término: recapitular, agradecer, nueva cita…

Análisis: pasar notas, reorganizar, evaluar…

8




Promueve la cooperación y el trabajo en equipo entre usuarios y analistas mediante un conjunto de reuniones de varios días de duración (workshops)

Razones:

Se requiere mucho tiempo para las entrevistas, prepararlas, hacerlas, redactar un conjunto coherente de requisitos

Es más difícil cometer errores en la especificación de requisitos porque lo revisa todo el equipo

Tiene una mayor probabilidad de éxito porque el usuario se siente involucrado

9




Fases:

Adaptación o preparación• Selección de participantes (8-12 distinto nivel y área + analistas)

• Recabar información, documentarse

• Organizar la reunión: lugar, fecha, ayudas audiovisuales, agenda, documentación inicial…

Sesión JAD:• Partir de un documento y elaborar y aprobar la ERS

• Medios audiovisuales, CASE

Documentación• Redactar y documentar detalles

10



Prototipado

“No sé lo que quiero”

Elaboración de un modelo o maqueta del sistema que se construye para evaluar mejor los requisitos que desean que cumpla

La cualidad esencial es que puede ser construido más rápidamente que la aplicación

Útil en áreas no bien definidas, con alto coste de rechazo o en las que sea necesario evaluar previamente el impacto

11



Prototipado

Tipos:

Prototipado de la interfaz de usuario

Modelos de Rendimiento

Prototipado funcional

Herramientas utilizadas:

Programas de dibujo, de presentación, hojas de cálculo, etc

Gestores de bases de datos y sistemas de 4ª generación

Herramientas CASE o generadores de aplicaciones

12


Contenidos



13


Visión general

14

Requisitos

Diseño

Implementación

Prueba

Análisis

Concepción Elaboración ConstrucciónVerificación

TransiciónWorkflow

Iteración-esInicial-es

Iter. #1

Iter. #2

Iter. #3

Iter. #4

Iter. #5

Iter. #6

Iter. #7

(Adaptado de Jacobson, 1999)


Visión general

15

Modelo de análisis

Modelo de diseño

Modelo de despliegue

Modelo de implementación

Modelo de pruebas

Modelo de casos de uso

Especificado por

Soportado por

Distribuido por

Implementado por

Verificado por

Modelo de análisis

Modelo de análisis

Modelo de diseño

Modelo de despliegueModelo de despliegue



Modelo de pruebas

Modelo de casos de usoModelo de

casos de uso

Especificado por

Soportado por

Distribuido por

Implementado por

Verificado por


Captura de requisitos – Visión general

Objetivos generales:

Encontrar los verdaderos requisitos

Representarlos de un modo adecuado

Uso de modelos• Un modelo es una abstracción del sistema, especificando el sistema

desde un cierto punto de vista y en un determinado nivel de abstracción

• Cada modelo es una vista autocontenida del sistema

• La mayoría de los modelos de ingeniería se definen mediante un subconjunto de UML

16


Captura de requisitos - Diagramas UML

17

Modelo de

Caso de Uso

Modelo de

Análisis

Modelo de

Diseño

Modelo de

Pruebas

Modelo de

Despliegue

Modelo de

Implementación

Diagramas de

Casos de Uso

Diagramas de

Clases

Diagramas de

Componentes

Diagramas de

Secuencias

Diagramas de

Colaboración

Diagramas de

Estados

Diagramas de

Actividad

Diagramas de

Objetos

Incluidos paquetes


Captura de requisitos

Enumerar Requisitos Candidatos: Lista de Características Comprender el Contexto del Sistema:

Modelo del DominioModelo del Negocio

Capturar los Requisitos Funcionales: Modelo de Casos de UsoIdentificar actores y casos de uso Descubrir los actores Descubrir los casos de uso Describir brevemente cada caso de uso Describir el modelo de casos de uso

Priorizar casos de usoDetallar casos de usoPrototipo de IUEstructurar el modelo

Capturar los Requisitos no Funcionales: Requisitos adicionales

18








19



Enumerar requisitos candidatosDefinición de requisito: Características que deben incluirse en un sistema o aplicación. Requisito Funcional: Acción que deberá ser capaz de desempeñar

el producto deseado. Requisito no Funcional: Otras propiedades del producto en sí

(tiempos de respuesta, seguridad, restricciones de la plataforma, etc).

Lista de características del sistema que sirven para realizar la planificación del proyecto.No todas las características del sistema tienen por qué ser desarrolladas en una misma versión.Cada característica puede tener asociada una prioridad, riesgo, coste, etc.

20








21



Comprender el contexto del sistema

Conocer el contexto en que se enmarcará el sistema.

Dos aproximaciones: Dominio y Negocio.

El modelo de dominio describe los conceptos importantes del contexto como objetos del dominio y enlaza los objetos unos con otros.

El modelo de negocio describe los procesos asociados al negocio con el objetivo de comprenderlos.

22



Comprender el contexto del sistema: Modelo de Dominio

Glosario de términos para el equipo.Sirven para identificar clases en el análisis y diseño.Se representa mediante un diagrama de clases, donde cada clase representa un objeto relevante del contexto. El glosario de términos recoge el resto de objetos menos relevantes.Proyectos grandes: Considerar en el modelo, sólo aquellos objetos verdaderamente relevantes (10-50 objetos). El resto recogerlos en el glosario.Proyectos pequeños: Directamente al glosario de términos.

23



Comprender el contexto del sistema: Modelo de Negocio

Determina qué procesos formarán parte del sistema.

Para cada proceso: Trabajadores, responsabilidades, operaciones

Se representa mediante un diagrama de casos de uso, donde cada trabajador se representa como un actor y cada proceso o necesidad como un caso de uso. También se utilizan los diagramas de actividad, que permiten reflejar la secuencia concreta en que han de ocurrir los procesos.

24


Recordatorio: Notación

Actor:

Conjunto coherente de roles o papeles que desempeñan los usuarios. Un usuario no siempre es un actor

Caso de uso:

Especifica un conjunto de secuencias de acciones que ejecuta un sistema produciendo un resultado de interés para un actor

25

Actor Caso de uso



Clase:

Descripción de un conjunto de objetos que comparten atributos, operaciones, relaciones y semántica.

Aspecto del diagrama

26

nombre

atributos

operaciones

Persona CochePosee

propietario

*1..n



Actividad:

Estado en el que se exhibe algún comportamiento

La representación del diagrama representa un flujo de trabajo, no los estados de un objeto. Generalmente se asume que no existen eventos externos

27

actividad[condición]

[condición]



Aspecto del diagrama (opción II)

28

actividad[condición]

[condición]

Calle a Calle b Calle c


Ejemplo A

El perfil de ADN es una huella digital que identifica a una persona de forma única en el mundo. Está compuesta por un conjunto de 16 marcadores. El perfil de ADN lo realiza habitualmente un biólogo. El proceso que se sigue para la obtención del perfil es el siguiente: El responsable del laboratorio de análisis autoriza la extracción de la muestra. La persona interesada dona una muestra (saliva), que el biólogo analizará en el laboratorio para extraer su perfil. Posteriormente, el biólogo entrega el resultado.

Realizar: Modelo de Dominio (diagrama de clases) Modelo de Negocio (diagrama de casos de uso y diagrama de

actividad)

29








33



Capturar los Requisitos FuncionalesLos requisitos funcionales son aquellas características que debe incorporar el sistema o aplicación a desarrollar, como acciones que éste deberá ser capaz de desempeñar.

Los requisitos funcionales se agrupan en torno a los casos de uso.

Un caso de uso para un actor es una forma concreta en la que utilizar el sistema.

Objetivos: Capturar el comportamiento

Comprensión común del sistema

34



Capturar los Requisitos Funcionales

Pasos a seguir para la captura de requisitos funcionales:

Identificar actores y casos de uso

Priorizar casos de uso

Detallar casos de uso

Prototipo de IU

Estructurar el modelo

35








36



Capturar los Requisitos Funcionales: Identificar actores y casos de uso

Para:

Delimitar el sistema

Actores y funcionalidad

Glosario

Pasos:

Descubrir los actores

Descubrir los casos de uso

Describir brevemente cada caso de uso

Describir el modelo de casos de uso

37


Ejemplo A

En el dominio de los perfiles de ADN, se desea desarrollar una aplicación que permite el almacenamiento de los perfiles de ADN de las personas que así lo demandan al laboratorio. Para cada perfil se debe registrar la persona solicitante y los marcadores obtenidos. Además para cada perfil se debe indicar el responsable que autorizó la prueba. Igualmente, el biólogo que realizó el perfil y la fecha en que fue realizada

Especificar: Lista de requisitos candidatos Actores y casos de uso Modelo de casos de uso

38


Ejemplo A

Lista de requisitos candidatos:

R1. Para cada perfil se debe registrar la persona solicitante y los marcadores obtenidos.

R2. Además para cada perfil se debe indicar el responsable que autorizó la prueba.

R3. Igualmente, el biólogo que realizó el perfil y la fecha en que fue realizada.

39


Ejemplo A

Identificar actores y casos de uso>Descubrir los actores>Descubrir los casos de uso>Describir brevemente cada caso de usoDescribir el modelo de casos de uso Caso de uso:

• Registrar Perfil

Actor:• Biólogo (iniciador)

Descripción:• El caso de uso comienza con la identificación del biólogo. Dicho usuario

introduce el nombre de la persona del perfil de ADN obtenido, además de sus marcadores. Incluye además el nombre del responsable que autorizó la realización del perfil. El sistema añadirá el nombre del biólogo (persona que accedió al sistema) y la fecha (del sistema).

40


Ejemplo B

Hacer ejemplo del cajero:

Lista de Requisitos Candidatos.

Descripción de Casos de Uso.

Diagrama de Casos de Uso.

42


Ejemplo B

Cajero AutomáticoLista de Requisitos Candidatos R1. El cliente debe validarse en el sistema para poder realizar

cualquier operación en el cajero automático.

R2. Si el cliente intenta sacar una cantidad que supera el saldo de su cuenta, el cajero le avisará de que no es posible sacar esa cantidad

R3. Si el cliente intenta sacar una cantidad que supera el límite diario, el cajero le avisará de que no es posible y volverá a solicitar una cantidad

R4. El cliente podrá hacer una transferencia a otra cuenta

R5. El cliente podrá realizar un ingreso a través del cajero automático

…

43


Ejemplo B

Capturar los Requisitos FuncionalesIdentificar actores y casos de uso >Descubrir los actores >Descubrir los casos de uso >Describir brevemente cada caso de uso Describir el modelo de casos de uso

• Caso de uso: Sacar dinero• Actor: Cliente• Descripción:

» El caso de uso comienza con la identificación del cliente. El cliente usa el caso de uso para acceder a su cuenta. El caso de uso le devuelve el dinero solicitado, un aviso de que no tiene saldo o de que ha excedido el límite diario.

• Caso de uso: Ingresar dinero• Actor: Cliente• Descripción:

» El caso de uso comienza con la identificación del cliente. El cliente usa el caso de uso para ingresar dinero en su cuenta.

• Caso de uso: Realizar transferencia• Actor: Cliente• Descripción:

» El caso de uso comienza con la identificación del cliente. El cliente usa el caso de uso para realizar una transferencia de dinero entre dos cuentas bancarias.

44


Ejemplo C

En el contexto de la universidad Rey Juan Carlos, cada titulación ofrece a sus potenciales alumnos un conjunto de asignaturas de las que pueden matricularse. Para que un alumno obtenga finalmente una nota en su expediente de una asignatura, se debe seguir el proceso siguiente: el alumno se matriculará de las asignaturas que estime oportunas puesto que no existe ningún tipo de restricción a ese respecto. Los profesores que imparten las asignaturas, tendrán acceso a las actas de dichas asignaturas, en cada convocatoria, con la finalidad de poder rellenar las actas con las notas obtenidas por los alumnos en el examen. Una vez el acta haya sido publicada, labor que realiza el mismo profesor de la asignatura, el alumno podrá visualizar su expediente, que es el conjunto de las asignaturas que las que está o ha estado matriculado, la nota y la fecha en la que la obtuvo, cuando procede esta información.

46


Ejemplo C

Hacer ejemplo URJC:

Diagrama de clases. (Modelo de dominio).

Lista de requisitos candidatos.

Diagrama de casos de uso. (Modelo de Negocio).

Diagrama de Actividad. (Modelo de Negocio).

Revisar los requisitos.

Descripción de casos de uso.

Diagrama de casos de uso. (Requisitos)

47


Ejemplo C

Enumerar Requisitos Candidatos

R1. Los alumnos podrán matricularse de asignaturas de una titulación.

R2. Los profesores deberán completar el acta de una asignatura donde se especificará la nota para cada alumno.

R3. Los profesores habrán de publicar las actas con el fin de hacerlas públicas de cara a los alumnos.

R4. Los alumnos podrán consultar sus expedientes académicos para determinar las notas obtenidas en sus exámenes.

49


Ejemplo C

Capturar los requisitos funcionales

Antes de continuar se indica que la aplicación a desarrollar no permitirá la matriculación de los alumnos a través de la misma, ya que éste es un proceso administrativo que queda fuera del alcance de la aplicación. Por lo tanto los requisitos funcionales a contemplar serían:

R2. Los profesores deberán completar el acta de una asignatura donde se especificará la nota para cada alumno.

R3. Los profesores habrán de publicar las actas con el fin de hacerlas accesibles y visibles para los alumnos.

R4. Los alumnos podrán consultar sus expedientes académicos para determinar las notas obtenidas en sus exámenes.

52


Ejemplo C

Capturar los Requisitos FuncionalesIdentificar actores y casos de uso >Descubrir los actores >Descubrir los casos de uso >Describir brevemente cada caso de uso Describir el modelo de casos de uso

• Caso de uso: Completar actas• Actor: Profesor• Descripción:

» El caso de uso comienza con el acceso del profesor a las actas de sus asignaturas con la finalidad de incluir una nota para cada alumno matriculado en la asignatura.

• Caso de uso: Publicar actas• Actor: Profesor• Descripción:

» El caso de uso comienza con el acceso del profesor a las actas de sus asignaturas con la finalidad de publicarlas, acción que tendrá como objetivo hacer pública la nota de cara a los alumnos.

• Caso de uso: Consultar expediente• Actor: Alumno• Descripción:

» El caso de uso comienza con el acceso del alumno a la consulta del expediente. La aplicación mostrará un listado de las asignaturas y sus calificaciones.

53


Ejemplo C

Enumerar Requisitos Candidatos Comprender el Contexto del Sistema Capturar los Requisitos Funcionales

Identificar actores y casos de uso Descubrir los actores Descubrir los casos de uso Describir brevemente cada caso de uso >Representar el diagrama de casos de uso

Alumno

Consultar

expediente

Profesor

Completar Actas

Publicar

Actas

Gestión de Actas y Expedientes

R3

R2

R4

54








55



Priorizar casos de uso

Casos de uso a desarrollar en las primeras iteraciones

Casos de uso significativos

Casos de uso con funcionalidad importante y crítica o que implique algún requisito importante que deba desarrollarse pronto

Esta vista forma la vista de la arquitectura del modelo de casos de uso

56








57




Objetivo: flujo de eventos en detalle

Cómo comienza y termina el caso de uso

Cómo interactúa con los actores

Veremos:

Cómo estructurar la descripción de un CU, para especificar todas las vías alternativas

Qué incluir en una descripción de un CU

Cómo formalizar la descripción del CU

En colaboración con los usuarios reales de los CU

Resultado: descripción detallada en texto y diagramas

58



Detallar casos de uso - Cómo estructurar un CU

Objetivo: hacer descripción precisa pero fácil de leer

Camino básico: “LO NORMAL”

Caminos alternativos:

El actor puede elegir diferentes caminos

El sistema detecta entradas erróneas

Algunos recursos funcionan mal

Gráficamente: diagrama de estados

59



Detallar casos de uso - Qué incluir en una descripción de un CUEstado inicial como precondición (condiciones previas)Cómo y cuándo comienza el caso de uso (la primera acción)Orden de acciones (flujo de eventos o sucesos)Cómo y cuándo termina el caso de usoEstados finales como postcondiciones (cond. posteriores)Caminos no permitidosDescripción caminos alternativos (a veces se incluyen en el básico)Interacción del sistema con los actores y cambios que producenUso de objetos, valores y recursos del sistemaQué hace el sistema. Separar responsabilidades.Requisitos especiales

Validar los casos de uso:Usuarios, clientes

60


Ejemplo A

Detallar el caso de uso de “Registrar perfil”

61


Ejemplo A: Solución

Detallar casos de uso – Cómo estructurar un CU

62

Flujo de eventos

Camino básico del caso de uso “Registrar Perfil”

ACTOR SISTEMA

1. El biólogo introduce su login y pwd 2. El sistema valida los datos

3. Introduce el nombre de la persona, los

marcadores y el responsable que autorizó

la prueba

4. El sistema agrega el nombre del

biólogo y la fecha del sistema

5. El sistema solicita la confirmación del

usuario para terminar

6. El biólogo acepta la operación y fin del

caso de uso.

Caminos alternativos

Evento 3. El actor puede cancelar la operación

Evento 6. El actor puede cancelar la operación.


Ejemplo B

Detallar caso de uso de “Sacar Dinero”

63


Ejemplo B

Detallar casos de uso - Qué NO incluir en una descripción de un CU

“El cliente solicita el PIN al banco”. No corresponde modelar la interacción entre el actor y otros agentes externos.

“El objeto impresora imprime el comprobante del cliente”. Un caso de uso es un modelo funcional, una visión externa del sistema. No corresponde modelar las acciones que llevarían a cabo los objetos del sistema.

“Si no se valida el usuario se vuelve al paso 02”. La descripción textual del caso de uso no es un algoritmo, no deben indicarse estructuras de control ni bifurcaciones a eventos o acciones específicas.

64


Ejemplo B: Solución

Detallar casos de uso “Sacar Dinero”>Cómo estructurar la descripción de un CU>Qué incluir en una descripción de un CUCómo formalizar la descripción del CU

65

Flujo de eventos

Camino básico del caso de uso “Sacar Dinero”

ACTOR SISTEMA



Detallar casos de uso “Sacar Dinero”>Cómo estructurar la descripción de un CU>Qué incluir en una descripción de un CUCómo formalizar la descripción del CU

66

Flujo de eventos

Camino básico del caso de uso “Sacar Dinero”

ACTOR SISTEMA

1. Este caso de uso empieza cuando un

Cliente introduce una tarjeta en el cajero

2. Pide la clave de identificación

3. Introduce la clave 4. Comprueba la clave

5. Presenta las opciones de

operaciones disponibles

6. Selecciona la operación de Reintegro 7. Pide la cantidad a retirar

8. Introduce la cantidad requerida 9. Procesa la petición

10 .Devuelve la tarjeta

11. Da el dinero solicitado.

12. Recoge la tarjeta.

13. Recoge el dinero y termina el caso de

uso



Flujo de eventos

Camino básico del caso de uso

“Sacar Dinero”

ACTOR SISTEMA

1. Este caso de uso

empieza cuando un Cliente

introduce una tarjeta en el

cajero

2. Pide la clave de

identificación


5. Presenta las opciones

de operaciones

disponibles

6. Selecciona la operación

de Reintegro

7. Pide la cantidad a

retirar

8. Introduce la cantidad

requerida

9. Procesa la petición


11. Da el dinero

solicitado.


13. Recoge el dinero y

termina el caso de uso

Flujo de eventos


“Sacar Dinero”

ACTOR SISTEMA

1. Este caso de uso

empieza cuando un Cliente

introduce una tarjeta en el

cajero

2. Pide la clave de

identificación



de operaciones

disponibles


de Reintegro


retirar


requerida







67



Flujo de eventos


“Sacar Dinero”

ACTOR SISTEMA


de Reintegro


retirar


requerida








Evento 3. El cliente cancela la transacción

Evento 4: La cantidad solicitada supera el saldo. Se

indica el error y se cancela la operación.

Evento 4: La cantidad solicitada supera el límite diario.

Se indica el error y se vuelve a pedir otra cantidad.

Flujo de eventos


“Validar Cliente”

ACTOR SISTEMA

1. Este caso de uso empieza

cuando un Cliente introduce

una tarjeta en el cajero

2. Pide la clave de

identificación



de operaciones

disponibles y termina el

caso de uso.



Evento 4. La clave no es válida y se reinicia el caso de

uso. Si ocurre tres veces se cancela la transacción y no

se devuelve la tarjeta

68




Cómo estructurar la descripción de un CU

Qué incluir en una descripción de un CU

>Cómo formalizar la descripción del CU

Para casos de uso sencillos es suficiente texto

Para complejos: necesitan estructuración y técnicas visuales• Diagramas de

» Estados

» Actividad

» Interacción

69



Cómo formalizar la descripción de un CU: Diagrama de estados:

Un diagrama de estados representa un elemento como una máquina de estados finita

Un diagrama de estado, representa la vida de un único elemento

Consta de: Estados, Transiciones, Eventos y Actividades

Permite visualizar el comportamiento (dinámico) de un elemento/sistema.

Es importante reconocer estos estados y las transiciones entre los mismos, cuando los objetos presentan diferentes comportamientos según el estado en que se encuentren.

70



Cómo formalizar la descripción de un CU: Diagrama de estados Elementos

Estado: situación en la vida de un elemento durante la cual se satisface alguna condición, se realiza alguna actividad o se espera algún suceso. Identifica un periodo de tiempo del objeto (no instantáneo). Inicial, Intermedio, Final

Transición: relación entre dos estados que indica que un elemento que esté en un primer estado realizará ciertas acciones y entrará en el segundo estado cuando se produzca un suceso especificado y se satisfacen las condiciones indicadas.Suceso o evento: especificación de algún acontecimiento que ocupa espacio y tiempo. Es la aparición de un estímulo que puede disparar la transición de un estado a otro

71



Cómo formalizar la descripción de un CU: Diagrama de estados

Actividad: ejecución no atómica en curso, dentro de una máquina de estados. Lo que se hace en el estado do: operación que toma un tiempo en el estado. Puede

interrumpirse por un suceso, externo o interno, o terminar en transición automática

Acción: computación atómica ejecutable que produce un cambio de estado del modelo o devuelve algún valor (deben ser operaciones de la clase) entry: instantáneamente a la entrada del estado

exit: instantáneamente a la salida del estado

Asociadas a eventos

72



73

EstadoE.Inicial

E.Final Transición

Estado

Suceso

Estado

T. autom.

en el paro en activo

jubilado

contratar

perder empleo

jubilarsejubilarse



La acción se considera instantánea

Ejemplos:

74

a bEvento[Condición]/acción

estado A

Entry/ acción al entrar en el estado

Exit/ acción al salir del estado

Do/ actividad mientras en estado


Ejemplo D

Un reloj digital tiene una pantalla y dos botones para accionarlo, el botón A y el botón B. El reloj tiene dos modos de operación, visualizar la hora y establecerla. En el modo de visualización aparecen las horas y los minutos separados por dos puntos (:) intermitentes. El modo de establecer la hora tiene dos submodos: poner las horas y poner los minutos. El botón A se utiliza para seleccionar el modo de operación. Cada vez que se aprieta, el modo avanza en secuencia: visualizar la hora, poner hora, poner minutos, visulizar la hora, etc. Dentro de los submodos, el botón B se utiliza para avanzar una hora o un minuto cada vez que se aprieta.

Realice un diagrama de estados del reloj

75



Ejemplo 1

77


Ejemplo 2

78




Ejemplo 3

79



Ejemplo 4

80



Flujo de eventos


“Validar Cliente”

ACTOR SISTEMA

1. Este caso de uso empieza

cuando un Cliente introduce

una tarjeta en el cajero

2. Pide la clave de

identificación


5. Presenta las opciones de

operaciones disponibles y

termina el caso de uso.



Evento 4. La clave no es válida y se vuelve al evento 2. Si

ocurre tres veces se cancela la transacción y no se devuelve

la tarjeta

Recordar que:

Correspondencia entre flujo de eventos y diagramas de estados: Los sucesos en el sistema

representan estados, actividades, acciones, etc

Los sucesos asociados al actor representa eventos.

Un diagrama de estados representa TODOS los caminos (el básico y los alternativos)

81


Ejemplo B

Realizar el diagrama de estados correspondiente al caso de uso “Validar Cliente”

82


Ejemplo E

Diagrama de transición de estados para el ordenador de a bordo de un automóvil, cuya especificación es la siguiente:

Una vez que el conductor ha introducido la llave en el contacto, el ordenador realiza un chequeo de arranque, indicándolo mediante el encendido de un testigo. A partir de este punto pueden darse las siguientes situaciones: Si no se detecta ninguna anomalía y los cinturones de seguridad están abrochados, el ordenador

espera el arranque del vehículo presentando un testigo indicando que se puede arrancar el motor. Una vez que el vehículo está arrancado, el ordenador mostrará los testigos habituales (indicador de nivel de combustible, temperatura, freno de mano, etc).

Si no se detecta ninguna anomalía pero algún ocupante del vehículo tiene el cinturón desabrochado, el ordenador esperará que se abrochen los cinturones mientras presenta un testigo indicando al conductor la situación. Una vez solventado el problema, se volverá a realizar el chequeo de arranque.

Si se detecta una anomalía no grave, el ordenador lo indicará al conductor, y esperará a que éste reconozca dicha anomalía, mediante la pulsación de una tecla OK y mostrando un testigo. Cuando pulse la tecla, se volverá a realizar el chequeo de arranque.

Si se detecta una anomalía grave, el ordenador bloqueará el motor de arranque, no permitiendo el encendido del vehículo y mostrará un testigo indicador de la situación. Sólo se podrá sacar la llave pero no se podrá realizar ninguna otra acción hasta la reparación de la anomalía. Una vez se haya retirado la llave, el ordenador se apaga.

84








86



Prototipo de IU

Hasta ahora, modelo de casos de uso que especifica:

Qué usuarios hay

Para qué utilizan el sistema

Ahora necesitamos un interfaz de usuario para llevar a cabo lo casos de uso de manera eficiente

Dos pasos:

Diseño lógico de la interfaz de usuario:• Qué se necesita para habilitar los casos de uso para cada actor

Diseño físico de la interfaz de usuario• Cómo se necesita (Prototipo)

87



Diseño lógico de la IU

A partir de:

Descripciones de los casos de uso

Requisitos adicionales

Modelo de casos de uso

Glosario

Los actores interactúan con el sistema utilizando y manipulando elementos de interfaces de usuario

Un mismo elemento puede intervenir en muchos casos de uso.

88



Diseño lógico de la IU

Para cada actor, respondemos a:

¿Qué elementos de IU se necesitan para posibilitar el CU?

¿Cómo deberían relacionarse unos con otros?

¿Cómo se utilizarán en los diferentes CU?

¿Cuál debería ser su apariencia?

¿Cómo deberían manipularse?

89



Diseño lógico de la IUPara ver qué elementos de IU deben ser accesibles al actor en cada CU: ¿Qué clases, entidades son adecuadas como elementos de

IU para cada CU?

¿Con qué elementos de la IU va a trabajar el actor?

¿Qué acciones puede invocar el actor y qué decisiones puede tomar?

¿Qué guía o información necesita el actor?

¿Qué información debe proporcionar el actor al sistema?

¿Qué información debe proporcionar el sistema al actor?

¿Cuál será el valor medio de los parámetros de entrada o salida? (ej: número de facturas medias)

90



Diseño físico de la interfaz de usuario

Esquemas de la configuración de elementos de las IU

Después o la a vez que el diseño físico

Preparación de prototipos ejecutables

Puede haber varios:

Uno por caso de uso

Esfuerzo proporcional al valor de retorno esperado:

Ejecutables cuando tenemos mucho que ganar en facilidad de uso

Bocetos en papel cuando no tenemos tanto que ganar

91








92



Estructurar el modelo de casos de uso

Para

Extraer descripciones de funcionalidad generales y compartidas que pueden ser utilizadas por descripciones más específicas

Extraer descripciones de funcionalidad adicionales u opcionales que pueden extender descripciones más específicas

Modelo de casos de uso, descripción detallada

Buscar comportamientos compartidos y extensiones

93




Identificar funcionalidad compartida

Generalizaciones

Identificar funcionalidad adicional y opcional

Extend

Identificar otras relaciones

Include

94




Generalización:

Un caso de uso se puede especializar en uno o más casos de uso hijos, utilizando una relación de generalización.

Es una relación que amplía la funcionalidad de un Caso de Uso o refina su funcionalidad original mediante el agregado de nuevas operaciones y/o atributos y/o secuencias de acciones.

95

Realizar Pago

Pago en efectivo Pago con tarjeta




Extensión:La relación de extensión permite un desarrollo incremental, comenzando el desarrollo con casos de uso más simples e ir agregando comportamientos específicos

Modela la adición de una secuencia de acciones a un CU

Partes opcionales de un caso de uso

Cursos complejos y alternativos

Subsecuencias que se ejecutan sólo bajo ciertas condiciones

96

Devolver vídeo Pagar recargo<<extend>>




Inclusión

Un caso de uso puede incluir en su comportamiento el comportamiento de otro caso de uso a través de una relación de inclusión

Extensión explícita e incondicional

Cuando varios casos de uso comparten descripciones similares para evitar redundancia y maximizar reutilización se puede extraer dichas secuencias comunes

97

Prestar vídeoComprobar

disponibilidad

<<include>>




Inclusión vs. Extensión

En líneas generales debe aplicarse la siguiente regla:

98

Situación Utilizar relación

Secuencias comunes <<inclusión>>

Cursos de acción nuevos u opcionales

<<extensión>>




Relaciones - Generalización

99

Sistema de Gestión de Ordenes




Relaciones

Inclusión

Extensión

100

Cliente

Hacertransfer.

Sacardinero

ConsultarSaldo

<<include>>

<<include>>

Cliente

Sacardinero

Ingresardinero

ReciboEn papel

<<extend>>

<<extend>>








101



Captura de requisitos no Funcionales

Identificar características no funcionales del sistema (restricciones de la plataforma, seguridad, tiempos de acceso…)

Asociados a casos de uso

En lista de requisitos adicionales

102


Ejemplo B

Supongamos que el caso de uso “Ingresar Dinero” se realiza de la siguiente forma:

Después de que el cliente se haya validado, se introduce por teclado la cantidad de dinero a ingresar. El sistema abrirá el cajón, donde habrá que realizar el depósito del dinero en metálico. A continuación, el sistema contabilizará el dinero depositado para comprobar si coincide con la cantidad tecleada. Si coincide, el ingreso se hará efectivo. En caso contrario, se permite que el usuario reintente la operación.Detallar Casos de Uso “Ingresar Dinero”. Cómo estructurar la descripción de un CU Qué incluir en una descripción de un CU

Hacer el diagrama de estados.

103


Ejemplo B

Supongamos que el caso de uso “Realizar Transferencia” se realiza de la siguiente forma:

Después de que el cliente se haya validado, se introduce por teclado la cantidad de dinero a transferir. El sistema solicitará el número de cuenta destino de la transferencia. El cajero realiza la operación realizando primero un reintegro y luego un ingreso. Si la transacción se ha realizado satisfactoriamente se le indica al usuario que la operación ha sido completada. Se expulsa luego la tarjeta y termina el caso de uso.

Detallar Casos de Uso. “Realizar Transferencia”

Estructurar el modelo. (Diagrama de casos de uso)

106


Bibliografía

El Proceso Unificado de Desarrollo de Software. I. Jacobson, G. Booch y J. Rumbaugh. PearsonPrentice-Hall 2007

Análisis y Diseño de Aplicaciones Informáticas de Gestión. M. Piattini, J. Calvo-Manzano, J.Cervera y L. Fernández . Ra-Ma 2003

Ingeniería del Software. Ian Sommerville. Pearson/ Addison Wesley 2005

117

tema 7: elicitación de requisitos - kybele · tema 7: elicitación de requisitos departamento de...

Documents