TCC - Telemática - Inácio Mota

Prévia do material em texto

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO CEARÁ 
IFCE CAMPUS TAUÁ 
TECNOLOGIA EM TELEMÁTICA 
 
 
 
 
INÁCIO HELDER PEREIRA MOTA 
 
 
 
 
DESENVOLVIMENTO DE UMA PLATAFORMA DE E-COMMERCE PARA 
CENTRALIZAR O COMÉRCIO TAUAENSE NA MODALIDADE DELIVERY 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
TAUÁ 
2020
INÁCIO HELDER PEREIRA MOTA 
 
 
 
DESENVOLVIMENTO DE UMA PLATAFORMA DE E-COMMERCE PARA 
CENTRALIZAR O COMÉRCIO TAUAENSE NA MODALIDADE DELIVERY 
 
 
Monografia apresentada ao curso Tecnologia 
em Telemática do Instituto Federal de 
Educação, Ciência e Tecnologia do Ceará 
(IFCE) - Campus Tauá, como requisito parcial 
para obtenção do Título de Tecnólogo. Área de 
concentração: Desenvolvimento de Software. 
 
Orientador: Prof. Jefferson Calixto Figueiredo. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
TAUÁ 
2020 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Dados Internacionais de Catalogação na Publicação 
Instituto Federal do Ceará - IFCE 
Sistema de Bibliotecas - SIBI 
Ficha catalográfica elaborada pelo SIBI/IFCE, com os dados fornecidos pelo(a) autor(a) 
___________________________________________________________________________ 
M917d Mota, Inácio Helder Pereira. 
 Desenvolvimento de uma Plataforma de E-commerce para centralizar o Comércio Tauaense na 
Modalidade Delivery / Inácio Helder Pereira Mota. - 2020. 
 61 f. : il. color. 
 
 Trabalho de Conclusão de Curso (graduação) - Instituto Federal do Ceará, Tecnologia em Telemática, 
Campus Tauá, 2020. 
 Orientação: Prof. Jefferson Calixto Figueiredo. 
 
 1. Ionic. 2. Firebase. 3. Commerce. 4. Development. 5. Software. I. Titulo. 
CDD 621.382 
___________________________________________________________________________ 
 
INÁCIO HELDER PEREIRA MOTA 
 
 
 
DESENVOLVIMENTO DE UMA PLATAFORMA DE E-COMMERCE PARA 
CENTRALIZAR O COMÉRCIO TAUAENSE NA MODALIDADE DELIVERY 
 
 
Monografia apresentada ao curso Tecnologia 
em Telemática do Instituto Federal de 
Educação, Ciência e Tecnologia do Ceará 
(IFCE) - Campus Tauá, como requisito parcial 
para obtenção do Título de Tecnólogo. Área de 
concentração: Desenvolvimento de Software. 
 
 
Aprovado (a) em: ____ / _____ / _____. 
 
 
BANCA EXAMINADORA 
 
_________________________________________________________ 
Prof. Jefferson Calixto Figueiredo (Orientador) 
Instituto Federal de Educação, Ciência e Tecnologia do Ceará (IFCE) – Campus Tauá 
 
_________________________________________________________ 
Prof. Saulo Anderson Freitas de Oliveira 
Instituto Federal de Educação, Ciência e Tecnologia do Ceará (IFCE) - Campus Tauá 
 
_________________________________________________________ 
Prof. José Aureliano Arruda Ximenes de Lima 
Instituto Federal de Educação, Ciência e Tecnologia do Ceará (IFCE) - Campus Tauá 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
A Deus. 
A minha família. 
Aos mestres. 
Aos Amigos. 
A minha companheira. 
AGRADECIMENTOS 
 
A Deus, por tudo. 
A minha família, em especial à minha mãe, pelo incentivo e suporte inicial. 
Aos amigos, pois me acompanharam durante a graduação e vivenciaram comigo os 
desafios, ajudando-me a vencê-los, agradeço o apoio, a paciência e as partidas de basquete 
que me aliviaram o estresse. 
Aos professores, que muito contribuíram com minha formação acadêmica, agradeço os 
ensinamentos, as orientações, as lições de vida, os risos, a atenção. Vocês são verdadeiros 
mestres. 
A minha digníssima mulher, por me manter de pé nos piores dias, comemorar comigo 
nos melhores, fazendo de uma parceria amorosa um real conto de fadas. Tão poderosa quanto 
uma deusa, mas tão humilde quanto uma reles mortal, levando-me a o encanto que hoje está 
sobre mim. Obrigado por todas as horas que me dedicara, Nayara S. Lima. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
“Computadores são inúteis. Eles só podem te 
dar respostas.” (Picasso). 
 
RESUMO 
 
Esse trabalho busca o desenvolvimento de uma aplicação móvel para serviços de delivery na 
cidade de Tauá, no Ceará. Obtendo as informações dos consumidores e dos empresários que 
atuam com delivery, este trabalho pretende descobrir qual o contexto atual desse atendimento 
remoto nessa cidade e com a análise dos resultados poder satisfazer ou não as hipóteses deste 
trabalho. Ainda, com uma avaliação do já corrente atendimento online pelos serviços atuais, 
descobrir quais os principais problemas encontrados por ambas as partes. Por fim, construir 
um produto de software que satisfaça tais problemas, avaliando questões financeiras, 
tecnológicas e especificidades locais. E ainda, mostrar cada etapa do desenvolvimento por 
meio de representação dos requisitos funcionais e não funcionais, diagramas de classe e de 
caso de uso, fluxogramas e interações esperadas e rotas alternativas. Logo, o resultado é 
apresentado nos tópicos finais por meio dos layouts do protótipo construído. O produto final é 
uma plataforma de comercio eletrônico composta por dois softwares para dispositivos 
portáteis, ambos desenvolvidos com a tecnologia híbrida Ionic Framework e o banco em 
nuvem Firebase, logo, poderá atuar em quaisquer sistemas móveis dentre os principais do 
mercado. 
 
Palavras-chave: Ionic. Firebase. Comércio. Desenvolvimento. Software. 
 
ABSTRACT 
 
This piece of work intends to build a mobile application for delivery services in Tauá city, 
Ceará. To attain this goal, as a first step, a survey was done with consumers and entrepreneurs 
first to get data so the hypothesis that we need in Tauá a robust delivery app software could be 
tested. As a second step, a android based app was built according the survey results so we can 
have demands supplied in the local market. Also, the app’s architecture is detailed as the 
functional and non-functional requisites, classes diagrams and user cases are exposed, 
showing all expected interactions and alternative ways. In the final chapters, the app’s layout 
is showed and discussed as a prototype. The delivery commerce platform itself is a mobile 
software split in two mobile apps (one for users and one for enterprises), both developed 
using Ionic Framework hybrid technology and a Firebase cloud based database, allowing 
them to work in almost any mobile system Android based in the market. 
 
Keywords: Ionic. Firebase. Commerce. Development. Software. 
 
LISTA DE FIGURAS 
 
Figura 1 — Análise do mercado delivery antes e durante o período de pandemia da 
Covid-19.......................................................................................................... 
17 
Figura 2 — Análise do crescimento do número de consumidores da modalidade delivery 19 
Figura 3 — Comparação entre metodologias de desenvolvimento mobile.......................... 22 
Figura 4 — Sobre a dificuldade de encontrar empresas/produtos online em Tauá-CE....... 26 
Figura 5 — Sobre as experiências no atendimento remoto (visão dos consumidores)...... 26 
Figura 6 — Dados sobre os erros no atendimento remoto (visão do consumidor)............ 27 
Figura 7 — Métodos para a realização de pedidos online (visão do consumidor).............. 27 
Figura 8 — Interesse dos consumidores no desenvolvimento dessa plataforma................. 28 
Figura 9 — Métodos de vendas na internet na cidade de Tauá (visão das empresas)....... 29 
Figura 10 — Sobre os erros no atendimento remoto (visão das empresas)......................... 29 
Figura 11 — Porcentagem da receita das empresas representada pelo delivery.................... 30 
Figura 12 — Sobre a necessidade do desenvolvimento da plataforma proposta (visão das 
empresas)........................................................................................................ 
30 
Figura 13 — Fluxograma da aplicação dos consumidores...................................................34 
Figura 14 — Representação do componente Sidebar do app dos consumidores................. 35 
Figura 15 — Diagrama de caso de uso da aplicação dos consumidores.............................. 36 
Figura 16 — Fluxograma da aplicação das empresas.......................................................... 40 
Figura 17 — Representação do componente sidebar do app das empresas......................... 41 
Figura 18 — Diagrama de caso de uso do app das empresas.............................................. 42 
Figura 19 — Estrutura de arquivos do projeto..................................................................... 45 
Figura 20 — Estrutura de arquivos de uma página.............................................................. 46 
Figura 21 — Diagrama de classe da plataforma.................................................................. 47 
Figura 22 — Páginas de entrada de dados no app do consumidor (1)................................. 50 
Figura 23 — Páginas de entrada de dados no app do consumidor (2)................................. 51 
Figura 24 — Páginas de listagem do app dos consumidores (1)......................................... 52 
Figura 25 — Páginas de listagem do app dos consumidores (2)......................................... 53 
Figura 26 — Páginas de detalhes da empresa, do produto e do pedido (visão do 
consumidor).................................................................................................... 
54 
Figura 27 — Páginas de entrada de dados no app das empresas......................................... 55 
Figura 28 — Detalhes de um pedido e de um produto (visão da empresa).......................... 56 
Figura 29 — Páginas de listagem do app das empresas....................................................... 57 
 
 
LISTA DE QUADROS 
 
Quadro 1 — Quadro demonstrativo dos requisitos funcionais do app dos consumidores.... 31 
Quadro 2 — Demonstrativo de requisitos funcionais do app das empresas......................... 32 
Quadro 3 — Demonstrativo dos requisitos não funcionais da plataforma............................ 33 
 
 
 
 
LISTA DE SIGLAS 
 
