Nuki's Brechó: Sistema Colaborativo em um Cenário de Moda Sustentável - Anuska Kepler Rehn

UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE SISTEMAS DE INFORMAÇÃO – BACHARELADO
NUKI’S BRECHÓ: SISTEMA COLABORATIVO EM UM
CENÁRIO DE MODA SUSTENTÁVEL
ANUSKA KEPLER REHN
BLUMENAU
2022

ANUSKA KEPLER REHN
NUKI’S BRECHÓ: SISTEMA COLABORATIVO EM UM
CENÁRIO DE MODA SUSTENTÁVEL
Trabalho de Conclusão de Curso apresentado
ao curso de graduação em Sistemas de
Informação do Centro de Ciências Exatas e
Naturais da Universidade Regional de
Blumenau como requisito parcial para a
obtenção do grau de Bacharel em Sistemas de
Informação.
Profa. Simone Erbs da Costa, Mestre - Orientador
BLUMENAU
2022

Esta página deverá ser substituída pela folha
de assinaturas entregue na Banca.
Digitalize a folha e cole aqui para a entrega da
versão final do TCC.
Atenção: não ultrapasse as margens!

Dedico este trabalho a todas as pessoas que
passam suas vidas sendo escravizadas para
suprir as demandas da moda rápida.

AGRADECIMENTOS
A conclusão com sucesso deste trabalho só foi possível graças às contribuições de
diversas pessoas. No início do desenvolvimento deste trabalho ele foi consagrado a Cristo,
agradeço a Ele que me ajudou a chegar até aqui e me capacitou para desenvolver cada
funcionalidade do sistema e cada página desta monografia e colocando as melhores pessoas
ao meu lado nesta jornada.
Aos meus avós e meus pais que durante muitos anos custearam meus estudos desde
pequena, sempre me ajudaram com postagens de encomendas e demais logísticas relacionadas
ao Nuki’s e sempre me incentivaram a empreender e concluir minha graduação.
Ao meu namorado Filipe Veber, que apoiou este sonho desde o início e ajudou a
construí-lo junto comigo durante madrugadas de ajuda com problemas de programação e
ideias, me acalmando e fazendo o possível para que tudo desse certo e dentro dos prazos.
Aos meus professores da Universidade que sempre me impulsionaram, especialmente
minha orientadora Simone Erbs que se dedicou ao máximo em me auxiliar e professor
Alexander Valdameri que tirou diversas dúvidas e me auxiliou ao longo do percurso.
E por último mas não menos importante, a cada cliente que algum dia já comprou no
Nuki’s Brechó e acreditou neste sonho da Anuska de 16 anos de idade que persistiu com o
empreendimento Nuki’s Brechó e tomou a iniciativa de iniciar o sistema como trabalho de
conclusão de curso.

E conhecereis a verdade, e a verdade vos
libertará.
João 8:32

RESUMO
Este trabalho apresenta o levantamento de informações, pesquisas, especificação,
desenvolvimento e operacionalidade do sistema colaborativo desenvolvido para possibilitar a
venda de roupas usadas por meio de um comércio eletrônico. O objetivo principal do trabalho
é o desenvolvimento de um comércio eletrônico colaborativo e, como principal motivação e
propósito do trabalho, a premissa de colaborar com a moda lenta, que diferentemente da moda
rápida, não escraviza pessoas nem prejudica mais o meio ambiente, pois as peças já foram
produzidas. Para o desenvolvimento do comércio eletrônico, o back end do sistema teve a
finalidade de gerar a autenticação do usuário cadastrado via token e foi feito na linguagem de
programação CSharp usando banco de dados Postgres. O front end foi implementado
utilizando a framework Angular com o auxílio da biblioteca Ng-zorro, e, a maior parte dos
dados utilizados é via mock em JavaScript Object Notation (JSON) puro simulando uma
Application Programming Interface (API). O levantamento de informações foi feito por
buscas na literatura sobre brechós, poluição e escravidão da indústria da moda, Design
Thinking e Modelo 3C de Colaboração. A fim de alcançar resultados mais precisos foi
realizada uma oficina de Design Thinking e utilizado o Método Relationship of M3C with
User Requirements and Usability and Communicability Assessment in groupware
(RURUCAg). O Método RURUCAg foi usado para confirmar se os objetivos foram atingidos
e analisar e avaliar a usabilidade, a comunicabilidade e a experiência do usuário das interfaces
desenvolvidas e de suas funcionalidades. A partir dos resultados alcançados por meio da
avaliação foi possível identificar que os objetivos do trabalho foram atingidos, além de
levantar melhorias futuras.
Palavras-chave: Brechó. Design Thinking. Método RURUCAg. Modelo 3C de Colaboração.
Moda lenta.

ABSTRACT
This paper contains the information gathering, researches, specification, development and
application’s developed operationality in order to have a thrift shop website developed with
the purpose of having used clothes selling through an e-commerce. This paper’s main goal is
to develop the website to be collaborative, and the main motivation to the paper is to
collaborate with the slow fashion system, that apart from the fast fashion industry, it doesn’t
make slaves nor injures the environment, since the products were already fabricated. To
develop this website, the back end was made to generate authentication using token and
maintain the users and was developed in CSharp programming language using Postgres
database. The front end was developed using the Angular framework along with the NgZorro
visual library, and the most significant part of the website data is from a JavaScript Object
Notation (JSON) API mocked. The information gathering to develop this paper was made by
literature researches about thrift shops, pollution and slavering caused by the fashion industry,
Design Thinking and 3C Collaboration model. In order to reach more accurate results to
develop the website, a Design Thinking workshop was held and the Relationship of M3C with
User Requirements and Usability and Communicability Assessment in groupware
(RURUCAg) method was applied. The RURUCAg method was used to check if the goals
were reached and to analyze the usability, communicability and the user’s experience within
the developed interfaces and its functionalities. With the rating results reached by the
evaluation results was possible to see that the paper’s goals were reached, and it was possible
to obtain future improvements for the website.
Key-words: Thrift shop. Design Thinking. RURUCAg method. 3C Collaboration model.
Slow fashion.

LISTA DE FIGURAS
Figura 1 - Modelo 3C de Colaboração .....................................................................................21
Figura 2 - Fases do Design Thinking........................................................................................22
Figura 3 - Página inicial do Enjoei (a) e barra lateral (b).........................................................24
Figura 4 - Tela de produto à venda...........................................................................................25
Figura 5 - Busca e filtro de produto..........................................................................................26
Figura 6 - Produto à venda (a) e filtro por tipo de produto (b).................................................27
Figura 7 - Interfaces de informações de ambiente (a, b) e Coordenador (c) ............................29
Figura 8 - Resultado da pergunta sobre experiências negativas em lojas virtuais ..................32
Figura 9 - Resultado da pergunta sobre experiências positivas em lojas virtuais ....................32
Figura 10 - Mural com resultados da atividade de Persona da oficina de DT..........................33
Figura 11 - Construção do Mapa de Jornada do Usuário para a oficina de DT .......................34
Figura 12 - Mapas mentais elaborados pelos participantes da oficina de DT ..........................34
Figura 13 - Atividade e votação do Mapa de Ideias da oficina de DT.....................................35
Figura 14 - Atividade de Prototipação e Mapa de Calor da oficina de DT ..............................36
Figura 15 - Diagrama de caso de uso do sistema .....................................................................39
Figura 16 - Diagrama de Atividades.........................................................................................40
Figura 17 - Modelo de persistência de dados estruturado ........................................................41
Figura 18 - Modelo de Entidade e Relacionamento back end..................................................42
Figura 19 - Esquema de tecnologias utilizadas no Nuki's Brechó............................................45
Figura 20 - Diagrama de implantação ......................................................................................46
Figura 21 - Tela inicial para usuários não autenticados ...........................................................49
Figura 22 - Tela de produto para usuários não autenticados ....................................................50
Figura 23 -Tela de login ...........................................................................................................50
Figura 24 - Tela de cadastro de usuário para login...................................................................51
Figura 25 - Tela de login por e-mail e senha............................................................................52
Figura 26 - Tela inicial usuário autenticado .............................................................................53
Figura 27 - Tela de perfil..........................................................................................................54
Figura 28 - Telas de notificações (a) e pedidos do usuário (b) sem informações ....................55
Figura 29 - Tela de produto para usuário autenticado..............................................................56
Figura 30 - Tela de compra.......................................................................................................57
Figura 31 - Tela de confirmação de compra.............................................................................57

Figura 32 - Tela meus pedidos .................................................................................................58
Figura 33 -Tela de ajuda e avaliações ......................................................................................59
Figura 34 - Tela de notificações ...............................................................................................60
Figura 35 -Tela de produto para administrador........................................................................61
Figura 36 - Tela de gerenciamento de usuários........................................................................62
Figura 37 - Tela de cadastro de usuários..................................................................................63
Figura 38 - Identificação: faixa etária (a); sexo (b) e uso de sistema de brechó (c).................65
Figura 39 - Figuras emotivas na escala Likert (1-4) para responder afirmações positivas (a) e
afirmações negativas (b)........................................................................................67
Figura 40 - Descrição das expressões de comunicabilidade.....................................................73
Figura 41 - Resultado da pergunta 1 sobre o público-alvo.......................................................83
Figura 49 - Resultado da pergunta de faixa etária..................................................................120
Figura 50 - Resultado da pergunta de sexo.............................................................................120
Figura 51 - Resultado da pergunta de uso de sistema de brechó............................................121
Figura 52 - Resultado da pergunta referente ao status atual do sistema.................................121
Figura 53 - Resultado da pergunta referente à localização no sistema...................................121
Figura 54 - Resultado da pergunta referente à compra no sistema.........................................122
Figura 55 - Resultado da pergunta referente à ações realizadas.............................................122
Figura 56 - Resultado da pergunta referente à Coordenação no gerenciamento de usuários.122
Figura 57 - Resultado da pergunta referente à Coordenação de responder perguntas ...........123
Figura 58 - Resultado da pergunta referente à Comunicação com notificações ....................123
Figura 59 - Resultado da pergunta referente à Comunicação com perguntas e respostas......123
Figura 60 - Resultado da pergunta referente à Cooperação com avaliações..........................124
Figura 61 - Resultado da pergunta referente à linguagem utilizada.......................................124
Figura 62 - Resultado da pergunta referente à ordem cronológica do sistema.......................124
Figura 63 - Resultado da pergunta referente a voltar nas ações anteriores ............................125
Figura 64 - Resultado da pergunta referente ao retorno à tela inicial.....................................125

