Especificaciones de Software Restaurante Huanchaquito

Especificación de Software

Versión <3.0.2>

SISTEMA DE ATENCIÓN DEL RESTAURANTE HUANCHAQUITO

Integrantes Balta Vilca Magaly Esther

Pérez Isidro Eugenia Isabela Quispe Mayta Christian

Silva Fuentes Miguel

Especificación de Software (ES) Página 1 de 40

HISTORIAL DE REVISIONES

Versión Autor Descripción Fecha de Elaboración

Fecha de Revisión

Revisado por

<3.0.1><Modificación de la matriz excel>

<07-09-15> <09-09-15>


Contenido

1. Requisitos Funcionales..........................................................4

2. Requisitos No Funcionales.....................................................5

3. Modelo de Casos de Uso........................................................73.1. Lista de Actores...............................................................................73.2. Diagrama de Actores.......................................................................83.3. Diagrama de Paquetes.....................................................................93.4. Lista de Casos de Uso del Sistema por Paquete...............................93.5. Diagrama de Casos de Uso por Paquete........................................103.6. Diagrama General de Casos de Uso...............................................113.7. Priorización de los Casos de Uso....................................................123.8. Matriz de Modelo de Negocio y Modelo de Sistema.......................133.9. Especificación de los Casos de Uso del Sistema............................14

CUS01 – Nombre del caso de Uso..........................................................9

4. Flujo General de Navegación................................................10

5. Esquema de Seguridad........................................................11

1. Requisitos Funcionales


Código Descripción Proceso de Negocio

RF-001 Elaborar proceso de información Atender Pedido

RF-002 Verificar disponibilidad de producto Atender Pedido

RF-003 Registrar platos solicitados Atender Pedido

RF-004 Terminar preparación el plato Entregar Pedido

RF-005 Tomar conocimiento del plato preparado Entregar Pedido

RF-006 Transportar plato hacia la mesa Entregar Pedido

RF-007 Verificar platos pedidos Modificar Pedido

RF-008Permitir acceso a la base de

datos Modificar Pedido

RF-009 Eliminar o Adicionar platos al pedido Modificar Pedido

RF-010 Solicitar cuenta o registro de pedidos Pagar Pedido

RF-011 Pagar por Tarjeta Pagar Pedido

RF-012 Pagar por efectivo Pagar Pedido


Código Descripción Proceso de Negocio

RF-013 Registrar transacción en la base de datos Pagar pedido

RF-014 Solicitar usuario y password para ingresar al sistema

Informar sobre ventas diarias

RF-015 Mostrar transacciones realizadas en el día

Informar sobre ventas diarias

2. Requisitos No Funcionales

Tipo de Requisito Código Descripción Implementación

Restricciones del Diseño RNF-001

El sistema debe ser compatible con

Windows XP, Windows Vista,

Windows 7, Windows8.1.

Este sistema se desarrolla en Windows 8.1, pero también

debe ser compatible con

los mencionados, en caso no se

tenga ese sistema operativo.

RNF-002

El sistema seguirá los componentes de implementación en la plataforma Java y

Php.

RNF-003El sistema a

desarrollarse, utilizará la base de

datos MySQL Server.

Se va a implementar una conexión con la base de datos que utilizará el

programa MySQL.



Componentes a Adquirir RNF-004

El sistema debe contar con hardware y software de buen

funcionamiento para las actividades que

se realicen.El software a utilizar

es de Java.

Interfaces de Usuario RNF-005

El formato de los menús deberá

distinguirse por los nombres de cada opción con una fuente grande y

resltante para una correcta

visualización.

Interfaces de Hardware RNF-006

Limitaciones y restricciones de las direcciones MAC de las computadoras y

dispositivos.

Todos los usuarios

dependiendo de su perfil tendrán

un límite de acceso a la

información y funcionalidades

del software.

Interfaces de Software RNF-007

Se utilizó el Rational Software Architect (RSA). Para diseñar

el proceso de Logística.

Se activa el permiso con la licencia de la versión 8.0.1

Interfaces de Comunicaciones RNF-008

El sistema contará con una conexión

de red LAN y WLAN.

Se contará con dispositivos que brindan conexión

a internet.

Requerimientos de Licenciamiento RNF-009 NetBeans 7.4 y

ASP.NET

Licencia para NetBeans 7.4 y

para.NET se usara la versión 4.5.1 de

64 bit

Seguridad RNF-010

Los usuarios pertenecientes al

negocio tendrán a su disposición un id y

contraseña.

Se evita exponer datos personales de los solicitantes



Requisitos del Sistema RNF-011 Requisitos Mínimos

Los ordenadores deben tener

microprocesador Core i3 y 4Gb de

memoria para almacenar datos e información.

Requisitos de Desempeño RNF-012

El sistema tendrá una automatización

durante las 24 horas.

Durante los feriados, días

festivos y de no atención al público se

realizara un mantenimiento.

3. Modelo de Casos de Uso

3.1. Lista de Actores

Actor del sistema Descripción

Es la persona quien gestiona la apertura, cierre de caja y comprobante de pago además de anular comprobantes.

Es el encargado de generar una orden de atención si es que el cliente no ha hecho una reserva y por consiguiente confirmará dicha reserva.