AdMob AdSense Mobile 
B2B Business-to-Business 
B2C/C2B Business-to-consumer/consumer-to-business 
BaaS Backend as a Service 
C2C Consumer-to-consumer 
COVID-19 Corona Virus Disease - 2019 
CRF Consumidor – Requisito Funcional 
CRUD Create Read Update Delete 
CSS Cascading Style Sheets 
FGV Fundação Getúlio Vargas 
FRF Fornecedor – Requisito Funcional 
G2B/B2G Government-to-business/business-to-government 
G2C/C2G Government-to-consumer/consumer-to-government 
G2G Government-to-government 
GPS Global Positioning System 
GSMA Global System for Mobile Communications Association 
HTML Hypertext Markup Language 
IBGE Instituto Brasileiro de Geografia e Estatística 
IGTI Instituto de Gestão e Tecnologia da Informação 
IOS I Operational System 
NoSql No Structured Query Language 
PIB Produto Interno Bruto 
RNF Requisito Não Funcional 
SDK Software Development Kit 
TI Tecnologia da Informação 
UI User Interface 
UML Unified Modeling Language 
WWW World Wide Web 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
LISTA DE SÍMBOLOS 
 
% Porcentagem 
R$ Real 
US$ United States Dollar 
 
 
SUMÁRIO 
 
1 INTRODUÇÃO...................................................................................................... 13 
1.1 Objetivos.................................................................................................................. 14 
1.1.1 Objetivo geral........................................................................................................... 14 
1.1.2 Objetivos específicos................................................................................................ 14 
1.2 Da estrutura do projeto......................................................................................... 15 
2 FUNDAMENTAÇÃO TEÓRICA.......................................................................... 16 
2.1 E-Commerce e seus objetivos................................................................................. 16 
2.2 O mercado e a modalidade delivery........................................................................ 18 
2.3 Delivery em Tauá-CE, como é feito?...................................................................... 20 
2.4 Tecnologia utilizadas no desenvolvimento deste projeto...................................... 21 
2.4.1 O Ionic Framework................................................................................................... 22 
2.4.2 O Firebase................................................................................................................. 23 
3 PESQUISA DE MERCADO................................................................................... 25 
3.1 Das pesquisas com os consumidores locais............................................................ 25 
3.2 Das pesquisas com os fornecedores locais.............................................................. 28 
4 ARQUITETURA DO SOFTWARE...................................................................... 31 
4.1 Levantamento de requisitos.................................................................................... 31 
4.1.1 Requisitos funcionais da aplicação dos consumidores.......................................... 31 
4.1.2 Requisitos funcionais da aplicação dos fornecedores........................................... 32 
4.1.3 Requisitos não funcionais da plataforma............................................................... 33 
4.2 Estrutura lógica da aplicação dos consumidores.................................................. 34 
4.2.1 Interação de login..................................................................................................... 36 
4.2.2 Interação de cadastro e alteração de dados........................................................... 37 
4.2.3 Recuperação de conta.............................................................................................. 37 
4.2.4 Interação com as pesquisas...................................................................................... 38 
4.2.5 Interação com o gerenciamento de favoritos......................................................... 38 
4.2.6 Interação com o carrinho........................................................................................ 38 
4.2.7 Interação com o sistema de pedidos......................................................................... 39 
4.2.8 Entrar em contato.................................................................................................... 39 
4.3 Estrutura lógica da aplicação dos fornecedores.................................................... 40 
4.3.1 Interação de login..................................................................................................... 42 
4.3.2 Interação de cadastro e alteração de dados........................................................... 43 
4.3.3 Recuperação de conta.............................................................................................. 43 
4.3.4 Interação com o gerenciamento de produtos......................................................... 43 
4.3.5 Interação com o sistema de pedidos....................................................................... 44 
4.3.6 Suporte...................................................................................................................... 44 
4.3.7 Interação de pesquisas............................................................................................. 44 
4.4 Da estrutura do projeto de software....................................................................... 44 
5 RESULTADOS E ANÁLISES................................................................................ 48 
5.1 Resultados e análises das pesquisas........................................................................48 
5.2 Resultados e análises do desenvolvimento dos softwares..................................... 49 
5.2.1 Layout e cumprimento dos requisitos funcionais do app dos consumidores......... 49 
5.2.2 Layout e cumprimento dos requisitos do app dos fornecedores.............................. 54 
5.2.3 Analise final do desenvolvimento............................................................................ 57 
6 CONSIDERAÇÕES FINAIS.................................................................................. 59 
 REFERÊNCIAS....................................................................................................... 60 
 
 
13 
 
1 INTRODUÇÃO 
 
Segundo pesquisas realizadas pela WEBSHOPPERS (2020), houve um visível 
crescimento do mercado eletrônico (E-Commerce) de 2020 em relação a 2019. Com um 
faturamento recorde e aumento de 40% de consumidores, o total de usuários dessa 
modalidade de consumo no Brasil chegou a 41 milhões apenas no primeiro semestre deste 
ano. Ainda de acordo com WEBSHOPPERS (2020), seja pelas melhorias de segurança e 
marketing empregados para esse fim ou pelo impulsionamento ocasionado pelo novo corona-
vírus, as estatísticas indicam que o crescimento continuará. Outro ponto que fez os e-
commerce chegarem ao melhor momento de sua história até aqui foi o também crescente 
número de smartphones em atividade, que a partir de pesquisas da FGV (2019), ultrapassam o 
total da população brasileira, ocasionando maior percentual de pessoas aptas a usufruir de 
uma maior facilidade na hora de fechar um pedido, sendo online, de qualquer lugar e sem 
burocracia. Com isso, a grande maioria das empresas que atuam com comércio na internet 
também possuem a portabilidade para celulares, seja a partir da responsividade dos sites ou 
mesmo por aplicações instaláveis. 
Esse tipo de mercado trouxe consigo, também, o crescimento dos pedidos na 
modalidade delivery, que, de acordo com site Delivery Much (2019), teve seu percentual 
elevado em 17,5% em 2019. Esse que se destaca no formato no qual os clientes recebem seus 
pedidos em casa por meio de entregadores empregados pela empresa que fornece os produtos, 
podendo realizar o pagamento no ato do recebimento ou na própria plataforma de compras, 
via cartão de crédito ou débito. 
Mas, para atender apenas a uma determinada região, nem sempre é viável investir em 
uma plataforma própria. Com isso em vista, algumas empresas como iFood, UberEats, Rappi 
e James fornecem serviços onde é possível reduzir os riscos operacionais da empresa 
contratante, uma vez que esta pode validar seus produtos online sem precisar ter um app para 
vender online, tendo prejuízos menores em caso de fracasso de validação. 
Ainda assim, muitas empresas que atuam localmente na cidade de Tauá-CE não 
aderem a tais serviços, seja pelos custos, por não haver uma aplicação na categoria na qual 
elas atuam, ou ainda, pela falta de especificidade das plataformas. Essa falta de especificidade 
permite que tanto a maior quanto a menor empresa possam estar no mesmo meio de 
publicação, criando uma concorrência desvantajosa para as empresas de menor porte. 
Logo, algumas dessas empresas veem melhores negócios oferecendo atendimento por 
meio das redes sociais como WhatsApp, Instagram e Facebook, o que é mais barato e simples, 
14 
 
porém, não tão adequado para o comércio propriamente dito. Com isso, além da concorrência 
comercial, essas empresas vão disputar sua visibilidade com perfis pessoais e publicações de 
quaisquer teores, além de não terem um gerenciamento de pedidos objetivo. 
Com isso em vista, o intuito deste trabalho é, por meio de pesquisas, realizar a 
validação das informações citadas. Logo, foram levantadas questões a fim de caracterizar o 
perfil desses atores, o modo com que comercializam na internet localmente, os problemas 
encontrados e sobre a importância deste trabalho. Se caracterizando então, como uma 
pesquisa exploratória. 
E ainda, visando propor uma solução, desenvolver o protótipo de uma plataforma 
mobile, onde seja possível o cadastro de qualquer categoria de empresa de vendas na 
modalidade delivery do município de Tauá-CE, e esta, ter o gerenciamento de seus produtos, 
pedidos e publicações de informativos ou promoções, de forma independente a outras 
aplicações. Com o fim de abstrair o comércio municipal a um único local online, facilitando 
para os consumidores, a realização de pesquisas e comparações entre produtos e provendo 
maior comodidade aos pedidos de qualquer tipo de produto de qualquer categoria de empresa 
dentro do município. Logo, também sendo uma pesquisa aplicada. 
Com a criação de uma aplicação capaz de resolver a problematização supracitada, a 
forma de atração e diferencial para uma real adesão das empresas locais a esse projeto, visto 
que estas ainda não aderiram a serviços existentes de forma majoritária, é ter uma 
especificidade ou direcionamento para o mercado local, dando maior suporte e se adequando 
intrinsicamente a ele, além de não restringir as funcionalidades a uma modalidade ou 
categoria de vendas. 
 
1.1 Objetivos 
 
1.1.1 Geral 
Desenvolver o protótipo de uma plataforma digital em que todo o comércio atuante na 
modalidade delivery da cidade de Tauá-CE possa se estabelecer, independentemente de sua 
categoria de mercado. 
 
1.1.2 Específicos 
a) Facilitar as buscas e comparações entre produtos locais, para os consumidores do 
mercado delivery; 
15 
 
b) Criar o um protótipo de SW da plataforma à servir de entro de publicações de produtos 
e promoções/informativos online; 
c) Gerenciar pedidos online de forma simplificada para as empresas; 
d) Automatizar o atendimento ao cliente da modalidade delivery; 
e) Validar a proposta com formulários direcionados aos consumidores e empresas. 
 
1.2 Da estrutura do projeto 
 