Figura 65 - Resultado da pergunta referente ao padrão de escrita..........................................125
Figura 66 - Resultado da pergunta referente ao padrão de elementos visuais........................126
Figura 67 - Resultado da pergunta referente à facilidade das perguntas e respostas..............126
Figura 68 - Resultado da pergunta referente à facilidade das avaliações do sistema.............126
Figura 69 - Resultado da pergunta referente à clareza dos botões .........................................127
Figura 70 - Resultado da pergunta referente à dificuldade de usar o sistema ........................127
Figura 71 - Resultado da pergunta referente à prevenção de erros na navegação..................127
Figura 72 - Resultado da pergunta referente às mensagens de confirmação..........................128
Figura 73 - Resultado da pergunta referente ao reconhecimento das funções do sistema .....128
Figura 74 - Resultado da pergunta referente ao reconhecimento do propósito do sistema....128
Figura 75 - Resultado da pergunta referente à simplicidade do propósito do sistema ...........129
Figura 76 - Resultado da pergunta referente aos filtros rápidos.............................................129
Figura 77 - Resultado da pergunta referente à experiência com a interface...........................129
Figura 78 - Resultado da pergunta referente à fluidez no uso do sistema..............................130
Figura 79 - Resultado da pergunta referente à objetividade das informações em tela ...........130
Figura 80 - Resultado da pergunta referente às cores utilizadas no sistema ..........................130
Figura 81 - Resultado da pergunta referente às mensagens de erros dos campos em
formulários...........................................................................................................131
Figura 82 - Resultado da pergunta referente às mensagens e situações do sistema ...............131
Figura 83 - Resultado da pergunta referente à informações na tela de compra......................131
Figura 84 - Resultado da pergunta referente à clareza das instruções, ações e opções do
sistema .................................................................................................................132
Figura 85 - Resultado da pergunta referente às informações na tela de login e criação de conta
.............................................................................................................................132
Figura 86 - Resultado da pergunta referente às informações na tela de produto....................132
Figura 87 - Resultado da pergunta referente às informações na tela de perfil .......................133
Figura 88 - Resultado da pergunta de comunicabilidade referente à coordenação com
gerenciamento de usuários...................................................................................133
Figura 89 - Resultado da pergunta de comunicabilidade referente à coordenação de responder
perguntas..............................................................................................................133
Figura 90 - Resultado da pergunta de comunicabilidade referente à perguntas e respostas e
notificações..........................................................................................................134
Figura 91 - Resultado da pergunta de comunicabilidade referente à cooperação com
avaliações do sistema...........................................................................................134

Figura 92 - Resultado da pergunta de comunicabilidade referente ao uso do sistema...........134
Figura 93 -Resultado da pergunta referente à reutilização do sistema...................................136
Figura 94 - Resultado da pergunta referente à recomendação do sistema..............................136

LISTA DE QUADROS
Quadro 1 - Requisitos Funcionais ............................................................................................37
Quadro 2 - Requisitos Não Funcionais.....................................................................................37
Quadro 3 - Regras de Negócio .................................................................................................37
Quadro 4 - Matriz de rastreabilidade dos RF com os UC referente ao sistema .......................39
Quadro 5 - Matriz de rastreabilidade entre UC e RF aplicados ao M3C de Colaboração........39
Quadro 6 - Codificação para usuários enviarem perguntas em produtos.................................47
Quadro 7 - Codificação para administradores responderem perguntas em produtos...............47
Quadro 8 - Codificação para administradores visualizarem todos os usuários cadastrados ....48
Quadro 9 - Codificação para consulta da média de avaliações do sistema ..............................48
Quadro 10 - Relação das afirmações x Heurísticas de Nielsen ................................................66
Quadro 11 – Comparativo dos correlatos perante o trabalho desenvolvido.............................75
Quadro 12 - Introdução ao questionário de público-alvo.........................................................83
Quadro 13 - Apresentação utilizada na oficina de Design Thinking........................................88
Quadro 14 - Termo de Consentimento para fotografias...........................................................99
Quadro 15 - Estrutura de dados AdminNotifications..................................................100
Quadro 16 - Estrutura de dados Stars.................................................................................100
Quadro 17 - Estrutura de dados Product ............................................................................101
Quadro 18 - Estrutura de dados Chat....................................................................................101
Quadro 19 - Estrutura de dados OrderProduct ................................................................101
Quadro 20 - Estrutura de dados Notification ................................................................102
Quadro 21 - Estrutura de dados Orders...............................................................................102
Quadro 22 - Estrutura de dados User....................................................................................103
Quadro 23 - Estrutura de dados Address ............................................................................103
Quadro 24 - TCLE..................................................................................................................104
Quadro 25 - Introdução ao roteiro de avaliação .....................................................................106
Quadro 26 - Roteiro de avaliação...........................................................................................106
Quadro 27 - Resultado da pergunta descritiva referente ao que mais gostou no sistema.......135
Quadro 28 - Resultado da pergunta descritiva referente ao que menos gostou no sistema....135
Quadro 29 - Heurísticas de Nielsen........................................................................................137

LISTA DE TABELAS
Tabela 1 - Facilidade de uso e compreensão do sistema ..........................................................68
Tabela 2 - Componentes visuais do sistema.............................................................................69
Tabela 3 - Prevenção de erros e performance...........................................................................70
Tabela 4 - Funções do sistema relacionadas ao M3C...............................................................70
Tabela 5 - Relação das Heurísticas com os problemas encontrados ........................................71
Tabela 6 - Resultado da avaliação de comunicabilidade pelo Método RURUCAg.................73
Tabela 7 - Reutilização e recomendação do sistema ................................................................75

LISTA DE ABREVIATURAS E SIGLAS
API – Application Programming Interface
CDN – Content Delivery Network
CO2 – Dióxido de carbono
DCU – Diagrama de Caso de Uso
DT – Design Thinking
FURB – Fundação Universidade Regional de Blumenau
HTML – HyperText Markup Language
IDE – Integrated Development Environment
JSON – JavaScript Object Notation
LESS – Leaner Style Sheets
MER – Modelo de Entidade e Relacionamento
M3C – Modelo 3C de Colaboração
PHP – Hypertext PreProcessor
RF – Requisitos Funcionais
RN – Regras de Negócio
RNF – Requisitos Não Funcionais
RURUCAg – Relationship of M3C with User Requirements and Usability and
Communicability Assessment in groupware, ver M3C
SC – Sistemas Colaborativos
UC – Use Case
UML – Unified Modeling Language

SUMÁRIO
1 INTRODUÇÃO..................................................................................................................17
1.1 OBJETIVOS......................................................................................................................17
1.2 ESTRUTURA....................................................................................................................18
2 FUNDAMENTAÇÃO TEÓRICA....................................................................................19
2.1 BRECHÓ E SUSTENTABILIDADE ...............................................................................19
2.2 SISTEMAS COLABORATIVOS E O MODELO 3C DE COLABORAÇÃO ................20
2.3 DESIGN THINKING........................................................................................................21
2.4 TRABALHOS CORRELATOS........................................................................................23
2.4.1 Enjoei ..............................................................................................................................23
2.4.2 Mundo Barth ...................................................................................................................26
2.4.3 Coda: Aplicativo móvel de avaliação de colaborativa da acessibilidade de ambientes..27
3 DESENVOLVIMENTO DO SISTEMA..........................................................................30
3.1 LEVANTAMENTO DE REQUISITOS ...........................................................................30
3.1.1 Público-alvo ....................................................................................................................30
3.1.2 Oficina de Design Thinking............................................................................................32
3.2 ESPECIFICAÇÃO ............................................................................................................36
3.2.1 Requisitos........................................................................................................................36
3.2.2 Diagrama de Caso de Uso...............................................................................................38
3.2.3 Matriz de rastreabilidade dos RFs e sua relação com os Casos de Uso..........................39
3.2.4 Diagrama de Atividades..................................................................................................40
3.2.5 Modelo de persistência de dados estruturado..................................................................41
3.2.6 Modelo de Entidade e Relacionamento back-end...........................................................42
3.3 IMPLEMENTAÇÃO ........................................................................................................43
3.3.1 Técnicas e ferramentas utilizadas....................................................................................43
3.3.2 Diagrama de implantação................................................................................................45
3.3.3 Codificação do sistema ...................................................................................................46
3.3.4 Operacionalidade da implementação ..............................................................................48
3.4 RESULTADOS E DISCUSSÕES.....................................................................................63
3.4.1 Oficina de Design Thinking............................................................................................63
3.4.2 Avaliação de usabilidade pelo método RURUCAg........................................................64
3.4.3 Comparação dos correlatos perante o trabalho desenvolvido .........................................75

4 CONCLUSÕES..................................................................................................................77
4.1 EXTENSÕES ....................................................................................................................78
REFERÊNCIAS......................................................................................................................80
APÊNDICE A – QUESTIONÁRIO DE LEVANTAMENTO DO PÚBLICO-ALVO.....83
APÊNDICE B – APRESENTAÇÃO DA OFICINA DE DESIGN THINKING...............88
APÊNDICE C – TERMO DE CONSENTIMENTO PARA FOTOGRAFIAS ................99
APÊNDICE D – DICIONÁRIO DE DADOS JSON .........................................................100
APÊNDICE E – DICIONÁRIO DE DADOS BACK END................................................103
APÊNDICE F – TERMOS DO PROTOCOLO PELO MÉTODO RURUCAG............104
APÊNDICE G – ROTEIRO DE AVALIAÇÃO DE USABILIDADE PELO MÉTODO
RURUCAG.......................................................................................................................106
APÊNDICE H – PERGUNTAS E RESPOSTAS OBTIDAS PELO MÉTODO
RURUCAG.......................................................................................................................120
APÊNDICE I – HEURÍSTICAS DE NIELSEN ................................................................137

17
1 INTRODUÇÃO
Na indústria da moda, milhares de pessoas são escravizadas para produzir peças de
roupas em meio a processos industriais que agridem o meio ambiente causando danos graves
e irreversíveis (WALK FREE FOUNDATION, 2018). Muitas peças têm um ciclo de vida
curto devido a serem feitas com materiais de baixa qualidade, resultando na necessidade do
consumidor final recomprar mais rápido e, por conseguinte, a indústria precisa e quer produzir
mais em menos tempo (FASHION REVOLUTION, 2019). Neste cenário, é muito difundido o
modelo industrial de moda rápida, o qual caracteriza-se pela agilidade de produção a preços
muito baixos e novidades constantes, com o objetivo de obter eficácia em vendas contínuas
(LOPES, 2019). Em resposta às consequências da moda rápida, a moda lenta tem como foco a
preservação dos recursos humanos e ambientais (FASHION REVOLUTION, 2019).
Nesse sentido, com o passar dos anos, os brechós têm se popularizado por
comercializarem roupas usadas, ajudando na sustentabilidade social e ambiental ao passo que
têm inovado em vendas por meio de sistemas em formato de comércio eletrônico
(FERNANDES, 2020). Assim, a população tem se conscientizado tanto em relação ao meio
ambiente quanto ao desperdício (FERNANDES, 2020). Desta forma, uma oportunidade de
preservar o meio ambiente, não compactuar com trabalhos escravos e disseminar o consumo
consciente é o comércio eletrônico de roupas usadas em brechós, permitindo que peças que já
foram produzidas sejam reutilizadas.
O comércio eletrônico ocorre por meio do processo de compra e venda de bens e
serviços pela internet fazendo uso de um ciberespaço para as pessoas interagirem e trocarem
informações (EMERITUS, 2020). Nesse sentido, estão os Sistemas Colaborativos (SC).
Pimentel e Carvalho (2020) observam que a Colaboração pode ser obtida na Comunicação via
troca de informações; na Coordenação via organização e administração; na Cooperação pela
operação conjunta em meio a um espaço compartilhado, formando assim, os pilares do
Modelo 3C de Colaboração (M3C) (FUKS et al., 2006). Diante deste cenário, este trabalho
realiza o desenvolvimento de um Sistema Colaborativo em um cenário de brechó. Conjectura-
se assim facilitar e encorajar a compra em brechós por meio da colaboração e do propósito
social do sistema.
1.1 OBJETIVOS
O objetivo geral do trabalho desenvolvido é oferecer um comércio eletrônico
colaborativo que permita o comércio de roupas usadas, promovendo sustentabilidade e
consumo consciente. Os objetivos específicos são:

