TCC Lucas - Completo

UNIVERSIDADE ESTÁCIO DE SÁ
LUCAS FERREIRA VAL
SISTEMA DE REGULAÇÃO DE TRÁFEGO DE PESSOAS EM

ESTABELECIMENTOS
Rio de Janeiro
2021
UNIVERSIDADE ESTÁCIO DE SÁ
LUCAS FERREIRA VAL

ESTABELECIMENTOS
Relatório final, apresentado a

Universidade Estácio de Sá, como parte
das exigências para a obtenção do título
de Bacharel em sistemas de informação.
Rio de Janeiro
2021
LUCAS FERREIRA VAL

ESTABELECIMENTOS
Relatório final, apresentado a

Universidade Estácio de Sá, como parte
das exigências para a obtenção do título
de Bacharel em sistemas de informação.
Aprovado em ___ de _________ de 2021
BANCA EXAMINADORA
___________________________________________________________________
Prof. Maiara Heil Cancian
Universidade Estácio de Sá
Resumo
Atender a necessidade de um cenário de pandemia em um primeiro momento,

criando a possibilidade de uma maior rentabilidade para os estabelecimentos,
buscando fortalecer as relações comerciais com base nos decretos do município, o
objetivo desse trabalho é criar um sistema que faça o controle e monitoramento do
tráfego de pessoas em estabelecimentos comerciais para evitar aglomerações,
posterior ao período da pandemia sendo empregado como um sistema de reserva
de lugares.
Palavras-chave: necessidade, controle, tráfego, reserva.

Abstract
To attend the necessity of a pandemic scenario on the first moment, creating the
possibility of a greater profitability for the establishments, seeking to strength the
commercial relationship based on municipal decrees, the objective of this work is to
create a system that control and monitor the traffic of people in commercial
establishments, to avoid crowd, after the pandemic period this system will be implied
as a seat reservation system.
Keywords: necessity, control, traffic, reservation.

LISTA DE ILUSTRAÇÕES
Figura 1. Cronograma detalhado de trabalho.............................................................16

Figura 2. Diagrama de casos de uso..........................................................................25
Figura 3. Modelo conceitual de classes......................................................................37
Figura 4. Modelo conceitual de dados........................................................................38
Figura 5. Diagrama de sequências.............................................................................39
Figura 6. Tela de login – visão do estabelecimento...................................................40
Figura 7. Tela cadastro – Visão estabelecimento.......................................................40
Figura 8. Tela de Estabelecimento – Atualização.......................................................41
Figura 9. Tela de estabelecimento – Inclusão............................................................41
Figura 10. Tela de estabelecimento – Atualização 1..................................................42
Figura 11. Tela de estabelecimento – Atualização 2..................................................42
Figura 12. Tela estabelecimento – Consulta reservas ativas.....................................43
Figura 13. Tela de alteração de senha – Estabelecimento........................................43
Figura 14. Tela login – Visão cliente...........................................................................44
Figura 15. Tela cadastro – visão cliente.....................................................................44
Figura 16. Alteração de senha – Cliente.....................................................................45
Figura 17. Consulta estabelecimento – visão cliente.................................................45
Figura 18. Consulta estabelecimento 2 – visão cliente..............................................46
Figura 19. Reserva horário – visão cliente.................................................................46
Figura 20. Diagrama de atividades.............................................................................47
Figura 21. Modelo de classe de projetos....................................................................48
Figura 22. Diagrama de implantação..........................................................................51
LISTA DE TABELAS
Tabela 1. Tabela orçamentária para aquisição de recursos de Hardware.................16

Tabela 2. Tabela orçamentária para aquisição de recursos de Software..................16
Tabela 3. Tabela orçamentária para contratação de profissionais.............................17
SUMÁRIO
1. TEMA DO TRABALHO.................................................................................10
1.1. CONTEXTUALIZAÇÃO................................................................................11
1.2. SITUAÇÃO-PROBLEMA..............................................................................11
1.3. BREVE DESCRIÇÃO DA SOLUÇÃO..........................................................11
2. CONTEXTUALIZAÇÃO................................................................................13
2.1. PREMISSAS E RESTRIÇÕES DO PROJETO............................................13
2.1.1. PREMISSAS................................................................................................13
2.1.2. RESTRIÇÕES..............................................................................................13
2.2. PERFIL DO PÚBLICO-ALVO.......................................................................13
2.2.1. PÚBLICO-ALVO...........................................................................................13
2.2.2. ATIVIDADES DO PÚBLICO-ALVO..............................................................13
2.2.3. ORGANOGRAMA........................................................................................14
2.3. PROPOSTA DE TRABALHO.......................................................................14
2.3.1. MÉTODO DO TRABALHO...........................................................................14
2.3.2. PREVISÃO E ALOCAÇÃO DE RECURSOS (HUMANOS E MATERIAIS).15
2.3.3. CRONOGRAMA DE TRABALHO................................................................15
2.3.4. PREVISÃO ORÇAMENTÁRIA.....................................................................16
2.4. O SISTEMA AUAL.......................................................................................17
2.4.1. FUNCIONAMENTO DO SISTEMA ATUAL.................................................17
2.4.2. PROBLEMAS DO SISTEMA ATUAL...........................................................17
3. A SOLUÇÃO................................................................................................18
3.1. O SISTEMA PROPOSTO............................................................................18
3.1.1. JUSTIFICATIVAS PARA O NOVO SISTEMA.............................................18
3.1.2. SITUAÇÃO DESEJADA...............................................................................18
3.2. SOLUÇÃO ESCOLHIDA..............................................................................19
3.2.1. LISTA DE REQUISITOS DO SISTEMA.......................................................19
3.2.1.1. REQUISITOS FUNCIONAIS........................................................................19
3.2.1.2. Requisitos não funcionais............................................................................23
3.2.2. DIAGRAMA DE CASOS DE USO................................................................25
3.2.3. ESPECIFICAÇÕES TEXTUAIS DOS CASOS DE USO.............................25
3.2.4. MODELO CONCEITUAL DE CLASSES......................................................37
3.2.5. MODELO CONCEITUAL DE DADOS.........................................................38
3.3. Solução tecnológica.....................................................................................39
3.3.1. Diagrama de sequência...............................................................................39
3.3.2. Projeto de interface......................................................................................40
3.3.3. Diagrama de atividades...............................................................................47
3.3.4. Modelo de Classes do projeto......................................................................48
3.3.5. Modelo fisico de dados.................................................................................49
3.3.5.1. Script de geração do banco de dados e tabelas.........................................49
3.3.6. Ambiente tecnológico do sistema................................................................51
3.3.6.1. Ambiente fisico(Diagrama de implantação).................................................51
3.3.6.2. Justificativa da escolha da linguagem de programação..............................51
3.3.6.3. Justificativa da escolha do SGBD (Sistema Gerenciador de Banco de
Dados) ......................................................................................................................52
4. Conclusões...................................................................................................53
4.1. Reflexões e comparação entre objetivos iniciais x alcançados...................53
4.2. Vantagens e desvantagens do sistema.......................................................53
4.3. Trabalhos futuros.........................................................................................54
5. REFERÊNCIAS BIBLIOGRÁFICAS.............................................................55
10
1. TEMA DO TRABALHO
Em dezembro de 2019, o primeiro caso de Covid-19, oficialmente, é
declarado ter ocorrido na China na cidade de Wuhan, sendo, este, vinculado ao
mercado de frutos do mar de Huanan. Logo foi percebido a velocidade que esta
doença se espalhava e o quão rápido as pessoas se contaminavam, em pouco
tempo Covid-19, sai de China e se internacionaliza, e, no dia 11 de março de 2021,
a Oms a caracteriza como pandemia.
Por causa da velocidade como a doença se propagou, muitos países