Este projeto, como citado, trabalhará em duas linhas interligadas, uma com a validação 
de mercado e outra com o desenvolvimento do protótipo. Além disso, é feito o levantamento 
dos dados e estatísticas a nível nacional e municipal, a fim de demonstrar e justificar a 
iniciativa do trabalho. 
Para tanto, na seção 2, será pesquisado e apresentado a fundamentação teórica da 
proposta, a partir de dados de revistas, sites, artigos e livros. O intuito desta seção é verificar 
como estão os números e previsões sobre o mercado delivery no Brasil e na cidade de Tauá-
CE e apresentar as tecnologias que serão implementadas na prototipação do produto de 
software. 
Após os dados iniciais serem apresentados, o modelo da metodologia se estende a duas 
seções. A 3° é responsável por demonstrar as características e os objetivos das pesquisas 
realizadas, assim como os resultados brutos dos questionários. E a 4°, que por sua vez, 
demonstrará a metodologia da projeção do software e toda a parte de engenharia aplicada. 
Logo, a metodologia cientifica deste projeto é caracterizada como exploratória e também 
como aplicada. 
A finalização deste projeto se inicia na seção 5, em que serão apresentados os 
resultados obtidos nas pesquisas de campo e no desenvolvimento do protótipo proposto. 
Seguido das considerações finais, na seção 6, em que é apontado as maiores dificuldades 
encontradas, os aprendizados e alguns possíveis trabalhos futuros. 
 
 
 
 
 
 
16 
 
2 FUNDAMENTAÇÃO TEÓRICA 
 A fim de fundamentar tanto a premissa quanto a escolha das tecnologias utilizadas 
neste trabalho, nessa seção são abordados os funcionamentos, objetivos, histórico e também 
as previsões para o e-commerce e a modalidade delivery nos próximos anos. Bem como, são 
demonstradas, a partir de comparativos, as motivações para a utilização das tecnologias de 
implementação adotadas na criação do software proposto. 
 
2.1 E-commerce e seus objetivos 
“O comércio-eletrônico envolve todas as transações que ocorrem via web entre dois 
agentes distintos” (BOTELHO; GOMES; SILVA, 2016), sendodefinido por Parente (2000 
apud Botelho, Gomes e Silva (2016, p. 2) como um intermédio digital que possibilita a 
transação por um sistema automatizado no formato de um varejo na internet, oferecendo 
produtos e serviços de forma interativa. Nesse sentido, entende-se o e-commerce como um 
comércio pelo meio digital, no qual é feito a intermediação do atendimento entre um 
consumidor e a empresa fornecedora, com o fim de obter uma transação de dados mais 
simplificada e objetiva. 
Há classes definidas de comércio e comércio eletrônico desde as primeiras iniciativas 
desse mercado até as que se expandiram ao longo dos anos. Crocco et al. (2012 apud Cunha 
et al. (2013, p. 4) cita que as mais utilizadas são: 
 
a) B2B (business-to-business) são transações realizadas entre empresas; 
b) B2C/C2B (business-to-consumer/consumer-to-business) são transações entre 
empresas e os consumidores finais; 
c) C2C (consumer-to-consumer) são transações entre os consumidores finais; 
d) G2C/C2G (government-to-consumer/consumer-to-government) são operações que se 
dão através do governo com os consumidores finais; 
e) B2G/G2B (government-to-business/business-to-government) são as transações 
realizadas entre o governo e as empresas como as licitações e produtos necessários 
socialmente; 
f) G2G (government-to-government) são transações realizadas somente entre os 
departamentos do governo 
 
17 
 
Essas classes são importantes para administradores de empresas e gerentes de projetos, 
pois contribuem para dar o foco ao desenvolvimento de uma plataforma de e-commerce ou 
organizar uma existente. Para fins de execução, a plataforma de comércio eletrônico 
resultante deste trabalho apresenta transações do tipo B2C, onde há a venda entre empresas e 
consumidores finais, assim como B2B, com o envio de valores das empresas cadastradas à 
equipe de gerenciamento e desenvolvimento da aplicação. 
Na década de 90 surgem as, hoje poderosas, Amazon, Ebay e Alibaba, como primeiras 
grandes lojas online da ainda nova WWW (World Wide Web) (AiPress.com, 2018). Nessa 
época, havia, em relação a 2020, poucos adeptos, mas suficientes para o desenvolvimento e 
continuidade desses projetos de visão futurista. 
Segundo Silva e Queiroz (2019), o advento de tal revolução no mercado mundial não 
demorou a chegar no Brasil, por volta dos anos 2000, com a criação do Mercado Livre e da 
Saraiva como exordiais da modalidade no país. 
Atualmente, vive-se um momento de isolamento social ocasionado pelo novo corona-
vírus, causador da COVID-19. Com isso, o crescente número de usuários do mercado digital 
teve seu ápice em abril de 2020, segundo pesquisa da WEBSHOPPERS (2020). Ela 
apresentou dados comparativos entre os meses que antecederam e o período de isolamento no 
Brasil, que são mostrados na figura que segue: 
 
Figura 1 - Análise do mercado delivery antes e durante o período de pandemia da Covid-19 
Fonte: WEBSHOPPERS 42° (2020) 
 
18 
 
Uma rápida visualização do gráfico e é possível ver os números muito superiores 
durante o período de isolamento social, com ênfase em datas comemorativas. Isso demonstra 
o quanto o consumidor digital (e-consummer) está preparado para fazer novos negócios 
dentro de plataformas com esse fim, dando assim maior mercado para os meios digitais atuais 
e futuros. 
 
2.2 O mercado e a modalidade delivery 
 
A modalidade de mercado delivery pode ser definida como “ação de entregar, de levar 
compras até ao endereço indicado por quem as comprou” (DICIO, 2020). Com isso, seu 
funcionamento, em essência, se dá a partir da venda por meio de algum sistema de 
comunicação de longa distância, a fim de obter a vantagem de receber tais compras sem sair 
do local de conforto. 
De acordo com o Delivery Much (2019), o mercado nacional projetava para o ano de 
2022 no Brasil, que o faturamento seria de mais de US$ 343 bilhões para pedidos via 
aplicativos, sendo mais de 10 milhões de usuários pelo país. Contudo, a pandemia de Covid-
19, que causou isolamento social em todo o mundo, ocasionou um crescimento inesperado, 
com dados que representam, já em 2020, 4 vezes o número de usuário da estimativa de 2022 
no Brasil (WEBSHOPPERS, 2020). Para um melhor entendimento e exposição visual do que 
foi citado, segue um gráfico que demonstra esse crescimento. 
 
19 
 
Figura 2 - Análise do crescimento do número de consumidores da modalidade delivery 
Fonte: WEBSHOPPERS 42° (2020) 
 
Atualmente, há diversas plataformas de comércio eletrônico que atuam com a 
modalidade delivery, como iFood, Delivery Much, Rappi, UberEats, James, dentre outros, o 
que traz facilidades aos consumidores dos locais onde essas empresas atuam. “O mercado é 
separado em segmentos, visando às diferenças demográficas, psicográficas e comportamentais 
entre os consumidores, identificando e apresentando grupos distintos que irão eleger ou 
estabelecer vários mixes diferentes de produtos ou serviços” (KOTLER; KELLER, 2012 apud 
RODRIGUES, et al., 2019). 
Nesse sentido, seja pelas taxas cobradas, pela falta de especificidade dessas aplicações, 
visto que trabalham em todas as regiões, ou por outros motivos, as empresas supracitadas não 
atuam em todas as cidades. A exemplo do iFood, líder do segmento alimentício na América 
Latina e que ocupa mais de 1000 cidades do Brasil, deixando aproximadamente 4570 outras 
sem adeptos ao seu serviço (IFOOD, 2020). Logo, essa característica dá oportunidade para os 
desenvolvedores locais pensarem em propostas similares, mas específicas para sua região. 
Portanto, ainda há mercado para inovações na área de desenvolvimento de plataformas 
de e-commerce que atuem na modalidade delivery, principalmente com enfoque em 
determinadas regiões, como cidades interioranas. Ayron Santarem, head de expansão da 
20 
 
Delivery Much, em entrevista ao blog da empresa onde trabalha, reforça a premissa de que 
existe muita demanda reprimida nos interiores e cidades pequenas, que estão em ascensão 
socioeconômica e não apresentam muita concorrência. 
 
2.3 Delivery em Tauá-CE, como é feito? 
 
Atualmente, no município de Tauá-CE, já existem diversas empresas dos mais 
variados segmentos que atuam com entregas a domicílio, atendendo pelos principais canais de 
comunicação, como Whatsapp, Facebook e Instagram. Para contribuir com esses canais, a 
prefeitura da cidade, durante a pandemia, lançou em seu site um catálogo de contatos online 
para cadastro dos comércios e visualização dos clientes interessados, a fim de “evitar ainda 
mais a circulação do coronavírus no meio social” (TAUÁ, 2020). 
Ainda de acordo com os dados do site taua.ce.gov.br, na data 05/10/2020, a plataforma 
supracitada possui 82 empresas cadastradas em 17 categorias distintas, o que demonstra o 
quão interessados os comerciantes locais de diversas categorias de comércio estão em 
interagir com a população pelo meio digital. Os comerciantes aderiram ao serviço mesmo não 
podendo publicar seus produtos ou gerenciar seus pedidos nele, o que enfatiza a necessidade 
de uma plataforma específica para este fim. 
Além disso, grandes empresas do ramo alimentício já fornecem seus serviços na 
cidade, como iFood, Aiqfome e Myfood com diversas empresas cadastradas, assim como há 
empresas que ainda não atuam na região, como UberEats e 99Food. Esses serviços também 
incluem gerenciamento de pedidos e produtos, diferente do catálogo municipal, tendo como 
desvantagens a falta de assimilação ao mercado local, não tratando de nenhuma especificidade 
demográfica, como custo de vida. Além da falta de diversidade categórica, onde geralmente 
não trabalham com mais de um tipo de serviço. 
Portanto, ainda há carência de aplicação que possibilite aos cidadãos tauaenses 
encontrar empresas que fazem entregas na cidade. Existem aplicações similares, como visto 
acima, mas existem pontos de demanda não supridos pelos já existentes. Tais pontos de 
demanda podem se tornardiferenciais que justifiquem um novo aplicativo. Diferenciais como 
um catálogo online com gerenciamento próprio de pedidos e produtos e a incorporação mais 
categorias de negócio. 
 
 
 