Es la persona que ingresa al Sistema a través de su usuario y contraseña personal.

Es el encargado de registrar el orden del pedido hecho por el cliente.


Es la persona que genera una reserva. Ya en el establecimiento se encarga de generar su orden, mostrar dicha orden y generar su cuenta.

Es el encargado de mantener perfil además de mantener usuario.

Es la persona que tiene la potestad de añadir y modificar producto de la carta del día, además de hacer la confirmación de ventas diarias.

3.2. Diagrama de Actores

3.3. Diagrama de Paquetes


3.4. Lista de Caso de Uso del Sistema por Paquetes

3.5. Diagrama de Casos de Uso por Paquete

Paquete: P01 - Administración


Paquete: P02 – Atención

Paquete: P03 – Cocina

Paquete: P04 – Requerimientos de Administracion de Caja

Paquete: P05 – Seguridad


3.6. Diagrama General de Casos de Uso

3.7. Priorización de los Caso de Uso

3.7.1. Clasificación de los Casos de Uso


0,4 0,3 0,2 0,1TOTAL CLASIFICACIÓN

DE CUCASO DE USO IMPORTANCIA COMPLEJIDAD RIESGO IMPACTO RNF

CUS01 – Realizar pago de pedido 9 9 8 8 8.5 Primario

CUS02 – Registra orden de pedido 9 9 8 8 8.5 Primario

CUS03 – Ingresar al Sistema 9 8 9 8 8.6 Primario

CUS04 – Añadir Producto 8 9 8 8 8.6 Primario

CUS05 – Modificar Producto 9 8 9 9 8.9 Primario

CUS06 – Confirmar Venta Diaria

7 6 6 7 6.5 Secundario

CUS07 – Generar Orden 9 9 8 8 8.5 Primario

CUS08 – Mostrar Orden 7 6 6 7 6.5 Secundario

CUS09 – Mantener Perfil 9 7 8 8 8 Primario

CUS10 – Mantener Usuario 9 7 8 8 8 Primario

CUS11 – Generar Reserva 9 9 8 8 8.6 Primario

CUS12 – Confirmar Reserva 7 6 6 7 6.5 Secundario

CUS13 – Generar Orden de Atención 9 9 8 8 8.5 Primario

CUS14 – Generar cuenta 9 9 8 8 8.6 Primario

3.7.2.Ciclos de Desarrollo de los Casos de Uso del Sistema


Ciclo de desarrollo Nombre del caso de uso Clasificación

Núcleo central o Ciclo 0

CUS01 – Realizar pago de pedidoPrimario

CUS02 – Registra orden de pedido Primario

CUS03 – Ingresar al Sistema Primario

CUS04 – Añadir Producto Primario

CUS05 – Modificar Producto Primario

CUS07 – Generar Orden Primario

CUS09 – Mantener Perfil Primario

CUS10 – Mantener Usuario Primario

CUS11 – Generar Reserva Primario

CUS13 – Generar Orden de Atención Primario

CUS14 – Generar cuenta Primario

Ciclo 1

CUS06 – Confirmar Venta Diaria Secundario

CUS08 – Mostrar Orden Secundario

CUS12 – Confirmar Reserva Secundario


3.8. Matriz de Modelo de Negocio y Modelo de Sistema

Proceso de Negocio Actividad del Negocio Responsable del

Negocio Requerimiento Caso de Uso Actores

Atender Pedido

Elaborar proceso de información Jefe del AADA RF-001 Elaborar proceso de información CUS-001 Registrar Administrado Jefe del AADA

Adjuntar requisitos Jefe del AADA RF-002 Verificar disponibilidad de producto CUS-002 Recepcionar requisitos Jefe del AAD

Registrar Documentos Jefe del AADA RF-003 Registrar platos solicitados CUS-003 Registrar Documentos Jefe del AADA

Gestión de Control de

Inscripción de Trámite

Revisar Documentos Director Regional RF-004 Terminar preparación el plato CUS-004 Consultar Elaboración del Trámite Director Regional

Registrar Documentación Jefatura de DFFS RF-005 Tomar conocimiento del plato

preparado CUS-005 Consultar la elaboración del documento Jefatura de DFFS

Recepcionar Expediente Especialista de DFFS RF-006 Transportar plato hacia la mesa CUS-006 Verificar los Documentos Aceptados

Especialista de DFFS

Emitir certificado Especialista de DFFS RF-007 Verificar platos pedidos CUS-007 Registrar Convenio de Exportador

Especialista de DFFS

Revisar Certificado Jefatura de DFFS RF-008 Permitir acceso a la base de datos CUS-008 Actualizar Estado del

Administrado Jefatura de DFFS

Entregar Certificado Administrado RF-009 Eliminar o Adicionar platos al pedido CUS-009 Generar Certificado Administrado

REUTILIZABLE

Solicitar cuenta o registro de pedidos CUS-012 Buscar DOCUMENTOS USUARIOS DE

REALIZACION DE Tramite de exportación

Mostrar datos del Usuario SOLICITANTE CUS-013 Buscar SOLICITANTE

Mostrar datos de la solicitud de exportadores CUS-014 Buscar datos de Solicitud de