tomaram a decisão de instaurar lockdown, obrigatoriedade no uso de máscaras,
recomendação do uso do álcool gel ou álcool 70% na higienização das mãos,
instauração de um toque de recolher, fechamento de transporte público, limitação
para a capacidade máxima de pessoas dentro de estabelecimentos, para que assim,
com o contato entre pessoas menor, pudesse reduzir a transmissão da Covid-19.
Uma preocupação muito grande que surgiu durante esse período inicial foi
com a economia, pois, com um lockdown instaurado, muitas lojas, restaurantes,
pequenos e médios comércios, que muitas vezes operam com uma margem de lucro
pequena, poderiam vir a falir. Muitas empresas optaram por um esquema de
teletrabalho, porém, nem todas as companhias puderam fazer o mesmo, empresas
de construção, restaurantes, transporte não tem como fazer trabalho remoto.
Mais de um ano depois dos primeiros casos, vacinas foram desenvolvidas e a

vida está, aos poucos, voltando a normalidade conhecida antes do início da
pandemia, porém ainda existe a preocupação com o contágio pela Covid-19, sendo
ainda recomendado o uso de máscaras, presença de álcool gel na entrada de
estabelecimentos comerciais e a instrução para evitar aglomerações.
Mas mesmo com todos os cuidados e avanços contra a doença que estão
acontecendo, ainda fica a pergunta de como evitar novas ondas dela. A resposta
pode estar nos cuidados que foram tomados durante a pandemia, como redução da
capacidade máxima, filas para entrar nos estabelecimentos, reservas antecipadas,
medidas que visam reduzir as aglomerações. O problema das filas no lado externo é
que, ao invés de evitar multidões dentro dos estabelecimentos apenas a transfere
para o lado de fora.
11
Por esta pandemia ter acontecido na era da informação foi feita a pergunta:
“Porque não trazer a fila presencial para a fila a distância?”, desse jeito poderiam ser
resolvidos vários problemas de uma única vez, reduzir a aglomeração, agilizar as
filas, controlar a entrada de saída de pessoas dos estabelecimentos, simplificar a
comunicação de clientes e prestadores de serviço.
1.1. CONTEXTUALIZAÇÃO
O sistema foi pensado, para que, durante a pandemia de Covid-19 pudesse

facilitar o controle da entrada de pessoas em estabelecimentos comerciais, para que
pudesse ser prevenido o acontecimento de aglomerações de pessoas, e pudesse
ser monitorado o limite máximo de pessoas dentro destes, respeitando assim, o
limite decidido pelos Estados.
1.2. SITUAÇÃO-PROBLEMA
Durante pandemia da Covid-19 muitos estabelecimentos comerciais

funcionaram com o esquema de rodizio de clientes e filas, para que pudesse ser
controlado o ingresso de consumidores, porém esse controle muitas vezes era
impossível, por causa de inúmeros fatores, como: número elevado de clientes, alta
demanda dos produtos e/ou serviços oferecidos, horário de funcionamento diferente
do regular, higienização constante do interior dos estabelecimentos e de bens que
podem ser tocados por várias pessoas.
1.3. BREVE DESCRIÇÃO DA SOLUÇÃO
Desenvolver um sistema, unificado, em que clientes e estabelecimentos

podem se cadastrar, para que, do lado cliente, possa ser consultado e reservado
horários para que o mesmo possa ir aos estabelecimentos usufruir de seus serviços
e/ou produtos, do lado dos estabelecimentos, possam ser cadastrados serviços e/ou
produtos ofertados, horário de funcionamento, informações de contato, um fila virtual
12
com horários que podem ser reservados pelos clientes para que eles possam ir
visitar os estabelecimentos.
13
2. CONTEXTUALIZAÇÃO
2.1. PREMISSAS E RESTRIÇÕES DO PROJETO
2.1.1. PREMISSAS
1. O cliente liberará ambientes de teste para o sistema.
2.1.2. RESTRIÇÕES
1. O valor do projeto não poderá ser superior a 120% do

estimado;
2. O término do projeto não poderá ser após dezembro de

2021;
2.2. PERFIL DO PÚBLICO-ALVO
2.2.1. PÚBLICO-ALVO
O sistema é destinado para prestadoras de serviços, estabelecimentos

comerciais que desejam ter um maior controle do fluxo de pessoas, um meio de
contato mais fácil para seus clientes e que desejam informatizar as filas.
O sistema também visa atender as necessidades dos clientes, sejam pessoas

físicas ou pessoas jurídicas que desejem facilitar o acesso aos estabelecimentos
cadastrados no sistema durante o período pandêmico da Covid-19, evitando
aglomerações, podendo ser estendido no período posterior a pandemia.
2.2.2. ATIVIDADES DO PÚBLICO-ALVO
O sistema será desenhado para atender a necessidade da maior parte de

estabelecimentos e de clientes, permitindo o cadastro de serviços dos mais variados
setores, podendo ser citado como exemplo, reservas em restaurantes e em salões
14
de beleza, agendamento de visita a loja de vestuário, marcação de horário em

consultórios médicos e dentistas, filas virtuais para prestação de serviços como
oficinas de carro, manutenção de aparelhos eletrônicos. O sistema deve permitir a
consulta por parte dos clientes dos serviços e/ou produtos cadastrados, bem como
visualizar os horários e dias disponíveis, deve ser capaz de exibir informações sobre
os estabelecimentos cadastrados.
2.2.3. ORGANOGRAMA
O objetivo do sistema é ser o mais inclusivo possível, abrangendo público de

todas as idades, credos, raças, posição social, deixando na responsabilidade das
empresas que optarem por fazer o cadastro no sistema de serviços direcionados a
um público-alvo específico ou não.
2.3. PROPOSTA DE TRABALHO
2.3.1. MÉTODO DO TRABALHO
O desenvolvimento do trabalho foi feito com base em pesquisas de

amostragem com consumidores e empresas, tal pesquisa foi encomendada pela
ABRASCE (Associação Brasileira de Shopping Centers), baseada essencialmente
na necessidade de desenvolver uma ferramenta que gere lucro, segurança e
comodidade para os utilizadores e estabelecimentos cadastrados.
As entrevistas foram realizadas com cerca de 500 pessoas, incluindo-se

consumidores, donos de estabelecimentos, visando identificar se a aplicação do
sistema seria favorável no âmbito proposto.
Depois de determinado os resultados da amostragem, identificou-se que a

