Proceso Unificado: Captura de Requisitos · Ingeniería del Software de Gestión - Bibliografía...

Ingeniería del Software de Gestión www.kybele.es

Tema XIII:Proceso Unificado: Captura de Requisitos

Verónica A. BollatiIngeniería del Software de Gestión


AIR -

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.


Índice

Visión general

Diagramas UML

Proceso de captura de requisitos Enumerar requisitos candidatos

Comprender el contexto del sistema

Capturar los requisitos funcionales

Capturar los requisitos no funcionales

Ejemplos


Captura de requisitosVisión general

Requisitos

Diseño

Implementación

Prueba

Análisis

PlanificaciónAnál. RiesgosPreparación

ElaboraciónConstrucciónVerificación

Transición

FasesFlujos 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)


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 requisitosVisión general


Captura de requisitosDiagramas 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


Captura de requisitos

Objetivos y artefactos 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


Captura de requisitosEnumerar requisitos candidatos

Definición de requisito: Características que deben incluirse en un sistema o aplicación

Requisito Funcional Funcionalidad 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.



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



Ejemplo

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



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




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




Modelo de NegocioDetermina qué procesos formarán parte del

sistema. Para cada proceso: Trabajadores, responsabilidades,

operaciones

Se representa mediante un diagrama de casos de uso: Cada trabajador se representa como un actor

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



Diagramas de Casos de Uso

Actor: Conjunto coherente de roles o papeles que desempeñan los usuarios

Un usuario no siempre es un actor

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



Diagramas de Clases

Clase: Descripción de un conjunto de objetos que comparten atributos,

operaciones, relaciones y semántica

Aspecto del diagramanombre

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

Aspecto del diagrama (opción I)

actividad[condición]

[condición]




Aspecto del diagrama (opción II)

actividad[condición]

[condición]

Calle a Calle b Calle c



Ejemplo – Contexto del sistema

Modelo de Dominio - 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.




Modelo de dominio: diagrama de clases (simplificado)

Perfil de ADN

Marcadores

PacienteBiólogorealiza pertenece




Modelo de negocio: diagrama de casos de uso

Realizar Perfil

Autorizar

Biólogo

Responsable

Entregar Perfil

Donar Muestra

Paciente




Modelo de negocio: diagrama de actividad

22

AutorizarDonar

MuestraRealizar

Perfil

Entregar

Perfil

Responsable Paciente Biólogo



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

24




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

25




Identificar actores y casos de usoPara: 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



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.



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



Ejemplo – Identificar actores y CU

Describir el modelo de casos de uso

Biólogo

Registrar Perfil

Aplicación de almacenamiento

de perfiles de ADN

R1, R2, R3




Priorizar los casos de uso:

Casos de uso a desarrollar en las primeras iteraciones

Identificar cuales son necesarios y cuales pueden dejarse para más tarde

Casos de uso significativos

En función del riesgo asociado a cada requisito funcional




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




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




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

Estado inicial como pre-condición

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 post-condiciones

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




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


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.



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




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




ElementosActividad: 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




Elementos gráficos

Ejemplo

EstadoE.Inicial

E.Final Transición

Estado

Sucesos

Estados

T. autom.

en el paro en activo

jubilado

contratar

perder empleo

jubilarsejubilarse




La acción se considera instantánea

Acciones, eventos y condiciones:

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




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)




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

Diseño físico: descripción y construcción del prototipo ejecutable pero con acciones nulas (validación y depuración)




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




Diagrama de casos de uso: Generalización

Usuario

IdentificarAdm.

AltaUsuario

IdentificarUsuario

Administrador

BajaUsuario




Diagrama de casos de uso: Relaciones

Inclusión

Extensión

45

Cliente

Hacertransfer.

Sacardinero

ConsultarSaldo

<<include>>

<<include>>

Cliente

Sacardinero

Ingresardinero

Obtener reciboen papel

<<extend>>

<<extend>>



