1
2.1 SUSTENTO FUNCIONAL
2.5.1 Requerimientos funcionales
Business
Use Case
Bussines Worker Requerimientos Use Case Actor Prioridad
(Bussines
Actor)
RF01:El sistema deberá mostrar un login para el ingreso de usuario.
BW_Usuario RF02:El Sistema deberá verificar si es usuario normal o jefe de ventas. BA_Usuario 1
RF03:El sistema deberá acceder con los privilegios para cada usuario.
RF01: El sistema deberá mostrar menú disponible en la carta.
BUC01: BW_Recepcionista RF02: El sistema deberá mostrar los precios de cada menú. UC01_BuscarPlato BA_Recepcionista 2
Realizar
Pedido RF03:El Sistema Podrá Buscar Menú en la lista.
Presencial RF03: El sistema deberá ingresar a través de un menú de elección, el pedido que ah
realizado el cliente.
UC02_ Generar
BW_Cajero RF04: El sistema debe calcular el costo total del pedido. BA_cajero 1
Boleta.
RF05: El sistema permitirá almacenar el monto pagado por una mesa dentro de un bd.
RF06 El sistema permitirá visualizar una Comprobante generado.
BUC02:
Realizar UC02_ Generar
El Sistema cumplirá las mismas funciones BA_ Operador 2
Pedido Boleta.
Telefónico
BUC03: RF15: El sistema permitirá generar un reporte de ventas.
Solicitar BA_Jefe de
BW_Cajero UC_ReporteVentas 1
reportes RF16: El sistema mostrar la fecha y la mesa dentro de cada venta mostrada. ventas
de ventas
2
2.5.2 Requerimientos no funcionales
MATRIZ DE REQUERIMIENTOS NO FUNCIONALES
TIPO REQUERIMIENTO RESPONSABLE / ACTOR PRIORIDAD
El sistema debe contar con manuales de usuario. GERENTE
La nueva aplicación debe manejar fuentes del alfabeto en Inglés, Idiomas latinos (Español, EQUIPO DE DESARROLLO
Frances, Portugués, Italiano), Arábico y Chino.
El sistema debe contar con un módulo de ayuda en línea. USUARIO
Usability
La aplicación web debe poseer un diseño “Responsive” a fin de garantizar la adecuada EQUIPO DE DESARROLLO
visualización en múltiples computadores personales, dispositivos tableta y teléfonos
inteligentes.
El sistema deberá tener iconos standares que representen ciertos procesos. EQUIPO DE DESARROLLO
El sistema debe contar con colores que no cancen a la vista. EQUIPO DE DESARROLLO
El sistema debe ser intuitivo. GERENTE
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 EQUIPO DE DESARROLLO
usuario final.
Reliability
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 GERENTE
operación total.
3
El promedio de duración de fallas no podrá ser mayor a 15 minutos. GERENTE
La probabilidad de falla del Sistema no podrá ser mayor a 0,05. GERENTE
Toda funcionalidad del sistema y transacción de negocio debe responder al usuario en EQUIPO DE DESARROLLO
menos de 5 segundos.
Performance El sistema debe ser capaz de operar adecuadamente con hasta 100.000 usuarios con EQUIPO DE DESARROLLO
sesiones concurrentes.
El sistema debera redondear los números decimales con una precisión de 2. EQUIPO DE DESARROLLO
El tiempo para iniciar o reiniciar el sistema no podrá ser mayor a 5 minutos. EQUIPO DE DESARROLLO
El sistema deberá responder a los estimulos de los usuarios en 2 segundos. EQUIPO DE DESARROLLO
El sistema debe ser multiplataforma. EQUIPO DE DESARROLLO
Los datos modificados en la base de datos deben ser actualizados para todos los usuarios EQUIPO DE DESARROLLO
que acceden en menos de 2 segundos.
Supportability
La aplicación debe ser compatible con todas las versiones de Windows, desde Windows EQUIPO DE DESARROLLO
95.
El sistema debe ser de fácil mantenimiento. 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. EQUIPO DE DESARROLLO
El sistema debe asegurar que los datos estén protegidos del acceso no autorizado 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