solução proposta foi bem-vista por 90% dos entrevistados pela pesquisa, ficando
acordado entre as partes, o desenvolvimento de um sistema que atenda às
necessidades propostas na pesquisa.
15
Na fase de Análise será empregada a utilização dos diagramas da UML,

objetivando mapear o sistema e os devidos processos com o intuito de gerar a
documentação necessária para o seu desenvolvimento adequado por parte dos
desenvolvedores do sistema.
No estágio do desenvolvimento do projeto será empregado o

desenvolvimento Web, utilizando-se a linguagem de programação PHP. No
Emprego do SGBD será utilizado um banco de dados no formato MySQL.
2.3.2. PREVISÃO E ALOCAÇÃO DE RECURSOS (HUMANOS E MATERIAIS)
Para o desenvolvimento do sistema foi percebido que será necessário a

alocação de 2 desenvolvedores, 1 gerente do projeto, 2 analistas de sistemas, 1
administrador de bancos de dados e 1 usuário para testar versões pré-lançamento.
Foi percebido que será necessária 1 licença do software para gerenciamento

de projetos Microsoft Project, 4 licenças do Microsoft Office, uso da linguagem PhP,
MySQL, e 6 licenças do sistema operacional Windows 10 e Desktops para uso dos
analistas e desenvolvedores.
2.3.3. CRONOGRAMA DE TRABALHO
A figura abaixo, feita no Microsoft Excel 2010, demonstra em detalhes o

cronograma de trabalho adotado pelo autor para esta pesquisa.
16
Figura 1. Cronograma detalhado de trabalho
Fonte: o autor.
2.3.4. PREVISÃO ORÇAMENTÁRIA
Para o desenvolvimento do sistema Reservado será necessária a aquisição

de recursos tais como Hardware, Software e profissionais a serem empregados no
desenvolvimento do projeto.
Tabela 1. Tabela orçamentária para aquisição de recursos de Hardware
Hardware Quantidade Valor total

Desktop DELL 4 20.000,00
Fonte: o autor.
Tabela 2. Tabela orçamentária para aquisição de recursos de Software
Software Quantidade Descrição Valor total

Ms Project 1 Gerenciador de projeto 2.000,00
Microsoft Office 2016 4 Editor de texto 2.000,00
Linguagem de
PHP 2 Gratuito
programação
MySQL 1 SGBD Gratuito
Microsoft Windows 6 Sistema Operacional 6.000,00
17
Software Quantidade Descrição Valor total

10
Fonte: o autor.
Tabela 3. Tabela orçamentária para contratação de profissionais
Cargo Quantidade Valor total

Gerente do projeto 1 12.000
Desenvolvedor 2 24.000
Analista de sistemas 2 24.000
Administrador de Banco de Dados 1 8.800
Beta tester 2 2000
Valor total do projeto : 100.800,00 R$
Fonte: o autor.
2.4. O SISTEMA AUAL
2.4.1. FUNCIONAMENTO DO SISTEMA ATUAL
Nos dias de hoje existem algum sistemas, sejam online ou por aplicativos que
realizam o processo que o sistema proposto pretende realizar, porém nenhum deles
foi focado especificamente para o período pandêmico. Os sistemas que existem
atualmente são específicos apenas para um tipo de serviço e não gerais como está
sendo proposto, por isso foi pensando unificar o processo de reservas em um só
sistema, facilitando tanto para quem quer prestar serviços quanto para quem quer
usufruir deles.
2.4.2. PROBLEMAS DO SISTEMA ATUAL
Os poucos sistemas que existem hoje em dia foram pensando para serem
usados em períodos não pandêmicos e apenas para o oferecimento de
estabelecimentos prestadores de serviços, como salões de cabelereiro e, não sendo
um sistema unificado, de cadastro único dificulta para os clientes, fazendo com que
esses sejam obrigados a ter cadastro em diversos sites e/ou aplicativos para que
possam usufruir de diversos serviços. Por isso, um sistema visado para atender as
18
necessidades especiais durante tempos de pandemia foi pensado, visando obedecer

a todas as restrições sugeridas pela OMS e pelos Estados.
19
3. A SOLUÇÃO
3.1. O SISTEMA PROPOSTO
3.1.1. JUSTIFICATIVAS PARA O NOVO SISTEMA
Durante a pandemia da Covid-19 diversas novas regras foram impostas, uso

obrigatório de máscaras, toque de recolher no período mais crítico da pandemia,
lotação e horários reduzidos para funcionamento de estabelecimentos comerciais.
Este último, o mais problemático para os ditos estabelecimentos, pois, reduziu de
maneira drástica os lucros e, gerou filas do lado externo o que pode ter criado
aglomerações. Analisando tudo isso o sistema proposto foi pensando, visando levar
as filas para o virtual e não mais para o pessoal, possibilitando os clientes a
reservarem horários para visitação dos estabelecimentos, fazendo com que o
estabelecimento possa gerenciar melhor a lotação máxima permitida, melhor
controle do fluxo de clientes, podendo, pelas reservas, entender qual horário mais
visado, permitindo que o estabelecimento possa fazer um maior número de ações
naquele horário especifico, permitindo maior segurança para clientes e funcionários,
pois durante período de tempo apenas um número de clientes, controlado e pré-
determinado estaria dentro do estabelecimento, respeitando os limites sugeridos
pela Oms e impostos por estados e municípios.
3.1.2. SITUAÇÃO DESEJADA
A situação desejada é que o sistema esteja pronto para lançamento e para

uso com as funcionalidade básicas, cadastro de clientes e prestadores de serviço,
permitindo que os clientes busquem e reservem horários cadastrados pelos
prestadores de serviço, permitir que os prestadores de serviços possam cadastrar
seus serviços e horários disponíveis, alteração de uma reserva, seja por parte do
cliente, seja por parte do prestador.
20
3.2. SOLUÇÃO ESCOLHIDA
3.2.1. LISTA DE REQUISITOS DO SISTEMA
3.2.1.1. REQUISITOS FUNCIONAIS
Requisitos funcionais representam as funções e informações do sistema,

portanto o objetivo principal desses requisitos é descrever as funcionalidades e os
serviços do sistema preocupando-se com o comportamento do sistema em diversos
cenários.
 USUÁRIO DO SERVIÇO
O sistema deve permitir o cadastro dos dados por parte do usuário do serviço,
para que ele possa usufruir das funcionalidades do sistema, tais como reservas de
horários e dia em um determinado estabelecimento, bem como cancelamento de
reservas.
Nível de prioridade:
☒ Fundamental ☐ Importante ☐ Desejável
RF001: Incluir usuário do serviço
O sistema deve permitir a inclusão de registros de clientes. O próprio usuário

do serviço poderá se cadastrar.
RF002: Consultar usuário do serviço
O Sistema deve permitir consultar dados do usuário do serviço.
RF003: Alterar usuário do serviço
O Sistema deve permitir a atualização dos dados do usuário do serviço.
RF004: Excluir usuário do serviço

