análisis e ingeniería de requisitosai… · cualquier interacción del sistema con el usuario es...
TRANSCRIPT
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 1
Análisis e Ingeniería de Requisitos Tema 3: Captura de Requisitos (Parte II)
Curso 2011-2012
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 2
Bibliografía Básica
El proceso unificado de desarrollo del software. Ivar Jacobson, Grady
Booch, James Rumbaugh. Addison-Wesley
Análisis y Diseño Orientado a Objetos con UML y el Procesos Unificado. Stephen R. Schach. Mc Graw Hill.
Ingeniería del Software. Ian Sommerville,Addison Wesley, 2004ª Ed.
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 3
Índice de transparencias
Fundamentos de la captura de requisitos
Introducción al proceso unificado
Captura de requisitos según el proceso unificado
1. Enumerar requisito candidatos
2. Comprender el Contexto del Sistema
3. Capturar los Requisitos Funcionales
4. Capturar los Requisitos no Funcionales
Parte I
Parte II
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 4
Introducción al Proceso Unificado
Realidad actual: sistemas más complejos y más grandes
Objetivo: Desarrollo más rápido menor tiempo de salida al mercado Software de calidad Mejor adaptación del software a las necesidades del cliente
Solución: un proceso de desarrollo que integre todas las facetas de un desarrollo software
Dé una guía para ordenar las actividades del equipo Dirija las tareas individuales y del equipo Especifique los productos (artefactos) que hay que desarrollar Ofrezca criterios para monitorizar y medir los productos y actividades
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 5
Introducción al Proceso Unificado
El proceso Unificado es un proceso de desarrollo software Def.: conjunto de actividades para transformar los requisitos de usuario en un sistema software
Principios: Dirigido por casos de uso Centrado en la arquitectura Iterativo e incremental Usa UML (Unified Modeling Language) como notación para los modelos del proceso de desarrollo
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 6
Introducción al Proceso Unificado Dirigido por casos de uso
Ideas: Cualquier interacción del sistema con el usuario es un
caso de uso Actor: alguien o algo
Def.: caso de uso Es una función del sistema que da al usuario un
resultado útil Captura los requisitos funcionales
¿Qué debe hacer el sistema para cada actor? Modelo de casos de uso
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 7
Introducción al Proceso Unificado Dirigido por casos de uso
Conducen el proceso de desarrollo: Los desarrolladores crean modelos de diseño e
implementación que realizan los casos de uso
Los encargados de pruebas aseguran que los componentes implementan los casos de uso
Los casos de uso se especifican, se diseñan y sirven de base para construir los casos de prueba
Se desarrollan junto a la arquitectura del sistema Ambos evolucionan en paralelo
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 8
Introducción al Proceso Unificado Centrado en la Arquitectura
El concepto de arquitectura software incluye los aspectos estáticos y dinámicos más significativos del sistema.
La arquitectura software se describe mediante diferentes vistas del sistema en construcción.
Influencias: Plataforma, aspectos legales, componentes reusables disponibles...
El proceso ayuda a centrarse en los objetivos correctos:
legibilidad, adaptabilidad, reutilización.
Relación entre casos de uso y arquitectura Casos de uso (Funcionalidad del sistema) deben encajar en la arquitectura Arquitectura (Forma) deben permitir el desarrollo de todos los casos de uso
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 9
Introducción al Proceso Unificado Iterativo e incremental
División del proyecto en “hitos” obtenidos como consecuencia de la repetición de iteraciones de trabajo Una iteración produce un incremento Cada fase e iteración se centra en disminuir algún riesgo y concluye con
un hito bien definido
Todas las iteraciones son planificadas y controladas Factores para la selección en una iteración:
La iteración trata un grupo de casos que extienden la funcionalidad La iteración trata los riesgos más importantes
Importante: un incremento no siempre es aditivo Elementos contemplados en cada iteración:
Casos de uso relevantes Diseño guiado por arquitectura Actividades de implementación y verificación
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es
Introducción al Proceso Unificado Iterativo e incremental
Ciclo de vida del software: Varios ciclos de desarrollo que concluyen con un producto evolucionado
El paso a través de las 4 fases principales constituye un ciclo de desarrollo produce una generación del software
Primera pasada desarrollo inicial
Siguientes ciclos de evolución del sistema
Hitos por fases (milestones)
...
Entrega
Ciclos
Concepción Elaboración Transición Construcción Iter.
1 Iter.
2 ... ... ... ... ... ... Iter.
n
Fases
Iterac.
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 11
Introducción al Proceso Unificado Flujos de trabajo principales (Workflows)
Requisitos
Diseño
Implementación
Prueba
Análisis
Planificación Anál. Riesgos Preparación
Elaboración Construcción Verificación
Transición
Fases Flujos de trabajo
Iteración(es) Inicial(es)
Iter. #1
Iter. #2
Iter. #3
Iter. #4
Iter. #5
Iter. #6
Iter. #7
(Adaptado de Jacobson, 1999)
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es
Requisitos
Diseño
Implementación
Prueba
Análisis
Planificación Anál. Riesgos Preparación
Elaboración Construcción Verificación
Transición
FASES Workflow
Iteración(es) Inicial(es)
Iter. #1
Iter. #2
Iter. #3
Iter. #4
Iter. #5
Iter. #6
Iter. #7
(Adaptado de Jacobson, 1999)
Iteración en Fase de Elaboración
Introducción al Proceso Unificado Flujos de trabajo principales (Workflows)
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 13
Flujos de Trabajo Principales
Requisitos
Captura de los requisitos del sistema Difícil: Los requisitos cambian Comprensión: lenguaje utilizado El cliente debe ser capaz de leer y comprender el resultado de la captura
Objetivo: guiar el desarrollo hacia el sistema correcto
El resultado ayuda al jefe de proyecto a planificar las iteraciones y los
recursos
Pasos a seguir: Enumerar los requisitos candidatos lista de características Comprender el contexto del sistema modelo de negocio/dominio Capturar requisitos funcionales modelo de casos de uso Capturar requisitos no funcionales requisitos suplementarios o
casos individuales
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es
Captura de requisitos Visión general
Requisitos
Diseño
Implementación
Prueba
Análisis
Planificación Anál. Riesgos Preparación
Elaboración Construcción Verificación
Transición
Fases Flujos de trabajo
Iteración(es) Inicial(es)
Iter. #1
Iter. #2
Iter. #3
Iter. #4
Iter. #5
Iter. #6
Iter. #7
(Adaptado de Jacobson, 1999)
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es
Modelo de análisis
Modelo de diseño
Modelo de despliegue
Modelo de implementación
Modelo de pruebas
Modelo de casos de uso
Captura de requisitos Visión general
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es
Captura de requisitos Diagramas UML
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 Secuencia
Diagramas de Colaboración
Diagramas de Estados
Diagramas de Actividad
Diagramas de Objetos
Incluidos paquetes
Modelo de
Casos de Uso
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 17
Captura de requisitos Proceso Unificado
Enumerar Requisitos Candidatos
Lista de Características
Comprender el Contexto del Sistema Modelo de Dominio y/o del Negocio
Capturar los Requisitos Funcionales Modelo de Casos de Uso
Capturar los Requisitos no Funcionales Requisitos adicionales
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 18
Captura de requisitos Enumerar requisitos candidatos
Requisito Funcional Funcionalidad que deberá ser capaz de
desempeñar el producto deseado Requisito no Funcional Restricciones y otras propiedades del producto
(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.
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 19
Captura de requisitos
Ejemplo - Enunciado
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
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 20
Captura de requisitos
Ejemplo
Lista de requisitos candidatos R1. El sistema deberá permitir que el responsable del laboratorio autorice
la realización de muestras.
R2. El sistema deberá permitir gestionar el análisis de los perfiles así como la entrega de los resultados a los donantes.
R3. El sistema deberá permitir gestionar la donación de muestras de ADN.
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 21
Captura de requisitos: proceso unificado
Enumerar Requisitos Candidatos
Lista de Características
Comprender el Contexto del Sistema Modelo de Dominio y/o del Negocio
Capturar los Requisitos Funcionales Modelo de Casos de Uso
Capturar los Requisitos no Funcionales Requisitos adicionales
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 22
Captura de requisitos
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
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 23
Captura de requisitos
Comprender el Contexto del Sistema
Modelo de Dominio Captura los tipos más importantes de objetos en el contexto del sistema. Glosario de términos para el equipo. Sirven para identificar clases en el análisis y diseño.
Los objetos del dominio representan “cosas” que existen en el dominio o eventos que suceden en el entorno en el que trabaja el sistema.
Obtención de objetos: (a partir de la especificación de requisitos) Objetos del negocio: pedidos, cuentas, contratos Objetos del mundo real y conceptos que requieren seguimiento: aviación
enemiga, misiles, trayectorias Sucesos: llegada y salida de un avión, hora de comida
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 24
Captura de requisitos
Comprender el Contexto del Sistema
Modelo de Dominio
Se representa mediante un diagrama de clases, donde cada clase representa un objeto relevante del contexto
El glosario de términos recoge estos objetos y 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
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 25
Captura de requisitos
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
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 26
Captura de requisitos
Diagramas de Casos de Uso
Actor:
Conjunto coherente de roles o papeles que desempeñan los usuarios
Se pueden crear categorías generales de actores y especializarlos a través de relaciones de generalización
Caso de uso:
Descripción de un conjunto de secuencias de acciones que ejecuta un sistema produciendo un resultado de interés para un actor
Aspecto del diagrama
Actor Caso de uso
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 27
Captura de requisitos
Diagramas de Clases
Clase (rectángulo):
Descripción de un conjunto de objetos que comparten atributos, operaciones, relaciones y semántica
Atributos: propiedad que es compartida por todos los objetos de la clase.
Asociaciones: forma en que se relacionan unas con otras.
Aspecto del diagrama
Persona Coche Posee
propietario
* 1..n
rol
multiplicidad
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 28
Captura de requisitos
Diagramas de Actividad
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
Aspecto del diagrama (opción I)
actividad [condición]
[condición]
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 29
Captura de requisitos
Diagramas de Actividad
Aspecto del diagrama (opción II)
actividad [condición]
[condición]
Calle a Calle b Calle c
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 30
Captura de requisitos
Ejemplo – Contexto del sistema
Glosario: Perfil de ADN: Perfil genético de una persona, que la identifica de forma única en el mundo.
Marcadores (o localidades) de ADN: Elementos que componen el perfil de ADN de una persona. En la actualidad el número de marcadores que componen el perfil son 16.
Biólogo: Persona que se encarga de recoger la muestra a la persona que desea que se le realice el perfil de ADN. El biólogo también obtiene finalmente el perfil de ADN de una persona, a partir de la muestra.
Muestra: sustancia biológica de una persona que contiene la información genética suficiente para poder extraer su perfil de ADN.
Solicitante: Sujeto al que pertenece la muestra y del que se obtiene el perfil de ADN.
Responsable: Persona del laboratorio que es la encargada de autorizar la prueba de ADN.
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 31
Captura de requisitos
Ejemplo – Contexto del sistema
Modelo de dominio: diagrama de clases
Perfil de ADN
Marcadores
Paciente Biólogo realiza pertenece
Responsable
autoriza 1..n
1..1
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 32
Captura de requisitos
Ejemplo – Contexto del sistema
Modelo de negocio: diagrama de casos de uso
Realizar Perfil
Autorizar
Biólogo
Responsable
Entregar Perfil
Donar Muestra
Paciente
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 33
Captura de requisitos
Ejemplo – Contexto del sistema
Modelo de negocio: diagrama de actividad
Autorizar Donar
Muestra Realizar
Perfil
Entregar
Perfil
Responsable Paciente Biólogo
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 34
Captura de requisitos: proceso unificado
Enumerar Requisitos Candidatos
Lista de Características
Comprender el Contexto del Sistema Modelo de Dominio y/o del Negocio
Capturar los Requisitos Funcionales Modelo de Casos de Uso
Capturar los Requisitos no Funcionales Requisitos adicionales
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 35
Captura de requisitos
Capturar los Requisitos Funcionales
Los 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
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 36
Captura de requisitos
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
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 37
Captura de requisitos
Capturar los Requisitos Funcionales
Identificar actores y casos de uso Para: Delimitar el sistema
Descubrir actores y funcionalidad
Crear un glosario de términos
Pasos: Descubrir los actores
Descubrir los casos de uso
Describir brevemente cada caso de uso
Describir el modelo de casos de uso
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 38
Captura de requisitos
Ejemplo
Lista de requisitos detallada R1. Para cada perfil se debe registrar la persona solicitante y los
marcadores obtenidos, labor que realizará siempre el biólogo.
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.
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 39
Captura de requisitos
Ejemplo – Identificar actores y CU
Identificar actores y casos de uso Caso de uso:
Registrar Perfil
Actor: Biólogo (iniciador)
Describir el caso de uso Descripción del caso de uso “Registrar Perfil”:
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).
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 40
Captura de requisitos
Ejemplo – Modelo de caso de uso
Describir el modelo de casos de uso
Biólogo
Registrar Perfil
Aplicación de almacenamiento
de perfiles de ADN
R1, R2, R3
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 41
Captura de requisitos
Capturar los Requisitos Funcionales
Priorizar los casos de uso:
Casos de uso a desarrollar en las primeras iteraciones
Casos de uso significativos
En función del riesgo asociado a cada requisito funcional
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 42
Captura de requisitos
Capturar los Requisitos Funcionales
Detallar los casos de uso
Objetivo: identificar un flujo de eventos Cómo comienza y termina el caso de uso
Cómo interactúa con los actores
Objetos que se intercambian
Veremos: 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
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 43
Captura de requisitos
Capturar los Requisitos Funcionales
Detallar los casos de uso
Cómo estructurar la descripción de un CU Describir el camino básico (“LO NORMAL”)
Describir las alternativas al camino básico. Motivos:
• El actor puede elegir diferentes caminos
• El sistema detecta entradas erróneas
• Algunos recursos funcionan mal
Representación gráfica:
• Diagrama de transición de estados
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 44
Captura de requisitos
Capturar los Requisitos Funcionales
Detallar los casos de uso Qué incluir en una descripción de un CU
Estado inicial como precondición (condiciones previas)
Cómo y cuándo comienza el caso de uso
Orden de acciones (flujo de eventos o sucesos)
Cómo y cuándo termina el caso de uso
Estados finales como postcondiciones (condiciones posteriores)
Caminos no permitidos
Descripción caminos alternativos (incluida o no con el c. básico)
Interacción del sistema con los actores y cambios que producen
Uso de objetos, valores y recursos del sistema
Qué hace el sistema. Separar responsabilidades.
Requisitos especiales
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 45
Captura de requisitos
Capturar los Requisitos Funcionales
Detallar los casos de uso
Cómo formalizar la descripción del CU
Casos de uso sencillos: • Es suficiente con un texto descriptivo
Casos de uso complejos: • Necesitan estructuración y técnicas visuales
• Formalismos: usar diagramas de
» transición de estados
» actividad
» interacción
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 46
Captura de requisitos (funcionales)
Ejemplo – Detallar los casos de uso
Qué incluir en una descripción de un CU flujo de eventos
Flujo de eventos del caso de uso “Registrar Perfil”
Camino básico
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.
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 47
Captura de requisitos
Diagramas de (transición de) estados
Un diagrama de estados representa un elemento como una máquina de estados finita
Un diagrama de estados representa la vida de un único elemento
Permite visualizar el comportamiento (dinámico) de un elemento/sistema
Consta de: Estados Transiciones Sucesos o eventos Actividades Acciones
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 48
Captura de requisitos
Diagramas de (transición 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 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
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 49
Captura de requisitos
Diagramas de (transición de) estados
Elementos 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
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 50
Captura de requisitos
Diagramas de (transición de) estados
Elementos gráficos
Ejemplo
Estado E.Inicial
E.Final Transición
Estado
Sucesos
Estados
T. autom.
en el paro en activo
jubilado
contratar
perder empleo
jubilarse jubilarse
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 51
Captura de requisitos
Diagramas de (transición de) estados
La acción se considera instantánea
Acciones, eventos y condiciones:
a b Evento[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
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 52
Captura de requisitos
Diagramas de (transición de) estados
Apuntes finales
Correspondencia entre flujo de eventos y diagramas de estados:
Los sucesos en el sistema representan estados, actividades, acciones, etc.
Los sucesos asociados al actor representan eventos
Un diagrama de estados representa TODOS los caminos (el básico y los alternativos)
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 53
Captura de requisitos
Capturar los Requisitos Funcionales
Prototipo de Interfaz de Usuario
A partir de las descripciones de los casos de uso
Pasos: Diseño lógico: qué necesita cada actor de la interfaz para que se
pueda ejecutar el caso de uso
Descripción y construcción del prototipo ejecutable pero con acciones nulas (validación y depuración)
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 54
Captura de requisitos
Capturar los Requisitos Funcionales
Estructurar el modelo de casos de uso
Identificar funcionalidad compartida
Generalizaciones
Identificar funcionalidad adicional y opcional
Relaciones de extensión: extend
Identificar otras relaciones
Relaciones de inclusión: include
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 55
Captura de requisitos
Capturar los Requisitos Funcionales
Diagrama de casos de uso: Generalización
Usuario
Identificar Adm.
Alta Usuario
Identificar Usuario
Administrador
Baja Usuario
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 56
Captura de requisitos
Capturar los Requisitos Funcionales
Diagrama de casos de uso: Relaciones
Inclusión
Extensión
Cliente
Hacer transfer.
Sacar dinero
Consultar Saldo
<<include>>
<<include>>
Cliente
Sacar dinero
Ingresar dinero
Obtener recibo en papel
<<extend>>
<<extend>>
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 57
Captura de requisitos: proceso unificado
Enumerar Requisitos Candidatos
Lista de Características
Comprender el Contexto del Sistema Modelo de Dominio y/o del Negocio
Capturar los Requisitos Funcionales Modelo de Casos de Uso
Capturar los Requisitos no Funcionales Requisitos adicionales
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 58
Captura de requisitos
Capturar los Requisitos No Funcionales
Identificar características no funcionales del sistema
Restricciones de la plataforma
Seguridad
Rendimiento
Tiempos de acceso…
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 59
Captura de requisitos
Ejemplos
Lista de ejemplos:
Cajero automático
Ordenador de a bordo
Reloj digital
Venta de billetes de tren
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 60
Ejemplos
Cajero automático
Lista 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 ………
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 61
Ejemplos
Cajero automático
Identificar actores y CU. Describir brevemente los 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.
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 62
Ejemplos
Cajero automático
Describir el modelo de casos de uso: primera aproximación
Cliente
Sacar Dinero
Cajero Automático
R1, R2, R3
Ingresar Dinero
Hacer Transferencia
R1, R5
R1, R4
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 63
Ejemplos
Cajero automático
Primera aproximación
Flujo de eventos del caso de uso “Sacar Dinero”
Camino básico
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 y da el dinero solicitado.
Devuelve la tarjeta
10. Recoge la tarjeta.
11. Recoge el dinero y termina el caso de uso
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 64
Ejemplos
Cajero automático
Primera aproximación
Flujo de eventos del caso de uso “Ingresar Dinero”
Camino básico
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
3. Introduce el importe a ingresar 4. Abre el cajón depósito del dinero en metálico.
5. Introduce el dinero 6. El sistema contabiliza dicho dinero y comprueba si coincide con el importe.
7. Notifica al usuario que el ingreso se ha realizado.
8. Devuelve la tarjeta.
9. Recoge la tarjeta y fin del caso de uso
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 65
Ejemplos
Cajero automático
Flujo de eventos del caso de uso “Ingresar Dinero”
Camino básico
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
3. Introduce el importe a ingresar
4. Abre el cajón depósito del dinero en metálico.
5. Introduce el dinero 6. El sistema contabiliza dicho dinero y comprueba si coincide con el importe.
7. Notifica al usuario que el ingreso se ha realizado.
8. Devuelve la tarjeta.
9. Recoge la tarjeta y fin del caso de uso
Flujo de eventos del caso de uso “Sacar Dinero”
Camino básico
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 y da el dinero solicitado.
Devuelve la tarjeta
10. Recoge la tarjeta.
11. Recoge el dinero y termina el caso de uso
Fu
ncio
na
lidad
co
mp
art
ida
!!!
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 66
Ejemplos
Cajero automático
Flujo de eventos del caso de uso “Validar Cliente”
Camino básico
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 y termina el caso de uso.
Caminos alternativos
Evento 3. El cliente cancela la transacción
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
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 67
Ejemplos
Cajero automático
Diagrama de estados del caso de uso “validar usuario”
Esperando clave
entry/ visualizar (pin)
do/ esperar (pinCliente)
Validando clave
do/ validar (nºtarjeta, clave)
exit/ n=n+1
OperacionCancelada
ClaveValidada[datos_correctos] / n=0;
Presentar OpcionesDisponibles
tarjeta_introducida
ClaveValidada
[NO datos_correctos AND n<3]
/mostrar (Clave Incorrecta, por favor…)
ClaveValidada
[ NO datos_correctos AND n=3 ]
/tragar_tarjeta
claveIntroducida
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 68
Ejemplos
Cajero automático
Flujo de eventos del caso de uso “Sacar Dinero”
Camino básico
ACTOR SISTEMA
1. Selecciona la operación de Reintegro
2. Pide la cantidad a retirar
3. Introduce la cantidad requerida 4. Procesa la petición y da el dinero solicitado.
5. Devuelve la tarjeta.
6. Recoge la tarjeta.
7. Recoge el dinero y termina el caso de uso
Caminos alternativos
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.
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 69
Ejemplos
Cajero automático
Supongamos que la descripción del caso de uso “ingresar dinero” es: 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
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 70
Ejemplos
Cajero automático
Flujo de eventos del caso de uso “Ingresar Dinero”
Camino básico
ACTOR SISTEMA
1. Selecciona la operación de Ingreso 2. Pide la cantidad a ingresar
3. Introduce el importe a ingresar
4. Abre el cajón depósito del dinero en metálico.
5. Introduce el dinero 6. El sistema contabiliza dicho dinero y comprueba si coincide con el importe.
7. Notifica al usuario que el ingreso se ha realizado.
8. Devuelve la tarjeta.
9. Recoge la tarjeta y fin del caso de uso
Camino alternativo
Evento 6. Notifica al usuario que la cantidad no coincide con el dinero introducido y permite que se repita la operación desde el principio.
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 71
Ejemplos
Cajero automático
Diagrama de estados del caso de uso “ingresar dinero”
Esperando importe a ingresar
entry/ mostrar (“Introduzca importe”)
do/ esperar (importe)
Esperando dinero metálico
Entry/ abrirCajon()
Exit/ cerrarCajón()
do/ Esperar ()
OperacionCancelada
Dinero Introducido
Opción “Ingreso” seleccionada
CantidadesValidadas [NOT OK]
/ mostrar (“Clave Incorrecta, por favor…”)
CantidadesValidadas [OK]
/ mostrar (“Operación finalizada con éxito”)
Importe Introducido
Validando cantidades
do/ Validar ()
OperacionCancelada
Esperando recoger tarjeta
Entry/ ExpulsarTarjeta;
Mostrar (“Recoja su tarjeta”)
do/ Esperar ()
EsperandoRecogerDinero
Entry/abrirCajon();
Mostrar(“Retire su dinero”)
Exit/ cerrarCajon()
do/ Esperar ()
Dinero Retirado
Tarjeta Retirada / mostrar(“Introduzca su tarjeta”)
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 72
Ejemplos
Cajero automático
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.
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 73
Ejemplos
Cajero automático
Flujo de eventos del caso de uso “Realizar transferencia”
Camino básico
ACTOR SISTEMA
1. Selecciona la operación de Transferencia
2. Pide la cantidad a transferir
3. Introduce la cantidad 4. Pide el número de cuenta
5. Introduce el número de cuenta 6. El sistema comprueba que existe saldo suficiente en la cuenta del cliente.
7. El sistema realiza un ingreso sobre la cuenta destino.
8. Se informa al cliente de que la operación se ha realizado satisfactoriamente.
9. Se expulsa la tarjeta
10. Recoge la tarjeta 11. El sistema vuelve a la situación inicial del cajero y fin del caso de uso
Caminos alternativos
Evento 3,5. El actor puede cancelar.
Evento 6. Si no existe saldo suficiente se informará que no es posible realizar la operación.
Evento 7. Si ocurre algún problema con el ingreso se informará que no se ha realizado.
Evento 10. Si el actor no recoge la tarjeta, el cajero automático tragará la tarjeta.
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 74
Ejemplos
Cajero automático
Estructurar el modelo de casos de uso: aproximación final
Cliente
Sacar Dinero
Cajero Automático
R2, R3
Ingresar Dinero
Hacer Transferencia
R5
R4
Validar Cliente
<< include >>
<< include >>
<< include >>
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 75
Ejemplos
Reloj digital
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, visualizar 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. Prepare un diagrama de estados del reloj.
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 76
Ejemplos
Reloj digital
Visualizando hora
Do/ Reloj ()
Cambiando hora
Do/ EsperarCambio ()
Cambiando minutos
Do/ EsperarCambio ()
Botón A pulsado Botón A pulsado
Botón A pulsado
Botón B pulsado / AvanzaH () Botón B pulsado / AvanzaM ()
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 77
Ejemplos
Semáforo
Un semáforo de circulación con el funcionamiento básico de dar paso a los coches y dar paso a los peatones, de forma cíclica, tiene un visor para los coches y otro visor para los peatones.
La secuencia cíclica de colores para el visor de los coches es Rojo, Verde, Ambar.
La secuencia para el visor de peatones es Rojo, Verde, Verde Intermitente.
El tiempo en el que el semáforo está en cada estado no tiene por qué ser siempre el mismo.
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 78
Ejemplos
Ordenador de a bordo
El ordenador de a bordo de un automóvil tiene la siguiente especificación: 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.
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 79
Ejemplos
Ordenador de a bordo
Realizando Chq Arranque
Entry : Encender Testigo ( Chk )
Do: Chequar Arranque
Realizando Chq Arranque
Entry/ : Encender Testigo ( Chk )
Do/ Chequar Arranque
Chequeo Terminado
[NOT anomalia AND cinturones_abrochados ]
Llave introducida
Esperando Arranque
Entry : Encender Testigo (Arranque)
Esperando Arranque
Entry/ : Encender Testigo (Arranque)
Do/ Esperar (Arranque)
Esperando Retirada llave
Entry (GRAVE)
Esperando Retirada llave
Entry/ Encender Testigo (GRAVE)
Do/ Esperar (Llave)
Esperando Pulsar OK
Entry : Encender Testigo (OK)
Esperando Pulsar OK
Entry/ : Encender Testigo (OK)
Do/ Esperar (OK) Esperando Abrochar
Cintur ó n
Entry : Encender Testigo AbrocharCintur ó n )
Esperando Abrochar Cintur ó n
Entry/ : Encender Testigo ( AbrocharCintur ó n )
Do/ Esperar (AbrocharCintur)
Veh í culo Arrancado/Encender Testigo (Habitual)
Chequeo Terminado
[NOT anomalia AND NOT cinturones_abrochados ]
Cinturones
Abrochados Chequeo Terminado
[NOT anomalia grave] Tecla OK pulsada
Chequeo Terminado
[ anomalia grave]/ BloquearMotor ()
Llave retirada/ ApagarOdenador
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 80
Ejemplos
Venta de billetes
La empresa de Transportes Ferroviarios (TRAFER) desea crear una nueva APLICACIÓN SOFTWARE que permita la Venta de billetes en RUTA (VIRUTA). Con esta nueva aplicación, un viajero puede subir al tren y comprar el billete dentro del mismo sin necesidad de pasar previamente por ventanilla. Tras una entrevista con el personal de TRAFER, se ha conseguido la siguiente información relativa al proceso de venta de billetes:
El revisor, a través de VIRUTA, registrará los datos del viaje a realizar seleccionando la estación de origen y destino, que le diga el viajero. La aplicación asignará la fecha y hora del sistema.
A partir de dicha información, VIRUTA comprobará la existencia de algún descuento en la tarifa de descuentos de calendario ("días azules, dorados o rojos y horas punta y valle"). Esta labor la realiza automáticamente el sistema a partir de los datos del viaje puesto que conoce la fecha y hora del mismo. A continuación calcula el precio del billete, consultando la tarifa de precios.
Posteriormente el revisor introduce el número de billetes a emitir y VIRUTA calculará entonces el importe total. Hay que aclarar que una venta sólo puede realizarse para el mismo origen, destino, fecha y hora de salida.
Finalmente, se imprime un único justificante donde se recogen el número de billetes solicitados, el importe total, el trayecto (estación de origen y destino, fecha y hora) y el descuento aplicado. El revisor recoge el billete y VIRUTA vuelve a la situación inicial.
Debido a que la aplicación va instalada en una PDA con impresora, y dada su reducida capacidad de disco, se ha acordado con el personal de TRAFER, que desde la aplicación VIRUTA, el revisor pueda ordenar la descarga de los datos de las ventas realizadas. Para la realización de esta descarga, la aplicación solicitará al revisor que se identifique. Cuando termina la descarga, VIRUTA lo indicará mediante un mensaje de confirmación. El revisor acepta la confirmación y VIRUTA vuelve a la situación inicial.
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 81
Ejemplos Venta de billetes – Especificación de requisitos
FUNCIONES BÁSICAS R1.1. Grabar la venta actual (productos comprados por el cliente)
R1.2. Calcular el total de la venta actual incluidos los impuestos
R1.3. Capturar información del producto usando el código de barras o tecleando el código del producto.
R1.4. Reducir la cantidad en inventario cuando se realice la venta
R1.5. Registrar ventas realizadas
R1.6. El dependiente debe iniciar una sesión con identificador y clave para usar el sistema
R1.7. Mostrar descripción y precio del producto almacenado
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 82
Ejemplos Venta de billetes – Especificación de requisitos
FUNCIONES DE PAGO R2.1. Manejar pagos en metálico, tomar cantidad ofrecida y calcular el
cambio R2.2. Manejar pagos con tarjeta, capturar información de la tarjeta con
un lector y autorizar el pago vía módem.
OTRAS FUNCIONES
R3.1. Es necesario dar de alta dependientes nuevos en el puesto de venta y dar de baja aquellos que dejan de trabajar en caja.
R3.2. El puesto de venta es encendido y apagado cada día por el encargado de la sección. En el encendido, si la fecha y hora no fueran correctas, se modificarían.
REQUISITOS NO FUNCIONALES
Fácil de usar, Tiempo de respuesta corto, Plataforma, Precio al público Interfaz (gráfica, con colores, ventanas, facilitar navegación por
teclado,…)
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 83
Ejemplos
Venta de billetes – Modelo de Dominio
PTO. VENTA
PRODUCTO
DEPENDIENTE
INVENTARIO
Nº UNIDADES
PRODUCTOS
VENDIDOS
VENTA PAGO
IMPORTE
TOTAL
CODIGO
PRECIO
DESCRIPCIÓN
registra
Se realiza
TARJETA METÁLICO
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 84
Ejemplos
Venta de billetes – Modelo de Negocio
Realizar
Pago
Iniciar sesión
Registrar
Venta
Encender
Gestionar usuarios
Apagar
Dependiente
Encargado
Admin .
Cliente
Punto de venta
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 85
Ejemplos
Venta de billetes – Modelo de Negocio
CLIENTE
Iniciar
Venta
DEPENDIENTE
Intro Cod.
Producto
Actualizar
inventario
Dar descripción
y precio Solicitar
Importe
total
Finalizar
venta
Pagar
Cobrar
SISTEMA
Análisis e Ingeniería de Requisitos – Tema 3 www.kybele.urjc.es AIR - 86
Ejemplos
Venta de billetes – Modelo de Casos de Uso
Iniciar sesión
Encender
Gestionar usuarios
Apagar
Dependiente
Encargado
Admin .
Punto de venta R1.1, R1.2, R1.3,
R1.4, R1.5, R1.7,
R2.1, R2.2 Realizar Venta
R1.6
R3.2
R3.1