21 
 
2.4 Tecnologias utilizadas no desenvolvimento deste projeto 
 
É natural o crescimento do número de usuários de smartphones e tablets nos últimos 
anos, com o barateamento ocasionado pela concorrência entre empresas e a evolução das 
tecnologias, que possibilitaram custos menores nas produções dos mesmos. Ainda em 2017, a 
GSMA (Global System for Mobile Communications Association) publicou uma pesquisa 
afirmando que já haviam mais de 5 bilhões de usuários dessas plataformas, o que representa 
mais de 2/3 da população mundial. Com isso, este trabalho adotou as tecnologias móveis 
como base da aplicação a ser desenvolvida, para que possa, assim, alcançar mais facilmente 
os usuários finais, o que dará maior comodidade e praticidade aos mesmos. 
O desenvolvimento de software é uma área profissional que não se abalou durante os 
períodos de crise dos últimos anos no Brasil, o site Computer World (2019), cita que ela 
ignorou as quedas de PIB (Produto Interno Bruto) e continuou seu crescimento. Contudo, é 
necessário que tais profissionais estejam preparados e atualizados acerca das tecnologias mais 
utilizadas. Nessa área, mais especificamente na de desenvolvimento de software mobile, tem-
se maiores preocupações com a iniciação e continuidade da tecnologia na qual se propôs 
trabalhar, pois a programação para estes é restritiva, por necessitar de módulos específicos de 
cada plataforma dentro do projeto, os SDK (Software Development Kit). Além disso, podem 
haver bastante disparidades entre as linguagens adotadas para a criação de aplicações em cada 
sistema móvel. 
Para contribuir com o caso acima, em que não é possível programar uma vez e 
executar em mais de uma plataforma mobile, método denominado “nativo”, foi criado o 
modelo de desenvolvimento híbrido que, a partir de diferentes formas de programar em 
relação ao nativo, geralmente utilizando linguagens web, torna possível obter uma compilação 
para a plataforma que desejar a partir do mesmo código. Além disso, outra vantagem é que, 
segundo Lopes (2019), por ser baseado em linguagens web, a curva de aprendizado é 
considerada mais suave, o que dá segurança para iniciantes tanto quanto para programadores 
mais experientes. 
As principais diferenças apresentadas pelo desenvolvimento híbrido em relação ao 
nativo, tomando como base as plataformas IOS e Android, podem ser visualizadas na figura 1. 
 
22 
 
Figura 3 - Comparação entre metodologias de desenvolvimento mobile 
 
Fonte: igti (2019) 
Com os dados da figura, é possível notar que é necessário um bom planejamento para 
iniciar um projeto de desenvolvimento mobile, pois, a depender do objetivo final da aplicação, 
é mais vantajoso desenvolver em um modelo ou em outro. Caso a finalidade da aplicação seja 
atender em tempo real, como aplicativos de geolocalização e GPS, o ideal é desenvolver 
nativamente, pelo maior desempenho que irá conseguir. Contudo, se for preciso obter 
rapidamente uma aplicação que execute em qualquer plataforma e que seja de fácil 
manutenção e evolução é indicado utilizar aplicações híbridas. 
 
2.4.1 O Ionic framework 
 
Este projeto utilizará a tecnologia de desenvolvimento híbrido Ionic Framework, 
sendo assim capaz de se obter uma compilação para qualquer uma das principais plataformas 
mobile do mercado e por não necessitar de desempenho de tempo real. 
“O Ionic Framework é um kit de ferramentas de interface do usuário de código aberto 
para a criação de aplicativos móveis e de desktop de alto desempenho, usando tecnologias da 
Web (HTML, CSS e JavaScript)” (IONIC FRAMEWORK, 2020), logo, pode ser entendido 
como um conjunto de bibliotecas integradas ou com possibilidade de integração para 
provimento de uma interface de desenvolvimento baseada em tecnologias web. 
Esse framework trabalha na camada de webview, provendo a aplicação por cima de um 
browser próprio, por isso é possível utilizar tecnologias web para seu desenvolvimento. 
Fazendo uso do Apache Cordova, que dá a aplicações web a possibilidade de acessar funções 
23 
 
nativas do hardware do aparelho, o Ionic consegue utilizar com facilidade as especificidades 
das plataformas onde executar. 
 
Segundo Barbosa et al. (2016, p. 2), 
O Ionic foi construído sobre a plataforma Apache Cordova, que facilita o 
acesso à funções específicas do hardware dos dispositivos, e o AngularJS, 
uma linguagem baseada em JavaScript. Fornece vários componentes de 
interface de usuário (UI) que podem ser utilizados e customizados no 
desenvolvimento de uma aplicação. 
 
Pois, como dito, por se tratar de um framework web, o Ionic precisa de um invólucro 
para acessar funções nativas e também para ser executado como uma aplicação desse nível, 
utilizando para tanto, o Cordova ou PhoneGap. (SILVA ; SOTTO, 2017, p .4) 
Assim como o framework AngularJS se faz necessário na metodologia da estrutura do 
Ionic, pois "permite que você estenda o vocabulário HTML para seu aplicativo. O ambiente 
resultante é extraordinariamente expressivo, legível e rápido de desenvolver" (ANGULARJS, 
2020). Com isso, é possível incrementar funções dentro do escopo HTML, fazendo operações 
e modelagens sem a dependência exclusiva do arquivo JavaScript. 
 
2.4.2 O Firebase 
 
O Firebase é uma plataforma BaaS (Backend as a Service) da Google, que atua sobre 
a infraestrutura dessa empresa. Ele é capaz de realizar o escalonamento automático de dados 
dos apps/websites, dos simples até os mais complexos. Com o intuito de abstrair os projetos 
que o adotam como banco, ele trata do gerenciamento dos seus diversos serviços de forma 
eficiente, o que dá ao programador mais tempo para focar no desenvolvimento e nos usuários 
(FIREBASE, 2020). 
Essa plataforma possui diversos serviços úteis para o desenvolvimento de software 
web e mobile, alguns são destacados por Sganzerla e Lummertz (2018): 
 
a) Real time Database: Banco de dados NoSql com armazenamento em nuvem. 
b) Authentication: Serviço de autenticação de usuários, com possibilidade de login por 
utilização de E-mail, conta do Google, Facebook, Twiter ou Github. 
c) Cloud Messaging: Recurso que oferece envio de mensagens instantâneas ou com 
tempo marcado do servido para os dispositivos. 
24 
 
d) Monitoring and performance: Mecanismo que fornece diagnósticos de sistema ou rede 
onde a aplicação está operando. 
e) Crash Reporting: Serviço que disponibiliza dados sobre problemas encontrados, 
segmentando por categorias e detalhando os dispositivos afetados. 
f) AdMob: "A Google AdMob ajuda você a gerar receita com seu aplicativo para 
dispositivos móveis por meio de publicidade no aplicativo.” (FIREBASE, 2020). 
 
Neste projeto, foi utilizado o serviço em nuvem do Real Time Database, que, de 
acordo com Firebase (2020), é um banco de dados NoSQL e, por isso, tem otimizações e 
funcionalidades diferentes de um banco relacional, dando aos softwares menor latência e 
melhor usabilidade para serviço com necessidades de tempo de resposta baixo. 
Foi utilizado, também, o serviço de autenticação para garantir a disparidade entre os 
usuários e poder tratar os pedidos e serviços adotados por cada um de forma única e 
identificável. 
Na evolução deste projeto, é esperado fazer uso dos outros 4 serviços citados, e assim 
obter uma aplicação com notificações do servidor, um monitoramento de tráfego e análise de 
erros, e também tratar da monetização com o AdMob, tudo gerenciado no console do 
Firebase. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
https://www.google.com/admob/?utm_source=firebase&utm_medium=et&utm_campaign=firebase-docs&utm_content=2017Q1&hl=pt-br
25 
 
3 PESQUISAS DE MERCADO 
 
Com o objetivo de obter informações acerca do público alvo deste trabalho, foram 
realizadasduas pesquisas com a ferramenta Google Forms, uma para os comerciantes e outra 
para os consumidores da cidade de Tauá-CE. A partir de perguntas objetivas, esses 
questionários receberam um total de 125 respostas no período de 30 dias, sendo 13 de pessoas 
jurídicas e 112 de pessoas físicas. 
 
3.1 Das pesquisas com os consumidores locais 
 
Essa primeira pesquisa teve início em 15/09/2020 e termino em 15/10/2020, com um 
total de 112 respostas de consumidores locais. 
As perguntas foram direcionadas à opinião do consumidor acerca do atendimento que 
ele recebe atualmente, quais ferramentas ele usa, se há dificuldades em achar determinado 
produto ou empresa, o julgamento de sua experiência com o atendimento de delivery local, 
além da sua faixa etária e renda familiar. Por fim, a opinião dele sobre a criação de uma nova 
plataforma de atendimento local, o que é proposto neste trabalho. 
Logo, até 40 anos (item a: 0 – 25 anos (41,4%) e item b: 26 – 40 anos (41,4%)) foi a 
faixa de idade da maioria dos consumidores e a renda familiar média foi de R$ 2058,37. 
Sobre o atendimento, 61,6% apontaram ter dificuldades em encontrar um produto ou 
empresa com os meios existentes, enquanto as experiências com os atendimentos foram 
avaliadas como 50% regular, 29,5% boa, 15,2% ruim e 5,3% Ótima, o que pode ser 
visualizado nos gráficos que seguem. 
26 
 
Figura 4 - Sobre a dificuldade de encontrar empresas/produtos online em Tauá-CE 
Fonte: Autor (2020) 
 