21
O Sistema deve permitir a exclusão dos usuários do serviço, desde que não
fira as regras do SGBD quanto à integridade referencial.
 EMPRESA – Estabelecimento prestador de serviço.
O sistema deve permitir que a empresa, possa cadastrar-se no sistema,

informando todos os dados necessários para que possa disponibilizar os dias e
horários de reservas disponíveis.
RF005: Incluir estabelecimento
O Sistema deve permitir a inclusão de registro de estabelecimento, sendo

assim, a própria empresa fica responsável por se cadastrar no sistema.
RF006: Consultar estabelecimento
O Sistema deve permitir a consulta aos registros de Empresas cadastradas.
RF007: Alterar dados do estabelecimento
O Sistema deve permitir a atualização nos dados da Empresa.
RF008: Excluir estabelecimento
O Sistema deve permitir a exclusão do estabelecimento, desde que não fira

as regras do SGBD quanto à integridade referencial.
 SERVIÇOS/PRODUTOS
Os serviços serão oferecidos pela empresa para que os clientes os vejam

previamente pelo aplicativo.

22
RF009: Incluir Serviço
O Sistema deve permitir que o estabelecimento inclua os serviços prestados.
RF010: Alterar Serviço
O Sistema deve permitir a alteração dos registros de serviços prestados.
RF011: Excluir Serviço
O Sistema deve permitir a exclusão de serviços.
RF012: Consultar serviços
O sistema deve permitir a consulta aos registros dos serviços e/ou produtos
ofertados no local físico das empresas.
RF013: Cadastrar agenda de serviços
O Sistema deve permitir que o estabelecimento cadastre a agenda de

serviços.
 RESERVAS
Reservas são incluídas pelos estabelecimentos, para que os usuários do

serviço possam escolher o melhor horário e serviço oferecido pelos
estabelecimentos, dentre outras funcionalidades.
Nível de prioridade
RF014: Inserir Reserva Horário
O Sistema deve permitir que o usuário possa fazer uma reserva para o
estabelecimento, para uma data e horário disponível.
RF015: Cancelar reserva

23
O Sistema deve permitir o cancelamento por parte do usuário do serviço, da

reserva no máximo 24 horas antes do horário reservado, sem sofrer sanções.
RF016: Cancelar reserva como estabelecimento
O Sistema deve permitir que o estabelecimento efetue o cancelamento da

reserva dos usuários do serviço, apresentando uma justificativa para esse
cancelamento.
RF017: Consultar histórico de reserva
O Sistema deve permitir que o usuário do serviço possa consultar o histórico

das suas reservas.
RF018: Alertar cancelamento de reserva para o estabelecimento
O Sistema deve emitir um alerta para o estabelecimento, no qual será

informado que um usuário do serviço cancelou a reserva. Ao cancelar um serviço
agendado, o sistema emite uma notificação para o estabelecimento, bem como, para
o usuário do serviço. Essa notificação será exibida por meio do próprio sistema.
 FINANCEIRO
☐ Fundamental ☐ Importante ☒ Desejável
O sistema poderá permitir a realização de pagamento de serviços por meio do

próprio sistema, bem como gerar relatórios para as empresas.
RF019: Pagar pelo aplicativo
Usuário poderá efetuar pagamento de serviços pelo aplicativo, possibilitando

que o usuário do serviço possa realizar o pagamento antecipado, no ato do
agendamento da reserva.
24
RF020: Gerar relatório financeiro para o estabelecimento
O sistema permitirá a geração de um relatório financeiro dos

estabelecimentos, por período, contendo todos os pagamentos efetuados pelos
clientes através do sistema.
 RANQUEAR ESTABELECIMENTO
O sistema deve permitir que clientes possam fornecer uma nota para os
estabelecimentos que ele reservou horários, avaliando como foi prestado o serviço
avaliado.
☐ Fundamental ☒ Importante ☐ Desejável
RF021: Ranquear estabelecimento
Usuários do serviço poderão ranquear as empresas cadastradas no sistema.
RF022: Consulta reserva
O sistema permitirá o estabelecimento consultar as avaliações feitas pelos

usuários do serviço, acerca dos serviços prestados pelo estabelecimento.
RF023: Registrar atendimento da reserva
O sistema deverá permitir que o estabelecimento ao registrar o atendimento

da reserva, gere uma avaliação do serviço que será feita pelo usuário do serviço.
3.2.1.2. Requisitos não funcionais
Requisitos não funcionais englobam propriedades tais como, a linguagem de

programação a ser utilizada no desenvolvimento do projeto, o tipo de SGBD a ser
empregado na construção do Banco de dados, questões que envolvam o sistema
25
operacional, método de desenvolvimento, sendo em sua grande maioria

mensuráveis.
RNF001 - Os usuários de negócio conseguirão se adaptar ao aplicativo após

um treino básico e curto; os consumidores conseguirão se adaptar ao sistema após
um curto período de uso.
RNF002 - O sistema estará disponível em 98% do tempo, exceto em ocasiões

que sejam necessárias a parada do sistema para alguma possível manutenção.
RNF003 - O sistema estará disponível em 99% de todos os dispositivos Web.

Não está nos planos o desenvolvimento para outros dispositivos devido à
complexidade. Num segundo release será feito o lançamento de uma versão voltada
para usuários dos sistemas Android.
RNF004- Não mais do que 5 erros a cada 1000 cadastros de visitação e 5

erros a cada 500 de cadastro de produtos por parte das empresas/negócios.
RNF005 - Será utilizada a linguagem de programação PHP juntamente com a

tecnologia Javascript e para o gerenciamento do SGBD será feito através de um
banco de dados MySQL, utilizando o software PHPadmin e Xampp respectivamente.
RNF006- O sistema será construído para funcionar em um ambiente Web e

deverá possuir um design responsivo.
26
3.2.2. DIAGRAMA DE CASOS DE USO
A figura abaixo, de autoria própria, traz a ilustração do diagrama de casos de

uso concernentes à essa pesquisa.
Figura 2. Diagrama de casos de uso
Fonte: o autor.
3.2.3. ESPECIFICAÇÕES TEXTUAIS DOS CASOS DE USO
UC001 – Cadastrar usuário do serviço
1. Cadastrar usuário do serviço
1.1. Descrição:
27
Este caso de uso descreve o processo através do qual um usuário efetua seu
cadastro no sistema.
1.2. Atores envolvidos

Usuário do serviço.
2. Fluxos de eventos
2.1. Fluxo básico
1. Este caso de uso se inicia quando o usuário do sistema necessita fazer o
cadastro dos seus dados no sistema.
2. O sistema solicita o preenchimento dos seguintes campos obrigatórios:
1. Nome
2. Email
3. Senha
2. O sistema verifica se todos os dados foram preenchidos [FA].
3. O sistema verifica se não existe um usuário do sistema cadastrado com
o.
e-mail informado [FA].
4. O sistema realiza a inclusão dos dados do usuário do sistema informado
no passo 2.
5. O Sistema exibe uma mensagem informando que os dados foram
cadastrados.
6. O usuário do sistema confirma a mensagem.
7. O caso de uso se encerra.
2.2. Fluxos Alternativos
2.2.1. Dados obrigatórios do usuário do sistema não informado [FB-3]
1. Esse fluxo se inicia no passo 3 do subfluxo 2.1.