18
a) disponibilizar um sistema para brechó que seja colaborativo, fundamentado no
M3C, permitindo que exista Comunicação (interação de perguntas e respostas e
notificações), Coordenação (funcionalidades administrativas) e Cooperação
(avaliações por estrelas) das atividades realizadas;
b) analisar e avaliar a usabilidade, a comunicabilidade e a experiência de uso das
interfaces desenvolvidas e de suas funcionalidades, pelo Método Relationship of
M3C with User Requirements and Usability and Communicability Assessment in
groupware (RURUCAg).
1.2 ESTRUTURA
Este trabalho está organizado em quatro capítulos. O primeiro capítulo apresenta a
introdução do tema referente ao trabalho desenvolvido, principais objetivos, justificativa e
estrutura do trabalho.
No segundo capítulo são abordados os conceitos e fundamentações teóricas utilizados
ao longo do desenvolvimento, referentes à sustentabilidade em meio à indústria da moda,
Design Thinking e Sistemas Colaborativos e o Modelo 3C de Colaboração. Além disso,
relata-se alguns trabalhos correlatos utilizados como base para o desenvolvimento deste
trabalho.
O terceiro capítulo apresenta o desenvolvimento do sistema, descrevendo a aplicação
das técnicas de Design Thinking; assim como é apresentada a modelagem, a implementação,
as ferramentas utilizadas e a operacionalidade da implementação. Ainda no terceiro capítulo,
os resultados são expostos junto ao comparativo entre os trabalhos correlatos e o trabalho
desenvolvido, bem como são descritos os processos da avaliação realizada pelo Método
RURUCAg.
Por fim, o quarto capítulo aborda as principais conclusões do trabalho desenvolvido e
as possíveis extensões para serem implementadas no futuro.