Figura 5 - Sobre as experiências no atendimento remoto (visão dos consumidores) 
Fonte: Autor (2020) 
Os erros com os atendimentos foram analisados como 8,9% ocorrendo sempre, 40,2% 
nunca e os outros 50,9% com frequência, além disso, do montante de respostas, 88,4% 
disseram fazer compras pelo Whatsapp, 33% pelo Instagram, 7,1% pelo Facebook, 11,6% por 
loja da empresa e 28,6% por outros serviços online ou telefone, informações que podem ser 
visualizadas a seguir. 
27 
 
Figura 6 - Dados sobre os erros no atendimento remoto (visão do consumidor) 
Fonte: Autor (2020) 
 
Figura 7 - Métodos para a realização de pedidos online (visão do consumidor) 
Fonte: Autor (2020) 
A última pergunta, que questionava sobre a importância de uma nova plataforma como 
a proposta neste artigo, teve as seguintes opções e respectiva porcentagem de resposta. 
 
a) Insignificante com 0,9%, 
b) Comum com 2,7%, 
c) Útil com 49,1%, 
d) Necessário com 47,3%. 
28 
 
Figura 8 - Interesse dos consumidores no desenvolvimento dessa plataforma 
 
Fonte: Autor (2020) 
 
3.2 Das pesquisas com os fornecedores locais 
 
Na segunda pesquisa, realizada com os fornecedores de serviços/produtos na 
modalidade delivery, foram avaliadas as respostas de 13 empresas, no período de 08/10/2020 
até 16/10/2020, além disso, foram selecionadas as empresas de pequeno e médio porte que se 
encaixavam como clientes da proposta inicial deste projeto para requisição dessas respostas. 
Com o mesmo objetivo da primeira, mas mudando o público alvo para as empresas, 
este questionário obteve informações sobre a forma com que essas atendem por delivery, se 
ocorrem erros nesses atendimentos, sobre a receita e quanto por cento desta vem do 
atendimento por pedidos online, e ainda, acerca do tempo de atividade da mesma e sobre a 
importância de uma plataforma com teor da proposta neste projeto. 
A forma com que essas empresas atendem online obteve o seguinte resultado: 100% o 
fazem pelo Whatsapp, 92,3% pelo Instagram, 15,4% pelo Facebook, 7,7% por loja da 
empresa e 38,5% por outros serviços online ou telefone. Sobre os erros no atendimento, 
ocorrem 7,7% sempre, 76,9% frequentemente, 15,4% nunca. Dados esse que podem ser 
melhor analisados nos gráficos a seguir. 
29 
 
Figura 9 - Métodos de vendas na internet na cidade de Tauá (visão das empresas) 
Fonte: Autor (2020) 
 
Figura 10 - Sobre os erros no atendimento remoto (visão das empresas) 
Fonte: Autor 2020 
 
Sobre os valores arrecadados por essas empresas na modalidade delivery, a média 
mensal de rendimento total das que responderam essa questão opcional (9) foi de R$ 
12.477,77. Com 3 empresas de menos de 1 ano de atividade, 7 na faixa de 2 a 5 anos e 3 de 6 
a 10 anos. 23,1% dessas empresas, afirmando que os pedidos recebidos online representam de 
26% a 50% de sua receita, outros 53,8% informando que de 50% a 75% de sua receita vem do 
delivery e 23,1% dizem ter de 75% a 100% de sua receita baseado em encomendas locais 
feitas pela internet, visível no próximo gráfico. 
30 
 
Figura 11 - Porcentagem da receita das empresas representada pelo delivery 
Fonte: Autor 2020 
Por fim, sobre a necessidade de uma plataforma como a idealizada neste projeto, 
69,2% das empresas votaram como necessário, 30,8% como útil, 0% comum e 0% como 
insignificante. Tendo 69,2% de empresas que se dispuseram a fazer testes e dar feedback para 
a melhoria de tal plataforma, e 30,8 que talvez o fizessem também. 
 
Figura 12 - Sobre a necessidade do desenvolvimento da plataforma proposta (visão das 
empresas) 
Fonte: Autor, 2020 
 
 
 
 
31 
 
4 ARQUITETURA DO SOFTWARE 
 
Para o desenvolvimento da plataforma, como já citado, foi utilizado o framework para 
o desenvolvimento de aplicações híbridas Ionic, juntamente do banco de dados em nuvem da 
Google, o Real Time Databse do Firebase. 
Para tanto, o sistema é composto por dois aplicativos, um direcionado aos 
consumidores e o outro aos comerciantes, ambos conectados pelo mesmo banco de dados em 
nuvem. Como a ideia é dar suporte aos atendimentos em delivery, o tempo de resposta deve 
ser baixo, a fim de oferecer o melhor atendimento dos fornecedores aos clientes 
Nesse tópico, serão explicados os requisitos funcionais e não funcionais adotados por 
cada aplicação, a disposição das páginas e do projeto, a fim de passar uma visão geral das 
aplicações e como elas trabalho em conjunto e individualmente. 
 
4.1 Levantamentos de requisitos 
 
4.1.1 Requisitos funcionais da aplicação dos consumidores 
 
Os objetivos a serem atendidos pela plataforma são adequados a cada um dos 
requisitos funcionais fundamentais para a execução deste projeto. Para melhor entendimento 
desses requisitos, os referentes ao app dos consumidores são apontados no quadro 1 que 
segue: 
 
Quadro 1 – Quadro demonstrativo dos requisitos funcionais do app dos consumidores 
ID Título Descrição 
CRF01 Cadastro Disponibilizar, antes de qualquer acesso, a possibilidade de o 
usuário realizar seu cadastro no sistema, dando-o assim, um 
meio de autenticação. 
CRF02 Login Ao usuário que já tenha acesso ao sistema, apresentá-lo, no 
caso de não autenticado, o painel de autenticação (login). 
CRF03 Recuperação de 
conta 
Dar a possibilidade de recuperação de acesso, em caso de 
perda de dados, mostrando-o a página de recuperação. 
CRF04 Alteração de 
dados 
Para os usuários manterem seus dados atualizados, ao se 
autenticar o usuário poderá inserir novos dados que 
substituirão os existentes. 
CRF05 Pesquisar 
produto ou 
empresa 
A fim de facilitar as procuras por um produto, manter sempre 
métodos de auxilio nas buscas, seja uma barra de pesquisa ou 
formas de filtragem nas páginas com esse fim. 
32 
 
CRF06 Adicionar 
produto aos 
favoritos 
Ao gostar de um produto, o cliente tem acesso a um botão que 
adicionará este produto a uma lista reservada para acesso 
facilitado somente dele. 
CRF07 Excluir dos 
favoritos 
Quando uma empresa parar de fornecer um produto ou o 
cliente que o tiver na sua lista de favoritos decidir não querer 
mais ele e clicar em excluí-lo, este produto será excluído 
imediatamente desta lista. 
CRF08 Adicionar 
produto ao 
carrinho 
Ainda na tela de exibição de um produto, o cliente poderá 
adicioná-lo ao seu carrinho clicando em “adicionar ao 
carrinho”, sendo apenas possível se o produto estiver 
disponível, o que é marcado pelo fornecedor. 
CRF09 Excluirproduto 
do carrinho 
Na lista de produtos do carrinho, os produtos são exibidos de 
forma segmentada por empresa, logo, o cliente poderá excluir 
tanto um vetor de produtos de uma empresa, como um único 
produto desse vetor. 
CRF10 Realizar pedido Ainda na lista de produtos do carrinho o cliente poderá, 
clicando em “confirmar pedido”, realizar seu pedido, levando 
os dados do cliente, do pedido e do fornecedor para a lista de 
pedidos dos dois agentes. 
CRF11 Excluir pedido Ao realizar um pedido, o cliente é direcionado a página 
referente a esses. Logo, poderá realizar o “cancelamento” 
caso o pedido ainda esteja com o status “realizado” ou marcar 
como “recebido”, ambos os casos excluem o pedido dessa 
lista. 
CRF12 Feedback Para melhorar aplicação constantemente, um meio de 
comunicação é necessário. Logo, a aba “sobre nós” dá a 
possibilidade de envio de quaisquer informações sobre o app, 
por meio do Whatsapp. 
Fonte: Autor (2020) 
 
4.1.2 Requisitos funcionais da aplicação dos fornecedores 
 
Já para o app das empresas, os requisitos funcionais evidenciados são apresentados no 
próximo quadro: 
 
Quadro 2 – Demonstrativo de requisitos funcionais do app das empresas 
ID Título Descrição 
FRF01 Cadastro Disponibilizar, antes de qualquer acesso, a possibilidade de a 
empresa realizar seu cadastro no sistema, dando-o assim, um 
meio de autenticação. 
FRF02 Login A empresa que já tenha acesso ao sistema, apresentá-la, no 
caso de não autenticada, o painel de autenticação (login). 
FRF03 Recuperação de Dar a possibilidade de recuperação de acesso, em caso de 
33 
 
conta perda de dados, mostrando-a a página de recuperação. 
FRF04 Alteração de 
dados 
Para as empresas manterem seus dados atualizados, ao se 
autenticar essa poderá inserir novos dados que substituirão os 
existentes. 
FRF05 Listar produtos Antes de adicionar um produto, é apresentado a lista com 
todos os produtos anteriormente adicionados ou vazia, com 
opções de exclusão, inserção e buscar por nome. 
FRF06 Adicionar 
produto 
Na página de adicionar um produto, provê caixas de entrada 
inerentes as características de um produto, como foto, nome, 
quantidade, disponibilidade, dentre outros. 
FRF07 Excluir produto Quando uma empresa parar de fornecer um produto, ela tem 
acesso na lista dos seus produtos à um botão para devida 
exclusão. 
FRF08 Alteração de um 
produto 
A página de inserção que alterna para alteração de um 
produto quando o fornecedor clica em um produto já 
existente, serve para edição e atualização dos dados de um 
produto. 
FRF09 Recebimento de 
pedidos 
Na tela inicial é apresentado sua lista de pedidos, sendo 
separadas por status “aguardando atendimento” e “em 
andamento”, podendo assim, acessar os seus detalhes. 
FRF10 Excluir pedido O fornecedor pode, a qualquer momento, marcar o pedido 
como cancelado, sendo assim, excluído de sua lista. 
FRF11 Pesquisar 
pedido ou 
produto 
Na página inicial para filtrar os pedidos, esses são 
segmentados por status. Já na listagem dos produtos, esses 
podem ser buscados pelo nome em uma caixa de pesquisa. 
FR211 Suporte Em caso de algum problema na aplicação ou mesmo para 
sujestão de algo, os fornecedores, por meio do Whatsapp, 
podem se comunicar com o gestor da plataforma. 
Fonte: Autor (2020) 
 