2. O sistema exibe uma mensagem “Dados obrigatórios não preenchidos”.
3. O Caso de uso retorna ao passo 2 do subfluxo 2.1.
2.2.2. Usuário do sistema já cadastrado [FB-4]

28
1. Este subfluxo se inicia no passo 4 do subfluxo 2.1.

2. O sistema exibe a mensagem “usuário do sistema já cadastrado”.
3. O sistema retorna ao passo 2 do subfluxo 2.2.
2.3. Pré-condições
1. Usuário não pode ter um cadastro no sistema.
2.4. Pós-condições
1. O usuário deverá ser cadastrado na base de dados.
UC002 – Cadastrar estabelecimento
1. Cadastrar Estabelecimento
1.1. Descrição
Este caso de uso descreve o processo através do qual o um
estabelecimento efetua o cadastro dos dados no sistema

Prestador de serviço
2. Fluxos de eventos
2.1. Fluxo básico (Happy Day)
1. Este caso de uso se inicia quando o prestador de serviço necessita fazer o
cadastro dos seus dados no sistema.
2. O sistema solicita o preenchimento dos seguintes campos obrigatórios:
a. Nome
b. CNPJ
c. Email
d. Senha
2. O sistema verifica se todos os dados foram preenchidos.
29
3. O sistema verifica se não existe um prestador de serviço cadastrado com

o CNPJ informado.
4. O sistema realiza a inclusão dos dados do prestador de serviço informado
no passo 2.
5. O Sistema exibe uma mensagem informando que os dados foram
cadastrados.
6. O prestador de serviço confirma a mensagem.
2.2. Fluxos Alternativos (Exceptions)

2.2.1. Dados obrigatórios do usuário do sistema não informado
1. Esse fluxo se inicia no passo 3 do subfluxo 2.1.
2. O sistema exibe uma mensagem “Dados obrigatórios não preenchidos”.
3. O Caso de uso retorna ao passo 2 do subfluxo 2.1.
2.2.2. Usuário do sistema já cadastrado

1. Este subfluxo se inicia no passo 4 do subfluxo 2.2.
2. O sistema exibe a mensagem “prestador de serviço já cadastrado”.
3. O sistema retorna ao passo 2 do subfluxo 2.2.
1. Prestador de serviços não pode ter um cadastro no sistema.
1. O prestador de serviços deverá ser cadastrado na base de dados.
UC003 – Cadastrar serviço
1. Cadastrar serviço
1.1. Descrição
Este caso de uso descreve o processo através do qual uma empresa
cadastra os serviços disponíveis no sistema.
Prestador de serviço.
30
2. Fluxo de eventos
2.1. Fluxo básico (Happy Day)
1. Este caso de uso se inicia quando o prestador de serviço deseja alterar
um serviço (incluir, editar, consultar ou excluir).
2. O sistema requisita que o prestador de serviço especifique a operação
que deseja realizar.
3. Uma vez que o prestador de serviço forneça a informação requerida, um
dos subfluxos é executado:
a. Se o prestador de serviço escolher “incluir”, o subfluxo 2.1.1 é iniciado.
b. Se o prestador de serviço escolher “consultar”, o subfluxo 2.1.2 é
iniciado.
c. Se o prestador de serviço escolher “editar”, o subfluxo 2.1.3 é iniciado.
d. Se o prestador de serviço escolher “excluir”, o subfluxo 2.1.4 é iniciado.
2.1.1. Incluir serviço

1. Este fluxo se inicia quando o prestador de serviço seleciona a opção de
incluir um novo serviço.
2. O sistema solicita o preenchimento dos seguintes campos:
a. Nome
b. Tipo
c. Preços
2. O prestador de serviços preenche os dados e solicita a inclusão.
3. O sistema valida se todos os campos obrigatórios estão preenchidos.
4. O sistema verifica se não há nenhum serviço cadastrado com o nome
informado.
5. O sistema realiza a inclusão dos dados informados pelo prestador de
serviço no passo 3.
6. O sistema exibe uma mensagem de confirmação informando que o
cadastro do serviço foi feito com sucesso.
7. O prestador de serviço confirma o recebimento da mensagem.
31
2.1.2. Consultar serviço

1. Esse fluxo se inicia quando o prestador de serviço seleciona a opção de
consultar um serviço.
2. O sistema solicita o preenchimento dos seguintes filtros:
a. Nome
b. Tipo
2. O prestador de serviços preenche os filtros e solicita a consulta.
3. O sistema valida se todos os dados obrigatórios estão preenchidos.
4. O sistema apresenta as seguintes informações dos serviços obtidos na
consulta.
a. Nome
b. Tipo
5. O sistema solicita que o prestador de serviço selecione os serviços
desejados.
6. O sistema solicita que o prestador de serviço selecione a operação que
deseja realizar.
7. Uma vez que o prestador de serviço forneça a informação solicitada, um
dos seguintes subfluxos é executado.
a. Se o prestador de serviço selecionar “consultar”, o subfluxo 2.1.2 é
executado.
b. Se o prestador de serviço selecionar “inserir”, o subfluxo 2.1.1 é
executado.
c. Se o prestador de serviço selecionar “editar”, o subfluxo 2.1.3 é
executado.
d. Se o prestador de serviço selecionar “excluir”, o subfluxo 2.1.4 é
executado.
2.1.3. Editar Serviço
1. Para este fluxo ser executado, o prestador de serviço deve ter
selecionado um único serviço.
2. Este fluxo se inicia quando o prestador de serviço solicita editar um
serviço.
3. O sistema exibe os dados do serviço selecionado e permite a alteração
dos seguintes dados:
32
a. Nome
b. Tipo
c. Preço
2. O prestador de serviço preenche todos os dados e solicita a alteração.
3. O sistema valida se todos os campos obrigatórios estão preenchidos.
4. O sistema verifica se não existe um serviço cadastrado com o nome
informado.
5. O sistema realiza a alteração do serviço.
2.1.4. Excluir serviço

1. Para este fluxo ser executado, o prestador de serviço deve ter
selecionado um ou mais serviços.
2. Este fluxo se inicia quando o prestador de serviço solicita excluir um
serviço.
3. O prestador de serviço informa quais serviços deseja excluir.
4. O sistema exibe uma mensagem solicitando confirmação da exclusão dos
serviços selecionados.
5. O prestador de serviço confirma a exclusão.
6. O(s) serviço(s) é(são) excluído(s) do sistema.
7. Fim do caso de uso.
2.2. Fluxos alternativos (Exceptions)