19
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo são apresentados os conceitos e fundamentos mais importantes para a
pesquisa deste trabalho, constando a seguinte organização: a seção 2.1 aborda Brechó e
Sustentabilidade; a seção 2.2 contextualiza o tema de Sistemas Colaborativos (SC) e o
Modelo 3C de Colaboração (M3C); a seção 2.3 traz o conceito de Design Thinking (DT); e,
por fim, a seção 2.4 expõe os trabalhos correlatos estudados.
2.1 BRECHÓ E SUSTENTABILIDADE
Brechó corresponde a uma loja de artigos usados, cujos produtos tais quais roupas,
sapatos, acessórios e afins são ofertados por um valor abaixo do de mercado por serem de
segunda mão (GADIOLI, 2019). Tótaro (2017) explica que o brechó teve origem no Brasil
por volta da década de 80 no Rio de Janeiro, quando um vendedor ambulante passou a vender
roupas usadas e outros artigos de segunda mão, com o nome de “Casa de Belchior”.
Roupas de segunda mão permitem desacelerar o consumo de massa que é negativo ao
meio ambiente (GADIOLI, 2019. A indústria de moda é a segunda que mais escraviza
pessoas (WALK FREE FOUNDATION, 2018) e é responsável pela emissão de 1,7 bilhões de
toneladas de dióxido de carbono (CO2), causando severos danos ao meio ambiente
(LOETSCHER et al., 2017). Além disso, a indústria têxtil é responsável pela poluição de 20%
da água de uso industrial decorrente do processo de tintura e tratamento de tecidos
(LOETSCHER et al., 2017). Assim, a ação dos brechós, que é fundamentada em reutilização
de artigos em desuso, colabora para a diminuição da produção em massa de artigos de moda e
evita a poluição (GADIOLI, 2019).
O modelo de moda rápida torna-se insustentável a longo prazo com o conflito entre
consumo e degradação ambiental, enquanto o consumidor afoga-se nas informações e
tendências momentâneas que potencializam o consumo da moda rápida (LOPES, 2019). Xu et
al. (2014) realizaram um estudo no qual foi observado que as motivações em consumir em
brechós podem mudar completamente em meio a diferentes culturas, como, por exemplo,
entre os jovens norte-americanos e os jovens chineses. Os norte-americanos consideram um
valor alto ao encontrar produtos exclusivos por meio de roupas de segunda mão, quando por
outro lado, os chineses valorizam o benefício ambiental da compra de roupas de segunda mão
(XU et al., 2014).
Com o estudo de Xu et al. (2014), pode-se afirmar que as motivações para compra em
brechós podem variar, porém, é indubitável o impacto ambiental e social que a escolha por
compra em brechós causa, independente da motivação do consumidor. Além disso, Green Me

20
(2019) pontua que todos os anos aterros sanitários em todo o mundo incineram 12 milhões de
peças de vestuário emitindo CO2, aumentando o efeito estufa. Logo, a atitude de destinar
roupas à brechós evita também que as peças parem em lixões ou aterros sanitários poluindo o
meio ambiente (GREEN ME, 2019).
2.2 SISTEMAS COLABORATIVOS E O MODELO 3C DE COLABORAÇÃO
Sistemas Colaborativos (SC) é a tradução brasileira que foi adotada para designar os
termos groupware e Computer Supported Cooperative Work, ambos relacionados a
computação para apoiar a Colaboração e foram cunhados antes mesmo do surgimento de
sistemas computacionais (NICOLACI-DA-COSTA; PIMENTEL, 2012). Diocesano e
Berkenbrock (2020) decorrem sobre SCs se constituírem em um espaço que possibilita as
interações humanas de serem vivenciadas, com grande poder de atrair e manter
frequentadores. O desenvolvimento de tais ambientes é realizado por meio do conhecimento
das relações pessoais e das diferentes formas de organização no trabalho (NICOLACI-DA-
COSTA; PIMENTEL, 2012).
SCs podem ser melhor compreendidos por meio do M3C, que é fundamentado em três
pilares, sendo eles: Coordenação, Cooperação e Comunicação e pelo Mecanismo de
Percepção (COSTA, 2018), que são apresentados na Figura 1. Para Pimentel e Carvalho
(2020), a Comunicação (letra A) pode ser vista na troca de informações e negociação entre os
usuários do ambiente para firmar compromissos; a Cooperação (letra B) ao possibilitar a
participação do grupo em um espaço compartilhado para a produção de informações para que
as tarefas gerenciadas pela Coordenação sejam realizadas; a Coordenação (letra C) se dá no
gerenciamento de recursos, no cumprimento de atividades e no trabalho colaborativo; e a
Percepção (letra D) facilita o relacionamento dos demais elementos. Fuks et al. (2011)
colocam que os 3C’s são interdependentes e se inter-relacionam para que possa haver a
colaboração.
A Coordenação é descrita por Pimentel e Carvalho (2020) como o elemento que realiza
a orientação e organização dos compromissos gerados pela demanda do elemento de
comunicação, com tarefas ordenadas e determinadas, oferecendo também suporte aos demais
elementos. A Coordenação pode ser exemplificada por uma típica sala de bate-papo na qual
há um suporte por parte da Coordenação que detém a lista de participantes e respectivas
informações, logo, sem a Coordenação, a Cooperação e a Comunicação ficam comprometidas
(FUKS et al., 2011). A Cooperação se dá pela produção conjunta das partes envolvidas, para
que haja um trabalho em conjunto no realizar das atividades, logo, é a ação de operar em

21
conjunto no espaço compartilhado (FUKS et al., 2011, PIMENTEL; CARVALHO, 2020). O
registo de compartilhamento como funcionalidade de uma ferramenta, tal qual perguntas e
respostas ou chat, disponibilizando registro de mensagens publicadas exemplifica a
Cooperação (FUKS et al., 2011, PIMENTEL; CARVALHO, 2020). Pimentel e Carvalho
(2020) descrevem a Comunicação por meio da ação de transmitir e receber mensagens para
que as partes envolvidas troquem ideias e tenham a oportunidade de negociar para tomadas de
decisões e realizações dos compromissos propostos, seja de maneira síncrona ou assíncrona.
Alguns exemplos práticos de Fuks et al. (2011) para a Comunicação são videoconferências,
fóruns e e-mails.
Figura 1 - Modelo 3C de Colaboração
Fonte: adaptado de Fuks, Raposa e Gerosa (2003).
Pimentel (2019) afirma que projetar e desenvolver a Colaboração proporciona o poder
de criar novas formas de interação social, o que gera novas oportunidades para a convivência
humana. Nicolaci-da-Costa e Pimentel (2012) também afirmam que um Sistema Colaborativo
não deve restringir-se apenas ao comando e controle da realização das tarefas propostas, mas
ser condizente com as necessidades das novas gerações que demandam colaborar, interagir e
compartilhar de forma flexível.
2.3 DESIGN THINKING
Brown (2008) descreve Design Thinking (DT) como sendo uma metodologia para
conceber ideias baseando-se em necessidades reais de um usuário. Já Luz (2018) estabelece
DT como um processo criativo que promove maior conexão entre as pessoas envolvidas
utilizando a inteligência coletiva a favor das entidades. DT foca nos usuários (ou clientes) e

22
em virtude disso, provê auxílio às situações propostas caracterizando-se como uma
abordagem multidisciplinar e colaborativa (MOREIRA; TORRES, 2020). Brown e Wyatt
(2010) trouxeram uma abordagem eficaz e amplamente acessível e ao mesmo tempo integrada
a todos os aspectos dos negócios e da sociedade para que equipes possam utilizar para gerar
ideias inovadoras.
Desta maneira, o DT incorpora percepções do constituinte ou consumidor em
profundidade e prototipagem rápida, com o objetivo de ir além das suposições comuns que
bloqueiam soluções eficazes, fazendo a diferença (BROWN; WYATT, 2010). O processo do
DT busca compreender e assimilar um problema, para então elaborar ideias e soluções que
melhorem a vida das pessoas (MOREIRA; TORRES, 2020). Neste contexto, Brown e Wyatt
(2010) pontuam três fases do Design Thinking, sendo elas (Figura 2): inspiração, ideação e
implementação e acrescentam que durante o processo do projeto é possível passar pelas etapas
mais de uma vez em busca de melhorias.
Figura 2 - Fases do Design Thinking
Fonte: adaptada de Brown (2008, p.88-89).
Brown e Wyatt (2010) apontam a fase de inspiração como sendo a fase responsável
pela realização da coleta de informações recorrendo à todas as fontes possíveis, definindo o
problema ou oportunidade que motiva a busca por uma solução por diferentes pontos de
vistas. Já na fase de ideação as informações são transformadas em ideias, restringindo-se ao
desenvolvimento e teste das ideias geradas, portanto, as ideias geradas na fase de inspiração

23
são aprimoradas (MOREIRA; TORRES, 2020). Por fim, a fase de implementação é o
caminho ao mercado e diz respeito à materialização das melhores ideias levando-as até a vida
das pessoas por meio do sistema desenvolvido, destacando-se nesta etapa as técnicas de
protótipos e storytelling (SOUZA; CAVASSINI; SABINO, 2020). Existem diversas técnicas
para aplicação das fases do Design Thinking, assim, não existe apenas uma maneira ou
técnica correta, ficando a critério de quem for realizar a aplicação (BROWN; WYATT, 2010).
2.4 TRABALHOS CORRELATOS
Nesta seção estão descritos três trabalhos correlatos que apresentam características
semelhantes ao trabalho desenvolvido. A subseção 2.4.1 traz o Enjoei, um Sistema
Colaborativo de comércio eletrônico de compras e vendas de artigos novos ou usados, com a
possibilidade de interação com o vendedor por meio de comentários antes da compra, bem
como meios de negociação de preços (CASHME, 2021). A subseção 2.4.2 apresenta o Mundo
Barth, um brechó que possui loja on-line com o propósito de promover sustentabilidade
social, ambiental e consumo consciente (CARVALHO, 2021). Por fim, a subseção 2.4.3 traz
um aplicativo colaborativo de avaliação de acessibilidade de locais, intitulado Coda, com
funções como pesquisa de locais, acesso ao mapa, ambiente de perguntas e respostas, dentre
outras funções (CARVALHO, 2020).
2.4.1 Enjoei
Enjoei é uma empresa brasileira de comércio eletrônico que vende artigos de segunda
mão e oferece soluções de consumo consciente e colaborativo (ENJOEI, 2021). Algumas das
principais características destacadas por Enjoei (2021) como pontos positivos são: o comércio
de artigos usados, a administração via coordenação das vendas, a opção de curtir ou dar nota
individualmente às peças, a busca com filtro, a avaliação por meio de sistema de estrelas e a
possibilidade de entrega das compras ou retirada em mãos e a comunicação via perguntas e
respostas entre comprador e vendedor. Já como ponto negativo, Fernandes (2019) esclarece
que há um percentual sobre o valor do produto e que muitos internautas julgam ser um valor
relativamente alto descontado.
De acordo com Brando (2021), o sistema foi desenvolvido em Ruby on Rails desde o
início, porém recentemente foi incorporada a linguagem Go à alguns serviços e alguns
códigos foram escritos em Python e Node.js. O sistema possui uma interface intuitiva e
jovem, adjetivos que se observam na Figura 3 (a). Ele conta também com uma barra lateral

24
(Figura 3 (b)), na qual o usuário tem acesso às suas notificações, compras, área financeira
(enjubank), produtos curtidos (yeyezados), dentre outras funções (ENJOEI, 2021).
Figura 3 - Página inicial do Enjoei (a) e barra lateral (b)
Fonte: adaptada de Enjoei (2021).
O Enjoei possui taxas que são descontadas do pagamento do vendedor para que possa
haver uma comissão de venda por parte do sistema pela intermediação das negociações
(ENJOEI, 2021). Ele também permite ao usuário interagir com o vendedor antes da compra
por meio de comentários disponíveis nas peças cadastradas (letra A da Figura 4) e dispõe da
opção yeyeah se o usuário desejar curtir o produto (letra B da Figura 4) e revê-lo
posteriormente nesta seção de produtos curtidos. O sistema ainda permite ao comprador
ofertar no item desejado (letra C da Figura 4), funcionalidade que é um ponto positivo desse
sistema, tendo em vista que o comprador poderá negociar valores. O Enjoei também possui
uma avaliação que conta com um sistema de estrelas (letra D da Figura 4), na qual o vendedor
é avaliado por usuários que concluem uma compra com o vendedor em questão (ENJOEI,
2021).

25
Figura 4 - Tela de produto à venda
Enjoei (2021) possui busca e filtros detalhados (Figura 5). A busca pode ser por
marcas específicas (letra A), selecionando a marca desejada nas opções disponíveis, ou com
palavras-chave (letra B), pelas quais o usuário digita o que deseja buscar. A interface
possibilita ao usuário selecionar qual a categoria principal que deseja filtrar sua busca (letra
C) e ao selecionar, mostra ao usuário as subcategorias daquela categoria principal para que ele
possa escolher alguma e iniciar a busca (letra D) (ENJOEI, 2021).

26
Figura 5 - Busca e filtro de produto
2.4.2 Mundo Barth
Mundo Barth é um brechó com loja física e virtual que preza pela moda sustentável e o
consumo consciente (CARVALHO, 2021). Furlan (2021) aponta que o front end utiliza o
framework Bootstrap e foi desenvolvido na linguagem Hypertext PreProcessor (PHP),
originalmente Personal Home Page e como diferencial a possibilidade de deixar à venda peças
únicas tanto na loja on-line quanto na loja física. Neste sentido, Furlan (2021) afirma que as
medidas de contenção e segurança foram essenciais para evitar que o mesmo produto fosse
vendido duas vezes. Para Furlan (2021), para construir o sistema foi necessário o uso de
Content Delivery Network (CDN) para otimizar o desempenho do sistema, tendo sido
necessário usar a biblioteca jQuery para suprir a CDN. Cabe destacar que ele possibilita o
agendamento de produtos novos como uma funcionalidade automatizada; na qual o
administrador cadastra peças no sistema, porém não libera para os usuários imediatamente,
fazendo um agendamento para sua liberação na data e hora escolhida (FURLAN, 2021).
Para auxiliar nas medidas de contenção, o front end possui consultas dinâmicas em
tempo real, garantindo que a mesma peça será vendida apenas uma vez, evitando problemas
(FURLAN, 2021). Além disso, algumas das principais características destacadas em Mundo
Barth (2021) como pontos positivos são: comércio de artigos usados, diferentes opções de
entrega contando com retirada em mãos, busca de produtos no sistema, bem como filtro por
categoria de produto para pesquisa e a opção sacolinha. Já como pontos negativos, nota-se
que o sistema não possui área de perguntas e respostas entre usuário e administrador, bem
como nenhum meio de avaliação do sistema como um todo ou as peças individualmente.
O sistema do Mundo Barth possui a opção de busca por palavras-chave, conforme
Figura 6 (letra A (a)) e também disponibiliza a opção de filtrar a busca pela categoria da peça

27
(Figura 6 (b)). Ele também possibilita que o cliente escolha entre receber o produto via
correios, entrega por motoboy ou retirada diretamente na loja física (letra B da Figura 6 (a)).
O sistema ainda oferece a modalidade de compra sacolinha, na qual o cliente compra
diversas peças em diferentes datas, mas paga apenas um frete no momento que desejar o
envio de sua sacolinha, sendo este um forte ponto positivo do Mundo Barth (CARVALHO,
2021). Atualmente o leque de produtos oferecido no sistema não conta com toda
disponibilidade de peças em loja física, o que acaba por ser um ponto negativo, pois muitos
usuários não residem nas redondezas para terem acesso a todas as peças, então dependem do
sistema para adquiri-las (CARVALHO, 2021).
Figura 6 - Produto à venda (a) e filtro por tipo de produto (b)
Fonte: adaptada de Mundo Barth (2021).
2.4.3 Coda: Aplicativo móvel de avaliação de colaborativa da acessibilidade de ambientes
Carvalho (2020) desenvolveu um aplicativo móvel, com objetivo de realizar avaliação
da acessibilidade de ambientes públicos e privados de maneira colaborativo, intitulado Coda.
O aplicativo foi desenvolvido utilizando os frameworks Ionic e Angular, com linguagem
TypeScript e interface construída em HyperText Markup Language (HTML), Syntactically
Awesome Style Sheets (SASS) e Cascading Style Sheets (CSS), aplicando os conceitos de
Material Design para o desenho das interfaces (CARVALHO, 2020). Algumas das principais
características destacadas por Carvalho (2020) como pontos positivos são: coordenação em

28
ambientes, atribuição de nota individualmente, busca com filtro, perguntas e respostas,
avaliação por estrela, ser construído com base no M3C e utilizar o Método RURUCAg. Já
como pontos negativos, Carvalho (2020) aponta a falta de informações no mapa, a não
existência de histórico de busca e muita informação em tela.
Carvalho (2020) aponta ainda como um diferencial do Coda a característica de
pesquisa de locais e a oportunidade de utilizar filtros na pesquisa, disponibilizando resultados
exclusivos para diferentes tipos de serviços acessíveis. A pesquisa pode ser realizada por
dados geográficos como: nome de ruas, bairros, cidades, ou por tipo de estabelecimento,
como restaurante, cinema, parque, dentre outros (CARVALHO, 2020). Ao selecionar um
dos resultados da pesquisa, o usuário é direcionado à interface de detalhamento do ambiente,
apresentada na Figura 7 (CARVALHO, 2020).
O detalhamento é dividido em três abas (letra A da Figura 7 (a)), sendo elas referentes
a informações, avaliações e perguntas. Na aba de informações o usuário tem acesso a
dados do ambiente, tais como nome, nota em estrelas e dados de localização e
contato (letra B da Figura 7 (a)). Logo abaixo (de cima para baixo) na aba de informações,
são listados os serviços acessíveis que aquele ambiente dispõe, separados em as pessoas
dizem que esse local e esse local informou que (letra C da Figura 7 (b)). O usuário
tem ainda a possibilidade de solicitar a coordenação daquele local consultado clicando em
Coordenar este local, direcionando o usuário para a Tela do Coordenador (letra D da
Figura 7 (c)) (CARVALHO, 2020).
Carvalho (2020) construiu um aplicativo colaborativo fundamento no M3C, que
estabelece como pilares a Coordenação, a Cooperação e a Comunicação e que formam os 3Cs
do Modelo. A Coordenação está presente na forma como as atividades são gerenciadas, na
qual um usuário pode ficar responsável pelas informações de um ambiente. A Comunicação
foi implementada por meio de perguntas e respostas sobre ambientes públicos e privados
dentro do aplicativo, assim como pela localização em tempo real. Já o pilar de Cooperação
está representado com um diferencial que é a possibilidade de avaliação de ambientes, na qual
os estabelecimentos podem ser avaliados de zero (0) a cinco (5) estrelas conforme
apresentado na Figura 7 (a). Por fim, o Mecanismo de Percepção sugerido pelo Modelo 3C
também foi implementado, pois para os usuários ficou claro como cada uma das pessoas
colabora dentro do grupo e qual atividade cada um desempenhou (CARVALHO, 2020).

29
Figura 7 - Interfaces de informações de ambiente (a, b) e Coordenador (c)
Fonte: adaptada de Carvalho (2020).
Cabe destacar que Carvalho (2020, p. 20) analisou e avaliou “[...] a usabilidade, a
comunicabilidade e a experiência de uso das interfaces desenvolvidas e de suas
funcionalidades [...]”, por meio do Método Relationship of M3C with User Requirements and
Usability and Communicability Assessment in groupware (RURUCAg). O objetivo de
Carvalho (2020, p. 20) foi de “[...] avaliar de maneira simples a facilidade de uso de acordo
com padrões de usabilidade pelas heurísticas de Nielsen, do Modelo 3C de Colaboração, das
expressões de comunicabilidade e dos requisitos do aplicativo.”. Além disso, Carvalho (2020)
utilizou o Design Thinking (DT) na construção do aplicativo.

30
3 DESENVOLVIMENTO DO SISTEMA
Neste capítulo, será apresentado o conteúdo referente ao desenvolvimento do sistema.
A seção 3.1 apresenta o levantamento de informações utilizando uma pesquisa com o público-
alvo e a metodologia Design Thinking, conforme visto na seção 2.3. A seção 3.2 apresenta a
especificação do sistema. A seção 3.3 detalha a implementação, bem como as técnicas e
ferramentas utilizadas. A seção 3.4 aborda os resultados e as discussões, trazendo a avaliação
realizada de acordo com o Método RURUCAg, bem como a comparação entre os trabalhos
correlatos e o trabalho desenvolvido.
3.1 LEVANTAMENTO DE REQUISITOS
Nesta seção estão descritas as técnicas e metodologias utilizadas para o levantamento
de informações para o desenvolvimento do trabalho. A subseção 3.1.1 detalha o questionário
aplicado para identificar o público-alvo do sistema, enquanto a subseção 3.1.2 aborda a
prática da oficina de Design Thinking realizada.
3.1.1 Público-alvo
O público-alvo é considerado pelo perfil do grupo de pessoas que uma solução busca
atender. Então, antecedendo a oficina de DT, fez-se uma pesquisa em forma de questionário
para levantamento do público-alvo a fim de identificar os perfis e experiências das pessoas
selecionadas. O questionário foi disponibilizado por meio da ferramenta Google Forms para
extrair informações preferenciais e experiências a respeito do perfil dos participantes. Além
disso, foi possível identificar como os pesquisados classificam a experiência em comércios
eletrônicos difundidos. Para tanto, o questionário contou com perguntas objetivas e de
múltipla escolha com possibilidade de resposta alternativa, detalhadas no Apêndice A,
podendo ser sintetizadas da seguinte forma:
a) primeira seção: questões básicas para conhecer o participante, como sexo e faixa
etária;
b) segunda seção: foram elaboradas questões com o intuito de conhecer sobre os
tipos de brechós virtuais que o participante costuma visitar com exemplos
de sistemas de comércio eletrônico conhecidos e a possibilidade de citar outro
também. Em seguida foi feita uma pergunta objetiva de como o pesquisado
considera a interface destes brechós;
c) terceira seção: questão objetiva sobre o nível de conhecimento dos participantes
sobre o tema sustentabilidade, seguida de questão objetiva para saber se o