4.1.3 Requisitos não funcionais da plataforma 
 
A forma com que a aplicação atenderá à esses requisitos é chamado de requisitos não 
funcionais, métodos esses que são explicitados na seguinte tabela: 
 
Quadro 3 – Demonstrativo dos requisitos não funcionais da plataforma 
RNF01 Sincronia Manter dados sincronizados com o banco atualizando-os em 
tempo real. 
RNF02 Latência Obter menor tempo de transferência e atualização possível. 
RNF03 Persistência Dados alterados offline são salvos em cache e enviados ao 
banco de dados assim que uma conexão for estabelecida. 
RNF04 Transparência Manter usuário informado em quaisquer casos, seja erro ou 
sucesso no retorno de dados ou no carregamento de uma 
34 
 
página. 
RNF05 Segurança Garantir autenticidade e segurança aos usuários, evitando 
envio de senhas sem criptografia e dados cruzados 
incorretamente. 
Fonte: Autor (2020) 
 
4.2 Estrutura lógica da aplicação dos consumidores 
 
Para exemplificar a interação esperada com os consumidores, a seguir é apresentado o 
fluxograma que foi adotado para ter noções iniciais da fluidez dentre as páginas da aplicação 
dos clientes: 
 
Figura 13 - Fluxograma da aplicação dos consumidores 
 
Fonte: Autor (2020) 
 
Com o fluxograma apresentado, tem-se noções básicas da forma esperada de uso por 
parte dos consumidores, onde é possível observar que eles terão a qualquer momento atalhos 
no sidebar para qualquer página dentre as principais do app e para logout. Sendo assim, os 
usuários terão maior facilidade de encontrar o que desejam de forma objetiva. Esse sidebar é 
apresentado na imagem que segue: 
 
35 
 
Figura 14 – Representação do componente Sidebar do app dos consumidores 
 
 
Fonte: Autor (2020) 
 
Com o mesmo intuito do fluxograma, a segui o diagrama de caso de uso e as devidas 
interações dessa aplicação são apresentados. Assim, é possível observar as funções da 
aplicação que foram tratadas, tanto no fluxo esperado quando na rota alternativa. 
36 
 
Figura 15 - Diagrama de caso de uso da aplicação dos consumidores 
 
Fonte: Autor (2020) 
Já no diagrama de caso de uso, é notório as principais interações do usuário com as 
funções do sistema, tendo inicialmente que ter um perfil validado no login, assim, podendo 
executar os demais métodos. Ainda, o fornecedor, após publicação de um produto no banco 
de dados, fica à espera de um pedido feito nessa aplicação, tendo interação apenas quando 
essa ação é realizada pelo cliente. 
 
4.2.1 Interação de login 
 
Ao iniciar a aplicação pela primeira vez ou após fazer logout, o consumidor terá que 
realizar a validação do seu perfil na tela de login, onde, precisará inserir um e-mail e uma 
senha. Ainda, caso o usuário não possua esses dados, é nesta página que ele encontrará os 
37 
 
respectivos direcionamentos para as telas onde poderá obtê-los, sendo elas Recuperar Conta e 
Cadastre-se. 
No caso de um usuário tentar realizar essa validação com dados inesperados pelo 
sistema, será apresentado um dos dois tipos de mensagens de erro. O primeiro tipo é no 
próprio campo de entrada, onde será marcado com vermelho e uma frase indicará o erro, esse 
tipo é apresentado nos seguintes casos: com dados que não satisfaçam o modelo padrão de um 
e-mail ou uma senha de no mínimo 6 dígitos ou algum dos campos esteja vazio. 
O segundo tipo é acionado quando o usuário preenche as validações iniciais e clica no 
botão de login, apresentando assim, um toast (mensagem na parte inferior da tela com tempo 
de duração) informando o erro que ocorrera, esse que é enviado pelo próprio firebase. Esses 
erros são chamados quando ocorre: o preenchimento com informações que não consistam no 
banco de dados ou falta de conexão com a internet. 
 
4.2.2 Interação de cadastro e alteração de dados 
 
Ainda no login, clicando no botão que direcionará para a página de cadastro, o usuário 
poderá inserir seus dados conforme são necessariamente pedidos, sendo os dados de perfil: 
Nome, Sobrenome, E-mail, Senha, Confirmação de Senha, Idade e os de contato: Rua, 
Número, Bairro, Cidade, Telefone e um Complemento. Por fim, realizar o registro clicando 
no único botão desta página. Ainda, idêntico a página de cadastro, o usuário terá a opção de 
edição de seus dados já salvos, navegando pelo sidebar até a página de alteração de dados. 
Os possíveis erros esperados por essa página são: campos vazios, formato de e-mail 
errado, senha com menos de 6 dígitos, confirmação de senha diferente da senha anteriormente 
digitada, falha na conexão ou e-mail já cadastrado. Assim como no caso do login, o firebase é 
o responsávelpor enviar uma mensagem de erro para o toast desta página, informando qual 
ocorreu, isso quando o usuário já passou pelas validações iniciais das mensagens nos campos 
de entradas e clica em cadastrar-se. 
 
4.2.3 Recuperação de conta 
 
Partindo também do login, é possível observa o link que direciona a página de 
recuperação de senha, estando nela o usuário tem apenas a entrada de texto para inserção do 
e-mail e o botão de envio de um link de recuperação de dados para o e-mail digitado. 
38 
 
Os únicos erros esperados neste caso, são o de falha na conexão ou e-mail não 
cadastrado, pois o botão de envio só é liberado quando as demais validações de formato são 
aceitas. 
 
4.2.4 Interação com as pesquisas 
 
Após ter o perfil validado e adentrar no sistema, o usuário, já na página inicial, poderá 
observar diversas categorias de empresas para começar a filtrar as de seu interesse, ainda, há a 
barra de pesquisa no topo da página, dando a opção de buscar um produto diretamente. Além 
dessas opções, no sidebar o cliente terá um atalho para buscar qualquer produto a partir da 
categoria deste, assim como terá um atalho para uma lista com todas as empresas. 
Logo, as possibilidades de encontrar um produto são diversas, podendo busca-lo por 
nome na página inicial, pesquisar na lista de categorias, ou ainda, acessar o perfil de uma 
empresa e encontrar apenas os seus produtos. 
Neste caso, uma rota alternativa é apresentada no caso de uma pesquisa retornar vazio, 
logo é apresentado um texto fixo em tela, mostrando o motivo do erro, seja falta de conexão 
ou falta do dado pesquisado no banco de dados. 
 
4.2.5 Interação com o gerenciamento de favoritos 
 
Ao acessar os detalhes de um produto, o cliente poderá adiciona-lo à sua lista de 
favoritos clicando no ícone de coração ao lado do nome do produto. Para realizar a exclusão 
ou visualização deste produto, no sidebar ele encontra a opção de “Meus Favoritos” para 
acessar a lista com estes. 
Nesta página, são esperados erros de conexão e de retorno de vazio, sendo apresentado 
em tela, de forma fixa, assim como na interação de pesquisa. 
 
4.2.6 Interação com o carrinho 
 
Ainda na página de detalhes de um produto, há, de forma explicita e chamativa, a 
opção de adicionar ao carrinho, enviando para esta lista os dados deste produto, do fornecedor 
e do cliente. Ao acessar o carrinho, o usuário terá os produtos adicionados de forma 
segmentada por empresa, podendo excluir um produto ou todos os produtos de uma empresa 
ali encontrados. Além disso, poderá alterar a quantidade requerida em cada produto de forma 
39 
 
distinta. Por fim, ele poderá realizar seu pedido, momento em que o fornecedor receberá no 
app Buyers Sheeps - Fornecedores a atualização de sua lista de pedidos. 
Nesta interação, são esperados erros de retorno vazio e de conexão, onde também 
aparecerá uma mensagem fixa na página informando o motivo do mesmo. 
 
4.2.7 Interação com o sistema de pedidos 
 
Nessa interação, foi adotado um sistema de status com as seguintes possibilidades e 
seus significados: 
a) Realizado: Status que indica que o cliente finalizou um pedido, enviando-o ao 
fornecedor responsável. Apenas o cliente pode ativá-lo. 
b) Em andamento: Momento em que o fornecedor abre o atendimento de um pedido 
que acabou de receber, colocando em andamento até o momento da entrega. Apenas o 
fornecedor pode ativar este status. 
c) Cancelado: Ao perceber algum problema no seu pedido, o cliente pode cancelá-lo, 
desde que, o fornecedor ainda não o tenha colocado em andamento, neste caso, o usuário é 
direcionado ao WhatsApp do fornecedor para realizar o cancelamento do modo que lhes 
convier. Em outro caso, o fornecedor pode realizar o cancelamento a qualquer momento, 
sendo obrigado a enviar um motivo de cancelamento, que chegará em forma de alerta para o 
cliente. 
d) Entregue: Esse status pode ser ativado pelos dois agentes, um pedido deve assumir 
este valor apenas quando a entrega for finalizada. 
Os erros esperados nesta página tendem aos padrões, sendo erros de conexão e de 
retorno vazio, assim como as demais, são apresentadas fixas na tela. 
 
4.2.8 Entrar em contato 
 
É exposto uma página no sidebar onde um fornecedor ou um cliente pode entrar em 
contato conosco, seja para fazer negócio ou passa algum feedback, assim, mantendo uma 
linha de comunicação com os usuários e fornecedores. 
40 
 