2.2.1. Dados obrigatórios do serviço não informados
1. Este subfluxo se inicia no passo 4 do subfluxo 2.1.1 ou no passo do 4 do
subfluxo 2.1.2 ou no passo 5 do subfluxo 2.1.3 quando os dados
obrigatórios não são informados.
2. O sistema exibe a mensagem “Dados obrigatórios do serviço não
informados.
3. O caso de uso retorna ao passo 2 do subfluxo 2.1.1 ou ao passo 2 do
subfluxo 2.1.2 ou ao passo 3 do subfluxo 2.1.3 da operação de inclusão,
consulta ou editar serviço, respectivamente.
33
2.2.2. Nome do serviço já cadastrado

1. Este subfluxo se inicia quando no passo 5 do subfluxo 2.1.1 ou no passo
6 do subfluxo 2.1.3 o sistema verifica que existe um serviço cadastrado
com o nome informado.
2. O sistema exibe a mensagem “Serviço já cadastrado”.
3. O caso de uso retorna ao passo 2 do subfluxo 2.1.1 ou ao passo 3 do
subfluxo 2.1.3 da operação de inclusão ou edição do serviço,
respectivamente.
2.2.3. Filtros obrigatórios não informados

1. Este subfluxo se inicia no passo 4 do subfluxo 2.1.2 quando os filtros
obrigatórios não são informados
2. O sistema exibe todos os serviços cadastrado.
2.2.4 Seleção múltipla do serviço
1. Este subfluxo se inicia no passo 2 do subfluxo 2.1.3 quando o prestador
seleciona mais de um serviço para alteração.
2. O sistema exibe uma mensagem “Seleciona apenas um serviço para
alteração”.
3. O caso de uso retorna ao passo 2 do subfluxo 2.1.2.
2.2.3 Nenhum serviço encontrado
1. Este subfluxo se inicia no passo 3 do subfluxo 2.1.2 quando o sistema
não encontra nenhum serviço com os filtros especificados.
2. O sistema exibe a mensagem “nenhum serviço encontrado”.
3. O caso de uso retorna ao passo 2 do subfluxo 2.1.2.
1. Não haver nenhum serviço cadastrado no sistema.
1. O nome do serviço criado ou alterado pelo prestador de serviço deverá ser salvo
na base de dados.
2. Os serviços excluídos pelo prestador de serviços devem ser removidos da base
de dados do sistema.
34
UC004 – Cadastrar agenda de serviços
1. Cadastrar agenda de serviços

1.1. Descrição
Este caso de uso descreve o processo através do qual é feito o
cadastro da agenda de serviços no sistema.
Prestador de serviço.
2. Fluxo de eventos
2.1. Fluxo básico (Happy day)
1. Este caso de uso se inicia quando o prestador de serviço deseja alterar
uma agenda de serviços (criar, editar ou excluir) uma agenda de serviços.
2. O sistema requisita que o prestador de serviço especifique a operação
que deseja realizar.
3. Uma vez que o prestador de serviço forneça a informação requerida um
dos seguintes subfluxos será executado.
a. Se o prestador de serviço selecionar “criar”, o subfluxo 2.1.1 será
executado.
b. Se o prestador de serviço selecionar “editar”, o subfluxo 2.1.2 será
executado.
2.1.1. Criar agenda de serviços
1. Este fluxo se inicia quando o prestador de serviço seleciona a
opção criar.
2. O sistema solicita um nome para a agenda de serviços que será
criada.
3. O sistema verifica se todos os campos obrigatórios foram
preenchidos.
4. O sistema exibe uma mensagem confirmando a criação da
agenda.
2.1.2. Editar agenda de serviços
1. Este fluxo se inicia quando o prestador de serviço seleciona a
opção editar uma agenda de serviços.
35
2. O sistema requisita que o prestador de serviço especifique o

operação que deseja realizar.
i. Se o prestador de serviço selecionar a opção “adicionar serviço
na agenda”, o subfluxo 2.1.2.1 será executado.
ii. Se o prestador de serviço selecionar a opção “remover serviço
da agenda”, o subfluxo 2.1.2.2 será executado.
iii. Se o prestador de serviço selecionar a opção “editar serviço na
agenda”, o subfluxo 2.1.2.3 será executado.
2.1.2.1. Adicionar serviço na agenda
1. Este fluxo se inicia quando o prestador de serviço
seleciona a opção para adicionar serviço na agenda.
2. O sistema exibe os serviços que estão cadastrados no
sistema, mas não estão na agenda.
3. O prestador de serviços seleciona quais serviços deseja
adicionar na agenda.
4. O sistema solicita que o prestador de serviço defina um
ou mais horários para cada serviço solicitado.
5. O sistema exibe uma mensagem confirmando a inclusão
do serviço com seu respectivo horário.
6. O prestador de serviço confirma a mensagem.
7. O sistema faz a adição do(s) serviço(s) na agenda.
8. Caso de uso se encerra.
2.1.2.2. Remover serviço da agenda

1. O caso de uso se inicia quando o prestador de serviço
seleciona a opção para remover serviço da agenda.
2. O sistema exibe quais serviços estão na agenda.
3. O prestador de serviço seleciona um ou mais serviços.
4. O sistema exibe uma mensagem confirmando a exclusão
dos serviços.
5. O prestador do serviço confirma a mensagem.
6. O sistema faz a exclusão do(s) serviço(s) da agenda.
36
2.1.2.3. Editar serviço da agenda

1. O caso de uso se inicia quando o prestador de serviço
seleciona a opção editar serviço da agenda.
2. O sistema exibe quais serviços estão na agenda.
3. O prestador de serviço seleciona qual serviço deseja
editar.
4. O prestador de serviço faz a edição desejado no horário
do serviço.
5. O sistema exibe uma mensagem confirmando a edição
do serviço.
6. O prestador do serviço confirma a mensagem.
7. O sistema faz a edição do serviço.
2.2. Fluxos Alternativos
2.2.1. Já existe uma agenda criada
1. Esse subfluxo se inicia quando no passo 1 do subfluxo 2.1.1 já
existe um agenda criada.
2. O sistema exibe a mensagem “Já existe uma agenda criada”
3. O caso de uso retorna ao passo 2 do subfluxo 2.1.
2.2.2. Não existe uma agenda criada
1. Esse subfluxo se inicia no passo 1 do subfluxo 2.1.2 caso não haja
nenhuma agenda criada.
2. O sistema exibe a mensagem “Não há agendas criadas para
edição”.
3. O caso de uso retorna ao passo 2 do subfluxo 2.1.
2.2.3. Não existem serviços cadastrados no sistema

1. Esse subfluxo se inicia no passo 2 do subfluxo 2.1.2.1 quando não
há nenhum serviço cadastrado no sistema.
2. O sistema exibe a mensagem “Não existe(m) serviço(s)
cadastrado(s) no sistema.
2.2.4. Não existem serviços incluídos na agenda

37
1. Esse subfluxo se inicia no passo 2 do subfluxo 2.1.2.2 ou no passo

2 do subfluxo 2.1.2.3 quando não existem serviços cadastrados na
agenda.
2. O sistema exibe a mensagem “Agenda vazia”.
3. O caso de uso retorna para o passo 2 do subfluxo 2.1.2.1.
2.3. Pré-Condições
1. O sistema não deve ter uma agenda criada.
2.4. Pós-Condições
1. A agenda de serviços criada ou alterada pelo prestador de serviços
deverá ser salva na base de dados.
38
3.2.4. MODELO CONCEITUAL DE CLASSES
Modelo conceitual de classes idealizado pelo autor através do fluxograma

