Casos de Uso Detallados

Los casos de uso que tomaremos en cuenta en este prototipo son los siguientes:

  • Iniciar sesión
  • Cerrar sesión
  • Insertar producto
  • Modificar datos de un producto
  • Establecer datos económicos
  • Insertar Gastos Adicionales
  • Insertar Productos No Vendidos
  • Insertar zonas de una provincia
  • Modificar zonas de una provincia
  • Eliminar zonas de una
  • Consultar flores necesarias para reservas
  • Consultar economía
  • Establecer los datos de la empresa
  • Insertar Cliente
  • Modificar Cliente
  • Realizar una reserva
  • Modificar una reserva
  • Realizar una venta
  • Modificar una venta
  • Hacer una Búsqueda
  • Imprimir Factura
  • Imprimir Ticket
  • Capturar datos de zonas de provincia desde fichero

1. Iniciar Sesión

CASO DE USO: Iniciar sesión.
IDENTIFICADOR: CU01-ISES
ACTORES: Gerente
VERSIÓN: 2.11
DESCRIPCIÓN: El usuario se identifica en el sistema para tener acceso a las funciones concretas que tiene el gerente.
ESTADO: Revisado.
FRECUENCIA: Muy alta.
PRECONDICIONES:

  • 1. Debe de haberse establecido la contraseña de la aplicación para poder acceder al modo gerente.

SUPOSICIONES:

  • 1. Los usuarios que conocen la contraseña de entrada deberán de ser los únicos autorizados para ello.

CURSO NORMAL DE EVENTOS:

  • 1. El usuario introduce la contraseña y valida la identificación.
  • 2. EL sistema comprueba si la contraseña introducida es correcta.
  • 3. El sistema permitirá ahora nuevas funcionalidades acordes con el modo gerente, y la opción de cerrar la sesión para volver al modo vendedor.

CURSO ALTERNATIVO DE EVENTOS:

  • Sección 2.1. Si la contraseña no es la establecida, el sistema deberá mostrar un mensaje de error. Se indicará que se vuelva a intentar el acceso hasta un máximo de tres veces, tras lo cual el sistema se bloqueará por seguridad.

POSTCONDICIONES:

  • 1. El sistema queda en modo gerente, permitiendo varias opciones que son exclusivas de dicho modo.
  • 2. Si se ha realizado con éxito, se añadirá una línea nueva a un fichero log del sistema con la fecha de entrada y el tipo de acción (cierre de sesión).

HISTÓRICO DE CAMBIOS:

  • 27/11/06 – Antonio: Pequeños cambios - versión 2.11
  • 21/11/06 – Antonio: Inserción de nueva plantilla de C.U. y revisión hasta versión 2.1

2. Cerrar Sesión

CASO DE USO: Cerrar sesión.
IDENTIFICADOR: CU02-CSES
ACTORES: Gerente
VERSIÓN: 2.11
DESCRIPCIÓN: El usuario quiere finalizar la sesión abierta en modo gerente.
ESTADO: Revisado.
FRECUENCIA: Baja.
PRECONDICIONES:

  • 1. El sistema debe de estar abierto en modo gerente.

SUPOSICIONES:

  • 1. El gerente quiere continuar la sesión, pero en modo vendedor. Si lo que quiere es cerrar el sistema podrá hacerlo sin recurrir a cerrar la sesión.

CURSO NORMAL DE EVENTOS:

  • 1. El usuario valida el cierre de sesión.
  • 2. El sistema cierra la sesión abierta y abre la sesión en modo vendedor.

POSTCONDICIONES:

  • 1. Se continuará con la sesión en modo vendedor.
  • 2. Si se ha cerrado sesión con éxito, se añadirá una línea nueva a un fichero log del sistema con la fecha de entrada y el tipo de acción (cierre de sesión).

HISTÓRICO DE CAMBIOS:

  • 27/11/06 – Antonio: Pequeños cambios - versión 2.11
  • 21/11/06 – Antonio: Inserción de nueva plantilla de C.U. y revisión hasta versión 2.1

3. Insertar Producto

CASO DE USO: Insertar producto.
IDENTIFICADOR: CU03-IPRO
ACTORES: Gerente
VERSIÓN: 2.1
DESCRIPCIÓN: El gerente introduce los datos característicos de un nuevo producto en el sistema.
ESTADO: Revisado.
FRECUENCIA: Media.
PRECONDICIONES:

  • 1. El gerente debe estar identificado en el sistema.

CURSO NORMAL DE EVENTOS:

  • 1. El gerente rellena el formulario con los datos oportunos, incluyendo el nombre, la categoría, proveedor, precio de compra, fecha de caducidad (para productos perecederos), observaciones importantes del producto (como por ejemplo, de qué productos están compuestas las composiciones que vendemos como ramos o centros, maceta de interior o exterior, peso, tamaño máximo, secano o regadío, etc.), número de existencias, valor de umbral mínimo (-1 si no queremos hacer funcionar dicha función), época del año de venta y la dirección de una foto representativa.
  • 2. El sistema calcula automáticamente el precio de venta del producto a partir del precio de compra, margen de beneficios, IVA y recargo de equivalencia.
  • 3. El sistema muestra el precio de venta del producto obtenido automáticamente.
  • 4. El gerente valida los datos introducidos.
  • 5. El sistema comprueba que el nombre introducido para el producto nuevo no existe en el sistema y que ningún otro campo imprescindible este vacío.
  • 6. El sistema muestra un mensaje de conformidad por pantalla, almacenando los datos introducidos.

CURSO ALTERNATIVO DE EVENTOS:

  • Sección 3. Si el precio de venta del producto obtenido no es adecuado a nuestro gusto o se desea redondear el precio obtenido, se podrá modificar dicho valor.
  • Sección 4. Si el gerente cancela antes de este punto, el sistema desecha los datos introducidos.
  • Sección 5. Si algunos datos no se introdujeron correctamente, el sistema lo notificará, volviendo al punto 1 pero con los datos que el gerente acaba de introducir, para que pueda modificar los datos erróneos o introducir datos obligatorios.

POSTCONDICIONES:

  • 1. Los datos introducidos del nuevo producto serán almacenados en un registro de la base de datos.

HISTÓRICO DE CAMBIOS:

  • 21/11/06 – Antonio: Inserción de nueva plantilla de C.U. y revisión hasta versión 2.1

4. Modificar Datos de un Producto

CASO DE USO: Modificar datos de los productos.
IDENTIFICADOR: CU04-MPRO
ACTORES: Gerente
VERSIÓN: 2.21
DESCRIPCIÓN: El gerente introduce los datos nuevos que quiera modificar de un producto seleccionado entre los existentes en el sistema.
ESTADO: Revisado.
FRECUENCIA: Baja.
PRECONDICIONES:

  • 1. El gerente debe haberse identificado en el sistema.
  • 2. Se debe hacer una búsqueda del producto al que nos queremos referir (incluye caso de uso CU20-BUSQ).