exportadores DFFSMostrar datos del informe de confirmación de documento CUS-015 Buscar datos del trámite

MANTENIMIENTO

Permitir el Ingreso al SistemaCUS-016 Mantener el SISTEMA DFFSActualizar Información del

Usuario del SistemaActualizar Datos de Usuario CUS-017 Mantener USUARIO DFFS

Registrar Usuario en el Sistema CUS-018 REGISTRAR NUEVO USUARIO


3.9. Especificación de los Casos de Uso del Sistema

3.9.1.Especificación de Alto Nivel

Caso de uso: CUS01 – Realizar pago de pedidoActor(es): CajeroPropósito: Pagar el total del pedido consumido por el clienteCaso de uso asociado:

Ninguno

Resumen: Comprende en pagar el total del Pedido consumido por el Cliente en la ventanilla de pago atendido por el Cajero.

Clasificación Primario Requisitos El cajero debe estar registrado y haber sido

aceptado por el sistema.

Caso de uso: CUS02 – Registra orden de pedido Actor(es): Jefe del cocinaPropósito: Registra el pedido está siendo procesado en la

cocinaCaso de uso asociado:

Ninguno

Resumen: Después que el cliente ordenara su pedido, la información llegará a la cocina donde el jefe de cocina registrará que el pedido está siendo procesado

Clasificación Primario Requisitos El jefe de cocina debe estar registrado y haber sido

aceptado por el sistema.

Caso de uso: CUS03 – Ingresar al SistemaActor(es): UsuarioPropósito: Registro de usuario y contraseñaCaso de uso asociado:

Ninguno

Resumen: El usuario del sistema deberá haberse logueado para ingresar al sistema.

Clasificación Primario


Requisitos El sistema debe validar los campos rellenados con el usuario y la contraseña del mismo.

Caso de uso: CUS04 – Añadir ProductoActor(es): AdministradorPropósito: Añadir un nuevo producto a la cartaCaso de uso asociado:

Ninguno

Resumen: El administrador añadirá un producto a la carta del día.

Clasificación Primario Requisitos El sistema deberá guardar en la base de datos todas

las especificaciones del producto añadido.

Caso de uso: CUS05 – Modificar ProductoActor(es): AdministradorPropósito: Modificar un producto de la cartaCaso de uso asociado:

Ninguno

Resumen: El administrador modificará un producto de la carta.Clasificación Primario Requisitos El sistema se encargará de guardar las

especificaciones editadas del producto seleccionado.

Caso de uso: CUS06 – Confirmar Venta DiariaActor(es): AdministradorPropósito: Confirmar las ventas al finalizar el díaCaso de uso asociado:

Ninguno

Resumen: El administrador deberá haber concordado el total de ventas en el día.

Clasificación Primario Requisitos El sistema deberá guardar la confirmación del

administrador en la base de datos.

Caso de uso: CUS07 – Generar OrdenActor(es): ClientePropósito: Seleccionar un plato de la lista y agregarlo a la

cuenta


Caso de uso asociado:

Ninguno

Resumen: El usuario entre la lista de productos elegirá unoClasificación Primario Requisitos El sistema generará la orden de un producto la cual

irá directamente a la base de datos

Caso de uso: CUS08 – Mostrar OrdenActor(es): ClientePropósito: El sistema mostrará la lista de productos que han

sido cargados en la cuenta y ver el estado en el que se encuentran

Caso de uso asociado:

Ninguno

Resumen: El cliente verá el estado de los platosClasificación Primario Requisitos El sistema mostrará el informe

Caso de uso: CUS09 – Mantener PerfilActor(es): Administrador del SistemaPropósito: Actualizar perfiles, agregar o eliminarCaso de uso asociado:

Ninguno

Resumen: El administrador manejará la lista de perfiles y las restricciones de cada uno

Clasificación Primario Requisitos El sistema guardará los perfiles con sus cambios

Caso de uso: CUS10– Mantener UsuarioActor(es): Administrador del SistemaPropósito: Actualizar usuarios, agregar o eliminarCaso de uso asociado:

Ninguno

Resumen: El administrador manejará la lista de usuarios y las restricciones de cada uno

Clasificación Primario Requisitos El sistema guardará los usuarios con sus cambios


Caso de uso: CUS11 – Generar ReservaActor(es): ClientePropósito: Seleccionar una mesa disponible y registrarlo en el

sistemaCaso de uso asociado:

Ninguno

Resumen: El cliente escoge fecha, hora y mesa para ser atendido posteriormente.

Clasificación PrimarioRequisitos El sistema debe validar la disponibilidad de mesas

según fecha y hora.

Caso de uso: CUS12 – Confirmar ReservaActor(es): AnfitriónPropósito: Validar una reserva realizada anteriormenteCaso de uso asociado:

Ninguno

Resumen: El anfitrión podrá validar los datos de una reservación hecha por el cliente.

Clasificación PrimarioRequisitos Reserva registrada en el sistema

Caso de uso: CUS13 – Generar Orden de AtenciónActor(es): AnfitriónPropósito: Generar una orden de atención para un cliente que

no realizo reservaCaso de uso asociado:

Ninguno