abaixo.
Figura 3. Modelo conceitual de classes
Fonte: o autor.
39
3.2.5. MODELO CONCEITUAL DE DADOS
Modelo conceitual de dados idealizado pelo autor através do fluxograma

abaixo.
Figura 4. Modelo conceitual de dados
Fonte: o autor.
3.3. Solução tecnológica

40
3.3.1. Diagrama de sequência
Figura 5. Diagrama de sequências
Fonte: o autor.
41
3.3.2. Projeto de interface
Figura 6. Tela de login – visão do estabelecimento
Fonte: o autor.
Figura 7. Tela cadastro – Visão estabelecimento
Fonte: o autor.
42
Figura 8. Tela de Estabelecimento – Atualização
Fonte: o autor.
Figura 9. Tela de estabelecimento – Inclusão
Fonte: o autor.
43
Figura 10. Tela de estabelecimento – Atualização 1
Fonte: o autor.
Figura 11. Tela de estabelecimento – Atualização 2
Fonte: o autor.
44
Figura 12. Tela estabelecimento – Consulta reservas ativas
Fonte: o autor.
Figura 13. Tela de alteração de senha – Estabelecimento
Fonte: o autor.
45
Figura 14. Tela login – Visão cliente
Fonte: o autor.
Figura 15. Tela cadastro – visão cliente
Fonte: o autor.
46
Figura 16. Alteração de senha – Cliente
Fonte: o autor.
Figura 17. Consulta estabelecimento – visão cliente
Fonte: o autor.
47
Figura 18. Consulta estabelecimento 2 – visão cliente
Fonte: o autor.
Figura 19. Reserva horário – visão cliente
Fonte: o autor.
48
3.3.3. Diagrama de atividades
Figura 20. Diagrama de atividades
Fonte: o autor.
49
3.3.4. Modelo de Classes do projeto
Figura 21. Modelo de classe de projetos
Fonte: o autor.
50
3.3.5. Modelo fisico de dados
3.3.5.1. Script de geração do banco de dados e tabelas
Tabelas:
Agenda – Responsável por armazenar os dados da agenda do serviços prestados

pelos estabelecimentos
CREATE TABLE àgenda` (

Àge_id` int(11) NOT NULL,
Èstabelecimento_servico_Servico_Ser_id` int(11) NOT NULL,
Èstabelecimento_servico_Estabelecimento_Est_id` int(11) NOT NULL,
Àge_data` date NOT NULL,
Àge_hora` time NOT NULL
Estabelecimento – Responsável por armazenar os dados dos estabelecimentos

cadastrados
CREATE TABLE èstabelecimento` (

Èst_id` int(11) NOT NULL,
Èst_razaosocial` varchar(100) NOT NULL,
Èst_cnpj` bigint(20) NOT NULL
Estabelecimento_serviço - Responsável por armazenar serviços dos

estabelecimentos cadastrados
CREATE TABLE Èstabelecimento_servico` (

Èstabelecimento_Est_id` int(11) NOT NULL,
`Servico_Ser_id` int(11) NOT NULL
)
51
Reserva_serviço - Responsável por armazenar os dados das reservas feitas pelos