CASOS DE USO QUE INCLUYE: CU20-BUSQ
SUPOSICIONES:

  • 1. La búsqueda que se ha realizado debe de haber tenido éxito.

CURSO NORMAL DE EVENTOS:

  • 1. El gerente modificará los datos que crea conveniente en el formulario mostrado del producto que hemos seleccionado (datos informativos y datos de estado).
  • 2. En caso de que haya sido modificado el precio de compra, el sistema calcula automáticamente el precio de venta del producto a partir del precio de compra, margen de beneficios, IVA y recargo de equivalencia.
  • 3. En caso de que haya sido calculado de nuevo el precio de venta de forma automática, el sistema muestra el precio de venta del producto obtenido automáticamente.
  • 4. El gerente valida los datos introducidos.
  • 5. El sistema comprueba si el nombre del producto ha sido modificado, y en ese caso, comprueba que el nombre nuevo introducido para el producto no existe en el sistema y que ningún otro campo imprescindible este vacío.
  • 6. El sistema muestra un mensaje de conformidad por pantalla y almacena de nuevo los datos introducidos.

CURSO ALTERNATIVO DE EVENTOS:

  • Sección 3. Si el precio de venta del producto obtenido no es adecuado a gusto del gerente o lo desea redondear, se podrá modificar dicho valor.
  • Sección 4. Si el gerente cancela antes de este punto, el sistema desecha los datos modificados.
  • Sección 6.1. Si algunos datos no se introdujeron correctamente, el sistema lo notificará, volviendo al punto 1 pero con los datos que el gerente acaba de introducir, para que pueda modificar los datos erróneos, o introducir datos obligatorios.
  • Sección 6.2. Si se ha modificado el estado del producto poniéndolo en eliminado, el sistema lo comunicará y el producto dejará de estar activo, pero seguirá almacenado por si se vuelve a requerir activarlo de nuevo.

POSTCONDICIONES:

  • 1. Los datos modificados del producto serán guardados en el mismo registro de la base de datos.
  • 2. Si el estado del producto es “eliminado”, el producto dejará de estar activo en el sistema, pero no será eliminado de la base de datos.
  • 3. Los cambios en el precio del producto sólo afectan a las reservas y ventas posteriores al cambio, no realizándose la actualización del precio total de ventas y reservas anteriores al cambio.

HISTÓRICO DE CAMBIOS:

  • 27/11/06 – Antonio: Pequeños cambios - versión 2.21
  • 24/11/06 – Carlos: Inserción de un nuevo curso alternativo para la sección 3 y 4. Se obtiene la versión 2.2.
  • 21/11/06 – Antonio: Inserción de nueva plantilla de C.U. y revisión hasta versión 2.1

5. Establecer Datos Económicos

CASO DE USO: Establecer datos económicos.
IDENTIFICADOR: CU05-EDEC
ACTORES: Gerente
VERSIÓN: 1.1
DESCRIPCIÓN: El gerente establece el margen de beneficios (un valor común que será el tanto por ciento que ganaremos por cada producto vendido), el valor de IVA + recargo de equivalencia y/o precio por mano de obra en la elaboración de una composición de productos.
ESTADO: Revisado.
FRECUENCIA: Muy baja.
PRECONDICIONES:

  • 1. El gerente debe haberse identificado en el sistema.
  • 2. La primera vez que se accede al caso de uso deberá existir un valor inicial determinado para cada campo, por definición.
  • 3. Si ya se habían establecido los datos con anterioridad, el caso de uso parte del formulario inicial relleno con dichos datos.

SUPOSICIONES:

  • 1. Los valores a introducir serán valores enteros positivos.
  • 2. El gerente conoce el valor exacto de esos datos.

CURSO NORMAL DE EVENTOS:

  • 1. El gerente rellena el formulario con los datos oportunos, indicando un margen de beneficios para la empresa, estableciendo a cada categoría de productos su correspondiente IVA + recargo de equivalencia y estableciendo el precio de mano de obra en la elaboración de una composición de productos.
  • 2. El gerente valida los datos introducidos.
  • 3. El sistema comprueba si los datos introducidos son válidos y que ningún campo imprescindible este vacío.
  • 4. El sistema muestra un mensaje de conformidad por pantalla, almacenando los datos introducidos.

CURSO ALTERNATIVO DE EVENTOS:

  • Sección 2. Si el gerente cancela la introducción de valores antes de este punto, el sistema descarta los datos introducidos.
  • Sección 3. Si algunos datos no se introdujeron correctamente, el sistema lo notificará, volviendo al punto 1 pero con los datos que el gerente acaba de introducir, para que pueda modificar los datos erróneos.

POSTCONDICIONES:

  • 1. Los cambios económicos realizados en un momento dado solo afectan a las reservas y ventas realizadas posteriormente a ese cambio.
  • 2. Si el valor de IVA impuesto a una categoría es del 7 %, su recargo de equivalencia correspondiente será del 1 %. Si el valor de IVA impuesto a una categoría es del 16 %, su recargo de equivalencia correspondiente será del 4 %.

HISTÓRICO DE CAMBIOS:

  • 21/11/06 – Antonio: Inserción de nueva plantilla de C.U. y revisión hasta versión 1.1

6. Insertar Gastos Adicionales

CASO DE USO: Insertar Gastos Adicionales.
IDENTIFICADOR: CU06-IGAD
ACTORES: Gerente
VERSIÓN: 2.1
DESCRIPCIÓN: El gerente introduce una cantidad positiva que representa el gasto adicional producido durante un día señalado.
ESTADO: Revisado.
FRECUENCIA: Alta.
PRECONDICIONES:

  • 1. El gerente debe de haberse identificado en el sistema.

SUPOSICIONES:

  • 1. La cantidad a introducir es un número positivo que el gerente ha calculado previamente, representando el valor total del conjunto de gastos adicionales no previstos en el sistema.

CURSO NORMAL DE EVENTOS:

  • 1. El gerente introduce el día, el mes y el año al que quiere hacer efectiva el gasto adicional.
  • 2. El sistema comprueba que la fecha introducida es válida.
  • 3. El gerente rellena el resto del formulario con los datos oportunos del gasto adicional (cantidad y descripción)
  • 4. El gerente valida los datos introducidos.
  • 5. El sistema comprueba si los datos introducidos son válidos y que ningún campo imprescindible este vacío.
  • 6. El sistema muestra un mensaje de conformidad por pantalla, almacenando los datos introducidos.

CURSO ALTERNATIVO DE EVENTOS:

  • Sección 3. Si existieran ya datos para ese día, se muestran en el formulario y el sistema permitiría modificarlos. El gerente tendría que sumar la cantidad a la que él ya posee y añadir su descripción a la ya existente.
  • Sección 4. Si el gerente cancela la introducción de un nuevo valor para los gastos adicionales producidos en un día antes de este punto, el sistema desecha los datos introducidos.
  • Sección 5. Si algunos datos no se introdujeron correctamente, el sistema lo notificará, volviendo al punto 1 pero con los datos que el gerente acaba de introducir, para que pueda modificar los datos erróneos.