Resumen: El anfitrión podrá atender clientes fuera de una reserva siempre y cuando exista disponibilidad

Clasificación PrimarioRequisitos Disponibilidad de mesas


Caso de uso: CUS14 – Generar cuentaActor(es): ClientePropósito: Generar estado de cuentaCaso de uso asociado:

Ninguno

Resumen: El cliente podrá generar la cuenta de su consumo en el establecimiento para su posterior pago.

Clasificación PrimarioRequisitos El sistema registra el estado de cuenta.

3.9.2. Especificación Extendida

3.9.2.1. CUS01 Realizar pago de pedido1. Realizar pago de pedido

1.1 DescripciónComprende en pagar el total del Pedido consumido por el Cliente en la ventanilla de pago atendido por el Cajero.

1.2 Actor(es)Cajero

2. Flujo de EventosEl caso de uso se inicia cando el cajero selecciona la opción Pagar Pedido en la interfaz REALIZAR PAGO.

2.1 Flujo Básico de Eventos1. El sistema muestra el interfaz REALIZAR PAGO

En la interfaz se nuestra la lista de los Platos consumidos por el Cliente, los Precios del mismo, la Mesa y el Monto que deberá pagar.

2. El Cajero selecciona la opción Verificado donde el Sistema mostrará una interfaz llamada VERIFICACION donde el Cajero tendrá que llenar los respectivos campos.

3. El Cajero selecciona el número de mesa donde el Cliente ha consumido.

4. El Cajero importará los datos del número de Mesa respectivo, tales son: nombre de cada Plato, Bebida o


Piqueo que consumió el Cliente, precio y cantidad de cada plato, bebida o piqueo.

5. El Cajero llenara los campos respectivos: nombre del Cliente, documento de identidad del Cliente o RUC, Método de pago, empresa de la Tarjeta de Crédito o débito (MasterCard, Visa o American Express) y en tal caso, el código de la Tarjeta de crédito.

6. El Cajero selecciona el botón Procesar.6.1 El sistema empezar a procesar los datos ingresados6.2 El sistema mostrará los datos6.3 El Sistema muestra el total que se cobrara.

7. El Cajero selecciona la opción Imprimir Comprobante.

8. El Sistema procede a cobrar el monto total del Pedido consumido.

9. El Sistema muestra un mensaje de confirmación.10. El Sistema emite el comprobante de pago respectivo.11. El Sistema cierra la interfaz principal y termina el

caso de uso.

2.2 Flujos Alternativos

4.1 Datos sin llenar

El Sistema rechazará esto emitiendo un mensaje de alerta obligando a llenar todos los datos. El flujo regresa al evento 4.

6.1. Error de comunicación

El Sistema mostrará un mensaje que indique que no se ha podido establecer comunicación al Sistema de Tarjeta Solicitado e indica que lo vuelva a intentar hasta que se pueda conectar. El flujo regresa al evento 6.

3. Precondiciones


3.1 El Cajero tiene que estar previamente logueado

3.2 La mesa donde el Cliente debe estar marcada como atendida.

4. Post-condiciones

4.1. Se creó un objeto venta de Pedido.

5. Puntos de extensiónNinguno

6. Prototipo:

3.9.2.2. CUS02 Registra orden de pedido1. Registra orden de pedido

1.1 DescripciónDespués que el cliente ordenara su pedido, la

información llegará a la cocina donde el jefe de cocina registrará que el pedido está siendo procesado

1.2 ActoresJefe de cocina

2. Flujo de EventosEn el sistema se muestra la interfaz Registra Orden De Pedido


2.1 Flujo Básico de Eventos1. El sistema muestra la interfaz REGISTRO DE PEDIDO, donde se

muestra el número de Mesa, cantidad de Plato, Tiempo y nombre del plato.

2. El caso de uso empieza cuando el Pedido llega al sistema y el jefe de cocina selecciona que el Pedido está siendo procesado de la mesa que corresponda (se prioriza al primer pedido que llegue).

3. El jefe indica que Plato debe cocinarse.4. Cuando dicho palto este preparado, el seleccionara la opción

Pedido En Marcha y se mostrará la interfaz PEDIDO EN MARCHA

5. El Sistema cierra la interfaz principal y termina el caso de uso.2.2 Flujos Alternos

2.1 Error del jefe de cocina al mandar un Plato que aun no a sido terminadoSi el jefe de cocina se equivoca de Plato, este puede seleccionar el botón Pedidos De Mesa y se mostrará la interfaz de PEDIDO DE MESA

2.1.1 Se mostrará el interfaz PEDIDO DE MESA donde te pedirá el número de Mesa

2.1.2 Al ingresar ese número aparecerá los Platos preparados 2.1.3 después de ello se seleccionará la opción Pedido En

Proceso.

3. Precondiciones3.1. El jefe de cocina deberá estar logueado al sistema. 3.2. La base de datos debe estar habilitada.

4. Post-condiciones4.1Se ingresará la base de datos los platos que fueron atendidos.

5. Puntos de ExtensiónNO Presenta puntos de extensión cuando el jefe de

cocina no esté registrado


6. Prototipo:

3.9.2.3. CUS03 Ingresar al Sistema1. Atender Pedido