Capturar los Requisitos No Funcionales

Identificar características no funcionales del sistema

Restricciones de la plataforma

Seguridad

Rendimiento

Tiempos de acceso…

47



Ejemplos

Lista de ejemplos:

Cajero automático

Ordenador de a bordo

Reloj digital

Venta de billetes de tren


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

………


Ejemplos

Cajero automático

Modelo de Dominio: Glosario de Términos Validar Cliente: función que permite identificar al cliente de

manera única por medio de la introducción de su tarjeta y su PIN

Saldo de Cuenta: importe disponible que tiene el cliente en su cuenta

Límite diario: importe que el usuario puede retirar diariamente

Transferencia: pasar el dinero de una cuenta a otra cuenta, donde las cuentas pueden pertenecer a diferentes clientes

Ingreso: sumar un importe a la cuenta del cliente en cuestión Retiro: sacar dinero de una cuenta, siempre teniendo en

cuenta el límite diario………


Ejemplos

Cajero automático

Modelo de Dominio: Diagrama de clases

Cuenta

Egreso

Operación

TransferenciaIngreso

Cliente

Movimientos


Ejemplos

Cajero automático

Modelo de Negocios: 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


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.


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


Ejemplos

Cajero automático

Primera aproximación

Flujo de eventos del caso de uso “Ingresar Dinero”

Camino básico

ACTOR SISTEMA





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


Ejemplos

Cajero automático


Camino básico

ACTOR SISTEMA





3. Introduce el importe a ingresar

4. Abre el cajón depósito del dinero en metálico.






Camino básico

ACTOR SISTEMA





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



Fu

ncio

na

lidad

co

mp

art

ida

!!!


Ejemplos

Cajero automático

Flujo de eventos del caso de uso “Validar Cliente”

Camino básico

ACTOR SISTEMA




5. Presenta las opciones de operaciones disponibles y termina el caso de uso.


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


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


Ejemplos

Cajero automático


Camino básico

ACTOR SISTEMA

1. Selecciona la operación de Retiro 2. Pide la cantidad a retirar

3. Introduce la cantidad requerida 4. Procesa la petición y da el dinero solicitado.





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.


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


Ejemplos

Cajero automático


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.





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.


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


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.


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


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.


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


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 sub-modos: 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 sub-modos, 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.


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 ()


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.


Ejemplos


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.


Ejemplos


Realizando ChqArranque

Entry: Encender Testigo (Chk)

Do: Chequar Arranque

Realizando ChqArranque

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ónEntry: 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

[anomaliagrave]/BloquearMotor ()

Llave retirada/ApagarOdenador


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.


EjemplosVenta 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


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


Ejemplos

Venta de billetes – Modelo de Dominio

PTO. VENTA

PRODUCTO

DEPENDIENTE

INVENTARIO

Nº UNIDADES

PRODUCTOS

VENDIDOS

VENTAPAGO

IMPORTE

TOTAL

CODIGO

PRECIO

DESCRIPCIÓN

registra

Se realiza

TARJETAMETÁLICO


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


Ejemplos

Venta de billetes – Modelo de Negocio

CLIENTE

Iniciar

Venta

DEPENDIENTE

Intro Cod.

Producto

Actualizar

inventario

Dar descripción

y precioSolicitar

Importe

total

Finalizar

venta

Pagar

Cobrar

SISTEMA


Ejemplos

Venta de billetes – Modelo de Casos de Uso

Iniciar sesión

Encender

Gestionar usuarios

Apagar

Dependiente

Encargado

Admin.

Punto de ventaR1.1, R1.2, R1.3,

R1.4, R1.5, R1.7,

R2.1, R2.2 Realizar Venta

R1.6

R3.2

R3.1

Proceso Unificado: Captura de Requisitos · Ingeniería del Software de Gestión - Bibliografía...

Documents

Transcript of Proceso Unificado: Captura de Requisitos · Ingeniería del Software de Gestión - Bibliografía...