POSTCONDICIONES:

  • 1. El gasto adicional producido que ha sido registrado pasará a formar parte de la contabilidad de la empresa.
  • 2. Los datos introducidos del nuevo gasto adicional serán almacenados en un registro de la base de datos, o si sustituyen a otro dato anterior se sustituirá su valor.

HISTÓRICO DE CAMBIOS:

  • 21/11/06 – Antonio: Inserción de nueva plantilla de C.U. y revisión hasta versión 2.1

7. Insertar Productos No Vendidos

CASO DE USO: Insertar productos no vendidos.
IDENTIFICADOR: CU07-IPNV
ACTORES: Gerente
VERSIÓN: 2.1
DESCRIPCIÓN: El gerente introduce el producto que ha sido afectado, junto a la cantidad regalada o caducada, para que quede constancia en el sistema de que esos productos ya no existen en el almacén.
ESTADO: Revisado.
FRECUENCIA: Media.
PRECONDICIONES:

  • 1. El gerente debe de haberse identificado en el sistema.
  • 2. Para que se pueda eliminar productos del sistema debido a regalos o productos caducados, se debe tener almacenado una cantidad del producto igual o mayor de la que se quiere indicar.
  • 3. Se debe de hacer una búsqueda del producto al que nos queremos referir (incluye caso de uso CU20-BUSQ).

CASOS DE USO QUE INCLUYE: CU20-BUSQ
SUPOSICIONES:

  • 1. La búsqueda que se ha realizado debe de haber tenido éxito.

CURSO NORMAL DE EVENTOS:

  • 1. El gerente rellena el formulario con los datos oportunos. Se indicará la cantidad que ha sido retirado del almacén por regalo o por caducidad del producto anteriormente seleccionado.
  • 2. El gerente valida los datos introducidos.
  • 3. El sistema comprueba si los datos introducidos son válidos y que ningún campo imprescindible este vacío.
  • 4. El sistema muestra un mensaje de conformidad por pantalla, almacenando los datos modificados.

CURSO ALTERNATIVO DE EVENTOS:

  • Sección 2. Si el gerente cancela antes de este punto, el sistema desecha los datos introducidos.
  • Sección 3. Si no se introdujo el dato correctamente el sistema lo notificará, volviendo al punto 1 pero con los datos que el gerente acaba de introducir, para que pueda modificarlos.

POSTCONDICIONES:

  • 1. Al insertar la cantidad, ésta se restará de la que tenía anteriormente almacenada el producto seleccionado.
  • 2. Al insertar un producto no vendido, quedará constancia en el sistema de esta incidencia como si fuese una venta que se ha producido por la que no se ha obtenido ingreso alguno. Esta incidencia quedará almacenada en la Base de Datos.

HISTÓRICO DE CAMBIOS:

  • 21/11/06 – Antonio: Inserción de nueva plantilla de C.U. y revisión hasta versión 2.1

8. Insertar Zonas de una Provincia

CASO DE USO: Insertar zonas de una provincia.
IDENTIFICADOR: CU08-IZPR
ACTORES: Gerente
VERSIÓN: 2.2
DESCRIPCIÓN: Insertar en el sistema una zona de la provincia o un barrio donde se pueden enviar productos a domicilio.
ESTADO: Revisado.
FRECUENCIA: Baja.
PRECONDICIONES:

  • 1. El gerente debe de haberse identificado en el sistema.

ES EXTENDIDO POR: CU23-CDDF
SUPOSICIONES:

  • 1. El código postal introducido debe de pertenecer a la provincia donde trabajamos.
  • 2. El precio por el envío a domicilio a una determinada zona vendrá determinado por el número de kilómetros a recorrer desde el origen a dicha zona.

CURSO NORMAL DE EVENTOS:

  • 1. El gerente rellena el formulario con los datos oportunos. Se indicará la zona de la provincia o barrio, el código postal que tiene asociado y el precio por el envío a domicilio a dicha zona.
  • 2. El gerente valida los datos introducidos.
  • 3. El sistema comprueba que el nombre introducido para la zona de la provincia o barrio nuevo no existe en el sistema y que ningún otro campo imprescindible este vacío.
  • 4. El sistema muestra un mensaje de conformidad por pantalla y almacena los datos introducidos.

CURSO ALTERNATIVO DE EVENTOS:

  • Sección 2. Si el gerente cancela la introducción de una nueva zona de la provincia o barrio antes de este punto, el sistema desecha los datos introducidos.
  • Sección 3. Si algunos datos no se introdujeron correctamente, el sistema lo notificará, volviendo al punto 1 pero con los datos que el gerente acaba de introducir, para que pueda modificar los datos erróneos.

POSTCONDICIONES:

  • 1. Los datos introducidos de una nueva zona de la provincia serán almacenados en un registro de la base de datos.

HISTÓRICO DE CAMBIOS:

  • 24/11/06 – Carlos: Inserción de los casos de uso que extiende éste caso de uso. Se actualiza a la versión 2.2
  • 21/11/06 – Antonio: Inserción de nueva plantilla de C.U. y revisión hasta versión 2.1

9. Modificar Zonas de una Provincia

CASO DE USO: Modificar zonas de una provincia.
IDENTIFICADOR: CU09-MZPR
ACTORES: Gerente
VERSIÓN: 2.1
DESCRIPCIÓN: El gerente modificará el valor de cualquier dato referente a una localidad o barrio existente en el sistema.
ESTADO: Revisado.
FRECUENCIA: Muy baja.
PRECONDICIONES:

  • 1. El gerente debe de haberse identificado en el sistema.
  • 2. Se debe de hacer una búsqueda de la zona que queramos modificar (incluye caso de uso CU20-BUSQ).

CASOS DE USO QUE INCLUYE: CU20-BUSQ
SUPOSICIONES:

  • 1. La búsqueda que se ha realizado debe de haber tenido éxito.

CURSO NORMAL DE EVENTOS:

  • 1. El gerente modificará los datos que sean necesarios de dicho barrio o zona de la provincia seleccionada.
  • 2. El gerente valida los datos modificados.
  • 3. El sistema comprueba si se ha modificado el nombre de la zona de provincia o barrio, y en este caso, comprueba que el nombre introducido no existe en el sistema y que ningún otro campo imprescindible este vacío.
  • 4. El sistema muestra un mensaje de conformidad por pantalla y almacena de nuevo los datos introducidos.

CURSO ALTERNATIVO DE EVENTOS:

  • Sección 2. Si el gerente cancela la modificación de zonas de la provincia o barrios antes de este punto, el sistema desecha los datos introducidos.
  • Sección 3. Si algunos datos no se introdujeron correctamente, el sistema lo notificará, volviendo al punto 1 pero con los datos que el gerente acaba de introducir, para que pueda modificar los datos erróneos.