1.1. DescripciónPermite loguear a todos los usuarios del sistema, para así mantener la seguridad y la privacidad de cada uno.

1.2. Actor(es)Usuario

2. Flujo de Eventos

El caso de uso se inicia cuando el usuario abre la página web del restaurante.

2.1. Flujo Básico

1. El sistema muestra la interfaz INGRESAR en donde aparecen los campos de Usuario y Contraseña.2. EL usuario ingresara con su Usuario correspondiente.3. El usuario ingresara con su Contraseña.4. El usuario seleccionara la opción Aceptar para ingresar al sistema.5. EL sistema cierra la interfaz principal y termina el caso de uso.

2.2 Flujos Alternativos

2.1.4 Ingreso de loguin incorrectoSi ingresa un usuario y/o contraseña incorrecta, le aparecerá una ventana diciendo “Usuario y contraseña incorrectos”. El flujo continúa en el evento 5.

3. Precondiciones

3.1. El usuario debe estar asignado a una base de datos.3.2. La base de datos debe actualizarse diariamente.

4. Poscondiciones

4.1. El usuario accederá al sistema.


5. Puntos de Extensión

No existen puntos de extensión. 6. Prototipo

3.9.2.4. CUS04 Añadir Producto1. Añadir Producto

1.1. Descripción

El administrador certifica que algunos productos sean rentables es por eso que los añade a la carta.

1.2. Actor(es)

Administrador

2. Flujo de Eventos

El caso de uso inicia cuando el administrador selecciona la opción Añadir Producto.

2.1. Flujo Básico

1. El sistema mostrará la interfaz AÑADIR PRODUCTO en donde el administrador podrá rellenar todas las especificaciones del producto nuevo ya sean Nombre, Precio, etc.

2. El administrador seleccionará la opción Aceptar.


3. El sistema mostrará la interfaz CONFIRMACIÓN confirmando el producto añadido.

4. El administrador seleccionará la opción Aceptar.5. El sistema cierra la interfaz principal y termina el caso

de uso.

2.2. Flujos Alternativos

2.1.4 Especificación errónea ingresada Si no llena alguna especificación no podrá añadir el producto, en

consecuencia, el administrador seleccionará la opción Cancelar y el sistema regresará a la ventana anterior, en la cual podrá llenar dicha especificación. El flujo continúa en el evento 5.

3. Precondiciones

3.1.El administrador debe estar registrado y haber sido aceptado por el sistema.

3.2.Debe haber tomado en cuenta la rentabilidad del producto a añadir.

4. Poscondiciones

4.1.Se habrá añadido un nuevo producto a la carta.


No existen puntos de extensión.6. Prototipo


3.9.2.5. CUS05: Modificar Producto

1. Modificar Producto

1.1. Descripción

Al ser un dato erróneo alguna de las especificaciones de algún producto, el administrador modifica dicho producto.

1.2. Actor(es)

Administrador

2. Flujo de EventosEl caso de uso comienza cuando el administrador selecciona algún producto de la carta en el sistema.

2.1. Flujo Básico

1. El administrador seleccionará la opción Modificar Producto.2. El sistema le mostrará la interfaz EDITAR PRODUCTO en donde el

administrador podrá editar aquella especificación errónea de dicho producto.

3. El administrador seleccionará la opción Aceptar.4. El sistema cierra la interfaz principal y termina el caso de uso.


2.1.3. Selección errónea de un productoSi es que se equivocó al momento de escoger el producto, el administrador puede seleccionar la opción Cancelar y el sistema regresará a la ventana anterior. El flujo continúa en el evento 4.

3. Precondiciones

3.1. El administrador tiene que estar logueado.3.2. El administrador tiene que conocer que producto modificará.

4. Poscondiciones

4.1. Se habrá modificado un producto de la carta.


No existen puntos de extensión.

6. Prototipo


3.9.2.6. CUS06 Confirmar Venta Diaria1. Confirmar Venta Diaria

1.1. Descripción

El administrador verifica el total de boletas de las ventas del día, verifica el total de dinero recaudado, al coincidir registra la venta total del día.

1.2. Actor(es)

Administrador

2. Flujo de Eventos

El caso de uso empieza cuando el administrador selecciona la opción Visualizar Ventas Del Día.

2.1. Flujo Básico


1. El sistema muestra la interfaz VENTAS DIARIAS donde se visualiza el monto vendido en el día.

2. El administrador selecciona la opción Confirmar habiendo concordado el monto total de ventas diarias.

3. El sistema cierra la interfaz principal y termina el caso de uso.


2.1.2. Inconformidad del administradorSi el administrador no está de acuerdo, seleccionará la opción Cancelar y el sistema regresará a la ventana anterior. El flujo continúa en el evento 3.

3. Precondiciones

3.1. El administrador debe haber accedido al sistema.3.2. El administrador debe tener consigo las boletas de las

ventas del día.

4. Poscondiciones

4.1. El monto total de las ventas diarias queda confirmado y es guardado en la base de datos.


No tiene puntos de extensión.6. Prototipo


3.9.2.7. CUS07 Generar Orden

1. Generar Orden1.1 DescripciónEl cliente elige dentro de las opciones de productos disponibles por el

