Sesion 03B - Requerimientos - IEEE-Estandar-830 - Plantilla

Especificación de Requisitos de Software
Proyecto: Fly Order

Revisión
Documento validado por las partes en fecha:
Cliente Equipo de Desarrollo
[Nombre] Carlos Alberto Ríos Naranjo

[Cargo] [Cargo]
[Nombre] Kevin Alexis Marin Díaz

[Cargo] [Cargo]
[Nombre] Emanuel Álvarez Vargas

[Cargo] [Cargo]
Rev.
Especificación de Requisitos de Software Pág. 3
1 CONTENIDO
Contenido
1 CONTENIDO......................................................................................................3
2 INTRODUCCIÓN................................................................................................6
2.1 PROPÓSITO...................................................................................................6
2.2 ALCANCE.......................................................................................................6
2.3 DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS....................................7
2.4 REFERENCIAS..............................................................................................7
2.5 RESUMEN......................................................................................................7
3 DESCRIPCIÓN GENERAL................................................................................8
3.1 PERSPECTIVA DEL PRODUCTO.................................................................8
3.2 FUNCIONALIDAD DEL PRODUCTO............................................................8
3.3 CARACTERIZACIÓN DE LOS USUARIOS..................................................8
3.4 RESTRICCIONES..........................................................................................9
3.5 SUPOSICIONES Y DEPENDENCIAS.........................................................10

Rev.
3.6 EVOLUCIÓN PREVISIBLE DEL SISTEMA.................................................10
4 REQUISITOS ESPECÍFICOS..........................................................................11
4.1 REQUISITOS COMUNES............................................................................11
4.1.1 INTERFACES DE HARDWARE...............................................................11
4.1.2 INTERFACES DE SOFTWARE................................................................11
4.1.3 INTERFACES DE COMUNICACIÓN.......................................................12
4.2 REQUISITOS FUNCIONALES.....................................................................12
4.2.1 REQUISITO FUNCIONAL 1.....................................................................12
4.3 REQUISITOS NO FUNCIONALES..............................................................21

Rev.
4.3.1 REQUISITOS DE RENDIMIENTO............................................................22
4.3.2 REQUISITOS DE SEGURIDAD...............................................................22
4.3.3 REQUISITOS DE CONFIABILIDAD........................................................22
4.3.4 REQUISITOS DE DISPONIBILIDAD.......................................................23
4.3.5 REQUISITOS DE MANTENIBILIDAD......................................................23
4.3.6 REQUISITOS DE PORTABILIDAD..........................................................23
5 ANEXOS...........................................................................................................24

Rev.
2 INTRODUCCIÓN
2.1 PROPÓSITO
Generar una nueva forma de comunicación que permita a los clientes de
restaurantes, bares, etc. mayor interacción con estos. Facilitando a los usuarios
el acceso a los servicios de estos locales, permitiendo al usuario hacer uso de
los servicios que ofrecen estos locales, ya sea haciendo una reserva o un
pedido en determinado local, buscando una mayor agilidad en el momento de
realizar dichas peticiones.
Se cree que al agilizar el acceso a la información de estos locales y al uso de
los servicios con que estos disponen, hace de estos, establecimientos
actualizados y se contribuye a ahorrar tiempo y dinero.
2.2 ALCANCE
Constituir un estado del arte en el que exista una alta interacción y
comunicación entre los diferentes establecimientos comerciales y sus clientes,
de tal manera que se fortalezca altamente la atención de los comensales,
generando beneficios tanto para los establecimientos como para los clientes.
Pasados seis meses de la implementación del aplicativo el establecimiento
presentara una mejora en la calificación de la atención de los clientes. El
desarrollo del aplicativo tendrá una duración de tres meses, y, funcionará como
un aplicativo WEB, así como para Android y iOS; al culminarse cumplirá con los
estándares de calidad de la norma Ieee830.

Rev.
2.3 DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS

Carta: Lista de platos y bebidas con sus respectivos precios que ofrece un
restaurante o establecimiento análogo.
Establecimiento: Local, casa o edificio donde se realiza una actividad
comercial, industrial, sanitaria o de otro tipo.
Pedido: Encargo de géneros que se hace a un fabricante o a un vendedor.
Reservación: Acto de reservar; particularmente, acto de apartar un lugar en un
medio de transporte, en un hotel, en un restaurante, para un espectáculo, etc.
2.4 REFERENCIAS
Referencia Título Ruta Fecha Autor
Rojo, S.D. Requerimientos https://www.seman 2012 Silvana del
(2012). no funcionales ticscholar.org/pape Valle Rojo,
Requerimientos para r/Requerimientos- Alejandro
No funcionales aplicaciones No-funcionales- Oliveros
para Web para-aplicaciones-
aplicaciones Web-
Web. Rojo/cf53787d2fc4
ee4348237cdfa87
4a564a0b18b98
2.5 RESUMEN
En este documento se relacionan y explican todos los requisitos necesarios