POSTCONDICIONES:

  • 1. Los datos modificados de la zona de la provincia serán guardados en el mismo registro de la base de datos abierto con anterioridad.
  • 2. Los cambios en el precio del envío a domicilio solo afectan a las reservas y ventas posteriores al cambio.

HISTÓRICO DE CAMBIOS:

  • 21/11/06 – Antonio: Inserción de nueva plantilla de C.U. y revisión hasta versión 2.1

10. Eliminar Zonas de una Provincia

CASO DE USO: Eliminar zonas de una provincia.
IDENTIFICADOR: CU10-EZPR
ACTORES: Gerente
VERSIÓN: 2.1
DESCRIPCIÓN: El gerente selecciona una zona de la provincia y la elimina del sistema.
ESTADO: Revisado.
FRECUENCIA: Muy baja.
PRECONDICIONES:

  • 1. El gerente debe de haberse identificado en el sistema.
  • 2. Se debe de hacer una búsqueda de la zona que queramos modificar (incluye caso de uso CU20-BUSQ).

CASOS DE USO QUE INCLUYE: CU20-BUSQ
SUPOSICIONES:

  • 1. La búsqueda que se ha realizado debe de haber tenido éxito.

CURSO NORMAL DE EVENTOS:

  • 1. El gerente valida la eliminación de la zona de la provincia o barrio.
  • 2. El sistema muestra un mensaje de conformidad por pantalla y elimina la zona seleccionada de la Base de Datos.

POSTCONDICIONES:

  • 1. El registro con los datos de la zona de la provincia que se quiere eliminar será suprimido de la base de datos.

HISTÓRICO DE CAMBIOS:

  • 21/11/06 – Antonio: Inserción de nueva plantilla de C.U. y revisión hasta versión 2.1

11. Consultar Flores Reservadas

CASO DE USO: Consultar flores reservadas.
IDENTIFICADOR: CU11-CFLO
ACTOR: Gerente
VERSIÓN: 2.1
DESCRIPCIÓN: El gerente introduce en el sistema la fecha deseada y el sistema le muestra la cantidad y el tipo de flores que, por ahora, están contenidas en las reservas y ventas activas que finalizan en esa fecha.
ESTADO: Revisado.
FRECUENCIA: Alta.
PRECONDICIONES:

  • 1. El gerente debe de haberse identificado en el sistema.

CURSO NORMAL DE EVENTOS:

  • 1. El gerente le indica al sistema la fecha deseada indicando día, mes y año.
  • 2. El sistema comprueba que la fecha introducida es válida.
  • 3. El sistema muestra por pantalla el número total y tipo de cada uno de los productos incluidos en alguna reserva o venta que finalice en la fecha indicada.

CURSO ALTERNATIVO DE EVENTOS:

  • Sección 3. Si no hay reservas o ventas para ese día en concreto, el sistema muestra un mensaje indicándolo.

POSTCONDICIONES:

  • 1. Se obtienen los datos relativos a los productos incluidos en las ventas o reservas que finalizan el día señalado.

HISTÓRICO DE CAMBIOS:

  • 21/11/06 – Antonio: Inserción de nueva plantilla de C.U. y revisión hasta versión 2.1

12. Consultar Economía

CASO DE USO: Consultar economía.
IDENTIFICADOR: CU12-CECO
ACTOR: Gerente
VERSIÓN: 2.3
DESCRIPCIÓN: El gerente indica el tipo de consulta (ingresos, gastos, beneficios o estadísticas varias) y un rango de fechas, y el sistema le muestra los datos requeridos referentes a la economía de la empresa.
ESTADO: Revisado.
FRECUENCIA: Media.
PRECONDICIONES:

  • 1. El gerente debe de haberse identificado en el sistema.

SUPOSICIONES:

  • 1. La fecha que se va a consultar es una fecha actual o futura, ya que para fechas pasadas no habrá reservas activas (las reservas una vez llegado el día indicado se transforman en ventas).

CURSO NORMAL DE EVENTOS:

  • 1. El gerente le indica al sistema la fecha deseada de inicio de la consulta indicando día, mes y año. También la fecha deseada de fin de la consulta y el tipo de consulta económica quiere realizar (ingresos, gastos, beneficios, estadísticas varias).
  • 2. El sistema comprueba que las fechas introducidas sean válidas.
  • 3. El sistema calcula y muestra por pantalla los datos deseados (ingresos, gastos, beneficios, estadísticas varias).

CURSO ALTERNATIVO DE EVENTOS:

  • Sección 2. Si no son válidas, el sistema las rechazará, volviendo al punto 1 para que el gerente subsane el error.
  • Sección 3. Si no ha habido todavía ningún dato de los requeridos en el rango de fechas seleccionado, el sistema muestra un mensaje indicándolo.

POSTCONDICIONES:

  • 1. Se obtiene por pantalla los datos (ingresos, gastos, beneficios, estadísticas varias) que pertenecen a las fechas introducidas.

HISTÓRICO DE CAMBIOS:

  • 27/11/06 – Antonio: Inserción de curso alternativo para sección 2 - versión 2.3
  • 24/11/06 – Carlos: Inserción de un nuevo paso normal de eventos (paso 2). Se genera la versión 2.2
  • 21/11/06 – Antonio: Inserción de nueva plantilla de C.U. y revisión hasta versión 2.1

13. Establecer Datos de la Empresa

CASO DE USO: Establecer los datos de la empresa.
IDENTIFICADOR: CU13-EDEM
ACTOR: Gerente
VERSIÓN: 3.1
DESCRIPCIÓN: El gerente introduce en el sistema los datos actuales de la empresa, rellenando un formulario que se le muestra.
ESTADO: Revisado.
FRECUENCIA: Muy baja.
PRECONDICIONES:

  • 1. El gerente debe de haberse identificado en el sistema.
  • 2. La primera vez que se accede al caso de uso deberá existir un valor inicial determinado para cada campo, por definición.
  • 3. Si ya se habían establecido los datos con anterioridad, el caso de uso parte del formulario inicial relleno con dichos datos.

SUPOSICIONES:

  • 1. Los valores a introducir serán valores fieles a la realidad.
  • 2. El gerente conoce el valor exacto de esos datos.

CURSO NORMAL DE EVENTOS:

  • 1. El gerente rellena el formulario con los datos oportunos de la empresa. Estos datos son nombre, dirección, nif, código postal, localidad, provincia, teléfono, teléfono móvil.
  • 2. El gerente valida los datos introducidos.
  • 3. El sistema comprueba si los datos introducidos son válidos y que ningún campo imprescindible este vacío.
  • 4. El sistema muestra un mensaje de conformidad por pantalla, almacenando los datos modificados.