sistema.1.2 ActoresCliente

2. Flujo de EventosEl caso de uso inicia cuando el cliente “activa” el sistema tocando la pantalla y selecciona “pedir”.2.1 Flujo Básico

1.El sistema muestra la interfaz PRODUCTOS con Fotos y Precios,

Cantidad y Tiempo de Preparación. Incluye las opciones de Pedir y Mostrar Menú.

2.El cliente seleccionará la opción Pedir.2.1 El sistema cargará el producto a la cuenta y a lista de platos por preparar en el sistema. 3. El cliente seleccionará la opción Incidencia3.1 El sistema invoca al CU Registrar Incidencias (extend).

4. El cliente seleccionará la opción Mostrar Menú.4.1 El sistema cargará el menú principal del módulo.

5. Fin del Caso de Uso.

2.2 Flujo Alternativo2.1.2 El sistema muestra un tiempo de 2 minutos para cancelar la orden.2.1.3 El usuario cancela el pedido. El flujo continúa en el paso 5.

3. Precondiciones3.1 La base de datos debe estar habilitada.4. Post condiciones4.1 Se ingresará la base de datos los datos la lista de pedidos.5. Puntos de Extensión1. CU Registrar Incidencia, en el paso 3.7.1

Si el cliente ha introducido una cantidad que no se puede satisfacer con el stock actual del almacén el sistema generará un aviso de generación de incidencia y se podrá invocar al caso de uso Incidencia Pedido.

6. Prototipo


3.9.2.8. CUS08 Mostrar Orden

1. Mostrar Orden1.1 Descripción

Este caso de uso nos permite consultar todos los estados de nuestros platillos y ver si ya están siendo preparados

1.2 ActoresCliente

2. Flujo de EventosEl caso de uso inicia cuando el cliente “activa” el sistema tocando la pantalla y selecciona “Mostrar Ordenes”

2.1 Flujo BásicoEl sistema muestra la interfaz ORDENES con Nombres de los Platos, Precios, Cantidad, Tiempo y Estado. Incluye las opciones de Mostrar Menú.

1. El cliente seleccionará la opción Mostrar Menú.2.1 El sistema cargará el menú principal del modulo.

3. Fin del Caso de Uso

3. Precondiciones


3.1 La base de datos debe estar habilitada.4. Post condiciones4.1 Se mostrará la base de datos los datos la lista de pedidos.5. Puntos de Extensión

NO Presenta puntos de extensión.6. Prototipos

3.9.2.9. 0CUS 09 Mantener Perfil

1. Mantener Perfil1.1 Descripción

El actor podrá adicionar, modificar o eliminar perfiles del sistema. Cada perfil consta de una o más funcionalidades que serán utilizadas para la autentificación de usuarios

1.2 Actores


Administrador2. Flujo de Eventos

El caso de uso inicia cuando el programador entra al modulo de escritorio del sistema2.1 Flujo BásicoEl sistema muestra la interfaz PERFILES con Nombres de los Perfiles y los permisos que poseen. Incluye las opciones de Editar Perfil, Añadir Perfil, Eliminar Perfil.

1. El cliente seleccionará la opción Editar Perfil.2.1 El sistema cargará el menú para que el administrador pueda editar la información pertinente. 2.2 El administrador cambiará lo que sea necesario.2.3 El administrador seleccionará la opción Guardar.

2. El cliente seleccionará la opción Añadir Perfil.3.1 El sistema cargará el menú para que el administrador pueda rellenar la información sobre el nuevo perfil. 3.2 El administrador cambiará lo que sea necesario.3.3 El administrador seleccionará la opción Guardar.

3. El cliente seleccionará la opción Eliminar Perfil.4.1 El sistema cargará el menú para que el administrador elegir entre todos los perfiles disponibles.4.2 El administrador seleccionará el perfil o los perfiles que sean necesarios.4.3 El administrador seleccionará la opción Eliminar.4.4 El administrador seleccionará la opción Salir.

5. Fin del Caso de Uso.

3. Precondiciones3.1 La base de datos debe estar habilitada.

4. Post condiciones4.1 La lista de perfiles quedará actualizada.

5. Puntos de ExtensiónNO Presenta puntos de extensión.

6. Prototipo

3.9.2.10. CUS10 Mantener Usuario

1. Mantener Usuario1.1 DescripciónEl actor podrá adicionar, modificar o eliminar Usuarios del sistema. Cada perfil consta de una o más funcionalidades que serán utilizadas para la autentificación de usuarios


1.2 ActoresAdministrador

2. Flujo de EventosEl caso de uso inicia cuando el programador entra al módulo de escritorio del sistema

2.1 Flujo Básico

1. El sistema muestra la interfaz USUARIOS con Nombres de los Usuarios y que tipo de perfil poseen, al igual que sus datos (Nombre, DNI, Teléfono, Lugar de vivienda). Incluye las opciones de Editar Usuario, Añadir Usuario, Eliminar Usuario.

2. El cliente seleccionará la opción Editar Usuario.2.1 El sistema cargará el menú para que el administrador pueda editar la información pertinente. 2.2 El administrador cambiará lo que sea necesario.2.3 El administrador seleccionará la opción Guardar.