para poder llevar a cabo la construcción de este software para dispositivos
móviles que permite el acceso a la información detallada sobre los restaurantes
y bares (reservas, carta, etc.), usando como caso de estudio en este caso los
diferentes restaurantes y bares de la ciudad de Manizales donde prácticamente
muy pocos cuentan con este sistema bien implementado, con el fin de ahorrar

Rev.
tiempo y dinero a los clientes. Dicha aplicación permitirá la consulta de los

detalles y de lo particular de cada local, para así realizar pedidos con
anticipación llegando al lugar y encontrando el pedido prácticamente listo. Las
pruebas para validar y verificar el correcto funcionamiento del software también
se realizarán. Además, para identificar cada punto, se implementa en este caso
una prueba con un número determinado de usuarios para validar el
funcionamiento óptimo de este aplicativo.
3 DESCRIPCIÓN GENERAL
3.1 PERSPECTIVA DEL PRODUCTO

El aplicativo proporcionará a sus usuarios un panorama completo de
restaurantes, bares, discotecas y demás establecimientos; que tiene cerca,
además, le mostrará si existen mesas disponibles y realizar reservaciones, así
como ver la carta de productos y si lo desea puede ordenar a través del
aplicativo.
3.2 FUNCIONALIDAD DEL PRODUCTO
El producto contendrá información concreta, suficiente y actualizada de todos

los locales conectados a la plataforma, además de tener los menús con todos
los detalles de cada uno de estos, para así brindarle al cliente una excelente
atención y experiencia al momento de ordenar.
3.3 CARACTERIZACIÓN DE LOS USUARIOS

Tipo de usuario Usuario común, mayor a 15 años
Formación Educación básica
Habilidades Se requiere conocimiento básico en manejo de un
computador o celular, es decir, deberá poder
descargar y realizar un registro.
Actividades Navegar en la aplicación para poder visualizar la

Rev.
gran variedad de locales (restaurantes, bares) con

que cuenta dicha app, para así poder satisfacer el
gusto de cada persona, y poder brindarle una
excelente experiencia.
Tipo de usuario Usuario encargado de administrar los servicios de

cada establecimiento
Formación Educación básica
Habilidades Se requiere conocimiento básico en manejo de un
computador o celular, es decir, poder revisar las
peticiones que hayan realizado otros usuarios.
Actividades Navegar en la aplicación para visualizar las
actualizaciones y pedidos que han realizado los
usuarios, así como actualizar la carta de
productos y precios.
3.4 RESTRICCIONES
Dicho software trabajará en computadores y celulares, este sistema funcionará

en sistemas operativos Windows, iOS y Android. Se debe tener en cuenta que
al momento que el usuario esté interactuando con la aplicación, se restringe
todo tipo de lenguaje obsceno o sexual al momento de darle una calificación a
determinado local, todo esto porque también se encuentran menores de edad
interactuando en dicha aplicación.

Rev.
3.5 SUPOSICIONES Y DEPENDENCIAS
Como cada local va actualizando sus cartas entonces se debe estar

actualizando la información del aplicativo constantemente, para brindar un buen
servicio tanto a los locales como a los usuarios, puesto que estos tendrán todos
los datos actualizados tales como teléfonos, direcciones, cartas, etc. Además,
de que se dará una interacción en tiempo real y continúa debido a que
constantemente están ingresando órdenes.
3.6 EVOLUCIÓN PREVISIBLE DEL SISTEMA

Se planea implementar el aplicativo en principio como una aplicación WEB, una
vez esté disponible al público se lanzará una versión móvil tanto para iOS como
Android, así como una integración de nuevas actualizaciones donde se
agreguen nuevas herramientas al aplicativo, para lograr generar un producto
más detallado y perfectamente adaptable a cada local, se plantea la generación
de un producto especial, que marque la diferencia en el mercado a través de la
atención del cliente.