CURSO ALTERNATIVO DE EVENTOS:

  • Sección 2. Si el gerente cancela la introducción de un nuevo valor para los datos de la empresa antes de este punto, el sistema desecha los datos introducidos.
  • Sección 3. Si algunos datos no se introdujeron correctamente, el sistema lo notificará, volviendo al punto 1 pero con los datos que el gerente acaba de introducir, para que pueda modificar los datos erróneos o introducir datos obligatorios.

POSTCONDICIONES:

  • 1. Quedan almacenados en el sistema los datos actuales de la empresa.
  • 2. Los cambios de datos realizados en un momento dado solo afectan a tickets y facturas pertenecientes a las reservas y ventas realizadas posteriormente a ese cambio.

HISTÓRICO DE CAMBIOS:

  • 21/11/06 – Antonio: Inserción de nueva plantilla de C.U. y revisión hasta versión 3.1

14. Insertar Cliente

CASO DE USO: Insertar cliente.
IDENTIFICADOR: CU14-ICLI
ACTORES: Vendedor.
VERSIÓN: 1.1
DESCRIPCIÓN: El vendedor introduce los datos característicos de un nuevo cliente en el sistema.
ESTADO: Revisado.
FRECUENCIA: Media.
SUPOSICIONES:

  • 1. El vendedor va a rellenar interactivamente con el cliente sus datos en el momento de la primera venta o reserva.

CURSO NORMAL DE EVENTOS:

  • 1. El vendedor rellena el formulario con los datos oportunos, incluyendo el DNI, el nombre, los apellidos, dirección, localidad, provincia, código postal, teléfono y teléfono móvil.
  • 2. El vendedor valida los datos introducidos.
  • 3. El sistema comprueba que el DNI introducido para el cliente nuevo no existe en el sistema y que ningún otro campo imprescindible este vacío.
  • 4. El sistema muestra un mensaje de conformidad por pantalla, almacenando los datos introducidos.

CURSO ALTERNATIVO DE EVENTOS:

  • Sección 2. Si el usuario cancela antes de este punto, el sistema desecha los datos introducidos.
  • Sección 3. Si algunos datos no se introdujeron correctamente o el usuario ya existía, el sistema lo notificará. Si hubo error de datos, se volverá al punto 1 pero con los datos que el usuario acaba de introducir, para que pueda modificar los datos erróneos o introducir datos obligatorios.

POSTCONDICIONES:

  • 1. Los datos introducidos del nuevo cliente serán almacenados en un registro de la base de datos.

HISTÓRICO DE CAMBIOS:

  • 21/11/06 – Antonio: Inserción de nueva plantilla de C.U. y revisión hasta versión 1.1

15. Modificar Cliente

CASO DE USO: Modificar cliente.
IDENTIFICADOR: CU15-MCLI
ACTORES: Vendedor.
VERSIÓN: 1.1
DESCRIPCIÓN: El vendedor introduce los datos nuevos que quiera modificar de un cliente seleccionado entre los existentes en el sistema.
ESTADO: Revisado.
FRECUENCIA: Baja.
PRECONDICIONES:

  • 1. Se debe de hacer una búsqueda del cliente del que queremos modificar datos.

CASOS DE USO QUE INCLUYE: CU20-BUSQ
SUPOSICIONES:

  • 1. La búsqueda que se ha realizado debe de haber tenido éxito.

CURSO NORMAL DE EVENTOS:

  • 1. El usuario modificará los datos que crea conveniente en el formulario mostrado del cliente que hemos seleccionado (datos informativos y datos de estado).
  • 2. El usuario valida los datos introducidos.
  • 3. El sistema comprueba si el DNI del cliente ha sido modificado, y en ese caso, comprueba que dicho DNI no existe en el sistema y que ningún otro campo imprescindible este vacío.
  • 4. El sistema muestra un mensaje de conformidad por pantalla y almacena de nuevo los datos introducidos.

CURSO ALTERNATIVO DE EVENTOS:

  • Sección 3. Si algunos datos no se introdujeron correctamente, el sistema lo notificará, volviendo al punto 1 pero con los datos que el usuario acaba de introducir, para que pueda modificar los datos erróneos, o introducir datos obligatorios.
  • Sección 4. Si se ha modificado el estado del cliente poniéndolo en eliminado, el sistema lo comunicará y el cliente dejará de estar activo, pero seguirá almacenado por si se vuelve a requerir activarlo de nuevo.

POSTCONDICIONES:

  • 1. Los datos modificados del cliente serán guardados en el mismo registro de la base de datos.
  • 2. Si el estado del cliente es eliminado, el cliente dejará de estar activo en el sistema, pero no será eliminado de la base de datos.
  • 3. Los cambios en los datos de un cliente solo afectan a las reservas y ventas realizadas por este cliente tras el cambio.

HISTÓRICO DE CAMBIOS:

  • 21/11/06 – Antonio: Inserción de nueva plantilla de C.U. y revisión hasta versión 1.1

16. Realizar una Reserva

CASO DE USO: Realizar una reserva.
IDENTIFICADOR: CU16-RRES
ACTOR: Vendedor
VERSIÓN: 2.1
DESCRIPCIÓN: El vendedor selecciona los productos que quiere reservar el cliente desde la aplicación, introduce los datos necesarios y almacena la reserva en el sistema, el cual se encarga de imprimir el ticket.
ESTADO: Revisado.
FRECUENCIA: Muy alta.
PRECONDICIONES:

  • 1. Se debe de hacer una búsqueda del cliente que va a realizar la reserva, y en caso de que no exista dicho cliente, hay que insertarlo en el sistema.
  • 2. Si se decide enviar la reserva a domicilio, debe de ser dentro de la provincia a la que pertenecemos y siempre a una zona que exista en el sistema.

CASOS DE USO QUE INCLUYE: CU20-BUSQ, CU22-ITIC
SUPOSICIONES:

  • 1. La búsqueda que se ha realizado debe de haber tenido éxito.
  • 2. La cantidad a abonar será menor que el total. Si la cantidad total de la reserva va a ser abonada completamente, se considerará que estamos en CU18-RVEN.
  • 3. La reserva debe de ser abonada antes o durante la fecha indicada.

CURSO NORMAL DE EVENTOS:

  • 1. El vendedor crea una nueva reserva para el cliente seleccionado.
  • 2. El vendedor selecciona un producto e inserta una cantidad de dicho producto.
  • 3. El sistema comprueba si hay existencias suficientes del producto seleccionado.
  • 4. El sistema muestra el precio que correspondería para ese producto y esa cantidad.
  • 5. El vendedor, en caso de que quiera modificar el precio mostrado por dicho producto, lo modifica.
  • 6. Si el cliente desea comprar más productos, volvemos al paso 2.
  • 7. El vendedor selecciona la zona de la provincia a la que será enviado el producto, la fecha concreta (día, mes y año) y la hora aproximada (hora y minutos).
  • 8. El sistema comprueba que la fecha y la hora insertadas son válidas
  • 9. El sistema muestra el precio total de la reserva.
  • 10. El vendedor inserta la cantidad entregada a cuenta perteneciente a dicha reserva
  • 11. El vendedor valida los datos introducidos.
  • 12. El sistema comprueba que ningún campo imprescindible esté vacío y que todos los datos introducidos sean correctos.
  • 13. El sistema muestra un mensaje de conformidad por pantalla, almacenando los datos introducidos, e imprime un ticket con los datos de interés referentes a una reserva (include: CU22-ITIC)