Não há rota alternativa para esta interação, sendo links que independem de internet 
para serem realizadas, não tendo nenhuma entrada de texto e não tem nenhum tipo de retorno 
do banco de dados. 
 
4.3 Estrutura lógica da aplicação dos fornecedores 
 
A fim de demostrar como é esperado o uso da aplicação dos fornecedores, abaixo é 
apresentado o fluxograma que exemplifica os direcionamentos e principais decisões dentro de 
cada página ou fluxo do app. 
 
Figura 16 - Fluxograma da aplicação das empresas 
Fonte: Autor (2020) 
 
Logo, assim como no app dos consumidores, esse tem um sistema de login e 
tratamento de dados cadastrais de forma suscinta, afim de ser uma plataforma limpa e simples 
para ambos os tipos de usuários. Ainda é possível notar que há o sidebar, que dará a qualquer 
momento atalhos para as páginas principais da aplicação, esse que é apresentado a seguir. 
41 
 
Figura 17 - Representação do componente sidebar do app das empresas 
 
 Fonte: Autor (2020) 
 
Para melhor entender o modo como os fornecedores verão as possibilidades de 
utilização dessa aplicação, abaixo é apresentado o diagrama de caso de uso, exemplificando as 
principais interações deste usuário com a plataforma. 
42 
 
 Figura 18 - Diagrama de caso de uso do app das empresas 
 
 Fonte: Autor (2020) 
 
Com o diagrama acima, é observável as interações de forma simples e para melhor 
entendimento desses casos de uso, é apresentado abaixo as devidas considerações sobre cada 
um deles, levando em conta o fluxo esperado e alguns erros tratados. 
 
4.3.1 Interação de login 
 
Com um sistema de login idêntico ao do app dos clientes, mas com o documento do 
banco de dados diferente, é esperado que os fornecedores, tendo um perfil ativo, entrem a 
partir de um e-mail e uma senha. Podendo observar ainda, links que direcionarão para a 
página de cadastro ou de recuperação de conta. 
43 
 
Em rota alternativa, no caso de uma inserção de dados sem o formato adequado, é 
exibido um texto informando o erro. Logo, com essa primeira validação aceita e no caso de 
algum outro tipo de erro, como falha na conexão ou perfil inexistente, o firebase informará 
em um toast o motivo do erro. 
 
4.3.2 Interação de cadastro e alteração de dados 
 
As páginas de entrada de dados referentes ao perfil do comerciante são responsáveis 
por obter todos os dados públicos e privados necessários para sua existência no sistema. 
Sendo eles: logotipo, nome, slogan, proprietário, e-mail, senha, confirmação de senha, 
categoria, rua, número, bairro, cidade, complemento, telefone1 e telefone2. 
Assim como no primeiro app, os erros tratados nesta página são, em texto fixo, 
formatos de texto inesperados, senha e confirmação diferentes ou com menos de 6 dígitos e 
imagem não suportada. Já para os erros vindos do banco de dados, são esperados erros de 
conta existente e erro na conexão. 
 
4.3.3 Recuperação de conta 
 
Com o intuito de garantir a maior independência possível dos usuários, foi criado a 
partir de serviços do firebase uma forma de recuperar o perfil sem a intervenção do suporte 
técnico, sendo assim necessário o envio do e-mail para tal ação. 
Logo, como no app dos consumidores, a única entrada de texto é do e-mail, com isso, 
os erros esperados são apenas de e-mail inexistente ou falhas de conexão, pois os demais são 
validados antes da liberação do clique no botão de recuperação. 
 
4.3.4 Interação com o gerenciamento de produtos 
 
Parao gerenciamento de produtos, são implementadas todas as fases de um CRUD 
(create, read, update e delete), sendo necessário uma página de listagem de todos os produtos 
de uma empresa, onde também é possível realizar a exclusão de algum. Ainda, é 
imprescindível uma página de leitura de um único produto, podendo a partir dessa leitura, 
fazer alguma edição. Vale ressaltar que a mesma página de leitura de um único produto, é 
reutilizada para criação de um novo produto. 
44 
 
Para tratar dos possíveis erros, são exibidos mensagem fixa na tela, informando o 
motivo da falha quando tenta-se carregar a lista de produtos, podendo apresentar erros de 
conexão ou retorno vazio. Ainda, na página de detalhes do produto, pode apresentar em toast, 
uma mensagem no caso de não encontrar o id no banco de dados ou também, por falha de 
conexão com o banco ou com a internet. 
 
4.3.5 Interação com o sistema de pedidos 
 
Da interação com os pedidos, tratados na página principal do app, o fornecedor terá 
uma lista de seus pedidos, separados por “Aguardando atendimento” e “Em atendimento”. Na 
primeira aba, é possível abrir um pedido e ter as opções de “Realizar atendimento” e 
“Cancelar atendimento”, observando uma lista com os detalhes do cliente e dos produtos 
requisitados. 
Na segunda aba, o fornecedor tem as opções de “Cancelar atendimento” e “Entregue”, 
este que só é ativo após o pedido estar em andamento. Sendo assim, mantendo o cliente 
sempre informado do andamento do seu pedido. 
Logo, são tratadas as falhas de conexão com o banco ou internet ao tentar atualizar 
status, dando um retorno ao usuário por meio de um toast, podendo haver também, erros no 
carregamento, sendo apresentado um texto fixo na tela. 
 
4.3.6 Suporte 
 
A fim de prover um sistema de comunicação direta entre os fornecedores cadastrados 
e o suporte, há uma página específica para tal, onde é possível encontrar diversas possíveis 
questões já respondidas e onde é possível conseguir um direcionamento para o WhatsApp de 
suporte. 
Há a possibilidade de o app não encontrar conexão, ocorrendo erro de lista vazia e 
exibindo uma mensagem fixa com o devido informativo. Não havendo entrada de texto, essa é 
a única forma de interação indesejada que é esperada. 
 
4.3.7 Interação de pesquisas 
Com a intenção de facilitar as buscas por um pedido, a página inicial, onde encontram-
se a lista de pedidos, foi segmentada em duas abas, sendo “Aguardando atendimento” e “Em 
45 
 
atendimento”. Assim como, para encontrar um de seus produtos, as empresas terão uma caixa 
de pesquisa no topo da lista de produtos, a fim de encontrar um produto pelo nome de forma 
fácil e rápida. 
Como rota alternativa, essas páginas podem apresentar erros de conexão, mostrando o 
motivo do erro em uma mensagem fixa na tela, assim como, no caso de ocorrer um retorno 
vazio de algum dos documentos no banco, com isso, dando um feedback ao fornecedor. 
 
4.4 Da estrutura do projeto de software 
 
Para tanto, além do componente sidebar criado pelo autor , representado na figura 19 
como “Component”, e dos arquivos comuns a todo projeto com Ionic, este foi dividido em 4 
pastas principais, seus arquivos segmentados e padronizados, levando em conta as boas 
práticas de desenvolvimento de software, sendo elas: Pages, Interfaces, Services e Guards. 
 
Figura 19 - Estrutura de arquivos do projeto 
 
Fonte: Autor (2020) 
Com essa tecnologia, uma página é composta normalmente por 6 arquivos, e esse 
projeto também usará isso como base, são elas e suas funções de forma simplificada: 
46 
 
a) nomePage.html - Estrutura visual, 
b) nomePage.ts - Lógica funcional, 
c) nomePage.scss - Estilo dos componentes visuais, 
d) nomePage.spec.ts - Módulo de testes, 
e) nomePage.module.ts - Para o Lazy Loading dos componentes, 
f) nomePage.routing.module.ts - Roteamento com outros arquivos. 
Essa estrutura pode ser visualizada na imagem que segue, com o exemplo da página 
home. 
Figura 20 - Estrutura de arquivos de uma página 
 
 Fonte: Autor (2020) 
 
As Interfaces, neste projeto, são classes que comportam estruturas de códigos comuns 
a diversas páginas, como os atributos de um Usuário, necessários ao seu cadastro e 
recuperação de dados na plataforma. A vantagem de usar as Interfaces está no 
reaproveitamento de código, evitando ter que recriar uma classe ou conjunto de variáveis em 
todas as páginas necessárias, além de evitar, também, erros como o esquecimento de alguma 
variável nessas classes, melhorando assim, o entendimento dessas estruturas de código. 
Já os Services são arquivos que, assim como as Interfaces, servem para comportar 
estruturas de código comuns, mas em vez de atributos, ele é formado por métodos como o 
CRUD (Create, Read, Update e Delete) com o banco de dados ou o serviço de autenticação, 
evitando ter essas porções de código espalhadas pelas diversas páginas. 
Por fim, os Guards são arquivos relativamente pequenos dentro deste projeto, mas 
com funções muito importantes, pois são eles que garantem que o usuário não terá acesso a 
determinada página sem a autenticação necessária, dando maior segurança e confiabilidade ao 
software. 
A fim de demonstrar a interação da plataforma como um todo, unindo as interfaces, 
services e classes com suas devidas conexões, abaixo é apresentado um diagrama de classes. 
47 
 
Com isso é possível o entendimento, em um contexto geral, do funcionamento dos 
dois aplicativos trabalhando em conjunto, e assim, poder entender de forma abstrata os 
objetivos de cada ator, funções e atributos dentro do escopo da plataforma. 
 
Figura 21 - Diagrama de classe da plataforma 
Fonte: Autor (2020) 
 
Atuando em conjunto, os dois aplicativos possuem diversas interligações em comum, 
pois aonde um ator publica, o outro compra, aonde um realiza um pedido, o outro atende. 
Logo, na diagramação desta plataforma o resultado obtido foi objetivo e conciso, a fim de 
passar da melhor maneira as interações entre as aplicações que compõe o produto de software 
evidenciado neste trabalho. 
 
 
 
 
 
48 
 
5 RESULTADOS E ANÁLISES 
 Nesta seção, são apresentados os resultados das pesquisas de mercado, realizadas com 