Rev.
4 REQUISITOS ESPECÍFICOS
Registro de establecimientos: Permitirá a cada establecimiento realizar un
registro, así como una actualización de sus datos para ofrecer un mejor servicio
a sus clientes.
Registro de usuarios: Permitirá a personas mayores de 15 años, registrarse y

actualizar sus datos.
Actualización de cartas: Cada establecimiento podrá realizar actualizaciones

constantes de los productos ofertados, así como sus precios y demás
especificaciones.
Realización de reservaciones y pedidos: Deberá proporcionar a los usuarios un

formulario en el cual puedan realizar una reservación o un pedido, de tal
manera que todos los datos se actualicen dentro de las mesas disponibles del
establecimiento, así como la notificación de la orden al establecimiento.
4.1 REQUISITOS COMUNES
4.1.1 Interfaces de hardware

Tanto para la administración como para los usuarios, deben estar conectados a
la red. Para la carga de la página web tan solo se debe contar con un
navegador web y una máquina con la capacidad de correr dicho navegador por
lo que el requerimiento de hardware es mínimo.
4.1.2 Interfaces de software
El sistema propuesto en el presente documento necesita para su ejecución un
pc con un sistema operativo Windows o Linux en el que sea posible ejecutar un
navegador web; o un teléfono móvil o smartphone que cuente con un sistema

Rev.
operativo instalado Android 2.2 o superior, o iOs 6 o superior; de esta manera

podrán correr el aplicativo o si lo desean a través del navegador web
previamente instalado.
4.1.3 Interfaces de comunicación

Las interfaces de comunicación deben contener los estándares Web y
fundamentalmente se deben basar en protocolos HTTP, HTTPS para la
comunicación con usuarios finales.
4.2 REQUISITOS FUNCIONALES
4.2.1 Requisito funcional 1

● Prototipo página principal
● El objetivo de este prototipo es mostrar al usuario de forma rápida todas

las opciones del aplicativo, de tal manera que pueda acceder a cualquier
módulo de forma rápida.
● Este prototipo cuenta con dos botones principales a través de los cuales
se puede buscar establecimientos y hacer reservas, además cuenta con un
menú en el cual se pueden acceder a las opciones de inicio, realizar reservas,

Rev.
ver los pedidos realizados y listar los restaurantes, bares, discotecas y demás
que estén cerca y disponibles para realizar reservas.
● El botón “Buscar Restaurantes o Bares” lleva al prototipo para realizar
búsquedas de los diferentes establecimientos registrados.
El botón “Ir a Reservar” lleva al prototipo para realizar reservaciones en
cualquier establecimiento que se especifique.
Dentro del menú se tienen cinco opciones las cuales aplican para cualquier
prototipo en el que se esté ubicado los cuales son:
1. Inicio: Este conduce desde cualquier prototipo en el que se esté
navegando al prototipo de página principal.
2. Hacer reservas: Este conduce al prototipo para realizar una reservación.
3. Pedidos: Este conduce al prototipo para visualizar todos los pedidos
realizados y los pendientes aún.
4. Lista de Restaurantes y Bares: Este conduce al prototipo para realizar
búsquedas de los diferentes establecimientos registrados.
● Durante el primer mes se esperan alrededor de 70 a 100 usuarios sin
embargo se espera un incremento gradual del 60% cada mes.
● Diariamente se espera recibir unos 50 usos diariamente durante los
primeros 6 meses sin embargo se espera que este valor tenga un incremento
conforme pasa el tiempo.
● El tiempo de espera máximo de una petición será de 2 segundos.

● Prototipo de Login

Rev.
● El objetivo de este prototipo es permitir a los usuarios ingresar al

aplicativo mediante un usuario y contraseña, además, de permitir un registro a
los usuarios que aún no se encuentren dentro de la plataforma.
● En este prototipo se tienen entradas por dos submódulos el de ingreso y
el de registro. En el de ingreso se tienen:

Rev.
Usuario: En esta entrada el usuario ingresa su usuario único que lo reconoce