31
pesquisado acha relevante brechós difundirem informações sobre
sustentabilidade;
d) quarta seção: duas perguntas de múltipla escolha com possibilidade de resposta
alternativa para extrair o que afeta negativamente e positivamente a
experiência do participante em lojas virtuais em geral.
Com o questionário pronto, foi realizada uma seleção de pessoas de diferentes idades e
áreas de atuação profissional que já tiveram algum contato com brechós ou lojas virtuais. Em
seguida foi realizada a abordagem destas pessoas via redes sociais totalizando 52
participantes. A coleta de respostas foi feita em um período de uma semana, iniciando-se no
dia 09 de março de 2022 e encerrando no dia 16 de março de 2022.
O questionário permitiu identificar as principais dificuldades enfrentadas em acessar
comércios eletrônicos e também as preferências em meio à brechós conhecidos e o que mais
agrada nas experiências de comércios eletrônicos. Com estas informações, foi possível obter
informações relevantes para selecionar a amostragem do público das próximas fases do DT. A
partir das primeiras questões do questionário foi possível observar uma ocorrência maior de
participantes do sexo feminino com idades 18 e 24 anos de idade.
Na sequência, identificou-se que dos comércios eletrônicos de brechós expostos, os
mais acessados costumam ser o Enjoei e o Mudo Barth, juntamente com diversos brechós do
Instagram, no qual pode-se perceber a conveniência de desenvolver um sistema de comércio
eletrônico de brechó. No que diz respeito à interface destes comércios eletrônicos, metade dos
participantes a classifica como boa em uma escala de: péssima, ruim, boa, muito boa e
excelente. Em seguida analisou-se que uma grande fatia dos participantes conhece o mínimo
de sustentabilidade social e ambiental e acreditam ser relevante que os brechós abordem este
assunto em toda sua importância em meio ao brechó.
Os participantes foram incentivados a relatar o que mais afeta negativamente e
positivamente a experiência de quem consome em comércios eletrônicos. Pode-se analisar por
meio dos resultados evidenciados na Figura 8, que um sistema pouco intuitivo é o que mais
afeta negativamente a experiência do usuário, seguido pela falta de informações de contato
com responsáveis da loja. Por fim, conforme mostra a Figura 9, objetividade e facilidade de
processos são os fatores que mais afetam a experiência do participante positivamente em lojas
virtuais, assim como design agradável, ser intuitivo e possuir meio de contato com
responsáveis. Com esta análise concluída, foi viabilizado uma oficina de Design Thinking de
forma presencial com pessoas que se encaixam no público-alvo ou que possuem experiências

32
relevantes em brechós ou comércios eletrônicos. As etapas e detalhes deste encontro
encontram-se na subseção 3.1.2.
Figura 8 - Resultado da pergunta sobre experiências negativas em lojas virtuais
Fonte: elaborado pela autora.
Figura 9 - Resultado da pergunta sobre experiências positivas em lojas virtuais
3.1.2 Oficina de Design Thinking
A oficina de DT foi realizada no dia 26 de março de 2022 no Laboratório
Interdisciplinar de Formação de Educadores (LIFE) da Fundação da Universidade Regional
de Blumenau (FURB), tendo duração total de 2h, com início às 15h e término às 17h. Iniciou-
se a oficina com uma breve introdução sobre o trabalho desenvolvido e o tema principal
(brechós, sustentabilidade e colaboração) ao passo que foram apresentados aos participantes
os resultados da pesquisa de público-alvo da pesquisa qualitativa da subseção 3.1.1. O seu
detalhamento se encontra no Apêndice B. Já o Apêndice C traz o termo de consentimento de

33
fotografias utilizado nessa oficina. Em seguida, os participantes receberam orientações para
iniciar a primeira etapa da oficina, que foi dividida em um total de cinco etapas.
A primeira etapa consistiu na atividade de Persona, na qual os participantes
construíram uma pessoa fictícia para representação do público-alvo do comércio
eletrônico. Para isto, os participantes responderam perguntas específicas e pré-estabelecidas
em notas autoadesivas (Figura 10, letra A) e coladas em um mural (Figura 10, letra B),
relacionadas à biografia, costumes e frustrações quando relacionados à comércio eletrônico.
Figura 10 - Mural com resultados da atividade de Persona da oficina de DT
A segunda etapa da oficina de DT foi o Mapa da Jornada do Usuário, com o objetivo
de mapear as etapas da trajetória de um cliente de comércio eletrônico dentro do sistema. Para
isso, os participantes definiram qual seria o ponto de entrada do usuário no sistema e uma
meta a ser atingida ao final do processo. Desta forma, eles precisavam adicionar todas as
etapas necessárias neste fluxo para que a meta fosse atingida, incluindo descrições para cada
etapa realçando os pontos ao longo da jornada. Ao final da etapa, os participantes criaram o
seu próprio modelo mental que foi exposto em uma das paredes do laboratório para análise
em fase posterior da oficina (Figura 11).

34
Figura 11 - Construção do Mapa de Jornada do Usuário para a oficina de DT
Os participantes foram incentivados a utilizar setas, formas geométricas e tudo que
pudesse auxiliar na montagem do mapa mental da jornada do usuário, usando a quantidade de
etapas que julgassem necessárias. Alguns mapas desenvolvidos estão apresentados na Figura
12, que mostra que os participantes utilizaram criatividade e montaram fluxos pensando nas
necessidades reais dos usuários e nas etapas do sistema. Os participantes sugeriram
funcionalidades e fluxos interessantes que foram considerados para desenvolvimento
posterior.
Figura 12 - Mapas mentais elaborados pelos participantes da oficina de DT
A terceira etapa da oficina contou com o Mapa de Ideias, para que fosse possível
identificar oportunidades de soluções inovadoras e colaborativas, estimulando a criatividade
para a etapa de prototipação. Foi solicitado aos participantes que escrevessem em notas

35
autoadesivas funcionalidades que eles consideravam interessantes e relevantes para o sistema,
desde funções essenciais até mais criativas e elaboradas (Figura 13, letra B).
Em seguida, aconteceu a votação para que as melhores ideias de funcionalidades
fossem destacadas, e para isso, cada participante recebeu uma cartela de adesivos de bolinhas
(Figura 13, letra A), tal que cada bolinha representava um voto. Foi solicitado aos
participantes que lessem e passassem por todas as ideias votando em silêncio para não
influenciar outros participantes, podendo votar até duas vezes na mesma ideia e em quantas
ideias quisesse, inclusive na sua. O quadro com as votações encontra-se na Figura 13, letra C.
Figura 13 - Atividade e votação do Mapa de Ideias da oficina de DT
A quarta etapa da oficina foi a Prototipação, que para expandir ideias de soluções
palpáveis, cada participante poderia fazer, se assim preferisse, duplas ou trios, usando
quadros, figuras e palavras para prototipação das telas do sistema. Foram apresentados alguns
exemplos de prototipações aos participantes para instruí-los a como criar o protótipo. Além
disso, os participantes poderiam andar pela sala para rever as informações das etapas
anteriores se quisessem.
A quinta e última etapa da oficina foi o Mapa de Calor, momento em que todos os
protótipos criados pelos participantes foram expostos nas paredes do laboratório (Figura 14,
letra A). Cada participante, com adesivos de bolinha, observou em silêncio e colou bolinhas
nas partes mais interessantes dos protótipos, conforme Figura 14, letra B. Caso um
participante não compreendesse uma parte do protótipo, ele poderia colar uma nota
autoadesiva próximo ao protótipo com a dúvida.

36
Figura 14 - Atividade de Prototipação e Mapa de Calor da oficina de DT
Os resultados obtidos a partir da oficina foram fundamentais para que o
desenvolvimento do sistema faça sentido e esteja alinhado com necessidades reais,
identificando funcionalidades que os usuários consideram importante e descartando ideias que
não foram vistas como relevantes. Algumas funcionalidades levantadas já estavam previstas
de serem implementadas, o que ressaltou a relevância delas, como por exemplo: avaliação por
estrelas, perguntas e respostas e filtros rápidos.
3.2 ESPECIFICAÇÃO
Nesta seção, expõe-se os diagramas e especificações técnicas deste trabalho. Para isto,
os Requisitos Funcionais (RF), os Requisitos Não Funcionais (RNF) e as Regras de Negócio
(RN) são apresentados na subseção 3.2.1. Na subseção 3.2.2 é apresentado o Diagrama de
Caso de Uso (DCU). A subseção 3.2.3 traz a matriz de rastreabilidade dos RFs e sua relação
com os Casos de Uso, enquanto a subseção 3.2.4 traz o diagrama de atividades. A subseção
3.2.5 apresenta o Modelo de Persistência de dados estruturado. Por fim, o Modelo de Entidade
e Relacionamento (MER) back end consta na subseção 3.2.6.
3.2.1 Requisitos
Esta subseção apresenta os Requisitos Funcionais (RF) no Quadro 1, os Requisitos
Não Funcionais (RNF) no Quadro 2 e as Regras de Negócio do sistema desenvolvido no
Quadro 3. Todas essas informações foram baseadas no Modelo 3C de Colaboração abordado
na seção 2.2 e elaboradas a partir de conhecimentos adquiridos sobre brechó e