CURSO ALTERNATIVO DE EVENTOS:

  • Sección 3. Si no hay existencias suficientes sobre un producto, el sistema informará de las existencias totales de dicho producto y pedirá al vendedor cambiar dicha cantidad errónea.
  • Sección 7. Si la reserva no será enviada a domicilio se indicará que es una reserva de “recogida en mano”.
  • Sección 8. Si la fecha y la hora no son correctas, el sistema informará de que habrá que insertar una fecha u hora correcta.
  • Sección 11. Si el vendedor cancela la reserva antes de este punto, el sistema desecha los datos introducidos.
  • Sección 12. Si algunos datos no se introdujeron correctamente, el sistema lo notificará, volviendo al punto 7 pero con los datos que el vendedor acaba de introducir, para que pueda modificar los erróneos, o introducir datos obligatorios.

POSTCONDICIONES:

  • 1. Se guardará en el sistema la información referente a la reserva realizada.

HISTÓRICO DE CAMBIOS:

  • 21/11/06 – Antonio: Inserción de nueva plantilla de C.U. y revisión hasta versión 2.1

17. Modificar una Reserva

CASO DE USO: Modificar una reserva.
IDENTIFICADOR: CU17-MRES
ACTOR: Vendedor
VERSIÓN: 2.1
DESCRIPCIÓN: El vendedor realiza una búsqueda en el sistema para encontrar la reserva a modificar, la selecciona y se le muestran los datos disponibles de la reserva, tras lo que los modifica y almacena los cambios oportunos.
ESTADO: Revisado.
FRECUENCIA: Media.
PRECONDICIONES:

  • 1. Se debe hacer una búsqueda de la reserva que queremos modificar.

ES EXTENDIDO POR: CU22-ITIC
CASOS DE USO QUE INCLUYE: CU20-BUSQ
SUPOSICIONES:

  • 1. La búsqueda que se ha realizado debe de haber tenido éxito.
  • 2. La reserva debe de ser abonada antes o durante la fecha indicada.
  • 3. Si se va a modificar una reserva de forma que la reserva definitiva sea más barata y dicha modificación ha sido realizada el mismo día de entrega de la reserva, no se devolverá el dinero conveniente de dicho cambio.

CURSO NORMAL DE EVENTOS:

  • 1. El vendedor modificará los datos que crea conveniente en el formulario mostrado de la reserva que hemos seleccionado (datos informativos y datos de estado). Podemos anular productos, insertar productos, cambiar tipo de reserva, cambiar la zona de envío, cambiar la fecha y la hora de entrega, añadir entregado a cuenta, cambiar el estado de la reserva.
  • 1.1. Si se han insertado productos nuevos, el sistema comprueba si hay existencias suficientes sobre el producto seleccionado.
  • 1.2. Si se han insertado productos nuevos, el sistema muestra el precio que correspondería por ese producto.
  • 1.3. Si se han insertado productos nuevos, el vendedor, en caso de que quiera modificar el precio mostrado por dicho producto, lo modifica.
  • 1.4. Si se han insertado productos nuevos y el cliente quiere insertar más productos, volvemos al paso 1.
  • 1.5. Si se ha modificado la fecha y la hora de entrega, el sistema comprueba que la nueva fecha y hora sean correctas.
  • 2. El sistema muestra el precio total resultante de la modificación.
  • 3. El vendedor valida los datos introducidos.
  • 4. El sistema comprueba que ningún campo imprescindible esté vacío y que todos los datos introducidos sean correctos.
  • 5. El sistema muestra un mensaje de conformidad por pantalla, almacenando los datos introducidos.
  • 6. El sistema comprueba si se ha modificado la cantidad entregada a cuenta, y en este caso, si se ha abonado por completo. En caso de que ocurra esto último, el sistema marcará la reserva actual como venta y notificará este hecho.
  • 7. Si la reserva aún está activa y se solicita, se puede imprimir un ticket con los datos de interés referentes a la nueva reserva, actuando como en CU22-ITIC (punto de inserción: CU22-ITIC).

CURSO ALTERNATIVO DE EVENTOS:

  • Sección 1.1. Si no hay existencias suficientes sobre un producto, el sistema informará de las existencias totales que existen sobre dicho producto y pedirá al vendedor cambiar dicha cantidad errónea.
  • Sección 1.5. Si la fecha y la hora no son correctas, el sistema informará de que habrá que insertar una fecha u hora correcta.
  • Sección 3. Si el vendedor cancela la modificación de la reserva antes de este punto, el sistema desecha los datos introducidos.
  • Sección 4. Si algunos datos no se introdujeron correctamente, el sistema lo notificará, volviendo al punto 1 pero con los datos que el vendedor acaba de introducir, para que pueda modificar los datos erróneos, o introducir datos obligatorios.
  • Sección 5. Si se ha modificado el estado de la reserva poniéndolo en cancelada, el sistema lo comunicará y la reserva dejará de estar activa, pero seguirá almacenada por si se vuelve a requerir activarla de nuevo.

POSTCONDICIONES:

  • 1. Los datos modificados de la reserva serán almacenados en el sistema, sustituyendo a los anteriores.
  • 2. Si el estado de la reserva es “eliminada”, la reserva dejará de estar activa en el sistema, pero no será eliminada de la base de datos.
  • 3. Si una reserva ha sido modificada de forma que ha sido abonado el precio total de dicha reserva, esta reserva dejará de considerarse como tal y pasará a ser una venta.

HISTÓRICO DE CAMBIOS:

  • 22/11/06 – Antonio: Inserción de nueva plantilla de C.U. y revisión hasta versión 2.1

18. Realizar una Venta

CASO DE USO: Realizar una venta.
IDENTIFICADOR: CU18-RVEN
ACTOR: Vendedor
VERSIÓN: 2.1
DESCRIPCIÓN: El vendedor selecciona los productos que quiere el cliente desde la aplicación, introduce los datos necesarios y valida la venta, indicando al sistema si se imprimirá ticket o factura.
ESTADO: Revisado.
FRECUENCIA: Muy alta.
PRECONDICIONES:

  • 1. Se debe de hacer una búsqueda del cliente que va a realizar la venta, y en caso de que no exista dicho cliente, hay que insertarlo en el sistema.
  • 2. Si se decide enviar la reserva a domicilio, debe de ser dentro de la provincia a la que pertenecemos y siempre a una zona que exista en el sistema.