en el sistema.
Contraseña: En esta entrada el usuario ingresa su contraseña la cual le
proporciona un acceso seguro al aplicativo.
Por otro lado, en el submódulo de registro se tienen las siguientes entradas:
Usuario: En esta entrada el usuario ingresa su nombre de usuario el cual debe
ser único en la base de datos con el cual lo reconocerá el sistema.
Contraseña: En esta entrada el usuario ingresa una contraseña la cual le
brindará un acceso seguro a la aplicación por lo que debe cumplir con unos
requerimientos mínimos de seguridad.
Correo Electrónico: En esta entrada el usuario ingresa su correo electrónico de
tal manera que se pueda realizar una validación de seguridad de la cuenta, así
como la recuperación de contraseña en caso de ser necesario.
● Este prototipo al contar con dos submódulos los botones se reparten de
la siguiente manera. En el submódulo de ingreso se encuentra el botón “Iniciar
Sesión” el cual envía una petición para verificar que la información ingresada
sea correcta, en caso de que sí, dirigirá al usuario a la página principal; y si no
le pedirá que corrija la información. El botón “Crear Cuenta” nos cambiará al
submódulo de registro.
Dentro de este submódulo tenemos el botón “Registro” el cual recolecta toda la
información y valida que sea correcta, en caso de que si ingresa el nuevo
usuario al sistema.
Por otro lado, ambos módulos cuentan con el botón “¿Olvidaste la
Contraseña?” el cual dirige el usuario al prototipo de recuperación de la
contraseña en caso de que este la haya olvidado.
● El botón “Iniciar Sesión” lleva al prototipo de la página principal.
El botón “Crear Cuenta” lleva al submódulo de registro del prototipo “Login”.
El botón “Registro” lleva al submódulo de inicio de sesión del prototipo “Login”.

Rev.
El botón “¿Olvidaste tu contraseña?” lleva al prototipo de recuperación de

contraseña.
• Durante el primer mes se esperan alrededor de 20 a 25 usuarios sin

• Diariamente se espera recibir unos 25 usos diariamente durante los
• El tiempo de espera máximo de una petición será de 3 a 4 segundos.

● Prototipo de Reservación
● El objetivo de este prototipo es permitirles a los usuarios realizar

reservaciones en cualquier establecimiento que se encuentre registrado dentro
del aplicativo.
● Este prototipo cuenta con las siguientes entradas:
Restaurante: En esta entrada el usuario ingresa el nombre del establecimiento
en caso de que no lo haya seleccionado previamente.

Rev.
Fecha Reserva: En esta entrada el usuario ingresa la fecha en la que desea

realizar la reservación.
Hora reserva: En esta entrada el usuario ingresa la hora en la que desea
realizar la reservación.
Número de Personas: En esta entrada el usuario ingresa el número de
personas para las cuales desea realizar la reservación.
● El botón “Reservar Ahora” guarda los datos de la reservación y notifica
al establecimiento.
● El botón “Reservar Ahora” envía al usuario al prototipo de “Pedidos”
● El tiempo de espera máximo de una petición será de 1.5 a 2 segundos.

Rev.

● Prototipo de Búsqueda de Establecimientos
● El objetivo de este prototipo es mostrar a los usuarios los diferentes

establecimientos disponibles, además, proporciona una barra de búsqueda en
caso de tener alguna preferencia especial.
● Este prototipo solo cuenta con una entrada, la cual permite al usuario
hacer una búsqueda de algún establecimiento en especial.
● El botón “Buscar” realiza una búsqueda de los establecimientos que
muestran coincidencias con los caracteres ingresados.
● El tiempo de espera máximo de una petición será de 1 a 1.5 segundos.

Rev.

● Prototipo de Pedidos
● El objetivo de este prototipo es mostrar a los usuarios las diferentes
órdenes y reservaciones que ha realizado tanto pasadas como pendientes.
● Este prototipo solo cuenta con una entrada, la cual permite al usuario
hacer una búsqueda de alguna orden o reservación en especial.
● El botón “Buscar” realiza una búsqueda de los pedidos, órdenes o
establecimientos que muestran coincidencias con los caracteres ingresados.
● El tiempo de espera máximo de una petición será de 1 a 1.5 segundos.

● Prototipo de Orden
● El objetivo de este prototipo es permitirles a los usuarios realizar
órdenes en cualquier establecimiento que se encuentre registrado dentro del
aplicativo, desde el establecimiento o a través de la reserva.
Búsqueda: la cual permite al usuario hacer una búsqueda de algún ítem dentro
de la carta o menú del establecimiento.
Cantidad: esta entrada permite al usuario registrar la cantidad de un producto
que desea adquirir.
● El botón “Buscar” realiza una búsqueda de algún ítem dentro de la carta
o menú del establecimiento que muestran coincidencias con los caracteres
ingresados.

Rev.
El botón “Agregar” selecciona el producto y la cantidad registrada y lo agrega al