3. El cliente seleccionará la opción Añadir Usuario.3.1 El sistema cargará el menú para que el administrador pueda rellenar la información sobre el nuevo usuario. 3.2 El administrador cambiará lo que sea necesario.3.3 El administrador seleccionará la opción Guardar.

4. El cliente seleccionará la opción Eliminar Usuario.4.1 El sistema cargará el menú para que el administrador elegir entre todos los usuarios disponibles.4.2 El administrador seleccionará el usuario o usuarios que sean necesarios.4.3 El administrador seleccionará la opción Eliminar.4.4 El administrador seleccionará la opción Salir.

5. Fin del Caso de Uso

3. Precondiciones3.1 La base de datos debe estar habilitada.

4. Post condiciones4.1 La lista de usuarios quedará actualizada.


3.9.2.11. CUS11 Generar Reserva


1.Generar Reserva1.1 DescripciónEn este caso de uso se describe todo el procedimiento que el cliente hace para realizar una reserva en el restaurante “El Huanchaquito”.1.2 Actor(es)Cliente (Comensal)

2.Flujo de EventosEste caso de uso es iniciado por el usuario cuando selecciona en el menú Reservaciones, la opción Crear Reservación.2.1 Flujo Básico

1. El sistema le muestra la interfaz REALIZAR RESERVA donde se debe ingresar la información necesaria para realizar la reservación.

2. El cliente ingresa los datos solicitados en el formato, como Nombre, Documento de Identidad, Teléfono, Número de Comensales, Fecha y Hora, Correo Electrónico, entre otros.

3. El cliente selecciona la opción Buscar Mesas.3.1 El sistema convoca al CU Buscar Mesas (include).3.2 El cliente selecciona la mesa en la cual desea consumir.

3.3 El sistema captura la información y la ingresa en el campo Mesa.3.4 El cliente acepta las especificaciones ingresadas en los campos previos.3.5 El sistema captura la información ingresada.3.6 El sistema verifica la información ingresada.3.7 El sistema le muestra al cliente el costo según las especificaciones de la

reservación que se ingresó.3.8 El cliente acepta la reservación y el costo del mismo.3.9 El sistema guarda las especificaciones de la reservación.3.10 El sistema muestra en pantalla que la reservación se ha completado

con éxito y muestra el código correspondiente a esa reservación.

2.2 Flujos Alternativos 3.5. Ingreso incompleto de datos:

3.5.1 El sistema encuentra que hay campos a los cuales le falto el ingreso de datos.

3.5.2 El sistema muestra un mensaje de error diciendo que hay campos obligatorios que no han sido ingresados.

3.5.3 El sistema muestra de nuevo el formato para realizar la reservación con los datos ingresados por el usuario.

3.5.4 El cliente completa los campos que son necesarios para realizar la reservación.

3.5.5 El cliente acepta las especificaciones ingresadas en los campos previos.

3.5.6 El sistema captura la información ingresada.3.5.7 El sistema verifica la información ingresada.

Continúa en evento 3.73 Disponibilidad de mesas:

3.1 El sistema muestra un mensaje en el cual especifica que para el día solicitado no hay mesas disponibles.

3.2 El cliente acepta el mensaje.3.3 El cliente cambia la fecha para continuar con el proceso de


reservación en el restaurante.3.4 El cliente selecciona nuevamente la opción Buscar Mesas.

Continúa en evento 3.1

3. Precondiciones3.1 Mesas (Disponibles y No disponibles) y Número de Mesas deben estar en la

base de datos.

4. Poscondiciones4.1 La reserva queda almacenada en el sistema en la lista de Reservas

Realizadas.

5. Puntos de Extensión5.1 CU Buscar Mesas, en el paso 3.1

Si el cliente ha seleccionado una fecha en la cual no hay mesas disponibles, el sistema solicitara escoger otra fecha y/o hora. De haber mesas disponibles en la fecha y/o hora escogida este caso de uso las mostrará para su posterior selección.

6. Prototipo


3.9.2.12. Especificación de caso de uso: Confirmar Reserva

1. Confirmar Reserva1.1 Descripción

En este caso de uso se describe todo el procedimiento que el anfitrión hace para validar una reserva realizada y permitir el ingreso de los clientes (comensales) al establecimiento.

1.2 Actor(es)Anfitrión

2. Flujo de EventosEste caso de uso es iniciado por el anfitrión cuando selecciona en el menú Reservaciones, la opción Validar Reservación.

2.1 Flujo Básico 1. El sistema le muestra al usuario la interfaz VALIDAR RESERVACIÓN el cual

consta con dos campos para ingresar datos.2. El anfitrión ingresa los siguientes datos a quien hizo la reserva en el

formulario: Documento de Identidad y Código de Reserva.3. El anfitrión selecciona la opción Validar Datos.4. El sistema captura la información ingresada.5. El sistema verifica la información ingresada.6. El sistema le muestra al anfitrión un mensaje en pantalla que los datos son

correctos.7. El anfitrión selecciona la opción Salir que está en el mensaje.8. El sistema cambia el estado de la reservación, de Reservación Realizada a

Reservación Atendida.

2.2 Flujos Alternativos 3. Ingreso incorrecto de datos:

