Aplicação Web Moderna para Gerenciamento de Barbeariassaturno.unifei.edu.br/bim/201800223.pdf ·...
93
i UNIFERSIDADE FEDERAL DE ITAJUBÁ – UNIFEI Aplicação Web Moderna para Gerenciamento de Barbearias Autor Eduardo Bonfá Guimarães UNIFEI Itajubá 2018
Transcript of Aplicação Web Moderna para Gerenciamento de Barbeariassaturno.unifei.edu.br/bim/201800223.pdf ·...
i
UNIFERSIDADE FEDERAL DE ITAJUBÁ – UNIFEI
Aplicação Web Moderna para Gerenciamento de Barbearias
Autor
Eduardo Bonfá Guimarães
UNIFEI
Itajubá
2018
ii
Aplicação Web Moderna para Gerenciamento de Barbearias
Autor
Eduardo Bonfá Guimarães
Monografia apresentada como trabalho
final de graduação, requisito parcial
para obtenção do título de Bacharel em
Sistemas de Informação, sob orientação
do Prof. Laércio Baldochi.
UNIFEI
Itajubá
2018
i
MINISTÉRIO DA EDUCAÇÃO
UNIVERSIDADE FEDERAL DE ITAJUBÁ
Criada pela Lei no 10.435, de 24 de abril de 2002
Instituto de Matemática e Computação
FOLHA DE APROVAÇÃO
O Trabalho Final de Graduação em Sistemas de Informação de Eduardo Bonfá Guimarães intitulado "Aplicação web moderna para gerenciamento de barbearias" foi APROVADO.
Itajubá, 20 de Novembro de 2018.
BANCA EXAMINADORA
Universidade Federal de Itajubá — IMC
Presidente / Orientador
Prof. Adler Diniz de Souza
Universidade Federal de Itajubá — IMC
Profa. Melise Maria Veiga de Paula
Universidade Federal de Itajubá — IMC
Instituto de Matemática e Computação - IMC
Av. BPS, 1303 - Caixa Postal 50 - 37500-903 - Itajubá - MG - Brasil
Telefone: 35-3629-1135 — Fax: 35-3629-1140 - E-mail: [email protected]
i
AGRADECIMENTOS
Primeiramente, agradeço aos meus pais Milton e Ivete, pelo amor e apoio incondicional e pelo
exemplo de vida. Também sou grato a minha noiva Anne, pela ajuda, pelo apoio e por estar
sempre ao meu lado durante a elaboração deste trabalho. Aos meus familiares, amigos e colegas
que me deram forças e ficaram na torcida, meu muito obrigado. Não posso deixar de agradecer
a meu orientador Laércio, pelo incentivo, apoio e dedicação. Por fim, agradeço a Deus por suas
bênçãos.
ii
RESUMO
Com o crescimento do mercado de beleza masculino, cresce também o número de barbearias.
Essas barbearias apresentam um conceito moderno no atendimento de seus clientes, mas seu
gerenciamento ainda é realizado de maneira manual. O presente trabalho tem como objetivo
automatizar o atendimento e o controle de barbearias, possibilitando maior rapidez no
atendimento ao cliente e melhoria na gerência do negócio. Para o atendimento a clientes foi
desenvolvido um chatbot, um serviço de resposta automática, que facilita o agendamento de
serviços e para o gerenciamento da barbearia foi desenvolvida uma aplicação cliente-servidor
utilizando tecnologias modernas de desenvolvimento de software para a web, para a criação do
servidor foi utilizado o framework Spring Boot, e para a aplicação cliente foi utilizado o
framework Angular, seguindo as tedências de desenvolvimento SPA e Mashup. Todo o
processo de desenvolvimento e testes foi realizado com o suporte de uma barbearia real. Os
resultados obtidos atenderam as necessidades do negócio.
Palavras chave: Gerenciador de barbearia, barbearia, aplicação web moderna, spring boot,
chatbot, angular.
iii
ABSTRACT
With the growth of the male beauty market, the number of barber shops has grown. These
barbershops have a modern concept in serving their customers, but their management is still
carried out manually. The present work aims to automate the attendance and management of
barbershops, allowing to serve customers faster and to improve the management of the business.
For the customer service, an automatic response mechanism that facilitates the appointment of
services was provided. For the management of the barber shop, a client-server application was
developed using modern web-development software technologies, for the creation of the server
was used the framework Spring Boot, and for the client application was used the framework
Angular, following the development trend of SPA and Mashup. The whole process of
development and testing was carried out with the support of a real barbershop. The results
obtained met the needs of the business.
Keywords: Barber shop, barbershop, modern web application, spring boot, chatbot, angular.
iv
LISTA DE FIGURAS
2.1 – Arquitetura de uma Aplicação Web Moderna ................................................................. 25
2.2 – Arquitetura de uma Single-Page Application .................................................................. 26
2.3 – Aplicação SPA ................................................................................................................. 27
2.4 – Carregamento dos códigos iniciais da aplicão SPA. ....................................................... 27
2.5 – Funcionamento aplicação Mashup .................................................................................. 28
2.6 – Arquitetura Mashup servidor ........................................................................................... 29
2.7 – Arquitetura Mashup cliente ............................................................................................. 29
2.8 – Site do WikiCrimes ......................................................................................................... 30
2.9 – Chatbots do Trivago e Netflix ......................................................................................... 32
2.10 – Fluxo do Scrum .............................................................................................................. 34
3.1 – Arquitetura do Spring Boot ............................................................................................. 36
3.2 – Arquitetura de uma aplicação Angular ............................................................................ 37
3.3 – Painel de Controle do Chatfuel ........................................................................................ 38
3.4 – Plugins disponíveis no Chatfuel ...................................................................................... 39
3.5 – Plugin de POST no Chatfuel ........................................................................................... 40
3.6 – Formato JSON para enviar um text ao Chatfuel ............................................................. 40
3.7 – Quadro de tarefas semanais ............................................................................................. 42
3.8 – Quadro padrão scrum....................................................................................................... 42
3.9 – Painel de controle Bitbucket ............................................................................................ 43
4.1 – Diagrama de Casos de Uso .............................................................................................. 47
4.2 – Diagrama de Entidade-Relacionamento .......................................................................... 49
5.1 – Quadro da ferramenta Trello de gerenciamento do projeto (Sprint 1) ............................ 52
5.2 – Resposta de um cliente em format JSON ........................................................................ 54
5.3 – Documentação e métodos para consumir a API desenvolvida ........................................ 54
5.4 – Tela de autorização da Agenda do Google ...................................................................... 55
5.5 – Fluxo das funcionalidades de agendar horário ................................................................ 56
5.6 – Diálogo entre chatbot e usuário ....................................................................................... 56
5.7 – Tela de cliente .................................................................................................................. 58
5.8 – Tela de agendamentos marcados ..................................................................................... 58
5.9 – Tela da agenda dos barbeiros........................................................................................... 59
5.10 – Tela de relatório: Informações Gerais ........................................................................... 60
v
5.11 – Tela de relatório: Informações sobre serviços, vendas, forma de pagamento e
agendamento ............................................................................................................................. 60
5.12 – Tela de relatório: Informações por barbeiro .................................................................. 61
5.13 – Gráfico da avaliação da usabilidade da Tarefa 1 ........................................................... 63
5.14 – Gráfico da avaliação da usabilidade da Tarefa 2 ........................................................... 64
5.15 – Gráfico do desempenho ................................................................................................. 64
5.16 – Gráfico da sedimentação do conhecimento por experiência ......................................... 65
5.17 – Gráfico da taxa de erros cometidos pelo usuário ........................................................... 65
5.18 – Gráfico do tempo de aprendizagem ............................................................................... 66
5.19 – Gráfico da satisfação subjetiva ...................................................................................... 66
vi
LISTA DE QUADROS
Quadro 5.1 - Questões relacionadas aos critérios de usabilidade ............................................. 62
vii
LISTA DE ABREVIATURAS E SIGLAS
API - Application Programming Interface ................................................................................25
SPA - Single-Page Application .................................................................................................25
JSON - JavaScript Object Notation ...........................................................................................26
URL - Uniform Resource Locator .............................................................................................26
REST - Representational State Transfer ...................................................................................35
JAD - Joint Application Development ......................................................................................45
ER - Entidade-Relacionamento ................................................................................................48
viii
SUMÁRIO
1. INTRODUÇÃO .................................................................................................................... 22
1.1 Objetivos ......................................................................................................................... 22
1.2 Metodologia .................................................................................................................... 23
1.3 Organização do Texto ..................................................................................................... 23
2. FUNDAMENTAÇÃO TEÓRICA ....................................................................................... 24
2.1 Aplicação Web Moderna ................................................................................................ 24
2.2 Single-Page Application ................................................................................................. 25
2.3 Mashup ........................................................................................................................... 28
2.4 Chatbot ........................................................................................................................... 30
2.5 Scrum .............................................................................................................................. 33
3. FUNDAMENTAÇÃO TECNOLÓGICA ............................................................................ 35
3.1 Spring Boot ..................................................................................................................... 35
3.2 Angular ........................................................................................................................... 36
3.3 Chatfuel .......................................................................................................................... 38
3.4 JSON ............................................................................................................................... 41
3.5 Swagger .......................................................................................................................... 41
3.6 Trello .............................................................................................................................. 42
3.7 Bitbucket ......................................................................................................................... 42
4. MODELAGEM DO BARBER SOLUTIONS ..................................................................... 44
4.1 Levantamento de Requisitos ........................................................................................... 44
4.2 Requisitos Funcionais e Não Funcionais ........................................................................ 45
4.3 Casos de Uso .................................................................................................................. 46
4.4 Modelo de dados ............................................................................................................. 48
5. IMPLEMENTAÇÃO DO BARBER SOLUTIONS ............................................................ 50
5.1 Sprint 1 ........................................................................................................................... 53
5.2 Sprint 2 ........................................................................................................................... 53
5.3 Sprint 3 ........................................................................................................................... 57
5.4 Avaliação da Usabilidade do Barber Solutions .............................................................. 61
ix
5.4.1 Análise ..................................................................................................................... 63
6. CONCLUSÃO ...................................................................................................................... 67
6.1 Trabalhos Futuros ........................................................................................................... 67
7. REFERÊNCIAS ................................................................................................................... 69
APÊNDICES:
APÊNDICE A – DOCUMENTO GERADO PARA A REALIZAÇÃO DA ENTREVISTA . 72
APÊNDICE B – DOCUMENTO DE REQUISITOS .............................................................. 74
APÊNDICE C – TAREFAS PROPOSTAS ........................................................................... 100
APÊNDICE D – QUESTIONÁRIO SOBRE AS TAREFAS ................................................ 101
22
1. INTRODUÇÃO
Nos últimos anos o mercado de beleza masculina vem demonstrando um crescimento
significativo no Brasil. Segundo a revista EXAME1 (2017), uma pesquisa realizada pela
empresa Euromonitor International aponta um crescimento de 7,1% no ano de 2015. A previsão
é que este número se mantenha até 2019, tornando o Brasil o maior mercado do mundo na
categoria.
Seguindo este crescimento ressurgem as barbearias, que além dos tradicionais cuidados
de cabelo e barba, trazem conceitos modernos para atender clientes que querem mais que um
lugar para cuidar da aparência. Serviços diferenciados como sinuca, venda de cervejas e dia do
noivo estão conquistando o mercado masculino.
Essa abordagem mais contemporânea do negócio contrasta, muitas vezes, com
mecanismos de gestão do século passado. Em muitas barbearias a marcação de horário, o
controle de vendas e de serviços realizados ainda é feito utilizando caneta e papel.
A utilização de serviços baseados na Web pode oferecer às barbearias maior
flexibilidade na gestão do negócio e um melhor alinhamento com seus clientes. Dessa forma,
este trabalho propõe o Barber Solutions, sistema que visa automatizar o processo de interação
com clientes e gestão do negócio.
O Barber Solutions oferece ao cliente a possibilidade de marcação de horário através de
um aplicativo de mensageria, e disponibiliza ao gestor da barbearia um sistema baseado na web
que permite controlar a agenda dos barbeiros e consultar a comissão a ser paga por serviços
realizados e por produtos vendidos, além de permitir calcular o faturamento da barbearia.
1.1 Objetivos
Este trabalho tem como objetivo geral desenvolver uma aplicação web moderna que auxilie
gestores de barbearias que desejam automatizar seu negócio. Para alcançar o objetivo geral, os
seguintes objetivos específicos foram definidos:
i. Permitir a marcação de horários utilizando um aplicativo de mensageria;
ii. Realizar a gestão da agenda dos barbeiros utilizando uma aplicação web;
1 https://exame.abril.com.br/negocios/dino/novo-conceito-de-barbearia-conquista-espaco-no-disputado-mercado-
de-beleza-brasileiro-shtml/
23
iii. Controlar estoque e venda de produtos utilizando uma aplicação web;
iv. Fazer a gestão financeira da barbearia.
1.2 Metodologia
Para alcançar o objetivo específico (i) foi desenvolvido um chatbot. Inicialmente foi definido
qual aplicativo de mensageria seria utilizado, e o Facebook Messenger foi o aplicativo
selecionado, devido a quantidade de usuários e a facilidade de se criar um chatbot utilizando a
ferramenta Chatfuel. Assim esse chatbot permite marcar, alterar, excluir e verificar horários.
Para alcançar os demais objetivos específicos, foi desenvolvida uma aplicação cliente-servidor
que implementa todo o modelo de negócio da barbearia. O servidor foi implementado utilizando
o framework Spring Boot, e o cliente (views) foi desenvolvido utilizando a tecnologia Angular.
Ao final, foi realizado um questionário para validar o software desenvolvido.
1.3 Organização do Texto
Este trabalho está dividido em sete capítulos organizados da seguinte forma: o Capítulo 2,
apresenta a fundamentação teórica utilizada para o desenvolvimento do trabalho. No Capítulo
3 se encontra a fundamentação técnológica usada no desenvolvimento do projeto. No Capítulo
4 é apresentado como foi realizada a modelagem do Barber Solutions. O Capítulo 5 descreve o
desenvolvimento do projeto. O Capítulo 6 são apresentadas as conclusões e trabalhos futuros
do trabalho. Por fim, no Capítulo 7 encontra-se as referências utilizadas para a realização deste
trabalho.
24
2. FUNDAMENTAÇÃO TEÓRICA
Este capítulo apresenta a fundamentação teórica deste trabalho. As próximas seções apresentam
conceitos teóricos relevantes para o entendimento e contextualização do desenvolvimento do
Barber Solutions.
2.1 Aplicação Web Moderna
A internet está cada vez mais integrada ao dia a dia das pessoas. Empresas, agências de turismo,
faculdades com educação a distância e o governo são exemplos de organizações que utilizam a
internet para melhorar e elevar seus negócios. Alinhado a isso, segundo Shahzad (2017), nos
últimos anos, inovações tecnológicas permitiram o desenvolvimento de aplicações móveis
responsivas.
Segundo Pena (2017), aplicações móveis caracterizam-se por serem ubíquas, móveis,
interativas, emocionais e devem proporcionar um conjunto de benefícios para o usuário.
Existem três tipos de aplicações móveis2: (i) Aplicações Web Móveis, aplicações que não
necessitam ser instaladas, são executados em browsers, (ii) Aplicações Nativas, aplicações
desenvolvidas especificamente para a plataforma móvel e que necessitam serem instaladas e
(iii) Aplicações Híbridas, aplicações que devem ser instaladas, mas com suas funcionalidades
desenvolvidas utilizando tecnologias web. Aplicações híbridas podem ser desenvolvidas com
com frameworks específicos, como o React Native3, ou acessado através da funcionalidade de
Web view, que permite exibir páginas web como parte do layout da aplicação4.
Segundo a revista EXAME5 (2018) o brasileiro tem em média 80 aplicações nativas
instaladas em seus dispositivos móveis, mas mensalmente usa apenas 40. Devido a isso, está se
tornando cada vez mais comum o desenvolvimento de aplicações web que podem ser
executadas tanto em desktops quanto em dispositivos móveis. Essas aplicações possuem
interfaces responsivas, isso significa que, suas interfaces são redimensionadas dependendo do
display disponível para sua visualização. Outra característica dessas novas aplicações é o fato
de não armazenarem nenhum dado, ou seja, toda a informação é apresentada através de modelos
2 https://www.opensoft.pt/diferencas-aplicacoes-nativas-web-hibridas/ 3 http://www.reactnative.com/ 4 https://developer.android.com/reference/android/webkit/WebView 5 https://exame.abril.com.br/tecnologia/brasileiro-gasta-200-minutos-por-dia-em-aplicativos-diz-estudo/
25
que realizam busca em um banco de dados ou em requisições para Application Programming
Interfaces (APIs) disponíveis. Como exemplo, podemos citar as Single-Page Applications
(SPAs), uma tendência de aplicação web com um layout responsivo e que apresenta apenas
uma página HTML que é atualizada de acordo com a ação do usuário.
A FIGURA 2.1 ilustra a arquitetura de uma aplicação web moderna e através dela pode-
se perceber que o layout da aplicação se adapta a qualquer display disponível e é através desse
display que o usuário terá acesso as funcionalidades da aplicação. A cada interação do usuário
os dados são alterados, alterando assim os modelos da aplicação. Os modelos da aplicação são
preenchidos consumindo dados de APIs e banco de dados. A interface da aplicação se altera
em tempo real dependendo dos dados presentes nos modelos.
FIGURA 2.1 – Arquitetura de uma Aplicação Web Moderna
FONTE: Shahzad (2017)
2.2 Single-Page Application
Segundo Shahzad (2017), SPAs são aplicações web que apresentam apenas uma página HTML
que é atualizada de acordo com a ação do usuário. O objetivo de uma aplicação SPA é prover
uma experiência de usuário mais fluída e parecida com aplicações desktop6.
A FIGURA 2.2 ilustra a arquitetura de uma SPA. Percebe-se que na primeira integração,
o cliente realiza o download dos códigos (JavaScrip, CSS, HTML) para a exibição da aplicação
e renderiza a view para o display disponível para sua exibição. A partir deste momento são
6 https://patentimages.storage.googleapis.com/af/ac/08/5708fa91a81167/US9967309.pdf
26
realizadas interações entre cliente-servidor de acordo com a necessidade do usuário. Essas
interações são realizadas de maneira assíncrona e tipicamente no formato JavaScript Object
Notation (JSON).
FIGURA 2.2 – Arquitetura de uma Single-Page Application
FONTE: Joseph (2015)
Para garantir rápidas interações, os códigos de inicialização da aplicação, devem possuir
um controlador de rotas Uniform Resource Locators (URLs). Essas rotas definem onde a
aplicação irá buscar os dados requisitados pelo usuário.
Os benefícios de se utilizar uma SPA são: (i) a necessidade de fazer o download dos
códigos iniciais apenas no primeiro acesso, (ii) após as funcionalidades serem carregadas, as
próximas interações requisitarão apenas dados, tendo assim uma interação mais leve e rápida e
(iii) reutilização dos códigos em diferentes dispositivos, como mobile, desktops e web.
Entretanto, aplicações SPA também apresentam desvantagens: (i) dependendo do tamanho dos
códigos iniciais, o primeiro acesso à aplicação SPA pode demorar e (ii) uma aplicação SPA é
mais difícil de ser ranqueada para sites de busca como o Google.
A FIGURA 2.3 apresenta uma aplicação SPA, esta aplicação apresenta apenas uma
página HTML e muda apenas seu conteúdo através de interações do usuário através do menu
apresentado na parte superior da página. É possível perceber que no primeiro acesso à página
estão sendo carregados suas funcionalidades e dados, como ilustra a FIGURA 2.4.
27
FIGURA 2.3 – Aplicação SPA
FONTE: https://www.mercedes-benz.com/en/mercedes-benz/vehicles/passenger-cars/eqc/the-
eqc/
FIGURA 2.4 – Carregamento dos códigos iniciais da aplicão SPA.
FONTE: https://www.mercedes-benz.com/en/mercedes-benz/vehicles/passenger-cars/eqc/the-
eqc/
28
2.3 Mashup
Mashup é uma aplicação Web que busca integrar dados e funcionalidades de fontes de dados
independentes. Segundo Agrizzi (2015), aplicações Mashup possuem como características,
simplicidade, usabilidade e facilidade de acesso. O objetivo é gerar algo novo para o usuário.
A maneira mais comum de se desenvolver uma aplicação Mashup é consumindo dados
de APIs públicas. Com dados de diversas fontes se torna possível criar serviços e apresentar
informações relevantes ao usuário. Empresas como Google, Amazon e Facebook estão
desenvolvendo APIs para aumentar sua presença na Internet mesmo não sendo em seus próprios
sites. A FIGURA 2.5 ilustra o funcionamento de uma aplicação Mashup.
FIGURA 2.5 – Funcionamento aplicação Mashup
FONTE: Autor
A Arquitetura de uma aplicação Mashup pode variar de duas formas, Mashups clientes
e Mashups servidores.
Mashups servidores integram serviços e dados no servidor, devido a isso todas as
requisições feitas por aplicações clientes serão realizadas para esse servidor.
Enquanto Mashups clientes integram serviços e dados diretamente na aplicação cliente,
assim realizando requisições em diversas fontes disponíveis. A FIGURA 2.6 apresenta a
arquitetura de uma aplicação Mashup servidor e a FIGURA 2.7 ilustra a arquitetura de uma
aplicação Mashup cliente.
29
FIGURA 2.6 – Arquitetura Mashup servidor
FONTE: Sarraj (2014)
FIGURA 2.7 – Arquitetura Mashup cliente
FONTE: Sarraj (2014)
30
Um exemplo de aplicação mashup é o WikiCrimes7, FIGURA 2.8, que tem como
objetivo relatar locais onde ocorreram crimes para alertar outras pessoas. Os relatos são
enviados pelos próprios usuários e podem ser em formato de texto, reportagens e videos. Para
alcançar esse objetivo o WikiCrimes utiliza a API do Google Maps, Youtube e informações de
crimes.
FIGURA 2.8 – Site do WikiCrimes
FONTE: http://www.wikicrimes.org/main.html
2.4 Chatbot
Bernardo e Santanchè (2017, p. 1) afirmam que: “chatbot é um programa de computador capaz
de simular uma conversa com um ser humano, seja através de texto ou de áudio e, para tanto,
estes softwares utilizam algoritmo para o processamento de linguagem natural”.
Esta tecnologia surgiu no início dos anos 60 quando o chatbot Eliza foi desenvolvido.
Utilizando reconhecimento de padrões e um sistema de resposta baseado em modelos, este
chatbot conseguia simular uma conversa com um psicoterapeuta no estilo não direcional, DALE
(2016).
7 http://www.wikicrimes.org/main.html
31
Apesar dessa tecnologia existir a mais de 50 anos, somente em 2016 seu uso começou
a se popularizar e segundo Dale (2016), isso se deve ao fato de que o meio com que as pessoas
estão se comunicando mudou. Além de que, os Millenials preferem usar mídias digitais aos
outros canais de comunicação. Com a popularização dos dispositivos móveis, houve um
crescimento no desenvolvimento de aplicativos destinados a diversas áreas como:
entretenimento, ensino, compras, etc. Aplicativos destinados a troca de mensagens são os mais
utilizados pelos usuários. Exemplos como Facebook Messenger e Whatsapp possuem somados
mais de 2 bilhões de usuários.
Com este cenário, empresas estão adicionando aplicativos de mensageria como um de
seus serviços. Isso traz benefícios como maior fidelização e o poder de alcançar maior número
de clientes, auxiliar em pesquisas com diversas finalidades, e prover um atendimento que esteja
disponível a qualquer momento, entre outras.
A popularização dos chatbots despertou um grande interesse no desenvolvimento dessa
tecnologia, com isso várias plataformas foram desenvolvidas almejando facilitar o
desenvolvimento de um chatbot. Plataformas como ManyChat, Chattypeople e Chatfuel
permitem a criação de chatbots simples e complexos (utilizando APIs para integração com
outros sistemas). Por exemplo, os chatbots da Trivago e Netflix utilizam a plataforma Chatfuel
e o aplicativo de mensageria Facebook Messenger, conforme ilustra a FIGURA 2.9.
32
FIGURA 2.9 – Chatbots do Trivago e Netflix
Fonte: Autor
33
2.5 Scrum
Com o decorrer dos anos vários métodos de desenvolvimento de software foram propostos,
entre eles os métodos ágeis, os quais possuem como características a flexibilidade nas entregas
parciais, agregando valor ao negócio do cliente. Um desses métodos é o Scrum, considerado
ideal para o gerenciamento e planejamento de um projeto de software de pequeno ou médio
porte.
Carvalho e Mello (2012) levantaram os benefícios de se utilizar a metodologia Scrum.
São eles:
Aumento da satisfação de clientes;
Melhoria na comunicação;
Aumento de colaboração entre envolvidos nos projetos;
Aumento de investimentos em novos projetos;
Aumento de motivação;
Melhoria na qualidade do produto;
Aumento de produtividade da equipe;
Diminuição do tempo gasto para terminar os projetos;
Diminuição de risco.
O Scrum possui características para a sua utilização, o ponto inicial é o backlog do
produto que consiste em uma lista de funcionalidades ordenadas por prioridade, as quais
provavelmente serão desenvolvidas no decorrer do projeto. Estas funcionalidades são definidas
a partir dos requisitos levantados.
No primeiro momento é estimado o custo, é realizada uma análise dos riscos, são
definidas as datas para entrega de resultados, as ferramentas a serem utilizadas e a equipe que
ficará responsável pelo projeto.
A equipe responsável pelo projeto é dividida de acordo com o papel de cada membro.
Esses papéis são: Product Owner, Scrum Master e o Time de Desenvolvimento.
Product Owner é o cliente ou seu representante. Deve ser capaz de sanar qualquer
dúvida que o time de desenvolvimento possa ter em relação aos requisitos e definir a prioridade
do desenvolvimento.
34
O Scrum Master trabalha para garantir a execução das melhores práticas da metodologia
e resolver impedimentos que estejam atrasando o time de desenvolvimento.
O Time de Desenvolvimento é responsável pelo desenvolvimento técnico dos
requisitos.
O desenvolvimento do projeto é dividido em ciclos de trabalho chamados de Sprints e
tem como premissa concluir atividades definidas no Sprint Backlog, um subconjunto do
Backlog do produto. Para definir o Sprint Backlog é realizada uma reunião de planejamento da
Sprint. A Sprint ainda possui como atividades uma reunião diária na qual membros do time
formalizam atividades realizadas, o que está sendo realizado e se há algum obstáculo para a
finalização da tarefa. Também ocorre uma reunião de revisão ao final da Sprint na qual o time
relata erros, acertos, lições aprendidas e caso seja necessário o Backlog do produto é alterado.
Ao final de cada Sprint é lançada uma versão do produto (em caso de desenvolvimento de
software).
Com as características definidas é possível demonstrar o fluxo a ser seguido pelo Scrum,
ilustrado pela FIGURA 2.10.
FIGURA 2.10 – Fluxo do Scrum
FONTE: DevMedia (2017)
35
3. FUNDAMENTAÇÃO TECNOLÓGICA
O desenvolvimento de aplicações web voltadas para dispositivos móveis é fortemente baseado
no uso de frameworks e ferramentas de software que facilitam o desenvolvimento e aumentam
a produtividade. Neste trabalho, os seguintes frameworks e ferramentas foram utilizados:
- Spring Boot: Framework que visa facilitar os processos de desenvolvimento,
configuração e publicação de aplicações baseadas no Spring Framework.
- Angular: Framework utilizado para desenvolver aplicações modernas para web,
plataformas móveis ou desktop.
- ChatFuel: Plataforma para criar chatbot para ser utilizado via Facebook Messenger.
- JSON: Formato para intercâmbio de dados estruturados.
- Swagger: Conjunto de ferramentas voltado para o desenvolvimento e documentação
de APIs Representational State Transfer (REST).
Essas ferramentas serão detalhadamente apresentadas nas seções a seguir.
3.1 Spring Boot
Spring Boot, segundo Bianchi (2015), “trata-se de um framework que tem como objetivo
reaproveitar as tecnologias já existentes no Spring Framework, aumentando a produtividade do
desenvolvedor”.
O Spring Framework suporta o desenvolvimento de aplicações com diferentes cenários
e arquiteturas, isso porque é dividido em módulos8, ou seja, o desenvolvedor define quais
módulos utilizar. Entre esses módulos, pode-se citar os módulos de web, de persistência e de
segurança.
O Spring Boot permite desenvolver um software de uma maneira rápida e fácil, pois
exige pouca configuração para o início do desenvolvimento. É necessário apenas selecionar
quais módulos serão utlizados.
O Spring Boot possui quatro objetivos9:
Prover uma experiência de início de projeto extremamente rápida e direta;
8 https://docs.spring.io/spring/docs/5.1.2.RELEASE/spring-framework-reference/overview.html#overview 9https://docs.spring.io/spring-boot/docs/2.1.0.RELEASE/reference/htmlsingle/#getting-started-introducing-
spring-boot
36
Apresentar uma visão simples sobre o modo como deve-se configurar os projetos
Spring, e ao mesmo tempo flexível o suficiente para que possa ser facilmente substituída
de acordo com os requisitos do projeto;
Fornecer uma série de requisitos não funcionais já pré-configurados para o
desenvolvedor como, por exemplo, métricas, segurança, acesso a base de dados,
servidor de aplicações/servlet embarcado, etc;
Não realizar geração de código e minimizar a zero a necessidade de arquivos XML.
Portanto, pode-se concluir que o Spring Boot funciona como uma camada sobre
tecnologias já consagradas pelo Spring Framework, como ilustra a FIGURA 3.1.
FIGURA 3.1 – Arquitetura do Spring Boot
FONTE: https://www.devmedia.com.br/spring-boot-simplificando-o-spring/31979
3.2 Angular
Angular é uma plataforma e framework para construção da interface de aplicações usando
HTML, CSS, JavaScript e TypeScript10.
TypeScript é um superset do JavaScript, ou seja, possui todas as funcionalidades do
JavaScript e mais algumas. O próprio Angular foi desenvolvido utilizando esta linguagem e é
também a mais utilizada para desenvolvimento em aplicações Angular. Como os navegadores
10 https://blog.algaworks.com/o-que-e-angular/
37
atuais não suportam essa linguagem, deve ser gerado um códido JavaScript a partir do código
TypeScript.
O Angular permite o desenvolvimento de aplicações modernas para web, plataformas
móveis ou desktop11. Para isso, possui elementos básicos que auxiliam o desenvolvimento de
aplicações. O principais são: componentes, templates, diretivas, roteamento, módulos, serviços,
injeção de dependências e ferramentas de infraestrutura que automatizam tarefas.
Uma aplicação Angular é baseada em componentes, pois é possível reutilizá-los em
vários lugares na aplicação, tornando mais simples o desenvolvimento. Para criar as regras de
negócio são utilizados serviços, como por exemplo requisições REST, conforme ilustra a
FIGURA 3.2.
A aplicação web desenvolvida neste projeto segue esta arquitetura, garantindo
padronização e utilização das melhores práticas.
FIGURA 3.2 – Arquitetura de uma aplicação Angular
FONTE: https://blog.algaworks.com/o-que-e-angular/
11 https://angular.io/guide/quickstart
38
3.3 Chatfuel
Chatfuel é uma plataforma de desenvolvimento de chatbots. O desenvolvimento se dá a partir
de um painel de controle em que o usuário pode criar blocos de respostas, adicionar inteligência
artificial, enviar mensagem broadcast, além de possuir estatísticas de uso e informar quem está
utilizando o chatbot. A FIGURA 3.3 apresenta o painel de controle do Chatfuel.
FIGURA 3.3 – Painel de Controle do Chatfuel
FONTE: https://dashboard.chatfuel.com
Os blocos de respostas são onde a maior parte da conversa se situa e para isso existem
diferentes estilos de mensagem, podendo ser uma mensagem de texto ou até requisições via
GET e POST para outros sistemas. A FIGURA 3.4 mostra as opções disponíveis de criação de
resposta de um chatbot utilizando Chatfuel.
39
FIGURA 3.4 – Plugins disponíveis no Chatfuel
FONTE: https://dashboard.chatfuel.com
Devido a estes plugins e a existência do painel de controle do Chatfuel, a criação de um
chatbot é facilitada. Há possibilidade do usuário sem conhecimento em desenvolvimento de
software, criar seus próprios chatbots e integrar com outros sistemas utlizando o plugin Zapier,
que se caracteriza por ser uma plataforma de integração de ferramentas. A partir dela se torna
possível integrar mais de 1.000 sistemas disponíveis na Web, como Instagram, Facebook e
Gmail. Tanto Chatfuel quanto Zapier são ferramentas gratuitas, mas há exceções. No caso do
40
Chatfuel é cobrado um valor dependendo da quantidade de pessoas que utilizam o chatbot e no
caso do Zapier há um aumento no valor quando se integra mais de duas ferramentas.
O Chatfuel também dispinibiliza uma API que utiliza JSON para integração sem a
necessidade do Zapier, possibilitando que desenvolvedores de softwares adicionem chatbots a
seus sistemas. A FIGURA 3.5 mostra como fazer uma requisição POST a partir do Chatfuel e
a FIGURA 3.6 como deve ser o formato do JSON para enviar um texto para o Chatfuel que
posteriormente será enviado ao usuário do chatbot.
FIGURA 3.5 – Plugin de POST no Chatfuel
FONTE: https://dashboard.chatfuel.com
FIGURA 3.6 – Formato JSON para enviar um text ao Chatfuel
FONTE: https://dpcs.chatfuel.com/api/json-api/json-api
41
3.4 JSON
JSON é um formato de troca de dados estruturados. É baseado em texto, ou seja, o usuário pode
armazenar qualquer dado. Utiliza duas estruturas12, a primeira consiste em uma coleção de pares
chave/valor e a segunda em uma lista ordenada de valores.
JSON, por se tratar de texto simples, é fácil de ser interpretado por humanos e também
por outros sistemas, Portanto, uma vez criado o JSON, pode-se enviá-lo à outra aplicação.
Segundo Schmitt (2013). As principais vantagens do JSON são:
É compacto;
É de fácil entendimento para leitura como para desenvolvimento;
Mapeia muito facilmente as estruturas de dados usadas por muitas linguagens de
programação (números, strings, booleanos, nulos, matrizes e matrizes associativas);
Quase todas as linguagens de programação contém funções ou bibliotecas que podem
ler e escrever estruturas JSON.
3.5 Swagger
Swagger é um conjunto de aplicaçoes open-source que auxiliam no desenvolvimento de APIs
REST13. Suas principais ferramentas são:
Swagger Editor - Editor para o auxílio da criação do contrato;
Swagger UI14 - Permite documentar e consumir a API sem ter de desenvolver uma
lógica para isso;
Swagger Codegen - Geração de servidores em diversas tecnologias.
O Swagger especifica a OpenAPI, uma linguagem para descrição de contratos de APIs
REST15. Esses contratos permitem descrever toda a API, incluindo:
URLs disponíveis e qual tipo de operação (GET, POST, PUT e DELETE);
Dados necessários para requisições e suas respectivas respostas;
Licença, termos de uso e outras informações.
12 https://www,json.org 13 https://swagger.io/docs/specification/abount/ 14 https://swagger.io/tools/swagger-ui/ 15 blog.caelum.com.br/modeland0-apis-rest-com-swagger/
42
3.6 Trello
Trello16 é uma ferramenta de gerenciamento de projetos em listas, podendo ser customizado
para atender as necessidades do usuário. Pode-se utilizá-lo para organizar tarefas diárias, planos
de viagem e organizar projetos de qualquer tamanho.
Nestas listas pode-se criar cartões com comentários, carregar anexos, criar checklists,
adicionar etiquetas e prazos.
Nas duas figuras seguintes é ilustrado a flexibilidade do Trello com a possibilidade de
se criar listas. Na FIGURA 3.7 foi criado um quadro com tarefas semanais e na FIGURA 3.8
um quadro seguindo o padrão scrum.
FIGURA 3.7 – Quadro de tarefas semanais
FONTE: Autor
FIGURA 3.8 – Quadro padrão scrum
FONTE:Autor
3.7 Bitbucket
Bitbucket é uma ferramenta que utiliza o sistema Git com o intuito de realizar versionamento
de um projeto17. Com isso é possível obter históricos das modificações, permitir criação de
16 https://trello.com/about 17 https://br.atlassian.com/software/bitbucket/features
43
equipes para o desenvolvimento do projeto, e permitir um comparativo entre várias versões do
projeto18 . Permite também controlar o acesso ao projeto, assim cada pessoa que faz parte da
equipe tem suas permissões bem definidas.
A FIGURA 3.9 apresenta o painel de controle do Bitbuket, onde pode-se visualizar o
código fonte do projeto e todas as funcionalidades do sistema Git.
FIGURA 3.9 – Painel de controle Bitbucket
FONTE: Autor
18 https://medium.com/trainingcenter/controle-de-vers%C3%A3o-git-github-e-bitbucket-afinal-o-que-%C3%A9-
tudo-isso-9fa13fc13307
44
4. MODELAGEM DO BARBER SOLUTIONS
Um dos elementos que contribuem para o sucesso de desenvolvimento de um software é a sua
modelagem. Modelos são construídos para auxiliar na compreensão de sistemas em
desenvolvimento.
Pode-se utilizar modelos para visualizar o que se é esperado como resultado final,
especificar comportamentos do sistema e documentar as tomadas de decisões19.
Portanto, os modelos auxiliam a equipe a ter uma visão mais abrangente do funcionamento do
sistema, e assim, desenvolvê-lo de forma mais rápida e correta20. Neste trabalho, a modelagem
foi realizada da seguinte maneira:
- Levantamento de requisitos: Realizado em reuniões que utilizaram duas técnicas,
brainstorm e entrevista;
- Tabela de requsitos Funcionais e Não Funcionais: Classificação e definição de
prioridade dos requisitos levantados;
- Casos de uso: Representar as funcionalidades do Barber Solutions a partir dos
requisitos funcionais;
- Modelo de dados: Definição do conceito do banco de dados desenvolvido e sua
ilustração.
Esses tópicos estão detalhados nas seções a seguir.
4.1 Levantamento de Requisitos
Levantar Requisitos é o processo de definição das necessidades dos stakeholders, parte
interessada do projeto. O processo de coleta dos requisitos deve definir funções e
funcionalidades do produto que o projeto se propõe a criar21.
Segundo Sommerville (2011), para auxiliar na elicitação de requisitos, são utilizadas algumas
técnicas que serão detalhadas a seguir.
19http://www.ppgia.pucpr.br/~alcides/Teaching/ProgramasAprendizagem/ModelagemOrientadaObjetos/Introduc
ao.html 20 http://www.linhadecodigo.com.br/artigo/1293/a-importancia-do-modelagem-de-objetos-no-desenvolvimento-
de-sistemas.aspx 21 http://pm2all.blogspot.com/2011/09/pmbok-51-coletar-os-requisitos.html
45
Entrevistas: Nesta técnica clientes e/ou usuários são entrevistados pelo desenvolvedor,
com o intuito de permitir o entendimento dos requisitos do sistema. Existem dois tipos
de entrevista, (i) fechada, onde as perguntas já estão pré-definidas e (ii) aberta, que se
adapta para explorar o conhecimento do stakeholder sem agenda pré-definida.
Brainstorm: Técnica muito utilizada para o desenvolvimento de idéias criativas, com o
intuito de criar idéias novas ou resolver problemas.
Cenários Casos de Uso: Descreve uma situação de uso do sistema, identificando
usuários, principais funcionalidades e interação entre usuário e sistema.
Etnografia: Técnica de observação utilizada para compreender os requisitos sociais e
organizacionais.
Reutilização de requisitos: Considerar reutilizar requisitos que já foram desenvolvidos
em outros sistemas.
Prototipação: Técnica que consiste em implementar uma parte do sistema para que o
usuário possa dar um feedback sobre o levantamento de requisitos.
Joint Application Development (JAD): Propõe criar sessões de trabalho com dinâmicas
de grupo e recursos virtuais, onde usuários e analistas trabalham juntos para projetar um
sistema.
Para o levantamento de requisitos deste trabalho, foram realizadas três reuniões com o
stakeholder, gerente de uma barbearia. Em uma delas foi utilizada a técnica de entrevista e nas
reuniões restantes foi utilizada a técnica de brainstorm.
As duas primeiras reuniões foram realizadas de maneira informal. Utilizando a técnica
de brainstorm, foi possível identificar o problema e qual a solução esperada pelo stakeholder.
A última reunião foi realizada de maneira formal, visando alinhar cliente e autor sobre os
problemas e documentar quais seriam as soluções que seriam satisfatórias para o stakeholder.
No ANEXO A, é apresentado o documento que foi gerado para a realização da entrevista.
4.2 Requisitos Funcionais e Não Funcionais
Requisitos Funcionais descrevem as funcionalidades do produto e podem ser divididos em
requisitos funcionais de cliente e requisitos funcionais de sistema.
46
Requisito funcional de cliente apresenta uma noção pouco detalhada sobre o que o
sistema deve fazer. Em contrapartida, requisito funcional de sistema deve descrever os serviços
do sistema detalhadamente22.
Requisitos não funcionais restringem os requisitos funcionais, ou seja, requisitos não
funcionais especificam que o produto entregue deve se comportar de maneira particular. Devido
a isso, pode ser dividido em subgrupos, por exemplo, usabilidade, confiabilidade, desempenho,
segurança.
Os requisitos funcionais e não-funcionais do projeto são apresentados pelo documento
de requisitos presente no Apêndice B.
4.3 Casos de Uso
Um documento de casos de uso tem a finalidade de representar as funcionalidades de um
software e quais atores (tipos de usuários) podem utilizar essas funcionalidades. Para este
trabalho foi identificado três atores: (i) ator que representa o gerente de uma barbearia, (ii) ator
que representa o barbeiro e (iii) o ator que representa o cliente.
As funcionalidades que cada ator pode acessar foram definidas de acordo com os
objetivos de cada ator. Devido a isso, o ator cliente, foi limitado às funcionalidades de manter
cliente e horas agendadas. Já o ator barbeiro, tem acesso às funcionalidades de manter venda,
horário agendado, lançar serviço realizado e manter cliente. Por fim, o ator gerente pode acessar
todas as funcionalidades.
Com a definição dos requisitos, atores e funcionalidades permitidas para cada ator, é
possível criar um diagrama de casos de uso do Barber Solutions, ilustrado na FIGURA 4.1.
22 https://is.gd/AsxJQ5
47
FIGURA 4.1 – Diagrama de Casos de Uso
FONTE: Autor
48
4.4 Modelo de dados
Segundo Machado (2018), modelagem de dados é o estudo das informações existentes em um
contexto sob observação, para a construção de um modelo de representação e entendimento de
tal contexto. Tal modelo deve representar com precisão os dados requeridos pela aplicação,
para que possa ser revisado pelo usuário e ao mesmo tempo, deve ser detalhado o suficiente
para a implementação.
O modelo de Entidade-Relacionamento (ER) é o método mais comum para construção
de modelos de dados para banco de dados relacionais (MACHADO, 2018).
Devido ao Barber Solutions possuir múltiplos dados (entidades) que devem se
relacionar para obter o resultado esperado, definiu-se que seria desenvolvido um banco de dados
relacional. Um banco de dados relacional é dividido em tabelas com linhas e colunas, onde cada
linha representa uma ocorrência do objeto decrita por valores em cada coluna.
O sistema possui oito tabelas, sendo que todas possuem relacionamentos com alguma
outra tabela. Duas tabelas são as principais, onde ficam armazenados os dados referentes ao
negócio que o Barber Solutions visa automatizar. São elas: appointment e sale.
A tabela appointment concentra informações de horas agendadas. Nela é possível
visualizar qual cliente fez o agendamento, qual barbeiro foi escolhido para a realização do
serviço, quais foram os serviços solicitados, data e hora do agendamento, forma de pagamento,
forma de agendamento e o status do agendamento. O status do agendamento pode ser:
agendamento marcado, realizado ou perdido.
Já a tabale sale, possui informações das vendas da barbearia. Entre as informações
disponíveis estão: cliente que realizou a compra, barbeiro que realizou a venda, data da venda,
produtos vendidos e a forma de pagamento.
Definido os requisitos funcionais e por possuir o diagrama de casos de uso, foi possível
realizar a modelagem de dados e criar o diagrama de ER para representação dos dados
requiridos pelo sistema. O diagrama ER do Barber Solutions pode ser visualizado na FIGURA
4.2.
49
FIGURA 4.2 – Diagrama de Entidade-Relacionamento
FONTE: Autor
50
5. IMPLEMENTAÇÃO DO BARBER SOLUTIONS
O desenvolvimento do projeto foi dividido em três módulos principais, servidor, aplicação web
e chatbot. O servidor foi desenvolvido utilizando a tecnologia Spring Boot. A escolha dessa
tecnologia se deu pelo fato do rápido desenvolvimento e pela baixa necessidade de configuração
para o início do projeto. A ferramenta Chatfuel foi escolhida para o desenvolvimento do chatbot
devido à facilidade de criar fluxos de diálogos e pela possibilidade de integração REST. Por
fim, o desenvolvimento da aplicação web foi feito utilizando a tecnologia Angular pela
produtividade e qualidade que oferece. O template (AdminLTE22) foi utilizado para agilizar
ainda mais o desenvolvimento.
Em função das características do projeto, foi utilizada a metodologia ágil scrum. O autor
deste trabalho executou as atividades do scrum master e do time de desenvolvimento e o papel
de product owner ficou a cargo do cliente sendo ele o gerente de uma barbearia.
As etapas apresentadas no capítulo 4 permitiram a criação do product backlog, exibido
no QUADRO 5.1, o qual foi utilizado para realizar os ciclos de trabalho (sprints).
QUADRO 5.1 – Product Backlog
Requisito Tarefa Importância
RF01 Cadastrar barbeiro 100
RF02 Alterar barbeiro 100
RF03 Remover barbeiro 100
RF04 Visualizar barbeiro 100
RF05 Cadastrar serviço 100
RF06 Alterar serviço 100
RF07 Remover serviço 100
RF08 Visualizar serviço 100
RF09 Cadastrar produto 100
RF10 Alterar produto 100
RF11 Romover produto 100
RF12 Visualizar produto 100
RF13 Cadastrar cliente 100
51
RF14 Alterar cliente 100
RF15 Remover cliente 100
RF16 Visualizar cliente 100
RF17 Realizar controle de horas disponíveis 100
RF18 Agendar serviço 100
RF19 Alterar serviço agendado 100
RF20 Cancelar serviço agendado 100
RF21 Visualizar serviço agendado 100
RF22 Realizar venda 100
RF23 Alterar venda 100
RF24 Cancelar venda 100
RF25 Visualizar venda 100
RF26 Realizar autenticação 100
RF27 Integrar com API da Agenda do Google 100
RF28 Gerar relatório dos serviços realizados 100
RF29 Gerar relatório das vendas realizadas 100
RF30 Gerar relatório da forma de pagamento 100
RF31 Gerar relatório da forma de agendamento 100
RF32 Gerar relatório de serviços e vendas por barbeiro 100
RF33 Gerar relatório financeiro da barbearia 100
RF34 Gerar relatório financeiro por barbeiro 100
RF35 Desenvolver API de integração 100
RF36 Desenvolver ciclo de diálogo do chatbot 100
RF37 Integrar chatbot com a API desenvolvida 100
RF38 Desenvolver tela principal 100
RF39 Desenvolver tela de serviços agendados 100
RF40 Desenvolver tela de clientes 100
RF41 Desenvolver tela de produtos 100
RF42 Desenvolver tela de barbeiros 100
RF43 Desenvolver tela de serviços 100
RF44 Desenvolver tela de relatório 100
52
RF45 Integrar com API desenvolvida 100
FONTE: Autor
Para organizar e controlar o desenvolvimento do projeto, foi utilizado a ferramenta
Trello. O uso desta ferramenta facilitou a visualização das tarefas a serem realizadas em cada
sprint, além do controle do product backlog. Foi criado um quadro com quatro listas: product
backlog. sprint backlog, fazendo e concluído, ilustrado na FIGURA 5.1.
FIGURA 5.1 – Quadro da ferramenta Trello de gerenciamento do projeto (Sprint 1)
FONTE: Autor
As sprints do projeto seguiram o fluxo do Scrum, apresentado da FIGURA 2.9, sendo o
primeiro passo a reunião de abertura da sprint, na qual foram definidas as tarefas a serem
realizadas na sprint com a participação do product owner. Ao final da sprint foi realizada a sua
entrega ao product owner, para que fosse feita sua aprovação e validação.
As sprints do projeto tiveram duração entre 25 e 30 horas, com datas de entrega
marcadas a cada duas semanas, sendo o tempo de duração do projeto de seis semanas. Ao final
de cada sprint foi gerado uma versão funcional do projeto. O controle de versão foi realizado
através da ferramenta Bitbucket. As sprints do projeto serão detalhadas nas próximas seções.
53
Ao final da sprint 3, foi realizado um questionário para a validação do sistema. O
questionário foi realizado após duas tarefas pré estabelecidas, agendar um horário e realizar
uma venda.
5.1 Sprint 1
A reunião de abertura da primeira sprint definiu como objetivo o desenvolvimento dos
requisitos: RF01, RF02, RF03, RF04, RF05, RF06, RF07, RF08, RF09, RF10, RF11, RF12,
RF13, RF14, RF15, RF16, RF17, RF18, RF19, RF20, RF21, RF22, RF23, RF24 e RF25.
Após a modelagem do banco de dado, ele foi criado e foram desenvolvidas todas as
funções necessárias para a manipulação referente aos requisitos pré-estabelecidos. Portanto, o
sistema passou a possibilitar a inserção, alteração, remoção e visualização dos seguintes dados:
barbeiro, cliente, serviço, produto, horas agendadas e vendas.
Nesta sprint também foi implementada a lógica para controle de dias e horas
disponíveis. O controle desses dados é essencial para o funcionamento da barbearia, evitando
conflitos de atendimento a clientes e otimizando a marcação ou alteração de agendamento de
serviços.
O desenvolvimento da lógica de controle de dias e horas disponíveis foi a
funcionalidade que demandou mais tempo, e para sua total funcionalidade é necessário passar
a informação de quais serviços o cliente opta realizar, com definição de barbeiro e data
escolhida. Portanto, a necessidade desses dados determinaram o fluxo para agendar um horário.
Por fim, foram apresentadas as funcionalidades desenvolvidas ao product owner, e ele
aceitou a entrega da sprint. Assim a sprint foi considerada um sucesso, atendendo todos seus
requisitos. Como resultado se obteve a versão 0.1.0 do servidor.
5.2 Sprint 2
A reunião de abertura da segunda sprint definiu como objetivo o desenvolvimento dos
requisitos: RF26, RF27, RF35, RF36 e RF37. As primeiras tarefas executadas foram as que
tinham maior importância para o product owner.
54
Portanto, a primeira tarefa realizada foi o desenvolvimento da API de integração. Foram
criadas todas as URLs necessárias para acessar os dados desenvolvidos na primeira sprint e as
respostas foram desenvolvidas em formato JSON, como é apresentado na FIGURA 5.2.
FIGURA 5.2 – Resposta de um cliente em format JSON
FONTE: Autor
Como o servidor não possui interface, foi implementado o Swagger UI com o objetivo
de documentar a API e também consumi-la, assim podendo realizar testes para validar as
funcionalidades implementadas. A FIGURA 5.3 ilustra como o Swagger UI apresenta as URLs
da API.
FIGURA 5.3 – Documentação e métodos para consumir a API desenvolvida
FONTE: Autor
A seguir foi realizado a integração com a Agenda do Google. O primeiro passo é o
cliente permitir que o sistema realize operações em sua agenda. Para isso o sistema apresenta
55
uma tela solicitando autorização ao usuário, como mostra a FIGURA 5.4. Ao conceder a
autorização o sistema poderá manipular a agenda do usuário.
FIGURA 5.4 – Tela de autorização da Agenda do Google
FONTE: Autor
Para manipular eventos da agenda, foram criados três novos métodos no servidor: criar
evento, alterar evento e deletar evento.
Com o intuito de garantir que os dados dos eventos da Agenda do Google sejam os
mesmos que estão salvos no banco de dados do sistema, todas as funcionalidades referentes ao
agendamento de horário seguem o fluxo apresentado na FIGURA 5.5. Para testar a integração
e o fluxo foi utilizado o Swagger UI.
56
FIGURA 5.5 – Fluxo das funcionalidades de agendar horário
FONTE: Autor
Por fim, foi desenvolvido o chatbot utilizando a ferramenta do Chatfuel. Após testes, o
fluxo de diálogo foi criado. Para evitar erros de uso do chatbot, o diálogo é baseado em propor
respostas prontas para o usuário. A FIGURA 5.6 mostra o chatbot propondo respostas referentes
ao dia em que o cliente quer ser atendido.
FIGURA 5.6 – Diálogo entre chatbot e usuário
FONTE: Autor
57
A tarefa para realizar autenticação para utilizar sistema foi rejeitada pelo product owner
pelo fato de que sua implementação demoraria mais do que o estimado. O problema foi
identificado no começo da implementação desta tarefa, pois como há aplicações diferentes para
acessar funcionalidades e informações (aplicação web e chatbot), o servidor deve ser
configurado para tratar de forma diferente as requisições recebidas. Caso uma requisição seja
proveniente da aplicação web, é necessário gerar um token de acesso. No caso do chatbot, o
servidor deve identificar que tal requisição partiu do chatbot e não exigir mais o token
permitindo o acesso.
A sprint foi entregue e apresentada através do chatbot desenvolvido, onde foi possível
expôr que todas as funcionalidades da sprint foram desenvolvidas. O product owner relatou que
se sentiu satisfeito pelo contato quando houve uma situação de tomada de decisão, e aprovou a
entrega.
Como resultado foi gerado uma nova versão do servidor (0.2.1) e a versão 0.1.1 do
chatbot.
5.3 Sprint 3
A reunião de abertura da terceira sprint definiu como objetivo o desenvolvimento dos
requisitos: RF28, RF29, RF30, RF31, RF32, RF33, RF34, RF38, RF39, RF40, RF41, RF42,
RF43, RF44 e RF45.
A primeira tarefa realizada foi o desenvolvimento de uma aplicação web utilizando a
tecnologia Angular. Para agilizar o desenvolvimento foi utilizado um template gratuito
chamado AdminLTE.
Todo o conteúdo exibido pela aplicação é consumido através da API do servidor
desenvolvido na sprint 2, como ilustra a FIGURA 5.7 e 5.8.
58
FIGURA 5.7 – Tela de cliente
FONTE: Autor
FIGURA 5.8 – Tela de agendamentos marcados
FONTE: Autor
A FIGURA 5.9 apresenta as agendas dos barbeiros. Essa agenda é um código HTML
que a Agenda do Google disponibiliza para que a agenda possa ser exibida em outras aplicações.
59
FIGURA 5.9 – Tela da agenda dos barbeiros
FONTE: Autor
Seguindo com a sprint, foi desenvolvida a geração do relatório no servidor onde também
foi desenvolvido o controle financeiro. Esse relatório apresenta as seguintes informações: (i)
renda total, (ii) renda por serviço, (iii) renda por produto, (iv) quantidade de serviços realizados,
(v) quantidade de cada serviço realizado, (vi) quantidade de produtos vendidos, (vii) quantidade
de cada produto vendido, (viii) forma de pagamento dos serviços e vendas, (ix) forma de
agendamento, (x) quantidade de vendas, total e por produto, realizadas por barbeiro, (xi)
quantidade de serviços realizados, total e por serviço, por barbeiro, (xii) comissão a ser paga ao
barbeiro referente a serviços realizados, (xiii) comissão a ser paga ao barbeiro referente a
vendas de produtos. Enfim, todos os dados necessários para garantir a gerência de uma
barbearia. As figuras a seguir apresentam a tela de relatório do sistema. (i) FIGURA 5.10 mostra
informações gerais, (ii) FIGURA 5.11 apresenta informações sobre serviços, vendas e forma
de pagamento e agendamento e (iii) FIGURA 5.12 apresenta informações por barbeiro.
60
FIGURA 5.10 – Tela de relatório: Informações Gerais
FONTE: Autor
FIGURA 5.11 – Tela de relatório: Informações sobre serviços, vendas, forma de pagamento e
agendamento
FONTE: Autor
61
FIGURA 5.12 – Tela de relatório: Informações por barbeiro
FONTE: Autor
Os teste das funcionalidades foram realizados pelo scrum master. Assim que todas as
funcionalidades passaram nos testes, o product owner foi convidado para testar a usabilidade.
Esse teste teve como objetivo testar todas as telas da aplicação para garantir boa visualização
das informações e facilidade de obtê-las. Como resultado, a usabilidade da aplicação foi
aprovada pelo product owner.
Por fim, a sprint foi apresentada ao product owner através da aplicação web
desenvolvida. O product owner relatou estar satisfeito com a usabilidade e funcionalidade da
aplicação, e aprovou a entrega da sprint.
Como resultado foi gerado uma nova versão do servidor (1.0.0), uma nova versão do
chatbot (1.0.0) e uma versão da aplicação web (1.0.0).
5.4 Avaliação da Usabilidade do Barber Solutions
Para avaliar a usabilidade do software, foram propostas duas importantes tarefas para o
funcionamento do negócio da barbearia, agendar serviços e realizar vendas, essas tarefas são
62
apresentadas no Apêndice C. As tarefas foram realizadas no computador da barbearia e teve
participação do gerente e de todos os barbeiros.
Após a realização das tarefas, foi aplicado um questionário baseado na escala Likert
cujas alternativas de resposta são entre 1 e 5, sendo a opção 1 – Discordo totalmente, a opção 2
– Discordo parcialmente, a opção 3 – Indiferente, a opção 4 – Concordo parcialmente e a opção
5 – Concordo totalmente (Apêndice D).
Segundo Nielsen (2012), usabilidade pode ser definido por cinco componentes: (i)
tempo de aprendizagem, tempo necessário para o usuário aprender a realizar as tarefas, (ii)
desempenho, quantidade de tempo necessário para a realização das tarefas, (iii) taxa de erro
cometidos pelo usuário, quantidade e nível de erro apresentados durante a execução das tarefas,
(iv) sedimentação do conhecimento por experiência, capacidade de reproduzir o que foi feito a
partir do conhecimento obtido e (v) satisfação subjetiva, nível de satisfação apresentado pelo
usuário.
No Quadro 5.1 são apresentados os critérios de avaliação e as questões que
correspondem a cada um deles.
Quadro 5.1 - Questões relacionadas aos critérios de usabilidade
Critério Questões
Tempo de Aprendizagem 1. As informações apresentadas na tela são de
fácil entendimento?
2. Foi fácil executar a tarefa?
3. Os botões das funcionalidades do sistemas
estavam intuitivos?
Desempenho 4. A tarefa executada foi simples?
5. A tarefa foi realizada rapidamente?
Taxa de erros cometidos pelo
usuário
6. Foi possível realizar a tarefa sem cometer erros?
7. Caso tenha ocorrido algum erro, foi fácil corrigi-
lo?
63
Sedimentação do conhecimento por
experiência
8. Você executaria a tarefa novamente?
9. È fácil lembrar como realizar a tarefa?
10. Foi intuitivo realizar a tarefa?
Satisfação subjetiva 11. Você se sentiu satisfeito com o Barber
Solutions?
12. A interface agradou?
13. Usaria o Barber Solutions novamente?
5.4.1 Análise
Utilizando os gráficos apresentados na FIGURA 5.13 e na FIGURA 5.14, para analisar os
resultados das duas tarefas, nota-se que os resultados positivos se sobressairam (resposta 4 ou
5). A tarefa 1 obteve 71% de respostas positivas enquanto a tarefa 2 obteve 62%.
FIGURA 5.13 – Gráfico da avaliação da usabilidade da Tarefa 1
FONTE: Autor
2%14%
13%
27%
44%
T1
Discordo Totalmente
Discordo Parcialmente
Indiferente
Concordo Parcialmente
Concordo Totalmente
64
FIGURA 5.14 – Gráfico da avaliação da usabilidade da Tarefa 2
FONTE: Autor
As respostas neutras (3) e negativas (1 ou 2) se concentraram nos critérios de
desempenho e sedimentação do conhecimento por experiência, apresentados nas FIGURAS
5.15 e 5.16. Com isso pode-se concluir que as tarefas tiveram uma complexidade mais elevada
e que o desenvolvimento de guias e exemplos passo a passo auxiliariam na realização dessas
tarefas.Um solução pode ser botões de ajuda para apresentar dicas de como executar as tarefas.
FIGURA 5.15 – Gráfico do desempenho
FONTE: Autor
2%
17%
19%
25%
37%
T2
Discordo Totalmente
Discordo Parcialmente
Indiferente
Concordo Parcialmente
Concordo Totalmente
0
1
2
3
4
5
6
DiscordoTotalmente
DiscordoParcialmente
Indiferente ConcordoParcialmente
ConcordoTotalmente
Qu
anti
dad
e d
e R
esp
ost
as
Desempenho
65
FIGURA 5.16 – Gráfico da sedimentação do conhecimento por experiência
FONTE: Autor
O critério taxa de erros cometidos pelo usuário dividiu-se em notas positivas e negativas,
como mostra a FIGURA 5.17, pois ocorreram alguns erros de utilização da aplicação, mas que
os usuários conseguiram analisar e corrigir esses erros. Por exemplo, a função de adicionar
quais serviços deveriam ser realizados ao agendar serviços gerou dificuldade para os usuário,
mas que ao cometerem o erro uma vez, conseguiram corrigi-lo.
FIGURA 5.17 – Gráfico da taxa de erros cometidos pelo usuário
FONTE: Autor
0
1
2
3
4
5
6
7
8
DiscordoTotalmente
DiscordoParcialmente
Indiferente ConcordoParcialmente
ConcordoTotalmente
Qu
anti
dad
e d
e R
esp
ost
as
Sedimentação do conhecimento por experiência
0
0,5
1
1,5
2
2,5
3
3,5
4
4,5
DiscordoTotalmente
DiscordoParcialmente
Indiferente ConcordoParcialmente
ConcordoTotalmente
Qu
anti
dad
e d
e R
esp
ost
as
Taxa de erros cometidos pelo usuário
66
Nota-se a partir das FIGURAS 5.18 e 5.19, que os critérios que obtiveram mais
respostas positivas foram tempo de aprendizagem e satisfação subjetiva. Isso comprova que o
Barber Solutions agradou aos usuários e trouxe mais rapidez para as tarefas da barbearia.
FIGURA 5.18 – Gráfico do tempo de aprendizagem
FONTE: Autor
FIGURA 5.19 – Gráfico da satisfação subjetiva
FONTE: Autor
0
5
10
15
20
25
DiscordoTotalmente
DiscordoParcialmente
Indiferente ConcordoParcialmente
ConcordoTotalmente
Qu
anti
dad
e d
e R
esp
ost
as
Tempo de Aprendizagem
0
2
4
6
8
10
12
DiscordoTotalmente
DiscordoParcialmente
Indiferente ConcordoParcialmente
ConcordoTotalmente
Qu
anti
dad
e d
e R
esp
ost
as
Satisfação subjetiva
67
6. CONCLUSÃO
Com o desenvolvimento deste trabalho, concluiu-se que uma aplicação web moderna voltada
ao gerenciamento de uma barbearia apresentou resultados muito satisfatórios, possibilitando a
automatização deste ramo que está em amplo crescimento no Brasil. O sistema trouxe inovação
tecnológica e agilidade a atividades que antes eram realizadas de forma manual demandando
muito tempo.
A utilização da metodologia Scrum, possibilitou que o projeto fosse organizado de uma
maneira rápida, visando entregas incrementais e funcionais do projeto, com o objetivo de
concluir todos os requisitos levantados.
Os desafios do desenvolvimento foram as integrações realizadas com APIs de fontes
independentes, devido a necessidade de adequar o sistema a diferentes formas e formatos de
comunicação em diferentes linguagens de programação.
Concluiu-se ainda que todas as tecnologias utilizadas ofereceram benefícios importantes
para o desenvolvimento deste projeto. O Spring Boot ofereceu rápida inicialização do projeto
e utilização da linguagem de programação Java, facilitando o desenvolvimento devido a
experiência do autor com esta linguagem. O Chatfuel permitiu rápida configuração e validação
do chatbot. Angular possui funcionalidades que torna o desenvolvimento de uma aplicação web
mais fácil.
Ao final da sprint 3, foi realizada a entrega de uma versão totalmente funcional e que
foi aceita pelo Product Owner do projeto, o gerente de uma barbearia. A facilidade de utilização
da aplicação web e do chatbot foi um ponto elogiado, bem como a rapidez que o sistema trouxe
a todas as atividades da barbearia.
Por fim, ao realizar a avaliação usabilidade pode-se concluir que a interface do Barber
Solutions ajudou na realização das tarefas propostas, mas como são necessários muitos dados
e passos para a realização das tarefas, elas não foram consideradas simples de se realizar.
6.1 Trabalhos Futuros
Na fase de conclusão do projeto foram identificadas melhorias que podem ser implementadas
no futuro. A primeira diz respeito à segurança do sistema, pois como há requisições feitas de
diferentes fontes o sistema deve ser capaz de garantir a segurança das informações. Com essa
68
melhoria o produto pode ser comercializado de maneira integral. A segunda é a criação de login
diferenciado para barbeiros e gerentes de barbearias, para que não seja necessário o
gerente da barbearia inicializar o sistema. Um módulo de mineração de dados pode ser
implementado para entender melhor o comportamento do cliente, e assim prover serviços
personalizados. Por último, aprimorar o relatório, possibilitando filtrar pela data escolhida pelo
gerente.
69
7. REFERÊNCIAS
AGRIZZI, Bruno Alves. Uma Abordagem para Integração de Internet das Coisas e
Aplicações Web. 2015. 37 f. TCC (Graduação) - Curso de Ciência da Computação,
Universidade Federal do Espírito Santo, Vitória, 2015.
BERNARDO, Rogério O.; SANTANCHÈ, André. Aplicação de chatbots no
desenvolvimento de jogos em saúde. 2017. 12 f. TCC (Graduação) - Curso de
Computação, Universidade Estadual de Campinas, Campinas, 2017.
BIANCHI, Evaldo Augusto. Sistema de Envio e Recebimento de Mensagens para
Plataforma Android utilizando Spring Boot e Google Cloud Messaging. 2015. 56
f. Monografia (Especialização) - Curso de Curso de Especialização em Tecnologia Java,
Universidade Tecnológica Federal do Paraná, Pato Branco, 2015.
CARVALHO, Bernardo Vasconcelos de; MELLO, Carlos Henrique Pereira. Aplicação do
método ágil scrum no desenvolvimento de produtos de software em uma pequena empresa de
base tecnológica. Gestão & Produção, São Carlos, v. 19, n. 3, p.557-573, 2012.
FapUNIFESP (SciELO). http://dx.doi.org/10.1590/s0104-530x2012000300009.
DALE, Robert. The return of the chatbots. Natural Language Engineering, [s.l.], v. 22, n.
05, p.811-817, set. 2016. Cambridge University Press (CUP).
http://dx.doi.org/10.1017/s1351324916000243.
FERREIRA, João Luiz Mafra. Aplicação Web Para Gerenciamento de Campeonatos
de Futebol. 2017. 166 f. TCC (Graduação) - Curso de Sistemas de Informação, Universidade
Federal de Santa Catarina, Florianópolis, 2017.
JOSEPH, Renien John. Single Page Application and Canvas Drawing. International Journal
Of Web & Semantic Technology, [s.l.], v. 6, n. 1, p.29-37, 31 jan. 2015. Academy and
Industry Research Collaboration Center (AIRCC). http://dx.doi.org/10.5121/ijwest.2015.6103.
70
Disponível em: <https://arxiv.org/ftp/arxiv/papers/1502/1502.03530.pdf>. Acesso em: 03 nov.
2018.
MACHADO, Felipe Nery Rodrigues. Banco de Dados - Projeto e Implementação. 3.
ed. [s. I.]: Saraiva, 2018. Disponível em:
<https://books.google.com.br/books?id=N4diDwAAQBAJ&printsec=frontcover&hl=pt-
BR&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false>. Acesso em: 02 nov. 2018.
Nielsen. J.(2012). Usability 101: Introduction to Usability .
https://www.nngroup.com/articles/usability-101-introduction-to-usability/. Accessed on 04
december 2018.
PENA, Joana Rita Amaral. Projeto de conceito e estrutura de uma aplicação mobile
para o setor do Turismo Cultural Urbano. 2017. 51 f. Dissertação (Mestrado) - Curso de
Publicidade e Marketing, Escola Superior de Comunicação Social, [s. I.], 2017.
SARRAJ, Wael Al. TOWARD USABILITY EVALUATION CRITERIA FOR WEB
MASHUP MAKERS FOR END- USERS. International Journal Of Advanced
Computer Technology. Palestina, p. 23-32. out. 2014.
SCHIMITT, Peterson Ricardo Maier. Aplicação Web utilizando API Google
Maps. 2013. 49 f. TCC (Graduação) - Curso de Análise e Desenvolvimento de Sistemas,
Universidade Tecnológica Federal do Paraná, Medianeira, 2013.
SHAHZAD, Farrukh. Modern and Responsive Mobile-enabled Web Applications. Procedia
Computer Science, [s.l.], v. 110, p.410-415, 2017. Elsevier BV.
http://dx.doi.org/10.1016/j.procs.2017.06.105.
SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson Education do
Brasil, 2011. Disponível em:
<ftp://ftpaluno.umc.br/Aluno/Daisy/Engenharia%20de%20Software/Engenharia_Software_3
Edicao%20sommerville.pdf>. Acesso em: 03 nov. 2018.
71
ZHANG, Zhewei et al. Characterizing Generative Digital Artifacts: The Case of Web
Mashups. 2015. Disponível em: <http://www.orgdna.net/wp-
content/uploads/2015/07/Characterizing-Generative-Digital-Artifacts.pdf>. Acesso em: 30 out.
2018.
72
APÊNDICE A – DOCUMENTO GERADO PARA A REALIZAÇÃO DA ENTREVISTA
Pauta de Reunião:
Objetivo: Identificar as necessidades / demanda do Barber Solutions
Tópicos a serem discutidos: 1. Apresentação dos Problemas / Demanda da Barbearia;
2. Entrevista com o Gerente;
3. Fechamento da Reunião.
Pessoas que serão entrevistadas 1. Gerente da barbearia
1. Apresentação dos Problemas
1.1 Todo gerenciamento da barbearia feito e forma manual, entre eles, agendamento
de horário, vendas, comissões;
1.2 Gerenciamento financeiro muito demorado;
1.3 Falta de uma atendimento virtual.
2. Entrevista
Perguntas:
1. Você poderia falar um pouco sobre o dia a dia da barbearia, ou seja, descreva passo
a passo o que acontece entre o cliente entrar na barbearia e ser atendido por um
barbeiro?
2. Quantos barbeiros atendem na barbearia? Todos realizam as mesmas funções?
3. Todos os barbeiros tem acesso a todas as agendas?
4. Como gostaria que fosse o atendimento virtual ao cliente?
5. Você deseja que o sistema funcione via Web? Como?
6. Você deseja que o sistema faça o controle financeiro e contábil da barbearia?
Como?
7. Você deseja que o sistema controle o estoque de produtos?
8. Você deseja que o barbeiro tenha acesso LIMITADO a algum tipo de informação?
3. Fechamento
O que o cliente deseja: Um sistema web que possibilite gerenciar uma barbearia.
Este sistema deve permitir realizar agendamentos, gestão financeira e
de estoque
Um sistema de atendimento automatizado ao cliente.
Como: Cliente não especificou, deixando o desenvolvimento por conta do autor.
73
Validação: Ficou acordado com o cliente que ao final de cada ciclo de trabalho, será feita
uma reunião de entrega onde o cliente dará sua opinião sobre o produto.
74
APÊNDICE B – DOCUMENTO DE REQUISITOS
Barber Solutions Cliente: Rock Mustache Barbearia
01 – Barber Solutions DOCUMENTO DE REQUISITOS
Versão <1.0>
75
Revisões do Documento
Data Versão Descrição Autor
15/06/2018 1.0 Criação do Documento de Requisitos Eduardo
76
ÍNDICE
1.1 Convenções, termos e abreviações ............................................................................ 77
1.1.1 Identificação dos Requisitos............................................................................... 77
1.1.2 Prioridades dos Requisitos ................................................................................. 77
2.1 Abrangência e sistemas relacionados ........................................................................ 78
2.2 Descrição do cliente ................................................................................................... 78
2.3 Descrição dos usuários .............................................................................................. 79
3.1 Requisitos do módulo Servidor ................................................................................. 79
3.2 Requisitos do módulo Chatbot .................................................................................. 94
3.3 Requisitos do módulo Aplicação Web ...................................................................... 96
4.1 Usabilidade ................................................................................................................ 98
1. Garantir boa experiência de usuário .......................................................................... 98
4.2 Confiabilidade ........................................................................................................... 98
2. Garantir disponibilidade do sistema em 99% ............................................................ 98
4.3 Desempenho .............................................................................................................. 98
3. Requisições com tempo de resposta de no máximo 5 segundos ............................... 98
4.4 Segurança ................................................................................................................... 98
4. Realizar autenticação ................................................................................................. 98
77
1. Introdução Este documento especifica os requisitos do Barber Solutions, fornecendo aos desenvolvedores as informações necessárias para a execução de seu projeto e implementação, assim como para a realização dos testes e validação.
Esta introdução fornece as informações necessárias para fazer um bom uso deste documento, explicitando seus objetivos e as convenções que foram adotadas no texto. As demais seções apresentam a especificação do Barber Solutions e estão organizadas como descrito abaixo:
Seção 2 - Descrição geral do produto/serviço: apresenta uma visão geral do produto/serviço, caracterizando qual é o seu escopo e descrevendo seus usuários.
Seção 3 - Requisitos funcionais: lista e descreve os requisitos funcionais do produto/serviço, especificando seus objetivos, funcionalidades, atores e prioridades.
Seção 4 - Requisitos não funcionais: especifica todos os requisitos não funcionais do produto/serviço, divididos em requisitos de usabilidade, confiabilidade, desempenho, segurança, distribuição, adequação a padrões e requisitos de hardware e software.
Seção 5 - Rastreabilidade: apresenta os relacionamentos entre os requisitos do produto/serviço.
1.1 Convenções, termos e abreviações
A correta interpretação deste documento exige o conhecimento de algumas convenções e termos específicos, que são descritos a seguir.
1.1.1 Identificação dos Requisitos
Por convenção, a referência a requisitos é feita através do identificador do requisito, de acordo com o esquema abaixo:
[identificador de tipo de requisito.identificador do requisito]
O identificador de tipo de requisito pode ser:
RF – requisito funcional
RNF – requisito não-funcional
Identificador do requisito é um número, criado seqüencialmente, que determina que aquele requisito é único para um determinado tipo de requisito.
Ex: RF001, RF002, RNF001, RNF002.
1.1.2 Prioridades dos Requisitos
Para estabelecer a prioridade dos requisitos foram adotadas as denominações “essencial”, “importante” e “desejável”.
Essencial é o requisito sem o qual o sistema não entra em funcionamento. Requisitos essenciais são requisitos imprescindíveis, que têm que ser implementados impreterivelmente.
Importante é o requisito sem o qual o sistema entra em funcionamento, mas de forma não satisfatória. Requisitos importantes devem ser implementados, mas, se não forem, o sistema poderá ser implantado e usado mesmo assim.
Desejável é o requisito que não compromete as funcionalidades básicas do sistema, isto é, o sistema pode funcionar de forma satisfatória sem ele. Requisitos desejáveis são requisitos que podem ser deixados para versões posteriores do sistema, caso não haja tempo hábil para implementá-los na versão que está sendo especificada.
78
2. Visão geral do Barber Solutions O Barber Solutions visa automatizar o processo de interação com clientes e gestão do negócio, oferecendo ao cliente a possibilidade de marcação de horário através de um aplicativo de mensageria, e disponibiliza ao gestor da barbearia um sistema baseado na web que permite controlar a agenda dos barbeiros e consultar a comissão a ser paga por serviços realizados e por produtos vendidos, além de permitir calcular o faturamento da barbearia.
O desenvolvimento do projeto foi dividido em três módulos principais, servidor, aplicação web
e chatbot. O servidor foi desenvolvido utilizando a tecnologia Spring Boot. A escolha dessa
tecnologia se deu pelo fato do rápido desenvolvimento e pela baixa necessidade de
configuração para o início do projeto. A ferramenta Chatfuel foi escolhida para o
desenvolvimento do chatbot devido à facilidade de criar fluxos de diálogos e pela possibilidade
de integração REST. Por fim, o desenvolvimento da aplicação web foi feito utilizando a
tecnologia Angular pela produtividade e qualidade que oferece. O template (AdminLTE22) foi
utilizado para agilizar ainda mais o desenvolvimento.
Será utilizado a API da Agenda do Google, possibilitando utilizá-la de forma visual, pois será
importada para a aplicação web. Assim os usuários terão total acesso e visualização de suas
agendas. Também será utilizado o Chatfuel, ferramenta para a criação de chatbots, para que
clientes possam interagir com o sistema através de mensagens automáticas.
2.1 Abrangência e sistemas relacionados
O Barber Solutions possibilitará cadastrar clientes, produtos, serviços, barbeiros, vendas realizadas e permitir o agendamento de serviços. Além de dispor de um relatório para total gerenciamento de uma barbearia.
Nesta primeira versão, não será realizado a autênticação de barbeiros e sim apenas do gerente da barbearia. Além de não ser possível escolher datas específicas para a geração do relatório, tendo somente como opção, o dia, mês e ano atual. Essas funcionalidades serão desenvolvidas no decorrer das próximas versões.
O sistema irá interagir com a Agenda do Google com a intenção de possibilitar a visualização das agendas de cada barbeiro, agilizando o processo de consulta de horários disponíveis, e agendamento de serviços. Também ira interagir com o Chatfuel, onde cliente a partir do chatbot desenvolvido, poderão agendar serviços e consultar serviços agendados.
2.2 Descrição do cliente
Rock Mustache Barbearia é uma barbearia há 3 anos no mercado que remonta aos anos 60 com um ambiente clássico marcante nas antigas barbearias. Junto a isso se alinha produtos e serviços que agradam a geração de hoje. Como venda e cervejas e produtos de beleza voltados para o mercado masculino.
79
2.3 Descrição dos usuários
Os usuários do sistema enfrentam dificuldade devido ao fato de o gerenciamento da barbearia ser realizado com papel e caneta, assim o sistema busca facilitar ações dos seguintes usuários: (i) gerente da barbearia, (ii) barbeiros e (iii) clientes.
Gerente da barbearia:Possui acesso a todas as funcionalidades do sistema;
Chatbot: Possui acesso a funcionalidade de agendar e consultar serviços agendados.;
Cliente: Acesso ao sistema através do chatbot.
<Forneça o propósito do requisito funcional de forma clara e abrangendo todas as funcionalidades que serão construídas. Em seguida, assinale um dos símbolos abaixo para indicar a prioridade do requisito>
3. Requisitos funcionais
3.1 Requisitos do módulo Servidor
[RF1] Cadastrar barbeiro
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Para cadastrar um barbeiro deverá ser preenchido os campos presentes na tabela 1.
Tabela 1 – Campos para cadastramento de um barbeiro
Nome do Campo Descrição do Campo
*Nome
*Comissão por Serviço A comissão por serviço deverá ser em
porcentagem, ou seja, de 0 a 100.
*Comissão por Venda A comissão por venda deverá ser em valor em
dinheiro.
*Dia de Folga Deverá ser escolhido um dia da semana como
folga do barbeiro.
*Status O status identificará se o barbeiro ainda está
trabalhando na barbearia (Ativo), ou se
barbeiros não trabalha mais na barbearia
(Inativo)
(*) Campos com preenchimento obrigatório.
80
Saida e pós condições: Barbeiro cadastrado.
[RF2] Alterar barbeiro
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Para alterar os dados de um barbeiro deverá ser preenchido os campos da tabela 2.
Tabela 2 – Campos para alteração de um barbeiro
Nome do Campo Descrição do Campo
*Id Campo necessário para identificar barbeiro
no sistema.
Nome
Comissão por Serviço A comissão por serviço deverá ser em
porcentagem, ou seja, de 0 a 100.
Comissão por Venda A comissão por venda deverá ser em formato
de moeda.
Dia de Folga Deverá ser escolhido um dia da semana como
folga do barbeiro.
Status O status identificará se o barbeiro ainda está
trabalhando na barbearia (Ativo), ou se
barbeiros não trabalha mais na barbearia
(Inativo)
(*) Campos com preenchimento obrigatório.
Saida e pós condições: Barbeiro alterado.
[RF3] Remover barbeiro
Ator: Gerente da barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: A remoção de uma barbeiro não excluirá o barbeiro do sistema, devido a necessidade de manter um histórico da barbearia, o barbeiro terá seu status alterado para “Inativo” para que não seja mais possível realizar agendamentos de serviços com esse barbeiro. Para que seja possível a remoçao de um barbeiro, o sistema não poderá ter nenhum horário agendado com esse barbeiro.
81
Saida e pós condições: Status do barbeiro alterado para “Inativo”.
[RF4] Visualizar barbeiro
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: A primeira listagem irá apresentar os barbeiros com status “Ativo” e ordenada alfabéticamente.
A lista poderá ser agrupada da seguinte maneira: Lista Geral, Status Ativo ou Inativo.
Em todos os agrupamentos será possível filtrar os dados pelo nome.
Saida e pós condições: Lista de barbeiros.
[RF5] Cadastrar serviço
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Para cadastrar um serviço deverá ser preenchido os campos presentes na tabela 3.
Tabela 3 – Campos para cadastramento de um serviço
Nome do Campo Descrição do Campo
*Nome
*Preço O preço deverá ser informado no formato de
moeda.
*Duração Tempo de duração para realização do serviço,
deverá ser informado em minutos.
*Descrição
*Promoção Opção para realizar promoção de serviços,
deverá ser informado um valor em
porcentagem da promocação, de 0 a 100.
*Status O status identificará se o serviço ainda é
oferecido pela barbearia (Ativo), ou se não é
mais oferecido (Inativo).
(*) Campos com preenchimento obrigatório.
Saida e pós condições: Serviço cadastrado.
82
[RF6] Alterar serviço
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Para alterar os dados de um serviço deverá ser preenchido os campos da tabela 4.
Tabela 4 – Campos para alteração de um barbeiro
Nome do Campo Descrição do Campo
*Id Campo necessário para identificar serviço no
sistema.
Nome
Preço O preço deverá ser informado no formato de
moeda.
Duração Tempo de duração para realização do serviço,
deverá ser informado em minutos.
Descrição
Promoção Opção para realizar promoção de serviços,
deverá ser informado um valor em
porcentagem da promocação, de 0 a 100.
Status O status identificará se o serviço ainda é
oferecido pela barbearia (Ativo), ou se não é
mais oferecido (Inativo).
(*) Campos com preenchimento obrigatório.
Saida e pós condições: Serviço alterado.
[RF7] Remover serviço
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: A remoção de um serviço não excluirá o serviço do sistema, devido a necessidade de manter um histórico da barbearia, o serviço terá seu status alterado para “Inativo” para que não seja mais possível realizar agendamentos para esse serviço. Para que seja possível a remoção de um serviço, o sistema não poderá ter nenhum horário agendado para a realização desse serviço.
83
Saida e pós condições: Status do serviço alterado para “Inativo”.
[RF8] Visualizar serviço
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: A primeira listagem irá apresentar os serviços com status “Ativo” e ordenada alfabéticamente.
A lista poderá ser agrupada da seguinte maneira: Lista Geral, Status Ativo ou Inativo.
Em todos os agrupamentos será possível filtrar os dados pelo nome e ordenar pelo preço ou promoção.
Saida e pós condições: Lista de serviços.
[RF9] Cadastrar produto
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Para cadastrar um produto deverá ser preenchido os campos presentes na tabela 5.
Tabela 5 – Campos para cadastramento de um produto
Nome do Campo Descrição do Campo
*Nome
*Preço O preço deverá ser informado no formato de
moeda.
*Estoque Quantidade do produto em estoque.
*Descrição
*Promoção Opção para realizar promoção de serviços,
deverá ser informado um valor em
porcentagem da promocação, de 0 a 100.
*Status O status identificará se o produto ainda é
oferecido pela barbearia (Ativo), ou se não é
mais oferecido (Inativo).
*Segmento Finalidade do produto, para “Cabelo” ou
“Barba”.
84
(*) Campos com preenchimento obrigatório.
Saida e pós condições: Produto cadastrado.
[RF10] Alterar produto
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Para alterar os dados de um produto deverá ser preenchido os campos da tabela 6.
Tabela 6 – Campos para alteração de um produto
Nome do Campo Descrição do Campo
*Id Campo necessário para identificar produto no
sistema.
Nome
Preço O preço deverá ser informado no formato de
moeda.
Estoque Quantidade do produto em estoque.
Descrição
Promoção Opção para realizar promoção de serviços,
deverá ser informado um valor em
porcentagem da promocação, de 0 a 100.
Status O status identificará se o produto ainda é
oferecido pela barbearia (Ativo), ou se não é
mais oferecido (Inativo).
Segmento Finalidade do produto, para “Cabelo” ou
“Barba”.
(*) Campos com preenchimento obrigatório.
Saida e pós condições: Produto alterado.
[RF11] Remover produto
Ator: Gerente da Barbearia
Prioridade: Essencial Importante Desejável
85
Entrada e pré condições: A remoção de um produto não excluirá o produto do sistema, devido a necessidade de manter um histórico da barbearia, o serviço terá seu status alterado para “Inativo” para que não seja mais possível realizar vendas deste produto.
Saida e pós condições: Status do produto alterado para “Inativo”.
[RF12] Visualizar produto
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: A primeira listagem irá apresentar os produtos com status “Ativo”, ordenada alfabéticamente e de todos os segmentos.
A lista poderá ser agrupada da seguinte maneira:
Lista geral de produtos (Todos segmentos e status);
Lista por segmento, independe de status;
Lista por status, independe do segmento;
Lista de segmento com status “Ativo”;
Lista de segmento com status “Inativo”.
Em todos os agrupamentos será possível filtrar os dados pelo nome e ordenar pelo preço ou promoção.
Saida e pós condições: Lista de serviços.
[RF13] Cadastrar cliente
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Para cadastrar um cliente deverá ser preenchido os campos presentes na tabela 7.
Tabela 7 – Campos para cadastramento de um cliente
Nome do Campo Descrição do Campo
*Nome
*Telefone
Id do Chatfuel Caso o cliente utilize o chatbot deverá ser
salvo o id que o Chatfuel provê para cada
usuário.
86
*Data de nascimento
*Data da realização do cadastro
*Status O status identificará se o cliente foi removido
(Inativo) ou não (Ativo).
(*) Campos com preenchimento obrigatório.
Saida e pós condições: Cliente cadastrado.
[RF14] Alterar cliente
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Para alterar os dados de um cliente deverá ser preenchido os campos da tabela 8.
Tabela 8 – Campos para alteração de um cliente
Nome do Campo Descrição do Campo
*Id Campo necessário para identificar cliente no
sistema.
Nome
Telefone
Id do Chatfuel Caso o cliente utilize o chatbot deverá ser
salvo o id que o Chatfuel provê para cada
usuário.
Data de nascimento
Data da realização do cadastro
Segmento Finalidade do produto, para “Cabelo” ou
“Barba”.
(*) Campos com preenchimento obrigatório.
Saida e pós condições: Cliente alterado.
[RF15] Remover cliente
Ator: Gerente da Barbearia.
87
Prioridade: Essencial Importante Desejável
Entrada e pré condições: A remoção de um cliente não excluirá o cliente do sistema, devido a necessidade de manter um histórico da barbearia, o cliente terá seu status alterado para “Inativo” para que não seja mais possível realizar vendas e agendar horários para esse cliente.
Saida e pós condições: Status do cliente alterado para “Inativo”.
[RF16] Visualizar cliente
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: A primeira listagem irá apresentar os clientes com status “Ativo”, ordenada alfabéticamente.
A lista poderá ser agrupada da seguinte maneira: Lista Geral, Status Ativo ou Inativo.
Em todos os agrupamentos será possível filtrar os dados pelo nome.
Saida e pós condições: Lista de clientes.
[RF17] Realizar controle de horas disponíveis
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Controlar as horas diponíveis é de extrema importancia para o funcionamento de uma barbearia. Deverá ser realizado um controle para evitar conflitos de horários disponiveis ao agendar um serviço.
Saida e pós condições: Controle de horas disponíveis.
[RF18] Agendar serviço
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Para agendar um serviço deverá ser preenchido os campos presentes na tabela 9.
Tabela 9 – Campos para agendamento de serviço
88
Nome do Campo Descrição do Campo
*Data e hora do inicio do atendimento
*Data e hora do fim do atendimento
*Id do barbeiro Id do barbeiro para identificar qual barbeiro
irá realizar o serviço
*Id do cliente Id do cliente para identificar qual cliente
agendou o serviço.
*Forma de atendimento Poderá ser: “Local”, “Telefone”, “Chatbot”,
“Outro”. Caso seja escolhida a opção
“Outro”, deverá ser informado como foi
agendado.
**Forma de pagamento Poderá ser: “Dinheiro”, “Crédito” ou
“Débito”.
*Serviços Serviços escolhidos para o agendamento.
*Status Poderá ser: “Aberto” ou “Realizado”.
(*) Campos com preenchimento obrigatório.
(**) Campo deverá ser preenchido caso status seja “Realizado”.
Saida e pós condições: Serviço agendado.
[RF19] Alterar serviço agendado
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Para alterar os dados de um agendamento deverá ser preenchido os campos da tabela 10.
Tabela 10 – Campos para alterar um serviço agendado
Nome do Campo Descrição do Campo
*Id Campo necessário para identificar um
serviço agendado no sistema.
Data e hora do inicio do atendimento
Data e hora do fim do atendimento
Id do barbeiro Id do barbeiro para identificar qual barbeiro
irá realizar o serviço
Id do cliente Id do cliente para identificar qual cliente
agendou o serviço.
89
Forma de atendimento Poderá ser: “Local”, “Telefone”, “Chatbot”,
“Outro”. Caso seja escolhida a opção
“Outro”, deverá ser informado como foi
agendado.
**Forma de pagamento Poderá ser: “Dinheiro”, “Crédito” ou
“Débito”.
Serviços Serviços escolhidos para o agendamento.
Status Poderá ser: “Aberto” ou “Realizado”.
(*) Campos com preenchimento obrigatório.
(**) Campo deverá ser preenchido caso status seja “Realizado”.
Saida e pós condições: Serviço agendado alterado.
[RF20] Cancelar serviço agendado
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Será necessário informar o Id do serviço agendado para que possa ser removido do sistema.
Saida e pós condições: Serviço agendado cancelado e será liberado o horário para novos
agendamentos.
[RF21] Visualizar serviço agendado
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: A primeira listagem irá apresentar os agendamentos com status “Aberto”, ordenada pela data.
A lista poderá ser agrupada da seguinte maneira: Lista Geral, Status Aberto ou Realizado.
Em todos os agrupamentos será possível filtrar os dados pelo nome do cliente e ordenar pelo barbeiro, cliente, data ou serviço.
Saida e pós condições: Lista de serviços agendados.
[RF22] Realizar venda
Ator: Gerente da Barbearia.
90
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Para realizar uma venda deverá ser preenchido os campos presentes na tabela 11.
Tabela 11 – Campos para realizar uma venda
Nome do Campo Descrição do Campo
*Data da venda Data em que foi realizado a venda.
*Data de registro Data em que foi registrado no sistema a
venda.
*Id do barbeiro Id do barbeiro para identificar qual barbeiro
realizou a venda.
*Id do cliente Id do cliente para identificar qual cliente fez
a compra.
*Forma de pagamento Poderá ser: “Dinheiro”, “Crédito” ou
“Débito”.
*Produtos Produtos que foram vendidos.
(*) Campos com preenchimento obrigatório.
Saida e pós condições: Serviço agendado.
[RF23] Alterar venda
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Para alterar os dados de uma venda deverá ser preenchido os campos da tabela 12.
Tabela 12 – Campos para alterar uma venda
Nome do Campo Descrição do Campo
*Id Campo necessário para identificar uma venda
no sistema.
Data da venda Data em que foi realizado a venda.
Data de registro Data em que foi registrado no sistema a
venda.
Id do barbeiro Id do barbeiro para identificar qual barbeiro
realizou a venda.
91
Id do cliente Id do cliente para identificar qual cliente fez
a compra.
Forma de pagamento Poderá ser: “Dinheiro”, “Crédito” ou
“Débito”.
Produtos Produtos que foram vendidos.
(*) Campos com preenchimento obrigatório.
Saida e pós condições: Venda alterada.
[RF24] Cancelar venda
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Será necessário informar o Id da venda para realizar o cancelamento.
Saida e pós condições: Venda cancelada e deverá ser atualizado o estoque do(s) produto(s).
[RF25] Visualizar venda
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: A primeira listagem irá apresentar as venda ordenadas pela data.
A lista poderá ser agrupada da seguinte maneira: Produtos, Barbeiros ou Clientes.
Em todos os agrupamentos será possível filtrar os dados pelo nome do cliente, nome do barbeiro e produto e ordenar pelo barbeiro, cliente, data ou produto.
Saida e pós condições: Lista de vendas.
[RF26] Realizar autenticação
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Para realizar o login deverá ser informado email e senha.
Saida e pós condições: Ator autenticado e todas as funcionalidades disponíveis.
92
[RF27] Integrar com API da Agenda do Google
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Deverá ser realizado a integração com a API da Agenda do Google. Assim, todas os serviços agendados deverão estar presentes como eventos na Agenda do Google.
A Agenda do Google irá prover a parte visual da agenda de cada barbeiro.
Saida e pós condições: Agenda de cada barbeiro atualizada de acordo com os serviços
agendados.
[RF28] Gerar relatório dos serviços realizado
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Deverá prover informações da quantidade total de serviços realizados e a quantidade de serviços realizados por serviço.
Saida e pós condições: Dados sobre serviços realizados.
[RF29] Gerar relatório das vendas realizadas
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Deverá prover informações da quantidade total de vendas realizadas e a quantidade de vendas realizadas por produtos.
Saida e pós condições: Dados sobre vendas realizadas.
[RF30] Gerar relatório da forma de pagamento
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
93
Entrada e pré condições: Deverá agrupar serviços realizados e vendas realizadas pela forma de pagamento e prover a quantidade por cada forma de pagamento.
Saida e pós condições: Dados sobre a forma de pagamento.
[RF31] Gerar relatório da forma de agendamento
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Deverá agrupar serviços realizados pela forma de agendamento e prover a quantidade por cada forma de agendamento.
Saida e pós condições: Dados sobre a forma de agendamento.
[RF32] Gerar relatório de serviços e vendas por barbeiro
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Deverá prover a quantidade de vendas realizadas e a quantidade total de serviços realizados e a quantidade por serviço.
Saida e pós condições: Dados de vendas e serviços realizados por barbeiro.
[RF33] Gerar relatório financeiro da barbearia
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Deverá prover a receita total da barbearia e a receita provenientes dos serviços e vendas.
Saida e pós condições: Dados financeiros da barbearia.
[RF34] Gerar relatório financeiro por barbeiro
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
94
Entrada e pré condições: Deverá prover as comissões referentes a serviço e venda porbarbeiro.
Saida e pós condições: Dados de comissões para barbeiros.
[RF35] Desenvolver API de integração
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: A API deve permitir acesso a todas as funcionalidades apresentadas nos requisitos anteriores.
Saida e pós condições: URLs para acessar as funcionalidades do sistema.
3.2 Requisitos do módulo Chatbot
[RF36] Desenvolver ciclo de diálogo do chatbot
Atores: Gerente da Barbearia e Cliente.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Foi decidido um ciclo de diálogo para que possa ser possível o agendamento de serviços de forma automática. O ciclo deverá apresentar opções de resposta prontas ao usuário para agilizar o agendamento e evitar erros de comunicação. O ciclo de agendamento de serviços pelo chatbot é apresenado a seguir:
Chatbot Usuário
Bem vindo a Rock Mustache Barbearia.
Somos uma barbearia clássica. Estamos a 3 anos no mercado masculino. Não trabalhamos com nenhuma química para cabelo ou barba.
Para começar o agendamento do seu horário, precisamos fazer um breve cadastro em nosso sistema. São apenas 2 passos. Vamos prosseguir?
Não. ou Sim!
Ótimo. Será uma prazer atendê-lo.
Por favor, digite seu e-mail.
95
Agora seu telefone com DDD
35 9 9999 8855
Obrigado. Seus dados estão corretos? E-mail: [email protected]
Telefone: 35999998855
Não (negativo) Sim! (like)
Um momento, por favor.
Cadastro realizado com sucesso.
(Nome), como podemos te ajudar hoje?
Opções: (Marcar horário), (Desmarcar horário), (Consultar horário)
Escolher opção
Ok, vamos começar!
Opções: (Cabelo), (Barba) e (Acabamento)
Escolher opção
Mais algum?
Opções: (Não), (Cabelo), (Barba) e (Acabamento)
Escolher opção
Ecolha o barbeiro de sua preferência.
Opções: Barbeiros
Escolher opção
Qual dia você prefere?
Opções: (datas em até 1 semana a frente)
Escolher opção
Qual horário?
Opções: Horários disponíveis
Escolher opção
Beleza! Vamos confirmar?
Dia:01/04, as 18hrs. Cabelo e barba com o barbeiro Danilo.
Correto?
Opções: Não. Sim!
Escolher opção
Marcado para você (NOME). Se desejar fazer alguma alteração por aqui mesmo, basta voltar e escrever: Bom dia, Boa tarde
96
ou Boa noite. Agora se quiser entrar em contato via telefone, nossos números são: 35 3621 6349 e 35 9 9761 3502.
Aguardamos sua visita! Obrigado pela preferência.
[RF37] Integrar chatbot com API desenvolvida
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Todas as informações que o chatbot apresentar ao ator deverá estar de acordo e em sicronismo com as informações do sistema desenvolvido. Devido a isso deve integrar o chatbot com a API do sistema para requisitar os dados necessário.
Saida e pós condições: Ações possíveis com o chatbot em sincronismo com o sistema.
3.3 Requisitos do módulo Aplicação Web
[RF38] Desenvolver tela principal
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
A tela principal deverá espelhar a Agenda do Google. Assim, sendo possível visualizar as agendas de cada barbeiro.
[RF39] Desenvolver tela de serviços agendados
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
A tela de serviços agendados irá apresentar a lista de serviços agendados no sistema proveniente da API do módulo Servidor, além de possuir opções de agendar serviço, alterar serviço, cancelar serviço.
[RF40] Desenvolver tela de clientes
Ator: Gerente da Barbearia.
97
Prioridade: Essencial Importante Desejável
A tela de clientes irá apresentar a lista de clientes cadastrados no sistema proveniente da API do módulo Servidor, além de possuir opções de cadastrar novo cliente, alterar cliente, remover cliente.
[RF41] Desenvolver tela de produtos
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
A tela de produtos irá apresentar a lista de produtos cadastrados no sistema proveniente da API do módulo Servidor, além de possuir opções de cadastrar novo produto, alterar produto, remover produto.
[RF42] Desenvolver tela de barbeiros
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
A tela de barbeiros irá apresentar a lista de barbeiros cadastrados no sistema proveniente da API do módulo Servidor, além de possuir opções de cadastrar novo barbeiro, alterar barbeiro, remover barbeiro.
[RF43] Desenvovler tela de serviços
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
A tela de serviços irá apresentar a lista de serviços cadastrados no sistema proveniente da API do módulo Servidor, além de possuir opções de cadastrar novo serviço, alterar serviço, remover serviço.
[RF44] Desenvolver tela de relatório
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
A tela de relatório irá agrupar todas as informações fornecidas pelo módulo Servidor em relação a relatório.
98
Informações financeiras deverão ser apresentadas com título e valor em formato de moeda. Demais informações deverão ser apresentadas em gráficos de barras para facilitar a análise.
[RF45] Integrar com API do módulo Servidor
Ator: Gerente da Barbearia.
Prioridade: Essencial Importante Desejável
Entrada e pré condições: Todas as informações que a aplicação web apresentar ao ator deverá estar de acordo e em sicronismo com as informações do sistema desenvolvido. Devido a isso deve integrar a aplicação web com a API do sistema para requisitar os dados necessário.
Saida e pós condições: Ações possíveis com a aplicação web em sincronismo com o sistema
4. Requisitos não funcionais
4.1 Usabilidade
1. Garantir boa experiência de usuário
Interface não deve apresentar congelamentos de telas ao fazer requisições ao servidor.
Prioridade: Essencial Importante Desejável
4.2 Confiabilidade
2. Garantir disponibilidade do sistema em 99%
Sistema é essencial para o funcionamento do negócio, assim deverá estar disponível em 99% do tempo.
4.3 Desempenho
3. Requisições com tempo de resposta de no máximo 5 segundos
Tempo de espera de resposta da API de no máximo 5 segundos.
4.4 Segurança
4. Realizar autenticação
99
Usuário que tentar usar a aplicação web deverá realizar uma autenticação com login e senha, e ao tentar utilizar o chatbot, seu id deverá pertencer a um cliente já cadastradono sistema, se não houver será necessário o usuário se cadastrar ou confirmar cadastro.
100
APÊNDICE C – TAREFAS PROPOSTAS
Tarefa 1 – Agendar um horário
Suponha que você quer agendar um horário. Siga as instruções a seguir.
1. Na tela de horários agendados clique no botão, agendar um horário.
2. Forneça os dados necessários (barbeiro, cliente, serviços, dia e hora).
3. Agende o serviço.
Tarefa 2 – Realizar uma venda
Suponha que você quer realizar uma venda. Siga as instruções a seguir.
1. Na tela de produtos, clique no botão realizar venda.
2. Forneça os dados necessários (barbeiro, cliente, produtos, quantidade de cada produto
e data).
3. Realize a venda.
101
APÊNDICE D – QUESTIONÁRIO SOBRE AS TAREFAS
Legenda:
1. Discordo totalmente
2. Discordo parcialmente
3. Indiferente
4. Concordo parcialmente
5. Concordo totalmente
As informações apresentadas na tela são de fácil entendimento?
( ) 1 ( ) 2 ( ) 3 ( ) 4 ( ) 5
Foi fácil executar as tarefas?
( ) 1 ( ) 2 ( ) 3 ( ) 4 ( ) 5
Os botões das funcionalidades do sistema estavam intuitivos?
( ) 1 ( ) 2 ( ) 3 ( ) 4 ( ) 5
A tarefa executada foi simples?
( ) 1 ( ) 2 ( ) 3 ( ) 4 ( ) 5
A tarefa foi realizada rapidamente?
( ) 1 ( ) 2 ( ) 3 ( ) 4 ( ) 5
Foi possível realizar a tarefa sem cometer erros?
( ) 1 ( ) 2 ( ) 3 ( ) 4 ( ) 5
Caso tenha ocorrido algum erro, foi fácil corrigi-lo?
( ) 1 ( ) 2 ( ) 3 ( ) 4 ( ) 5
Você executaria a tarefa novamente?
( ) 1 ( ) 2 ( ) 3 ( ) 4 ( ) 5
102
É fácil lembrar como realizar a tarefa?
( ) 1 ( ) 2 ( ) 3 ( ) 4 ( ) 5
Fui intuitivo realizar a tarefa?
( ) 1 ( ) 2 ( ) 3 ( ) 4 ( ) 5
Você se sentiu satisfeito com o sistema?
( ) 1 ( ) 2 ( ) 3 ( ) 4 ( ) 5
A interface agradou?
( ) 1 ( ) 2 ( ) 3 ( ) 4 ( ) 5
Usario o sistema novamente?
( ) 1 ( ) 2 ( ) 3 ( ) 4 ( ) 5