carrito de compra.
El botón “Enviar Orden” pide al usuario una confirmación de pedido y
posteriormente carga esté al establecimiento correspondiente.
● El botón “Enviar Orden” envía al usuario al prototipo de “Pedidos”.

● Prototipo Restablecer Contraseña
● El objetivo de este prototipo es permitirle al usuario en caso de olvidar su
contraseña, tener la oportunidad de restablecer esta de forma segura para
continuar haciendo uso del aplicativo.
Usuario (Opcional): En esta entrada el usuario ingresara el nombre de usuario
con el que se registró en el aplicativo.
Correo Electrónico: En esta entrada el usuario ingresa el correo electrónico a
través del cual realizó el registro dentro del aplicativo.
● El botón “Recuperar contraseña” enviará un correo de validación al
usuario para restablecer la contraseña de su cuenta.

Rev.
● El tiempo de espera máximo de una petición será de 3 a 4 segundos.

● Prototipo de Vista de reservaciones y Pedidos
● El objetivo de este prototipo es mostrar a los diferentes establecimientos
las reservaciones y pedidos que tienen pendientes de tal manera que puedan
laborar con mayor agilidad.
● El botón “Confirmar Pedido” o “Confirmar Reservación” enviará una
señal confirmando la recepción del pedido o la reservación o pedido por parte
del establecimiento. Descripción de las acciones (botones) con sus respectivas
operaciones de procesamiento.
● El botón “Confirmar Pedido” o “Confirmar Reservación” lleva al prototipo
“Pedido” en donde se visualizarán las reservaciones y órdenes pendientes.
4.3 REQUISITOS NO FUNCIONALES
4.3.1 Requisitos de rendimiento

Los tiempos de respuesta relacionados con las páginas de consulta de
información, adición, modificación, eliminación, consulta de registros,
autenticación por parte del usuario, en forma general, no debe ser superior a
2.5 segundos. Sin embargo, y para que el sistema sea funcional, se espera que
el 90% de las transacciones no excedan el tiempo de respuesta entre 3 y 4

Rev.
segundos, sin embargo estos tiempos serán revisados en una etapa posterior
de diseño detallado, una vez se identifique y defina la infraestructura y entorno
tecnológico en el cual se implementará la solución.
4.3.2 Requisitos de seguridad

El sistema debe garantizar el control en el acceso, utilizando la autenticación
de los usuarios para la administración del mismo. Además de evitar
suplantaciones, algunas de las metodologías empleadas serán:
● Empleo de técnicas criptográficas.
● Registro de ficheros con “logs” de actividad.
● Asignación de determinadas funcionalidades a determinados módulos.
● Restricciones de comunicación entre determinados módulos.
4.3.3 Requisitos de confiabilidad

Los principales factores que se deben considerar para garantizar la fiabilidad
del sistema de información a desarrollar y por ende reducir al máximo la
presencia de fallos futuros en el sistema que afecten directamente el servicio
prestado por el mismo son los siguientes: Capacidad de recuperación: se debe
considerar como parte del diseño la capacidad para restablecer el nivel de
rendimiento y de recuperación de datos afectados directamente en el caso de
un fallo. Madurez: inicialmente se enfoca a la utilización de componentes base
o herramientas utilizadas para el diseño, construcción, pruebas e
implementación reconocidas que tengan más de 3 años en el mercado, que
tengan soporte por parte del fabricante y que cuente con una trayectoria.
4.3.4 Requisitos de disponibilidad

El sistema debe soportar una operación en alta disponibilidad, no debe
presentar ningún punto de fallo, es decir, debe estar provisto de mecanismos o
componentes que aseguren la continuidad del servicio. Por lo que al momento

Rev.
de realizar el diseño detallado se debe validar la arquitectura física en la que

funcionará el sistema. Se espera una disponibilidad mínima del 99.6 %.
4.3.5 Requisitos de mantenibilidad

Se debe realizar cada mes un mantenimiento del cual se hará cargo un
desarrollador, el cual sacará estadísticas de los nuevos usuarios, cuántas
personas hacen uso del aplicativo, y, cuales son las funciones a las que se les
da un mayor uso, de esta manera se dará una idea de que enfoques dentro del
aplicativo a futuro.
4.3.6 Requisitos de portabilidad

Los requisitos de portabilidad de este aplicativo son:
● Separar en segmentos los complementos que estén ligados al servidor
para así poder identificarlos.
● Tener en cuenta que el lenguaje utilizado para el desarrollo del software
debe ser retro compatible o multi plataforma.
● Todo compilador o plataforma utilizado en el desarrollo del software
debe ser guardado y documentado para saber en qué referenciar en caso de
incompatibilidad con un paquete externo o actualizado.