37
sustentabilidade vistos na seção 2.1, bem como da oficina de DT realizada, apresentada na
subseção 3.1.2.
Quadro 1 - Requisitos Funcionais
RF O sistema deve: M3C
RF01 permitir ao usuário se cadastrar no sistema -
RF02 permitir ao usuário cadastrado autenticar-se no sistema com e-mail e senha -
RF03 permitir ao usuário administrador cadastrar usuários no sistema Coordenação
RF04 permitir ao usuário realizar avaliações nele com sistema de estrelas Cooperação
RF05 permitir ao usuário e ao administrador se comunicarem via perguntas e respostas Comunicação
RF06 permitir ao usuário visualizar as notificações de sua conta Comunicação
RF07 permitir ao usuário realizar pesquisa de produtos por título e filtros rápidos -
RF08 permitir ao usuário consultar seus pedidos -
RF09 permitir ao usuário editar suas informações cadastrais -
RF10 disponibilizar ao usuário meios de contato com responsáveis -
RF11 permitir ao usuário acesso a informações rápidas e explicativas sobre ele -
RF12 permitir ao usuário acesso a instruções de como realizar compras -
RF13 permitir ao usuário realizar uma compra -
RF14 permitir ao usuário administrador visualizar todos os usuários cadastrados Coordenação
RF15 permitir ao usuário administrador ativar ou inativar um usuário Coordenação
RF16 permitir ao usuário realizar pagamento via Transferência bancária -
RF17 permitir ao usuário realizar pagamento via PIX -
RF18 permitir ao usuário autenticado desconectar-se do sistema -
RF19 permitir ao usuário autenticado curtir produtos ativos Cooperação
Quadro 2 - Requisitos Não Funcionais
RNF O sistema deverá:
RNF01 utilizar JavaScript Object Notation (JSON) escritos como Application Programming Interface (API)
RNF02 utilizar a framework Angular para desenvolver o front end
RNF03 ser responsivo
RNF04 utilizar a linguagem TypeScript
RNF05 ter sua interface desenvolvida utilizando Hipertext Markup Language (HTML) e Leaner Style
Sheets (LESS)
RNF06 ser construído utilizando a metodologia de Design Thinking
RNF07 ser construído com base no M3C
RNF08 utilizar o Método RURUCAg para modelar a relação entre os requisitos, o M3C e as heurísticas de
Nielsen
RNF09 utilizar o Método RURUCAg para avaliar a usabilidade e a experiência de uso
RNF10 utilizar token para autenticação
RNF11 utilizar a linguagem c# no back end
RNF12 utilizar banco de dados Postgres
Quadro 3 - Regras de Negócio
RN Descrição
RN01 um usuário poderá realizar uma compra apenas estando autenticado no sistema
RN02 um usuário poderá fazer perguntas em produtos apenas quando estiver autenticado no sistema
RN03 um usuário administrador poderá responder perguntas de produtos apenas quando estiver
autenticado no sistema
RN04 um usuário poderá curtir um produto apenas quando estiver autenticado no sistema
RN05 um usuário poderá visualizar suas notificações apenas quando estiver autenticado
RN06 um usuário poderá efetuar a compra de um produto por vez
RN07 as notificações de administradores devem ser compartilhadas a todos usuários com esta permissão
RN08 um produto inativo ficará ainda visível, porém sem poder ter interação como compra, curtida ou
perguntas e não aparecendo mais nas listagens do sistema
RN09 um usuário não autenticado poderá acessar apenas funções básicas do sistema

38
3.2.2 Diagrama de Caso de Uso
Esta subseção apresenta o Diagrama de Casos de Uso (DCU) e os User Case (UC) do
sistema desenvolvido, exibido na Figura 15 que contém os atores Usuário e Administrador.
Qualquer usuário no sistema pode realizar a avaliação do sistema por meio do UC04 –
Avaliar o sistema; realizar consultas dos produtos por meio do UC03 – Pesquisar por
produtos; ter acesso a informações e instruções explicativas do sistema como consta UC02
– Acessar informações e instruções explicativas; e ter acesso aos meios de contato
por meio do UC01 – Acessar meios de contato. O Usuário pode realizar seu cadastro,
conforme demonstrado no UC11 - cadastrar-se no sistema ou autenticar-se no sistema
por meio do UC07 – Realizar login/logout. Desta forma o usuário pode, por estar
autenticado, acessar algumas funções restritas à usuários autenticados no sistema. Dentre tais
funções, o ator Usuário pode comprar produtos como demonstrado no UC09 -Realizar
compra de produto e fazer perguntas em produtos conforme consta no UC10 – Fazer
perguntas em produtos. As perguntas serão respondidas pelo Administrador, por meio
da UC13 – Responder perguntas em produtos.
Com o UC-07 - Realizar login/logout tanto o Usuário como o Administrador
podem consultar os pedidos que foram realizados por meio do UC08 – Consultar pedidos.
Desta forma, o Administrador consulta pedidos realizados por todos os usuários e o
usuário consulta os pedidos feitos apenas na própria conta. Ambos os atores podem editar
suas informações cadastrais por meio da UC05 – Editar perfil e também podem visualizar
notificações de suas contas e interações no sistema conforme demonstrado na UC6 –
Visualizar notificações. Os dois atores podem também curtir produtos ativos por meio
do UC14 – Curtir produtos. O Administrador, por meio da UC12 – Gerenciar
usuários, pode ativar e inativar usuários existentes bem como criar usuários novos com
permissão de administrador ou não, e visualizar listagem com todos os usuários cadastrados
no sistema.

39
Figura 15 - Diagrama de caso de uso do sistema
3.2.3 Matriz de rastreabilidade dos RFs e sua relação com os Casos de Uso
Esta subseção apresenta o Quadro 4 que exibe a matriz de rastreabilidade dos
Requisitos Funcionais do sistema com os Casos de Uso dele. Adiante, é apresentada a matriz
de rastreabilidade entre UC e RFs aplicados ao M3C de Colaboração no Quadro 5.
Quadro 4 - Matriz de rastreabilidade dos RF com os UC referente ao sistema
RF UC
RF01 UC11
RF02, RF18 UC07
RF07 UC03
RF08 UC08
RF09 UC05
RF10 UC01
RF11 e RF12 UC02
RF13, RF16 e RF17 UC09
Quadro 5 - Matriz de rastreabilidade entre UC e RF aplicados ao M3C de Colaboração
RF UC M3C
RF03 UC12 Coordenação
RF04 UC04 Cooperação
RF05 UC10 e UC13 Comunicação
RF06 UC06 Comunicação
RF14 e RF15 UC12 Coordenação
RF19 UC14 Cooperação

40
3.2.4 Diagrama de Atividades
Esta subseção mostra o diagrama de atividades (Figura 16), que traz a atividade que
envolve as perguntas e respostas de produtos no sistema e as notificações, explicitando assim
a Coordenação e a Comunicação.
Figura 16 - Diagrama de Atividades
A primeira e terceira raia (Usuário e Administrador, respectivamente) iniciam com o
acesso a um produto do sistema (segunda raia), que por sua vez carrega o produto e
verifica permissão do usuário. Com base nisto, ao verificar perguntas
respondidas, habilita ao administrador responder perguntas que não tem resposta ainda e
exibe perguntas que já tenham respostas também. Ao selecionar opção de responder
pergunta, o administrador digita sua resposta e envia para que o sistema receba e
publique a resposta, notificando sucesso em tela, removendo o botão de responder
daquela pergunta e cadastrando nova notificação ao usuário de que sua pergunta foi
respondida. De mesma forma, se for um usuário sem permissões administrativas, ao
verificar perguntas e respostas, irá exibi-las em tela e habilitar campo para
digitação de perguntas. Assim, quando o usuário escreve uma pergunta e envia, o

41
sistema recebe e publica a pergunta para, por fim, notificar o usuário que a pergunta foi
publicada e cadastrar nova notificação ao administrador informando que há uma nova
pergunta.
3.2.5 Modelo de persistência de dados estruturado
A Figura 17 apresenta um modelo de persistência de dados estruturado do mock em
JavaScript Object Notation (JSON), que não é uma estrutura relacional de dados e por isso
esse modelo foi escolhido para fazer tal representação. O dicionário de dados desse modelo de
persistência encontra-se no Apêndice D. O JSON foi criado para suportar os atributos e
entidades do sistema que não dizem respeito ao armazenamento de usuários. Desta forma, no
modelo está representada a classe User que não está persistida no modelo JSON, porém foi
inserida no modelo de persistência para fazer referência ao modelo relacional do back end
mencionado e que se encontra na subseção 3.2.6.
Figura 17 - Modelo de persistência de dados estruturado
Vale ressaltar que, a estrutura AdminNotifications não possui ligações com outras
estruturas pois tem seu funcionamento independente. Desta forma, tal estrutura armazena
notificações administrativas e todos os administradores têm visibilidade das mesmas
notificações, a estrutura apenas armazena os dados das notificações sem exigir relações com
outras estruturas. De mesma forma a estrutura Stars, que apenas armazena dados do cálculo
de média, não possui ligações com outras estruturas pois não se faz necessário tendo em vista
que armazena dados apenas. Segue abaixo a descrição de cada classe apresentada acima:

42
a) AdminNotifications: classe que representa as notificações dos administradores
do sistema;
b) Stars: classe que representa as notas atribuídas ao sistema;
c) Product: classe que representa produtos cadastrados no sistema;
d) Chat: classe que representa conversação em produtos com perguntas e respostas;
e) OrderProduct: classe que representa produtos dentro de uma compra;
f) Orders: classe que representa uma compra do usuário;
g) Notification: classe que representa notificações de usuários;
h) User: classe que representa usuários cadastrados no sistema.
3.2.6 Modelo de Entidade e Relacionamento back-end
Nesta subseção é apresentado o Modelo de Entidade e Relacionamento (MER) do back
end que é a única estrutura relacional de dados do sistema. A Figura 18 apresenta o MER do
banco de dados Postgres e o dicionário de dados encontra-se no Apêndice E.
Figura 18 - Modelo de Entidade e Relacionamento back end
O sistema foi desenvolvido utilizando um modelo de banco de dados relacional, o
Postgres, portanto, cada entidade na representação da Figura 18 representa uma tabela que
armazena os registros do banco. No MER são apresentados os campos e seus tipos de
atributos de cada entidade do banco de dados. Segue a descrição de cada entidade apresentada
na Figura 18:

43
a) Users: entidade que armazena usuários;
b) Addresses: entidade que armazena endereços dos usuários.
3.3 IMPLEMENTAÇÃO
Nesta seção são descritas as técnicas e as ferramentas utilizadas para o
desenvolvimento das aplicações e está estruturada da seguinte maneira: a subseção 3.3.1 traz
técnicas e ferramentas utilizadas e o esquema de tecnologias utilizadas; a subseção 3.3.2 traz
o diagrama de implantação; a subseção 3.3.3 traz a Codificação do sistema e por fim, a
subseção 3.3.4 traz a operacionalidade da implementação.
3.3.1 Técnicas e ferramentas utilizadas
Esta subseção descreve as técnicas e as ferramentas utilizadas na implementação do
sistema desenvolvido, que foram aplicadas em diferentes etapas durante a elaboração deste
trabalho. Em um primeiro momento foi realizado um aprofundamento bibliográfico sobre o
tema do trabalho, especificamente sobre os assuntos citados na fundamentação, nas
referências bibliográficas e trabalhos correlatos. Após isso deu-se início as etapas do Design
Thinking, como explicado na seção 2.3, começando pela fase de inspiração. Na fase de
inspiração realizou-se uma pesquisa qualitativa para identificar o público-alvo do trabalho e
reunir pessoas relevantes para a oficina de Design Thinking, que inicialmente instigou a
criatividade de ideias para a fase de ideação posteriormente. A fase de ideação consistiu em
reunir informações e problemas identificados na fase de inspiração e transformá-los em
funcionalidades e protótipos ao término da oficina de Design Thinking (subseção 3.1.2).
A partir das informações obtidas na etapa de inspiração foi realizado o levantamento
dos requisitos que constam na subseção 3.2.1. A especificação e análise ocorreu pela
formalização das funcionalidades das aplicações com apoio das seguintes estruturas: diagrama
de casos de uso; diagrama de atividade; modelo de persistência; diagrama de casos de uso; e
modelo de entidade de relacionamento. Todas as estruturas foram desenvolvidas com a
Unified Modeling Language (UML), utilizando algumas ferramentas para digitalizá-los como
Microsoft Paint e Diagrams.net.
Para desenvolver o sistema foi utilizada para o back end a framework .Net com a
linguagem Csharp e banco de dados Postgre SQL, contemplando o cadastro e login de
usuários com geração de token de acesso na autenticação via JSON Web Token (JWT). Na
camada de front end foi utilizada a framework Angular e a biblioteca Ng-Zorro para auxílio
da construção da interface do usuário. Como ambientes de desenvolvimento foram utilizadas