ES EXTENDIDO POR: CU22-ITIC, CU21-IFAC
CASOS DE USO QUE INCLUYE: CU20-BUSQ
SUPOSICIONES:

  • 1. La búsqueda que se ha realizado debe de haber tenido éxito.
  • 2. La cantidad total será abonada por completo por el cliente.

CURSO NORMAL DE EVENTOS:

  • 1. El vendedor crea una nueva venta para el cliente seleccionado.
  • 2. El vendedor selecciona un producto e inserta una cantidad de dicho producto.
  • 3. El sistema comprueba si hay existencias suficientes del producto seleccionado.
  • 4. El sistema muestra el precio que correspondería para ese producto y esa cantidad.
  • 5. El vendedor, en caso de que quiera modificar el precio mostrado por dicho producto, lo modifica.
  • 6. Si el cliente desea comprar más productos, volvemos al paso 2.
  • 7. El vendedor selecciona la zona de la provincia a la que será enviado el producto, la fecha concreta (día, mes y año) y la hora aproximada (hora y minutos).
  • 8. El sistema comprueba que la fecha y la hora insertadas son válidas.
  • 9. El sistema muestra el precio total de la venta.
  • 10. El vendedor valida los datos introducidos y el pago de la venta.
  • 11. El sistema comprueba que ningún campo imprescindible este vacío y que todos los datos introducidos sean correctos.
  • 12. El sistema decrementa el número de artículos vendidos de la cantidad de productos del mismo tipo existentes en el almacén.
  • 13. El sistema muestra un mensaje de conformidad por pantalla, almacenando los datos introducidos.
  • 14. El sistema da la posibilidad de, o bien imprimir un ticket (punto de inserción: CU22-ITIC), o bien imprimir una factura (punto de inserción: CU21-IFAC).

CURSO ALTERNATIVO DE EVENTOS:

  • Sección 3. Si no hay existencias suficientes sobre un producto, el sistema informará de las existencias totales de dicho producto y pedirá al vendedor cambiar dicha cantidad errónea.
  • Sección 7. Si la venta no será enviada a domicilio se indicará que es una venta de “recogida en mano”, y si es una venta directa, la fecha será la del día actual.
  • Sección 8. Si la fecha y la hora no son correctas, el sistema informará de que habrá que insertar una fecha u hora correcta.
  • Sección 10. Si el vendedor cancela la venta antes de este punto, el sistema desecha los datos introducidos.
  • Sección 11. Si algunos datos no se introdujeron correctamente, el sistema lo notificará, volviendo al punto 7 pero con los datos que el vendedor acaba de introducir, para que pueda modificar los erróneos, o introducir datos obligatorios.

POSTCONDICIONES:

  • 1. Se guardará en un nuevo registro la información referente a la venta realizada.

HISTÓRICO DE CAMBIOS:

  • 22/11/06 – Antonio: Inserción de nueva plantilla de C.U. y revisión hasta versión 2.1

19. Modificar una Venta

CASO DE USO: Modificar una venta.
IDENTIFICADOR: CU19-MVEN
ACTOR: Vendedor
VERSIÓN: 2.1
DESCRIPCIÓN: El vendedor realiza una búsqueda en el sistema para encontrar la venta a modificar, la selecciona y se le muestran los datos disponibles de la venta, tras lo que los modifica y almacena los cambios oportunos.
ESTADO: Revisado.
FRECUENCIA: Baja.
PRECONDICIONES:

  • 1. Se debe hacer una búsqueda de la venta que queremos modificar.

ES EXTENDIDO POR: CU22-ITIC, CU21-IFAC
CASOS DE USO QUE INCLUYE: CU20-BUSQ
SUPOSICIONES:

  • 1. La búsqueda que se ha realizado debe de haber tenido éxito.
  • 2. Si el total de la nueva venta es superior al anterior, se tendrá que abonar la diferencia. Si es inferior, salvo si ha sido por error, no se devolverá el dinero por los productos.

CURSO NORMAL DE EVENTOS:

  • 1. El vendedor modificará los datos que crea conveniente en el formulario mostrado de la reserva que hemos seleccionado (datos informativos y datos de estado). Podemos anular productos, insertar productos, cambiar tipo de reserva, cambiar la zona de envío, cambiar la fecha y la hora de entrega, añadir entregado a cuenta, cambiar el estado de la reserva.
  • 1.1. Si se han insertado productos nuevos, el sistema comprueba si hay existencias suficientes sobre el producto seleccionado.
  • 1.2. Si se han insertado productos nuevos, el sistema muestra el precio que correspondería por ese producto.
  • 1.3. Si se han insertado productos nuevos, el vendedor, en caso de que quiera modificar el precio mostrado por dicho producto, lo modifica.
  • 1.4. Si se han insertado productos nuevos y el cliente quiere insertar más productos, volvemos al paso 1.
  • 1.5. Si se ha modificado la fecha y la hora de entrega, el sistema comprueba que la nueva fecha y hora sean correctas.
  • 2. El sistema muestra el precio total resultante de la modificación.
  • 3. El vendedor valida los datos introducidos y el pago del mismo.
  • 4. El sistema comprueba que ningún campo imprescindible este vacío y que todos los datos introducidos sean correctos.
  • 5. El sistema, en caso de haber añadido productos a la venta, decrementa el número de artículos vendidos de la cantidad de productos del mismo tipo existentes en el almacén. En caso de haber suprimido productos de la venta, aumenta el número de artículos en la cantidad de productos que han sido anulados de la venta.
  • 6. El sistema muestra un mensaje de conformidad por pantalla, almacenando los datos introducidos.
  • 7. El sistema da la posibilidad de, o bien imprimir un ticket (punto de inserción: CU22-ITIC), o bien imprimir una factura (punto de inserción: CU21-IFAC).

CURSO ALTERNATIVO DE EVENTOS:

  • Sección 1.1. Si no hay existencias suficientes sobre un producto, el sistema informará de las existencias totales que existen sobre dicho producto y solicitará al vendedor cambiar dicha cantidad errónea.
  • Sección 1.5. Si la fecha y la hora no son correctas, el sistema informará de que habrá que insertar una fecha u hora correcta y volverá a 1.
  • Sección 3. Si el vendedor cancela la modificación de la venta antes de este punto, el sistema desecha los datos introducidos.
  • Sección 4.1. Si algunos datos no se introdujeron correctamente, el sistema lo notificará, volviendo al punto 1 pero con los datos que el vendedor acaba de introducir, para que pueda modificar los datos erróneos, o introducir datos obligatorios.
  • Sección 4.2. Si se ha modificado el estado de la venta poniéndolo en cancelada, el sistema lo comunicará y ésta dejará de estar activa (no contará para la parte económica), pero seguirá almacenada por si se vuelve a requerir activarla de nuevo.

