• Author / Uploaded
• perro

Citation preview

1

2.1 SUSTENTO FUNCIONAL 2.5.1 Business Use Case (Bussines Actor)

BUC01: Realizar Pedido Presencial

Requerimientos funcionales

Bussines Worker

Use Case

RF01:El sistema deberá mostrar un login para el ingreso de usuario. RF02:El Sistema deberá verificar si es usuario normal o jefe de ventas. BW_Usuario RF03:El sistema deberá acceder con los privilegios para cada usuario. RF01: El sistema deberá mostrar menú disponible en la carta. BW_Recepcionista RF02: El sistema deberá mostrar los precios de cada menú. RF03:El Sistema Podrá Buscar Menú en la lista. RF03: El sistema deberá ingresar a través de un menú de elección, el pedido que ah realizado el cliente. BW_Cajero

BUC02: Realizar Pedido Telefónico BUC03: Solicitar reportes de ventas

Requerimientos

RF04: El sistema debe calcular el costo total del pedido. RF05: El sistema permitirá almacenar el monto pagado por una mesa dentro de un bd. RF06 El sistema permitirá visualizar una Comprobante generado. El Sistema cumplirá las mismas funciones

Actor

Prioridad

BA_Usuario

1

UC01_BuscarPlato BA_Recepcionista

2

UC02_ Generar Boleta.

BA_cajero

1

UC02_ Generar Boleta.

BA_ Operador

2

UC_ReporteVentas

BA_Jefe de ventas

1

RF15: El sistema permitirá generar un reporte de ventas. BW_Cajero

RF16: El sistema mostrar la fecha y la mesa dentro de cada venta mostrada. 2

2.5.2

Requerimientos no funcionales

MATRIZ DE REQUERIMIENTOS NO FUNCIONALES TIPO

Usability

Reliability

REQUERIMIENTO El sistema debe contar con manuales de usuario.

RESPONSABLE / ACTOR GERENTE

La nueva aplicación debe manejar fuentes del alfabeto en Inglés, Idiomas latinos (Español, Frances, Portugués, Italiano), Arábico y Chino. El sistema debe contar con un módulo de ayuda en línea.

EQUIPO DE DESARROLLO

La aplicación web debe poseer un diseño “Responsive” a fin de garantizar la adecuada visualización en múltiples computadores personales, dispositivos tableta y teléfonos inteligentes. El sistema deberá tener iconos standares que representen ciertos procesos. El sistema debe contar con colores que no cancen a la vista. El sistema debe ser intuitivo. El sistema deberá realizar backup a la base de datos.

EQUIPO DE DESARROLLO

El sistema debe proporcionar mensajes de error que sean informativos y orientados a usuario final. El sistema deberá seguir funcionando a pesar de fallos.

EQUIPO DE DESARROLLO

La tasa de tiempos de falla del sistema no podrá ser mayor al 0,5% del tiempo de operación total. 3

USUARIO

EQUIPO DE DESARROLLO EQUIPO DE DESARROLLO GERENTE EQUIPO DE DESARROLLO

EQUIPO DE DESARROLLO GERENTE

PRIORIDAD

El promedio de duración de fallas no podrá ser mayor a 15 minutos. La probabilidad de falla del Sistema no podrá ser mayor a 0,05.

Performance

Supportability

GERENTE GERENTE

Toda funcionalidad del sistema y transacción de negocio debe responder al usuario en menos de 5 segundos.

EQUIPO DE DESARROLLO

El sistema debe ser capaz de operar adecuadamente con hasta 100.000 usuarios con sesiones concurrentes. El sistema debera redondear los números decimales con una precisión de 2. El tiempo para iniciar o reiniciar el sistema no podrá ser mayor a 5 minutos. El sistema deberá responder a los estimulos de los usuarios en 2 segundos. El sistema debe ser multiplataforma.

EQUIPO DE DESARROLLO

Los datos modificados en la base de datos deben ser actualizados para todos los usuarios que acceden en menos de 2 segundos.

EQUIPO DE DESARROLLO

La aplicación debe ser compatible con todas las versiones de Windows, desde Windows 95. El sistema debe ser de fácil mantenimiento.

EQUIPO DE DESARROLLO

+

EQUIPO DE DESARROLLO EQUIPO DE DESARROLLO EQUIPO DE DESARROLLO EQUIPO DE DESARROLLO

EQUIPO DE DESARROLLO

EQUIPO DE DESARROLLO

El nuevo sistema debe desarrollarse aplicando patrones y recomendaciones de programación que incrementen la seguridad de datos.

4

GERENTE

Los permisos de acceso al sistema podrán ser cambiados solamente por el administrador de acceso a datos.

GERENTE

Si se identifican ataques de seguridad o brecha del sistema, el mismo no continuará operando hasta ser desbloqueado por un administrador de seguridad. El sistema será desarrollado para las plataformas PC y Macintosh. El sistema debe asegurar que los datos estén protegidos del acceso no autorizado

EQUIPO DE DESARROLLO GERENTE

2.2 PROPUESTA DE SOLUCIÓN 2.5.1 Objetivos.  Diseñar y evaluar un plan de negocio para una solución de restaurantes a través de una herramienta tecnológica. 5

Objetivos específicos  Definir un estudio de mercado que permita determinar el mercado potencial, así como las características del servicio que mejor respondan a las necesidades de los clientes.  Definir el diseño, la operación, los recursos, los costos y la capacidad del servicio.  Establecer el análisis de gestión en temas de la planeación estratégica, la estructura organizacional y los aspectos legales.  Elaborar el estudio financiero que evalúe la factibilidad del negocio y su viabilidad financiera.  Establecer el plan de implementación de la metodología.

2.5.2 Alcance Aspectos que incluyen el proyecto Aspectos excluidos del proyecto

6

2.5.1 Características y Funcionalidades Características  El sistema utiliza métodos propios del lenguaje de programación para evitar inyecciones sql.  El sistema es compatible en cualquier navegador.  El sistema usa un gestor de base de datos GPL.  El sistema utiliza íconos estandarizados.  El sistema usa colores que no cansen la vista.  El sistema se adapta a cualquier tipo de servicio.  El sistema está basado en una arquitectura 3n capa (Modelo, vista y controlador). Funcionalidades El sistema permitirá:  Visualizar las mesas disponibles y ocupadas.  Registrar, visualizar y modificar los datos del cliente. 7

 Actualizar el estado de las mesas.  Visualizar las boletas emitidas.  Contabilizar la cantidad de platos vendidos durante el día, semana o mes. 2.5.2

Beneficios Esperados

 Mejorar en el proceso de atención al cliente.  Mejorar la rapidez al momento de reportes.  Mayor rapidez en la búsqueda de un paltos.  Mejor visibilidad de información.  Menor riesgo a perder la información 1. Estandarización del ingreso de información

8