44
com duas Interfaces de Desenvolvimento (Integrated Development Environment - IDEs)
Visual Studio e Visual Studio Code. Para hospedagem em servidor, utilizaram-se os serviços
do Heroku, uma plataforma que suporta e facilita o desenvolvimento em nuvem de aplicações
web. Neste meio, foi inserido o back end e o front end, bem como os mocks de dados do front
end na nuvem. O banco de dados utilizado é o Postgre SQL e para poder subir ao servidor do
Heroku, o mock JSON foi englobado por um projeto simples de NodeJS apenas para tais fins,
não tendo nenhuma influência no funcionamento do sistema ou mocks. Além disto, os três
repositórios (back end, front end e mock JSON) foram hospedados no GitHub para controle
de versão e hospedagem de código para comunicação com o servidor Heroku.
A última etapa é referente à verificação e validação do sistema. Nesta etapa buscou-se
analisar e avaliar a usabilidade, a comunicabilidade e a experiência do usuário das interfaces
desenvolvidas e de suas funcionalidades pelo método Relationship of M3C with User
Requirements and Usability and Communicability Assessment in groupware (RURUCAg).
Desta forma, os participantes da oficina de DT e pessoas selecionadas aleatoriamente foram
convidadas para participar dessa avaliação. Para tal, foi criado um protocolo de avaliação na
ferramenta Google Forms contendo: termos de aceite necessários, roteiro das tarefas pré-
definidas e por fim, um questionário para avaliar o sistema desenvolvido.
Na Figura 19, é apresentado o esquema de tecnologias, que busca trazer a relação das
tecnologias utilizadas no desenvolvimento deste projeto. O diagrama está separado nas
seguintes finalidades: servidor, distribuição, cliente e desenvolvimento. Para o
servidor, utilizaram-se os serviços do Docker e Heroku para manter o sistema ativo e na
nuvem, com a colaboração do JSON e do Postgre SQL entregando os dados do sistema. Ao
passo que, o desenvolvimento do sistema foi feito utilizando as duas IDE, sendo o Visual
Studio Code para o front end e o Visual Studio para o back end, escolhidos pela
compatibilidade com as tecnologias utilizadas no desenvolvimento. O framework Angular foi
utilizado para desenvolvimento dos componentes de front end do sistema, com as diretivas e
demais componentes prontos que a framework oferece. As linguagens de programação
utilizadas foram Typescript para front end e Csharp para back end. Foi feito um projeto
básico em NodeJs que abrigasse o arquivo JSON para hospedar e poder ter versionamento do
mock API.
Para a interface gráfica do sistema foram utilizadas as linguagens HyperText Markup
Language (HTML) para estruturação de componentes visuais e para definir layouts, cores e
estilos padronizados ao formar componentes utilizou-se a linguagem Leaner Style Sheets

45
(LESS). Para auxiliar na construção de componentes na interface gráfica, foi utilizada a
biblioteca visual para interfaces de usuário Ant Design. Todo código-fonte gerado para o
sistema foi hospedado em três diferentes repositórios na plataforma GitHub. A distribuição
do sistema ocorre pelo deployment de arquivos compilados para o sistema hospedado na
nuvem. O cliente faz uso do sistema via aparelho computador no navegador de preferência.
Figura 19 - Esquema de tecnologias utilizadas no Nuki's Brechó
3.3.2 Diagrama de implantação
Nesta subseção é apresentado o diagrama de implantação (Figura 20). O nó
<<dispositivo>> Navegador web em computador representa os dispositivos usados pelos
usuários que usam o sistema rodando na nuvem. Este nó se comunica por meio de APIs com
protocolo HTTPS com o serviço <<dispositivo>> API Mock JSON que está contido no
servidor <<dispositivo>> Heroku Servidor JSON. De igual forma, os serviços
<<dispositivo>> API Usuários e <<dispositivo>> Base de dados Postgres
também se comunicam via protocolo HTTPS usando o servidor <<dispositivo>> Heroku
servidor back end.

46
Figura 20 - Diagrama de implantação
3.3.3 Codificação do sistema
Esta subseção apresenta algumas codificações fundamentais do sistema, exibindo as
principais funcionalidades do Nuki’s Brechó. A primeira codificação exibida é apresentada no
Quadro 6, com o método sendQuestion, que mostra o código responsável pelo envio de
perguntas em produtos, função importante do sistema. Para tal, primeiramente verifica se o
conteúdo do formulário da pergunta controlado por FormGroup em text área no HTML (linha
02) é válido. Assim, prossegue para o envio da pergunta atribuindo valor true para a variável
submitting, na linha 03. Em seguida, com uma promise, chama o método
sendQuestionPromise (linha 05), que irá fazer o mapeamento do objeto, criando um novo
objeto pergunta e inserindo no JSON de perguntas por meio de uma requisição HTTP post.
Assim que esta ação for feita, o método notifyAdminsPromise é chamado para inserir
também via HTTP post a notificação da nova pergunta no JSON que irá aparecer nas
notificações de todos os usuários administradores (linha 06). Após a promise ser realizada, na
linha 08 o campo no qual o usuário digitou a pergunta enviada é limpo e em seguida uma
notificação temporária em tela informando sucesso é convocada para a tela, conforme
apresentado na linha 09. Se houver algum problema com o envio da pergunta, é realizado o
processo que está nas linhas 11 e 12, e enviam uma notificação temporária de erro na tela do
usuário informando que um erro ocorreu e por consequência a variável submitting fica falsa
(linha 14).

47
Quadro 6 - Codificação para usuários enviarem perguntas em produtos
01 public async sendQuestion() {
02 if (this.formUserQuestion.valid && this.formUserQuestion.dirty){
03 this.submitting = true;
04 await Promise.all([
05 this.sendQuestionPromise(),
06 this.notifyAdminsPromise(),
07 ]).then(() => {
08 this.inputValue = '';
09 this.notification.success('Sucesso!', 'Pergunta enviada');
10 this.getMessages();
11 }).catch(error => {
12 this.notification.error('Oops!', error)
13 });
14 this.submitting = false;
15 }
16 }
Ao passo que o usuário envia perguntas em produtos, o administrador pode responder
as perguntas, como consta representação do código no Quadro 7 com a implementação do
método sendAnswer. O método possui dois parâmetros (linha 01), um deles é o id, que
representa o identificador único da pergunta em que o administrador irá publicar a resposta;
enquanto o parâmetro userId representa o identificador único do usuário que publicou a
pergunta. Na linha 02 há uma constante que guarda a subscrição da chamada do método da
linha 03, para que, como na linha 06, a variável seja inserida na lista de subscrições e
posteriormente no método ngOnDestroy, seja dado unsubscribe de todas estas subscrições.
Para então fazer o envio da resposta, na linha 03 é chamado o serviço chatService,
invocando seu método update, que é uma requisição HTTP put que insere uma resposta na
pergunta que já havia sido criada no momento que o usuário a enviou. O método update pede
como parâmetro um objeto de pergunta, portanto, como parâmetro é chamado o método
mapAnswerToModel com o parâmetro id da pergunta, que mapeia o objeto pergunta e suas
propriedades. Desta forma, na linha 04 é chamado o método notifyUserPromise que é
responsável por enviar, via HTTP post, uma notificação para o usuário que fez aquela
pergunta, usando o parâmetro userId, dizendo que a pergunta que ele havia feito foi
respondida.
Quadro 7 - Codificação para administradores responderem perguntas em produtos
01 public sendAnswer(id: string, userId: string) {
02 const subscription =
03 this.chatService.update(this.mapAnswerToModel(id)).subscribe({
04 next: () => this.notifyUserPromise(userId)
05 });
06 this.subscriptions.push(subscription);
07 }

48
Uma das funções administrativas do sistema é poder visualizar todos os usuários
cadastrados. No Quadro 8 está ilustrado o método getAllUsers, que conforme linha 01
retorna um Observable de lista de UserGetAllModel, que tem as propriedades de objetos do
tipo usuário. O método retorna uma requisição HTTP do tipo get, na qual a variável http
utilizada na linha 02 se refere à uma injeção de dependência de HttpClient no construtor do
serviço em questão que se encontra tal método. Ao chamar o método get do http, é
sinalizado que ele retornará uma listagem de usuários. Ao fazer a requisição para a api do
back end, conforme linha 03 com a variável urlApiBack, é requerido o get de users. Nas
próximas linhas é feito um pipe para que caso ocorra algum erro na execução deste método,
ele seja retornado como resposta do método (linha 04).
Quadro 8 - Codificação para administradores visualizarem todos os usuários cadastrados
01 public getAllUsers(): Observable<UserGetAllModel[]> {
02 return this.http.get<UserGetAllModel[]>
03 (this.urlAuthApiBack + 'users/')
04 .pipe(catchError(error => throwError(error.error.errors[0])));
05 }
Conforme Quadro 9, a média de avaliações por estrela do sistema é apresentada em
tela por meio do método getStarsAverage. O método retorna um observable do objeto
StarsModel (linha 01) ao fazer a requisição HTTP get invocando a variável urlApiV1 com o
endpoint stars, que diz respeito às avaliações no mock JSON (linha 02). Após isto é feito um
pipe para que caso venha a ocorrer quaisquer erros ao consultar a média, ele retorne ao
método (linha 03).
Quadro 9 - Codificação para consulta da média de avaliações do sistema
01 public getStarsAverage(): Observable<StarsModel> {
02 return this.http.get<StarsModel>(this.UrlApiV1 + 'stars')
03 .pipe(catchError(error => throwError(error.error.errors[0])));
04 }
3.3.4 Operacionalidade da implementação
Nesta subseção será demonstrado o funcionamento da implementação por meio das
telas desenvolvidas para os usuários. A primeira interface exibida ao usuário é a Tela
inicial, na qual é apresentada uma listagem de produtos, que busca apresentar os produtos
disponíveis, ordenados de forma que os mais novos fiquem sempre no topo. Demonstrado na
Figura 21, o usuário pode: visualizar tais produtos (letra A); pesquisar produtos por título
(letra B) ou por filtros rápidos (letra C); redirecionar-se para a página de Ajuda e