Rev.
5 Anexos
Pueden contener todo tipo de información relevante para la SRS pero que,
propiamente, no forme parte de la SRS.

Sesion 03B - Requerimientos - IEEE-Estandar-830 - Plantilla

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sesion 03B - Requerimientos - IEEE-Estandar-830 - Plantilla

Cargado por

Copyright:

Formatos disponibles

Especificación de Requisitos de Software

Proyecto: Fly Order

Cliente Equipo de Desarrollo

[Nombre] Carlos Alberto Ríos Naranjo

[Nombre] Kevin Alexis Marin Díaz

[Nombre] Emanuel Álvarez Vargas

2.3 DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS....................................7

3.1 PERSPECTIVA DEL PRODUCTO.................................................................8

3.2 FUNCIONALIDAD DEL PRODUCTO............................................................8

3.3 CARACTERIZACIÓN DE LOS USUARIOS..................................................8

3.5 SUPOSICIONES Y DEPENDENCIAS.........................................................10

Especificación de Requisitos de Software

3.6 EVOLUCIÓN PREVISIBLE DEL SISTEMA.................................................10

4.1 REQUISITOS COMUNES............................................................................11

4.1.1 INTERFACES DE HARDWARE...............................................................11

4.1.2 INTERFACES DE SOFTWARE................................................................11

4.1.3 INTERFACES DE COMUNICACIÓN.......................................................12

4.2 REQUISITOS FUNCIONALES.....................................................................12

4.2.1 REQUISITO FUNCIONAL 1.....................................................................12

4.2.2 REQUISITO FUNCIONAL 2.....................................................................13

4.2.3 REQUISITO FUNCIONAL 3.....................................................................16

4.2.4 REQUISITO FUNCIONAL 4.....................................................................18

4.2.5 REQUISITO FUNCIONAL 5.....................................................................19

4.2.6 REQUISITO FUNCIONAL 6.....................................................................19

4.2.7 REQUISITO FUNCIONAL 7.....................................................................20

4.2.8 REQUISITO FUNCIONAL 8.....................................................................21

4.3 REQUISITOS NO FUNCIONALES..............................................................21

Especificación de Requisitos de Software

4.3.1 REQUISITOS DE RENDIMIENTO............................................................22

4.3.2 REQUISITOS DE SEGURIDAD...............................................................22

4.3.3 REQUISITOS DE CONFIABILIDAD........................................................22

4.3.4 REQUISITOS DE DISPONIBILIDAD.......................................................23

4.3.5 REQUISITOS DE MANTENIBILIDAD......................................................23

4.3.6 REQUISITOS DE PORTABILIDAD..........................................................23

Especificación de Requisitos de Software

Especificación de Requisitos de Software

2.3 DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS

En este documento se relacionan y explican todos los requisitos necesarios

Especificación de Requisitos de Software

tiempo y dinero a los clientes. Dicha aplicación permitirá la consulta de los

3.1 PERSPECTIVA DEL PRODUCTO

3.2 FUNCIONALIDAD DEL PRODUCTO

El producto contendrá información concreta, suficiente y actualizada de todos

3.3 CARACTERIZACIÓN DE LOS USUARIOS

Especificación de Requisitos de Software

gran variedad de locales (restaurantes, bares) con

Tipo de usuario Usuario encargado de administrar los servicios de

Dicho software trabajará en computadores y celulares, este sistema funcionará

Especificación de Requisitos de Software

3.5 SUPOSICIONES Y DEPENDENCIAS

Como cada local va actualizando sus cartas entonces se debe estar

3.6 EVOLUCIÓN PREVISIBLE DEL SISTEMA

Especificación de Requisitos de Software

Registro de usuarios: Permitirá a personas mayores de 15 años, registrarse y

Actualización de cartas: Cada establecimiento podrá realizar actualizaciones

Realización de reservaciones y pedidos: Deberá proporcionar a los usuarios un

4.1 REQUISITOS COMUNES

4.1.1 Interfaces de hardware

Especificación de Requisitos de Software

operativo instalado Android 2.2 o superior, o iOs 6 o superior; de esta manera

4.1.3 Interfaces de comunicación

4.2 REQUISITOS FUNCIONALES

4.2.1 Requisito funcional 1