os consumidores e com as empresas atuantes na modalidade delivery da cidade de Tauá-CE. 
Em seguida, o resultado do produto de software construído, demonstrando os objetivos que 
foram alcançados e a visualização dos protótipos em execução. 
 
5.1 Resultados e análises das pesquisas 
 
Com o objetivo de pesquisa completo, as hipóteses desse projeto se mostraram 
corretas, com muitas pessoas de diversas faixas etárias adeptas à ideia de ter um aplicativo 
que promova um sistema de delivery através de pedidos online, tal qual este trabalho propõe. 
Além disso, todas as empresas se posicionaram interessadas em um produto de software como 
o proposto. 
Portanto, segundo as respostas dos questionários, a criação de um sistema que leve em 
conta as questões negativas e positivas desse banco de respostas, ajudaria a evitar muitos erros 
de comunicação no atendimento, melhorando as experiências e centralizando o mercado 
online municipal. Obtendo assim, um grande diferencial em relação as demais aplicações que 
apresentam seus serviços no município. 
Sobre as dificuldades encontradas, a de maior relevância foi a de obter dados a partir 
dos questionários, com a dos consumidores tendo maior visibilidade em redes sociais como 
Facebook e Whatsapp e a dos comerciantes sendo enviadas diretamente para o contato deles. 
A disponibilidade das empresas em responder o questionário foi menor, porém, as que o 
fizeram mostraram concordância com a proposta deste trabalho, inclusive com a possibilidade 
de oferecer feedbacks durante o desenvolvimento do app. 
Ainda, dando ênfase aos dados do formulário dos fornecedores, é observável que 
100% das respostas indicaram utilizar Whatsapp e 92,3% Instagram para receberempedidos, 
o que reforça uma necessidade que na penúltima questão foi também confirmada, onde 69,2% 
apontaram que necessitam de um projeto assim. 
Logo, a modalidade delivery continua em constante crescimento e desenvolvimento, o 
que faz com que este trabalho tenha potencialidade de atingir uma considerável parcela desse 
mercado no município. 
 
 
49 
 
5.2 Resultados e análises do desenvolvimento dos softwares 
 
5.2.1 Layout e cumprimento dos requisitos funcionais do app dos consumidores 
 
O aplicativo dos consumidores possui 16 páginas, distribuídas em: Login, Cadastro, 
Recuperar Senha, Página inicial, Favoritos, Empresas, Perfil da Empresa, Produtos, 
Categorias de Produtos, Subcategorias de Produtos, Produto Detalhado, Carrinho, Meus 
Pedidos, Pedido Detalhado, Perfil e Sobre Nós. Essas podem ser categorizadas em 4 tipos a 
partir do seu conteúdo e interface, são elas: 
 
a) Páginas de dados do usuário, possuindo Login, Cadastro, Recuperar Senha e Perfil. 
Nesta categoria são encontradas entradas simples de dados dos usuários, usadas para realizar 
autenticação, recuperação de conta e receber os dados de contato que serão utilizados quando 
o mesmo fizer algum pedido. A fim de cumprimento de requisitos, essas páginas respondem 
aos requisitos funcionais CRF01, com o cadastro do usuário; CRF02, com a página de login; 
CRF03, com a recuperação dos dados de uma conta e CRF04, com a possibilidade de 
alteração de dados cadastrais no perfil. Abaixo é possível ver as páginas citadas e ter noções 
do layout. 
50 
 
Figura 22 - Páginas de entrada de dados no app do consumidor (1) 
 
Fonte: Autor (2020) 
51 
 
Figura 23 - Páginas de entrada de dados no app do consumidor (2) 
 
Fonte: Autor (2020) 
 
b) Páginas de listagem, sendo a Página Inicial, Empresas, Categorias de Produtos, 
Subcategorias de Produtos e Produtos, essas que atuam no cumprimento dos requisitos 
CRF05, possibilitando a buscar por um produto pelo searchbar ou filtrando por categoria e de 
uma empresa pelas categorias expostas na listagem ou select. Esse tipo de página possui ainda 
a Meus Pedidos que exibe e dá a possibilidade de exclusão de um pedido, contribuindo para o 
CRF11, Favoritos que lista um vetor com produtos separados para o cliente e Carrinho que 
contribui no cumprimento da CRF09 na exclusão de um pedido do carrinho. Local de 
listagem de dados, onde é possível encontrar muitos dados ordenados, a fim de mostrar 
diversas possibilidades de escolha para o usuário. Com o dito, na figura que segue é exposto 
as páginas Produtos, Principais Categorias, Meu Carrinho e Meus Pedidos, respectivamente, a 
fim de exemplificar os modelos de listagem e forma de dispersão dos componentes de cada 
item dentro de uma lista no app. 
52 
 
Figura 24 - Páginas de listagem do app dos consumidores (1) 
 
Fonte: Autor (2020) 
53 
 
Figura 25 - Páginas de listagem do app dos consumidores (2) 
 
Fonte: Autor (2020) 
 
c) Páginas de detalhes, com o Perfil da Empresa, Produto Detalhado e Pedido 
Detalhado. Ao selecionar algum item dentro de uma lista, seja uma empresa, produto ou um 
de seus pedidos, o usuário vai para uma página detalhada deste item, afim de possibilitar uma 
melhor visualização, contribuindo para os requisitos CRF06, CRF07 no gerenciamento de 
favoritos. CRF08 na adição de um produto ao carrinho e CRF11 na possibilidade de exclusão 
de um pedido. Com isso, a figura abaixo mostra o perfil de uma empresa, detalhes de um 
produto e pedido detalhado na visão dos usuários. 
54 
 
Figura 26 - Páginas de detalhes da empresa, do produto e do pedido (visão do 
consumidor) 
Fonte: Autor 2020 
 
d) Páginas de Suporte, possuindo apenas a página Sobre Nós. Esta mostra informações 
públicas do Buyers Sheeps de forma simplificada, dando a possibilidade de uma empresa 
entrar em contato a fim de assinar o serviço, assim como, dos usuários mandarem feedbacks 
para melhoria da aplicação. Essa página justifica o requisito CRF12, dando o meio de 
comunicação ao usuário. 
As páginas de maior importância, por demandar uma maior complexidade de 
integração com o banco de dados, são Carrinho e Meus Pedidos, pois necessitam trabalhar e 
assimilar sem possibilidade de erros os diferentes tipos de dados de diferentes alocações, de 
forma impecável e síncrona, produzindo um resultado correto para cada usuário sobre seus 
pedidos em cada empresa. 
 
5.2.2 Layout e cumprimento dos requisitos funcionais do app fornecedores 
 
Na aplicação dos fornecedores há 9 páginas, sendo elas: página inicial, pedidos 
detalhados, meus produtos, editar/criar um produto, alterar dados, cadastro, login, recuperar 
55 
 
conta e suporte. Também, assim como o app dos consumidores, podendo ser categorizadas 
pelo conteúdo de seu layout: 
 
a) Páginas de dados - Páginas cujo fim é obter informações para sincronizar no banco 
de dados, possuindo campos de entrada de texto e de arquivos, no caso, imagens. Esse tipo de 
página é visível nas páginas: cadastro, login, recuperar conta e alterar dados. Assim como no 
app dos clientes, essas páginas cumprem os requisitos de autenticação e manutenção de dados 
referente a CRF01, CRF02, CRF03 e CRF04. Dentre essas, as páginas a seguir são 
apresentadas para se ter noções do layout adotado para esse tipo de página: 
 
Figura 27 - Páginas de entrada de dados no app das empresas 
 
Fonte: Auto (2020) 
 
b) Páginas de detalhes - Semelhante ao app dos consumidores, as páginas deste app 
possuem um background dark, mas com opções diferentes de interação. A exemplo da página 
pedido detalhado que possui, neste app, as funções de mudar o status para “Em andamento”, 
“Entregue” e “Cancelado”, enquanto essa página no app dos consumidores pode alterar para 
“Realizado”, “Entregue” e “Cancelado”. Portanto, essa página cumpre o requisito FRF10, na 
alteração do status ao excluir. Ainda, também há a página de edição e criação de um produto, 
possuindo entrada de texto, mas se assimilando mais com o detalhamento de um produto, 
entrando assim, nessa categoria e cumprindo o requisito FRF06 e FRF08. 
56 
 
Figura 28 - Detalhes de um pedido e de um produto (visão da empresa) 
 
Fonte: Autor 2020 
c) Páginas de listagem - Nesta categoria, são encontradas as páginas: página inicial e 
meus produtos, com o mesmo intuito apresentado no app dos consumidores, esse tipo de 
página oferece uma listagem de vários itens, sejam produtos ou pedidos, com isso, essas 
páginas cumprem os requisitos funcionais citados em FRF05, FRF09 e FRF11. A seguir as 
páginas são exibidas para uma melhor noção do layout. 
57 
 
 Figura 29 - Páginas de listagem do app das empresas 
 
 Fonte: Autor 2020 
d) Página de suporte – Nesta, é apresentado algumas possíveis dúvidas respondidas, 
além de um botão com direcionamento para o WhatsApp, para assim, realizar novos 
questionamentos sobre a plataforma e assim ter quaisquer dúvidas sanadas. Logo, cumprindo 
o requisito de feedback citado no requisito FRF12. 
 
5.2.3 Análise final do desenvolvimento 
 
Com a proposta deste trabalho de desenvolver uma plataforma de e-commerce para o 
município de Tauá e de reunir dados sobre a necessidade de uma, foi possível chegar a um 
protótipo construído com Ionic framework e Firebase, observando-a como uma proposta 
válida, segundo os dados obtidos em pesquisa com a população de consumidores e 
comerciantes da modalidade delivery. 
Como a plataforma de comércio ainda está na fase de protótipo, não é rentável, logo, 
serviços pagos como notificações push, upload para a Google Play/App Store e contrato com 
o Firebase para obter um poder de armazenamento maior, ficaram de fora do projeto, mas 
58 
 
tudo indica que tal plataforma terá futuramente a aceitação necessária para ser mantida com 
os serviços necessários à sua melhor performasse.