49
Avaliações (letra D); escolher realizar login no sistema ao selecionar a opção Entrar, (letra
F); acessar qualquer produto exibido na listagem, clicando sobre ele. As informações
apresentadas sobre os produtos na listagem são as essenciais para que o usuário julgue
necessário ou não acessar e saber mais detalhes sobre aquele produto, sendo elas: preço, título
descritivo, marca e foto principal (letra A).
Conforme mostra letra B, na barra de pesquisa, ao digitar alguma palavra de busca, são
filtrados os produtos com o título pesquisado e exibido no select, que, quando uma opção é
selecionada, redireciona o usuário a tela daquele produto em questão. Nos filtros rápidos,
exibidos na letra C, são disponibilizados três filtros específicos organizados por categoria,
sendo elas: Roupas; Acessórios e Calçados. A opção Todos os produtos apresenta, sem
filtrar por categoria, todos os produtos ativos do sistema. As quatro opções de filtros rápidos
levam o usuário à listagem da opção selecionada, portanto, se o usuário selecionar Calçados,
será redirecionado à uma listagem somente com calçados ativos.
Figura 21 - Tela inicial para usuários não autenticados
Fonte: elaborada pela autora.
Quando o usuário ainda não autenticado no sistema acessa a Tela de produto, todas
as informações do produto são carregadas normalmente. Porém, como é demonstrado na
Figura 22, pela falta de autenticação no sistema, o usuário não pode comprar o produto (letra
A), curtir o produto (letra B) e nem enviar uma pergunta (letra C).

50
Figura 22 - Tela de produto para usuários não autenticados
Ao selecionar a opção de entrar no sistema (Figura 21 letra E), o usuário é
redirecionado para a Tela de login. Conforme Figura 23, as opções exibidas são: Já
tenho cadastro (letra A), para usuários previamente cadastrados no sistema que desejam
realizar a autenticação apenas; e Sou novo aqui (letra B) para usuários ainda não
cadastrados.
Figura 23 -Tela de login

51
Ao selecionar a opção Sou novo aqui (Figura 23 letra B), o usuário é redirecionado
para a Tela de cadastro de usuário apresentada na Figura 24, na qual deve preencher
corretamente as seguintes informações: Nome; E-mail; Rua; Número; Bairro; CEP; Cidade;
Complemento; Estado; Senha. Todos os campos possuem validações que devem ser
cumpridas para envio do formulário de cadastro, como aviso de campo obrigatório caso o
usuário não preencha (letra A) e aviso de mínimo e máximo de caracteres quando pertinente
(letra B). O campo Estado, que é um campo selecionável, também é pesquisável, ou seja, se
o usuário digitar o estado no campo, virão resultados de acordo com a pesquisa, se houverem,
como exemplificado na letra C. No campo de Senha, o texto digitado inicialmente será
ocultado por pontos ao invés de letras, porém há uma ícone de olho, destacado pela letra D,
com a finalidade de possibilitar o usuário ler sua senha para conferência. Com o
preenchimento destas informações, o botão Enviar (letra E) é habilitado e clicando nele o
usuário é cadastrado no sistema e redirecionado à página inicial, juntamente com uma
notificação temporária de sucesso exibida em tela.
Figura 24 - Tela de cadastro de usuário para login
Se o usuário optar pela opção Já tenho cadastro (Figura 23 letra A), é
redirecionado à Tela de login convencional apresentada na Figura 25, na qual inserindo
seus dados cadastrais de E-mail e Senha é habilitado o botão Enviar (letra A). Ao selecionar
o botão Enviar, o usuário será redirecionado à tela inicial do sistema juntamente com a
exibição de uma notificação temporária indicando sucesso.

52
Figura 25 - Tela de login por e-mail e senha
Ao entrar no sistema por autenticação, o usuário terá a mesma tela inicial, porém com
funções a mais. Conforme Figura 26, logo na barra de navegação aparece uma mensagem de
boas-vindas ao usuário com o nome de cadastro (letra A) e as seguintes funções são exibidas:
opção Minha conta, que é a conta do usuário autenticado (letra B); opção de Meus pedidos,
para visualizar os pedidos que já foram realizados por aquele usuário (letra C); opção de
visualizar as Notificações da conta de usuário (letra D); e pôr fim a opção de Sair do
sistema (letra E). Ao clicar em Sair, a conta do usuário é desconectada do sistema e ele volta
para a página inicial. Cada uma das opções leva o usuário até a página em questão ou
realizam a função mencionada ao clicar sob ela.

53
Figura 26 - Tela inicial usuário autenticado
Assim, o usuário autenticado que selecionar a opção Minha conta (Figura 26 letra B)
será redirecionado à Tela de perfil apresentada na Figura 27, contendo todas suas
informações cadastrais prontas para serem editadas, se o usuário assim desejar. O usuário
pode alterar quantas e quais informações quiser. O formulário é similar ao de cadastro,
contendo a mesma lógica de avisos de erros e limites de campos (Figura 24), visíveis nas
letras A, B e C. Também tem a opção de deixar a senha visível ou não para digitação e
conferência (letra D). No canto inferior esquerdo da tela (de cima para baixo e da esquerda
para direita), há o botão Voltar, para que o usuário volte à página que estava anteriormente
do sistema, caso não queira prosseguir com a edição das informações de perfil (letra E). Com
o formulário corretamente preenchido, o botão Enviar, destacada pela letra F, é habilitado e
ao selecioná-lo o usuário receberá uma notificação temporária em tela informando o sucesso.

54
Figura 27 - Tela de perfil
Quando um usuário que ainda não possui pedidos no sistema ou notificações em sua
conta acessa a tela Meus pedidos ou Notificações, é exibido uma ilustração informando
que não há informações, convidando o usuário a fazer compras, levando-o à tela inicial ao se
clicar nele. A rotina de notificações relaciona-se com o pilar da Comunicação do M3C,
conforme visto na seção 2.2. Conforme Figura 28, ambas as páginas possuem o botão Voltar
no canto inferior esquerdo (de cima para baixo e da esquerda para direita). Ao selecionar essa
opção, o usuário é redirecionado à página anterior. A Figura 28 (a) traz a Tela de
notificações sem informações, enquanto a Figura 28 (b) apresenta a Tela de pedidos do
usuário sem informações.

55
Figura 28 - Telas de notificações (a) e pedidos do usuário (b) sem informações
Para haver dados nas telas de Notificações e Meus pedidos, o usuário deve realizar
uma compra ou ter alguma pergunta respondida em algum produto. Para tal, quando um
usuário autenticado acessa um produto, ele visualiza da forma exibida na Figura 29 (a). Por
estar autenticado, são liberadas as seguintes funções: curtir produto (letra A), que se
selecionado torna o ícone de coração preenchido com cor; Comprar Agora (letra B); e Enviar
perguntas sobre o produto (letra C), por uma caixa de texto aberta para digitação. Ao enviar
uma pergunta sobre aquele produto evidenciando a Comunicação do M3C, uma notificação
temporária aparece na lateral da tela, conforme mostrado na Figura 29 (b) letra A, indicando
Sucesso. A pergunta enviada aparece em tela, conforme destacada pela letra B na Figura 29
(b), mesmo que ainda não tenha resposta, pois aparece a informação de que a pergunta está
aguardando resposta e caso tenha resposta, ela é carregada juntamente com a pergunta.

56
Figura 29 - Tela de produto para usuário autenticado
Ao selecionar a opção Comprar agora, o usuário é redirecionado a Tela de compra,
exibida na Figura 30. A Tela de compra é dividida por dois containers. O container
destacado pela letra A é responsável por informar ao usuário como se dará o decorrer da
compra, bem como dados sobre o produto e dados de entrega. No container destacado pela
letra B contêm informações de pagamento, detalhando cada item que compõe o valor Total
a pagar. O usuário tem a opção de realizar pagamento via PIX ou Transferência
Bancária, e, selecionando o método de preferência, são exibidas informações sobre o método
de pagamento e os dados necessários. Para que o usuário possa concluir a compra, ele deve
inserir o comprovante de pagamento no campo sinalizado pela letra C. Ao inserir o
comprovante, o sistema habilita o botão Confirmar compra, que, selecionado, leva o usuário
à Tela de confirmação.

57
Figura 30 - Tela de compra
Após ter sua compra confirmada, o usuário será redirecionado à Tela de
confirmação de compra, apresentada na Figura 31. Desta forma, juntamente com uma
notificação temporária de sucesso (letra A), a tela traz informações sobre o status do pedido
para o usuário (letra B), com a opção de ir até a tela Meus pedidos quando o usuário
escolher o botão destacado na letra C.
Figura 31 - Tela de confirmação de compra
Quando o usuário que já fez algum pedido acessa a tela Meus pedidos, encontra,
conforme Figura 32, uma listagem com todos seus pedidos, detalhando conforme letra A,
informações do produto comprado como: Título, Foto e Valor. Também é exibida a Data

58
da compra, representada na letra B, bem como o Status da compra, conforme letra C. Ao
selecionar as opções das letras D ou E o usuário é redirecionado à tela de Ajuda e
Avaliações, na qual poderá encontrar informações de contato. Usuários administradores não
tem acesso à Tela meus pedidos, pois não podem realizar compras no sistema.
Figura 32 - Tela meus pedidos
Redirecionando-se à tela de Ajuda e avaliações, o usuário ou administrador
visualizará as informações conforme Figura 33. Ao selecionar as opções disponíveis, logo
abaixo abrirá o conteúdo dela. Na opção Quem somos? há informações sobre o Nuki’s Brechó
e como surgiu (letra A). A opção Como comprar? traz informações de como funciona a
compra no sistema Nuki’s Brechó conforme mostra letra B. Ao abrir a opção Avaliações,
representada na letra C, o usuário encontrará informações sobre a avaliação do sistema,
evidenciando a Cooperação do M3C, conforme visto na seção 2.2. A avaliação se dá por um
sistema de estrelas, com a nota mínima sendo um (1) e a máxima cinco (5) e a quantidade de
estrelas pintadas de amarelo representa a nota atual do sistema. Ao clicar em uma estrela, a
nota atribuída é enviada e a nota será recalculada em seguida, ao passo que aparecerá uma
notificação temporária indicando sucesso no canto superior da tela, conforme letra D. Ao
selecionar a opção Contato, o usuário poderá visualizar três meios de contato com os
responsáveis do sistema, conforme letra E, e, ao clicar sobre algum, é redirecionado para ele,
fora do sistema.

59
Figura 33 -Tela de ajuda e avaliações
Quando um usuário ou administrador acessa a tela Notificações, tem visibilidade de
todas as notificações de sua conta, que aparecem em ordem decrescente, ou seja, as
notificações mais recentes encontram-se no topo da listagem. As notificações de
administradores, conforme ilustrado na Figura 34 (a), são sobre novas perguntas em produtos
e novas compras de usuários. As notificações de todos os usuários com permissão de
administrador são iguais, ou seja, se algum usuário realizar uma compra ou pergunta, todos os
administradores serão notificados. Já as notificações de usuários, conforme Figura 34 (b),
referem-se a perguntas respondidas apenas daquele mesmo usuário. Sempre que for clicado
sobre a notificação, ela redirecionará o usuário à tela do produto em questão.

Nuki's Brechó: Sistema Colaborativo em um Cenário de Moda Sustentável - Anuska Kepler Rehn

Nuki's Brechó: Sistema Colaborativo em um Cenário de Moda Sustentável - Anuska Kepler Rehn

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Nuki's Brechó: Sistema Colaborativo em um Cenário de Moda Sustentável - Anuska Kepler Rehn

Semelhante a Nuki's Brechó: Sistema Colaborativo em um Cenário de Moda Sustentável - Anuska Kepler Rehn (20)

Nuki's Brechó: Sistema Colaborativo em um Cenário de Moda Sustentável - Anuska Kepler Rehn