usuários
CREATE TABLE `reserva_servico` (

Ùsuario_servico_Usu_id` int(11) NOT NULL,
Àgenda_Age_id` int(11) NOT NULL,
Àgenda_Estabelecimento_servico_est` int(11) NOT NULL,
Àgenda_Estabelecimento_servico_Ser_id` int(11) NOT NULL
Serviço - Responsável por armazenar os dados dos serviços oferecidos pelos

estabelecimentos
CREATE TABLE `Servico` (

`Ser_id` int(11) NOT NULL,
`Tipo_servico` int(11) NOT NULL,
`Ser_nome` varchar(120) NOT NULL
Tb_usuario_servico - Responsável por armazenar os dados dos usuarios dos

serviço
CREATE TABLE `Servico` (

`Ser_id` int(11) NOT NULL,
`Tipo_servico` int(11) NOT NULL,
`Ser_nome` varchar(120) NOT NULL
)
52
3.3.6. Ambiente tecnológico do sistema
3.3.6.1. Ambiente fisico(Diagrama de implantação)
Figura 22. Diagrama de implantação
Fonte: o autor.
3.3.6.2. Justificativa da escolha da linguagem de programação
As linguagens Php e javascript estão entre as linguagens mais utilizadas para

o desenvolvimento de aplicações web e sites, podendo ser usadas por
desenvolvedores iniciantes aos mais avançados. Possuem um ambiente de
desenvolvimeto amigável, não são linguagens custosas quando se pensa em uso de
memória e processamento, permitem a criação de páginas dinamicas e
personalizáveis, são compativeis com uma variedade grande de bancos de dados.
53
3.3.6.3. Justificativa da escolha do SGBD (Sistema Gerenciador de Banco de

Dados)
O MySql foi escolhido como SGBD pela necessidade de requisitos de

sistema, pois, utilizando Php e Javascript, foi necessários escolher um SGBD que
aliasse segurança, desempenho e integridade e por tornar o processo de integraçao
do front-end e backend da aplicaçao mais simples e dinamico.
54
4. Conclusões
Durante a pandemia de Covid-19, pode se perceber a impotência de todos
perante ao vírus sendo pegos de surpresa e não possuindo nenhum plano de
contigência para tal, mesmo, na história recente ter acontecido uma pandemia, a de
gripe suína em 2009. Todas as medidas tomada foram padrões contra pandemias,
porém, nenhuma pandemia anterior foi tão complexa quanto a de Covid-19. Os
países de uma maneira geral não souberam como gerir os lockdowns, como fazer a
transição do trabalho presencial para o tele-trabalho, todas essas mudanças foram
feitas as pressas, muitas, sendo mal realizadas ou mal adaptadas pelas empresas e
funcionários.
Dentre as medidas que ocorreram durante o período de pandemia uma delas

foi a restrição do número de pessoas dentro de estabelecimentos comerciais a uma
fração do total, o que foi uma solução para reduzir as aglomerações dentro dos
estabelecimentos porém gerou uma aglomeração fora dos locais, por causa das filas
surgidas por causa da restrição de lotação, pensando nisso e aliando com a idéia de
delivery o sistema proposto neste trabalho foi pensado, para marcação de horários
para a visitação dos locais comerciais, transportando a fila para o virtual, com uma
tentativa de reduzir ao máximo as aglomerações.
4.1. Reflexões e comparação entre objetivos iniciais x alcançados
De maneira geral o objetivo do trabalho foi alcançado, desenhar um sistema

unificado que possa atender a necessidade de clientes e prestadores de serviços e
estabelecimentos comerciais, primariamente durante a pandemia de Covid-19 mas
podendo ser utilizado em períodos não pandemicos, para que os estabelecimentos
possam cadastrar seus serviços, bem como horários disponíveis para que clientes
possam escolher dentre os horários disponibilizados para visitação do mesmo.
Foi pensado uma funcionalidade que permitiria que os clientes pudessem

pagar antecipadamente, porém, não foi colocado no projeto com o intuito de agilizar
o processo da modelagem do mesmo, podendo, esta funcionalidade ser
implementada em releases posteriores. Bem como outras melhorias que possam vir
a ser sugeridas pelos usuários do sistema.
4.2. Vantagens e desvantagens do sistema

55
Como vantagem do sistema pode-se destacar sua finalidade, a reduzção das filas
presenciais e das aglomerações durante um período pandêmico que seriam geradas
naturalmente com a ida de pessoas aos estabelecimentos.
Entende-se que nem todos os clientes e estabelecimentos vão optar por utilizar o
sistema, o que pode contar como uma desvantagem para o mesmo, visto que não
obterá exito em sua proposta. Pode ser citado, como outra desvantagem para o uso
do sistema, uma concorrência por horários, uma burocracia a mais na hora de ir a
determinado estabelecimento, visto que será necessário reservar uma hora, criação
de regras, os estabelecimentos só aceitarão clientes reservados? Ou aceitarão
pessoas que chegarem sem reservar?
4.3. Trabalhos futuros
Como ideias para futuras implementações considera-se:
1. Pagamento antecipado para que posso ainda mais agilizar o atendimento em

caso de prestadores de serviço
2. Um serviço de geolocalização para permitir que clientes possam descobrir

estabelecimentos perto de si que utilizem do sistema
3. Um sistema de anuncios em que, utilizando-se de geolocalização os

estabelecimentos possam enviar propagandas, este envio pode ser ligado ou
desligado pelo cliente, para clientes próximos.
56
5. REFERÊNCIAS BIBLIOGRÁFICAS
LOPES, Bergson. Modelo Conceitual de Dados - Aprenda a utilizar os principais

mecanismos de abstração. Blog da BLR Data. Disponível em
<https://www.blrdata.com.br/single-post/2016/03/19/modelo-conceitual-de-dados-
aprenda-a-utilizar-os-principais-mecanismos-de-abstração>. Acesso em 25/10/21.
LUCID. O que é um diagrama de classe UML? Lucidchart. Disponível em

<https://www.lucidchart.com/pages/pt/o-que-e-diagrama-de-classe-uml>. Acesso em
22/04/2021.
MEDEIROS, Higor Zardo. Introdução a Requisitos de Software. DEVMEDIA.

Disponível em
<https://www.devmedia.com.br/introducao-a-requisitos-de-software/29580>. Acesso
em 15/04/2021.
SCHEMES, Taynara. Regras de negócio em TI: descubra esse importante conceito

e entenda como aplicá-lo no seu negócio. Movidesk Blog. Disponível em
<https://conteudo.movidesk.com/regras-de-negocio-ti/>. Acesso em 15/04/2021

TCC Lucas - Completo

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TCC Lucas - Completo

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE ESTÁCIO DE SÁ

LUCAS FERREIRA VAL

SISTEMA DE REGULAÇÃO DE TRÁFEGO DE PESSOAS EM

LUCAS FERREIRA VAL

SISTEMA DE REGULAÇÃO DE TRÁFEGO DE PESSOAS EM

Relatório final, apresentado a

SISTEMA DE REGULAÇÃO DE TRÁFEGO DE PESSOAS EM

Relatório final, apresentado a

Aprovado em ___ de _________ de 2021

Atender a necessidade de um cenário de pandemia em um primeiro momento,

Palavras-chave: necessidade, controle, tráfego, reserva.

Keywords: necessity, control, traffic, reservation.

Figura 1. Cronograma detalhado de trabalho.............................................................16

Tabela 1. Tabela orçamentária para aquisição de recursos de Hardware.................16

Por causa da velocidade como a doença se propagou, muitos países

Mais de um ano depois dos primeiros casos, vacinas foram desenvolvidas e a

O sistema foi pensado, para que, durante a pandemia de Covid-19 pudesse

Durante pandemia da Covid-19 muitos estabelecimentos comerciais

1.3. BREVE DESCRIÇÃO DA SOLUÇÃO

Desenvolver um sistema, unificado, em que clientes e estabelecimentos

1. O cliente liberará ambientes de teste para o sistema.

1. O valor do projeto não poderá ser superior a 120% do

2. O término do projeto não poderá ser após dezembro de

2.2. PERFIL DO PÚBLICO-ALVO

O sistema é destinado para prestadoras de serviços, estabelecimentos

O sistema também visa atender as necessidades dos clientes, sejam pessoas

2.2.2. ATIVIDADES DO PÚBLICO-ALVO

O sistema será desenhado para atender a necessidade da maior parte de

de beleza, agendamento de visita a loja de vestuário, marcação de horário em

O objetivo do sistema é ser o mais inclusivo possível, abrangendo público de

2.3. PROPOSTA DE TRABALHO

2.3.1. MÉTODO DO TRABALHO

O desenvolvimento do trabalho foi feito com base em pesquisas de

As entrevistas foram realizadas com cerca de 500 pessoas, incluindo-se

Depois de determinado os resultados da amostragem, identificou-se que a

Na fase de Análise será empregada a utilização dos diagramas da UML,

No estágio do desenvolvimento do projeto será empregado o

2.3.2. PREVISÃO E ALOCAÇÃO DE RECURSOS (HUMANOS E MATERIAIS)

Para o desenvolvimento do sistema foi percebido que será necessário a

Foi percebido que será necessária 1 licença do software para gerenciamento

2.3.3. CRONOGRAMA DE TRABALHO

A figura abaixo, feita no Microsoft Excel 2010, demonstra em detalhes o

Figura 1. Cronograma detalhado de trabalho

2.3.4. PREVISÃO ORÇAMENTÁRIA

Para o desenvolvimento do sistema Reservado será necessária a aquisição

Tabela 1. Tabela orçamentária para aquisição de recursos de Hardware

Hardware Quantidade Valor total

Tabela 2. Tabela orçamentária para aquisição de recursos de Software

Software Quantidade Descrição Valor total

Software Quantidade Descrição Valor total

Tabela 3. Tabela orçamentária para contratação de profissionais

Cargo Quantidade Valor total

2.4. O SISTEMA AUAL

2.4.1. FUNCIONAMENTO DO SISTEMA ATUAL

2.4.2. PROBLEMAS DO SISTEMA ATUAL

necessidades especiais durante tempos de pandemia foi pensado, visando obedecer

3.1.1. JUSTIFICATIVAS PARA O NOVO SISTEMA

Durante a pandemia da Covid-19 diversas novas regras foram impostas, uso

3.1.2. SITUAÇÃO DESEJADA

A situação desejada é que o sistema esteja pronto para lançamento e para

3.2. SOLUÇÃO ESCOLHIDA

3.2.1. LISTA DE REQUISITOS DO SISTEMA

3.2.1.1. REQUISITOS FUNCIONAIS

Aprovado em _ de _______ de 2021