3.1 El anfitrión selecciona la opción Validar Datos.3.2 El sistema captura la información ingresada.3.3 El sistema verifica la información ingresada.3.4 El sistema le muestra al anfitrión un mensaje en pantalla que los datos son incorrectos.3.5 El anfitrión selecciona la opción Aceptar.3.6 El sistema solicita los datos nuevamente.3.7 El anfitrión ingresa los siguientes datos a quien hizo la reserva en el formulario: Documento de Identidad y Código de Reserva.3.8 El anfitrión selecciona la opción Validar Datos.3.9 El sistema captura la información ingresada.3.10 El sistema verifica la información ingresada.3.11 El sistema le muestra al anfitrión un mensaje en pantalla que los datos son correctos.3.12 El anfitrión selecciona la opción Salir que está en el mensaje.3.13 El sistema cambia el estado de la reservación, de Reservación


Realizada a Reservación Atendida.

3. Precondiciones3.1 La Reservación Realizada por el cliente debe estar en la base de datos.

4. Poscondiciones4.1 El estado de la reserva cambia, de Reservación Realizada a Reservación

Atendida.


6. Prototipo

3.9.2.13. Generar Orden de Atención

1. Generar Orden de Atención1.1 Descripción

En este caso de uso se describe todo el procedimiento que el anfitrión hace para crear una orden de atención y permitir el ingreso de los clientes (comensales) al establecimiento.

1.2 Actor(es)Anfitrión


2. Flujo de EventosEste caso de uso es iniciado por el usuario cuando selecciona en el menú Reservaciones, la opción Generar Orden de Atención.

2.1 Flujo Básico 1. El sistema le muestra al anfitrión la interfaz GENERAR ORDEN DE ATENCIÓN

donde se debe ingresar la información necesaria para realizar la una orden de atencíón

2. El anfitrión ingresa los datos del cliente en el formato, como Nombre, Documento de Identidad, Número de Comensales.

3. El anfitrión selecciona la opción Buscar Mesas.3.1. El sistema convoca al CU Buscar Mesas (include).3.2. El anfitrión selecciona la mesa en la cual el cliente desea consumir.3.3. El sistema captura la información y la ingresa en el campo Mesa.3.4. El anfitrión acepta las especificaciones ingresadas en los campos previos.3.5. El sistema captura la información ingresada.3.6. El sistema verifica la información ingresada.3.7. El sistema guarda las especificaciones de la Orden de Atención.3.8. El sistema muestra en pantalla que la Orden de Atención se ha

completado con éxito y muestra el código correspondiente a esa Orden.

2.2 Flujos Alternativos 3.5. Ingreso incompleto de datos:

3.5.1 El sistema encuentra que hay campos a los cuales le falto el ingreso de datos.

3.5.2 El sistema muestra un mensaje de error diciendo que hay campos obligatorios que no han sido ingresados.

3.5.3 El sistema muestra de nuevo el formato para realizar la orden de atención con los datos ingresados por el usuario.

3.5.4 El anfitrión completa los campos que son necesarios para realizar la orden de atención.

3.5.5 El anfitrión acepta las especificaciones ingresadas en los campos previos.

3.5.6 El sistema captura la información ingresada.3.5.7 El sistema verifica la información ingresada.

El flujo continúa en el evento 3.7

3. Precondiciones3.1 Mesas (Disponibles y No disponibles) y Número de Mesas deben estar en la

base de datos.

4. Poscondiciones4.1 La Orden de Atención queda registrada en la base de datos.

5. Puntos de Extensión5.1 CU Buscar Mesas

Si el cliente ha seleccionado una fecha en la cual no hay mesas disponibles, el sistema solicitara escoger otra fecha y/o hora. De haber mesas disponibles en


la fecha y/o hora escogida este caso de uso las mostrará para su posterior selección.

3.9.2.14. CUS14 Generar Cuenta

1. Generar Cuenta1.1 Descripción

En este caso de uso se describe todo el procedimiento que el cliente hace para generar la cuenta de su consumo.

1.2 Actor(es)Cliente (Comensal)

2. Flujo de EventosEste caso de uso es iniciado por el usuario cuando selecciona en el menú Estado de Cuenta, la opción Generar Cuenta.

2.1 Flujo Básico 1. El sistema le muestra al usuario la interfaz ESTADO DE CUENTA el cual consta

de una imagen autogenerada con los datos del consumo y una opción de Pagar Cuenta.

2. El sistema convoca al CU Generar Cuenta2.1 El sistema muestra un comprobante de pago virtual con el monto y los

productos específicos.3. El cliente selecciona la opción Pagar Cuenta.

3.1. El sistema muestra en pantalla un mensaje: “En seguida será atendido por el mozo”.

4. El cliente selecciona la opción Aceptar.

3. Precondiciones3.1 Orden de atención o Reserva Atendida registrada en el sistema.

4. Poscondiciones4.1 Estado de Cuenta registrada en el sistema.

5. Puntos de Extensión5.1 CU Generar Cuenta, en el paso 2

El sistema solicita a la base de datos los productos que han sido registrados en el número de cuenta correspondiente.


6. Prototipo


Documents

Especificaciones de Software Restaurante Huanchaquito