POSTCONDICIONES:

  • 1. Los datos modificados de la venta serán guardados en el mismo registro de la base de datos abierto con anterioridad.
  • 2. Si el estado de la venta es “eliminado”, la venta dejará de estar activa en el sistema y no se tendrá en cuenta para cálculos económicos, pero no será eliminada de la base de datos.

HISTÓRICO DE CAMBIOS:

  • 22/11/06 – Antonio: Inserción de nueva plantilla de C.U. y revisión hasta versión 2.1

20. Hacer una Búsqueda

CASO DE USO: Hacer una búsqueda.
IDENTIFICADOR: CU20-BUSQ
ACTOR: Vendedor, gerente
VERSIÓN: 1.1
DESCRIPCIÓN: El usuario desea que se le muestren los datos de un elemento concreto de entre varios del mismo tipo.
ESTADO: Revisado.
FRECUENCIA: Muy alta.
SUPOSICIONES:

  • 1. El elemento a buscar es del tipo de los elementos válidos que el sistema almacena.

CURSO NORMAL DE EVENTOS:

  • 1. El usuario selecciona el tipo de elemento que desea buscar dentro del sistema.
  • 2. El sistema muestra varias opciones de búsqueda para localizar el tipo de elemento seleccionado.
  • 3. El usuario selecciona algún criterio de búsqueda posible y añade la información relevante de la búsqueda.
  • 4. El usuario valida la información insertada.
  • 5. El sistema muestra el(los) resultado(s) obtenido(s) de la búsqueda.
  • 6. El usuario selecciona el elemento que le interesa desde el resultado de la búsqueda.
  • 7. El sistema muestra un formulario con los datos del elemento seleccionado, dando la posibilidad si es pertinente de modificar esos datos.

CURSO ALTERNATIVO DE EVENTOS:

  • Sección 3. Si el usuario no introduce los datos necesarios para realizar la búsqueda, el sistema da la posibilidad de volver al punto 1 y seleccionar otro tipo distinto de elemento a buscar.
  • Sección 5.1. Si el sistema no encuentra ningún elemento que coincida con los datos de búsqueda, se lo indica al usuario, volviendo al punto 2.
  • Sección 5.2. Si ninguno de los elementos mostrados son los requeridos, el sistema da la posibilidad de volver al punto 1 o 2 y rehacer la búsqueda.

POSTCONDICIONES:

  • 1. Se obtiene un formulario con los datos de interés del elemento que se ha buscado.

HISTÓRICO DE CAMBIOS:

  • 22/11/06 – Antonio: Inserción de nueva plantilla de C.U. y revisión hasta versión 1.1

21. Imprimir Factura

CASO DE USO: Imprimir una factura.
IDENTIFICADOR: CU21-IFAC
ACTOR: Vendedor
VERSIÓN: 1.1
DESCRIPCIÓN: El vendedor indica al sistema que desea obtener la factura de una determinada venta
ESTADO: Revisado.
FRECUENCIA: Media.
CASOS DE USO QUE EXTIENDE: CU18-RVEN, CU19-MVEN
PRECONDICIONES:

  • 1. Hemos escogido la opción de imprimir una factura cuando se ha realizado/modificado una venta.

CURSO NORMAL DE EVENTOS:

  • 1. El vendedor le indica al sistema que desea obtener una factura de la venta.
  • 2. El sistema muestra un mensaje de conformidad por pantalla e imprime la factura con los datos de la venta (datos del cliente, datos de la empresa, productos comprados, envío a domicilio, precio total).

POSTCONDICIONES:

  • 1. Se ha obtenido una factura impresa.

HISTÓRICO DE CAMBIOS:

  • 22/11/06 – Antonio: Inserción de nueva plantilla de C.U. y revisión hasta versión 1.1

22. Imprimir Ticket

CASO DE USO: Imprimir ticket.
IDENTIFICADOR: CU22-ITIC
ACTOR: Vendedor
VERSIÓN: 1.1
DESCRIPCIÓN: Una vez realizada una reserva, el sistema imprime un ticket con los datos característicos de dicha reserva. También existe la posibilidad de imprimirlo cuando se modifica la reserva, y cuando se realiza o modifica una venta (en estos dos últimos casos se ofrece la posibilidad de imprimir el ticket o una factura).
ESTADO: Revisado.
FRECUENCIA: Muy alta.
CASOS DE USO QUE EXTIENDE: CU17-MRES, CU18-RVEN, CU19-MVEN
PRECONDICIONES:

  • 1. Hemos escogido imprimir el ticket durante la modificación de una reserva, la modificación o realización de una venta, o estamos terminando una reserva nueva.

CURSO NORMAL DE EVENTOS:

  • 1. El sistema imprime el ticket con los datos de interés referentes a la reserva o venta para que se lo quede el cliente, utilizando para ello los datos del cliente, de la empresa y de la reserva o venta.

HISTÓRICO DE CAMBIOS:

  • 22/11/06 – Antonio: Inserción de nueva plantilla de C.U. y revisión hasta versión 1.1

23. Capturar Datos de Zonas de Provincia desde Fichero

CASO DE USO: Capturar datos de zonas de provincia desde fichero.
IDENTIFICADOR: CU23-CDDF
ACTORES: Gerente
VERSIÓN: 1.0
DESCRIPCIÓN: Insertar datos de nuevas zonas de provincia para el envío a domicilio desde un fichero.
ESTADO: Pendiente de revisión.
FRECUENCIA: Muy baja.
PRECONDICIONES:

  • 1. El gerente debe de haberse identificado en el sistema.

CASOS DE USO QUE EXTIENDE: CU08-IZPR
SUPOSICIONES:

  • 1. El fichero es un archivo de texto, con formato: // localidad o barrio // código postal // precio por viaje //, y en el cual se podrán poner todas las zonas que se quieran separadas por retornos de carro.

CURSO NORMAL DE EVENTOS:

  • 1. El gerente le indica al sistema la ruta exacta en la que tiene que buscar el fichero de texto con los datos.
  • 2. El sistema abre el fichero de texto y lo trata, creando una zona de provincia para cada una de las entradas válidas.
  • 3. El sistema muestra un mensaje de conformidad por pantalla y cierra el archivo de texto.

CURSO ALTERNATIVO DE EVENTOS:

  • Sección 2. Si la ruta no era válida o el fichero no tiene el formato correcto, el sistema muestra un mensaje de error y cierra el fichero.
  • Sección 3. Si ha habido algún problema al almacenar alguna de las zonas, el sistema lo mostrará por pantalla.

POSTCONDICIONES:

  • 1. Los datos válidos del archivo de texto están ahora introducidos en el sistema como nuevas zonas de provincia.

HISTÓRICO DE CAMBIOS:

  • 22/11/06 – Antonio: Creación.

Volver a especificación de requisitos del prototitpo I

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-Share Alike 2.5 License.