CENTRO UNIVERSITÁRIO DE JOÃO PESSOA - UNIPÊ

PRÓ-REITORIA ACADÊMICA – PROAC

CURSO SUPERIOR DE TECNOLOGIA EM SISTEMAS PARA INTERNET

ISAIAS LEITE SILVA

ISRAEL ARAÚJO RODRIGUES

WALCLÊNIA DE FRANÇA BRAGA

WENDELL CLIVE SANTOS DE LIRA

RECEITA SEGURA – Sistema de Emissão de Receitas de Medicamentos e Atestados

Antifraude

JOÃO PESSOA-PB
2020
 ISAIAS LEITE SILVA

ISRAEL ARAÚJO RODRIGUES

WALCLÊNIA DE FRANÇA BRAGA

WENDELL CLIVE SANTOS DE LIRA

RECEITA SEGURA – Sistema de Emissão de Receitas de Medicamentos e Atestados

Antifraude

Relatório Técnico apresentado ao Curso Superior de

Tecnologia em Sistemas para Internet do Centro
Universitário de João Pessoa - UNIPÊ, como pré-
requisito para a obtenção do grau de Tecnólogo em
Sistemas para Internet, sob orientação do Professor
Mestre Thiago Rodrigues Medeiros.

JOÃO PESSOA-PB

2020
AGRADECIMENTOS
 RESUMO

Palavras chave:
 ABSTRACT

Keywords stock:
 LISTA DE TABELAS

Quadro 1 - Principais Softwares de Filas do Mercado.............................................................10

Quadro 2 - Lean Canvas do Produto.........................................................................................16
Quadro 3 - Requisitos Funcionais.............................................................................................23
Quadro 4 -Requisitos Não-Funcionais......................................................................................24
 LISTA DE ILUSTRAÇÕES

Figura 1 - Tela de Login...........................................................................................................14

Figura 2 - Tela de validação de documentos............................................................................14
Figura 3 - Tela de Login WebAtestados...................................................................................15
Figura 4 - Tela de Validação de Atestados...............................................................................15
Figura 5 - Tela de Login - Atestado Médico Digital................................................................16
Figura 6 - Tela de Validação de Documentos...........................................................................16
Figura 7 - Tela de Login Atestify.............................................................................................17
Figura 8 - MVP - Minimum Viable Product.............................................................................24
Figura 9 - Diagrama de Caso de Uso........................................................................................28
Figura 10 - Diagrama de Classe................................................................................................29
Figura 11 - Diagrama de Entidade-Relacionamento do Banco de Dados................................30
Figura 12 - Arquitetura do Sistema...........................................................................................31
 SUMÁRIO

1. INTRODUÇÃO......................................................................................................................9
1.1 CONTEXTO E MOTIVAÇÃO...........................................................................................9
1.2 COMPETIDORES.............................................................................................................10
1.3 PROBLEMA......................................................................................................................14
1.4 SOLUÇÃO.........................................................................................................................15
1.5 LEAN CANVAS...............................................................................................................16
1.6 OBJETIVOS......................................................................................................................17
1.6.1. Objetivo geral....................................................................................................18
1.6.2. Objetivos específicos........................................................................................18
1.7 INDICAÇÃO DE METODOLOGIA................................................................................18
1.8 ESTRUTURA DO DOCUMENTO...................................................................................19
2.1 LEAN STARTUP..............................................................................................................20
2.2.1 MVP - MINIMUM VIABLE PRODUCT...............................................................20
2.2 PROCESSO DE DESENVOLVIMENTO ÁGIL..............................................................21
2.3 DESCRIÇÃO SIMPLES DOS REQUISITOS..................................................................22
2.3.1. Requisitos Funcionais.......................................................................................22
2.3.2 Requisitos Não Funcionais................................................................................23
2.4 ANÁLISE DOS REQUISITOS.........................................................................................24
2.4.1 Principais Diagramas de Caso de Uso..........................................................25
2.4.2 Diagrama de Classes.....................................................................................26
2.4.3 Projeto de Banco de Dados...........................................................................27
2.5 ESPECIFICAÇÃO ARQUITETURAL E TECNOLOGIAS UTILIZADAS...................27
2.5.1. Tecnologias Utilizadas......................................................................................28
2.5.3. Estratégias para o Design de Interface.............................................................32
2.5.3.1. User Experience............................................................................................32
2.5.3.2. Protótipos de Interface..................................................................................33
2.5.3.3. Principais interfaces do Sistema...................................................................33
2.6 PLANO DE TESTES DO PROTÓTIPO...........................................................................33
3 RESULTADOS......................................................................................................................36
3.1 AMBIENTE DOS TESTES E AVALIAÇÃO..................................................................36
3.2 AVALIAÇÃO DA SOLUÇÃO.........................................................................................36
3.2.1 Análise quantitativa............................................................................................36
3.2.2 Análise qualitativa..............................................................................................36
CONSIDERAÇÕES FINAIS....................................................................................................37
REFERÊNCIAS........................................................................................................................38
1. INTRODUÇÃO

É uma pratica bastante significativa na vida da população brasileira a automedicação e

a compra de atestados e receitas falsificados. Notícias recentes apontam que cerca de 30% dos
atestados emitidos no país são falsificados (Nader,2020).

Quando o assunto é atestado médico, é uma pratica muito utilizada por diversos
trabalhadores, uns precisam de tratamento médico outros utilizam de má fé fingem sintomas
que façam os médicos acreditarem que o paciente precisa se afastar do trabalho ou
simplesmente buscam a forma mais rápida e talvez também a mais barata, o mercado negro. A
falsificação de atestados pode causar prejuízos bilionários à empresas privadas e aos órgãos
públicos girando em torno de R$33 bilhões, segundo Wolff (2019).

Hoje em dia a grande maioria dos receituários e atestados são emitidos sem
burocracia, o documento só precisa ter um carimbo com CRM do médico e uma assinatura, os
dados do carimbo podem até ser fictícios pois não há forma de verificar a proveniência do
documento. Pesquisas feitas mostram que existe como comprar um atestado ou uma receita
pela internet com muita facilidade.

Baseado em notícias como estas o presente estudo apresenta o desenvolvimento de um

sistema para emissão de receituário médico, tanto para medicamentos simples como
controlados, como também para emitir atestados médicos. Os documentos conterão em seu
escopo uma chave de validação, esta chave servirá para que as farmácias e as empresas sob
posse deste documento possam verificar a veracidade do mesmo.

9
1.1 CONTEXTO E MOTIVAÇÃO

É cada dia mais recorrente os brasileiros procurarem “soluções” de mais fáceis mesmo
sendo ilegítimas e podendo trazer consequências graves para sua própria saúde. Ao se
automedicar as pessoas estão claramente fazendo mal a si mesmas como também agravando
saúde pública dado que esta pessoa muito provavelmente irá necessitar de maiores cuidados
podendo chegar a necessitar de internações e/ou até mesmo de cirurgias dado que o
medicamento que o próprio paciente escolheu no mercado negro, em muitos casos, não irá
tratara raiz do problema, podendo estar apenas mascarando agravando assim a saúde no
estado geral.

A classe médica no Brasil possui cerca de 497.105 mil médicos ativos segundo dados
informados no site do conselho regional de medicina do estado da Paraíba. Uma quantidade
expressiva que pode ser explorada a taxa de pagamento pela utilização do sistema de emissão
de receitas e certificados.

1.2 COMPETIDORES

Pesquisas recentes apontam algumas plataformas que oferecem um serviço semelhante

ao proposto por este estudo. As principais estão listadas no quadro um abaixo que relaciona os
principais softwares pesquisados na Internet e seus diferenciais positivos e negativos:

Quadro 1 - Principais Softwares de Filas do Mercado

Software Empresa Plataforma Pago

VeusSaúde Veus Web Sim

Webatestados Ames Web Sim

Atestado Medico Digital Associação Paulista de Web/Mobile Sim

10
 Medicina Multiplataforma

Atestify Atestify Web Sim

Fonte: Elaboração própria (2020).

Abaixo apresentamos as telas dos sistemas dos concorrentes acima descritos, bem
como descrição de algumas funcionalidades.

 Veus Saude

O sistema Web é utilizado para a emissão de laudos médicos (não especificados na

plataforma), faz integração entre médicos, clínicas, laboratórios como uma plataforma
colaborativa.

A Figura 1 abaixo mostra a tela de login, o usuário poderá ter acesso ao sistema para
emitir os documentos oferecidos pela plataforma.

Figura 1 - Tela de Login

A figura 2 mostra a tela de validação de um documento emitido pelo sistema

VeusSaude.
11
 Figura 2 - Tela de validação de documentos

 Sistema - WebAtestados

Sistema Web para a emissão e validação de atestados médicos, utilizado por médicos
da Associação Médica do Espítito Santo. As figuras 3 e 4 abaixo mostram a interface do
sistema.

12
 Figura 3 - Tela de Login WebAtestados

Figura 4 - Tela de Validação de Atestados

 Atestado Médico Digital

O sistema web atestado médico digital é uma plataforma de emissão de atestados

médicos com validação. O sistema não emite outros tipos de documentos médicos. Os
médicos que podem utilizar o sistema fazem parte da Associação Paulista de Medicina.

13
 A figura 5 abaixo mostra a tela de login, onde o médico deverá estar logado para poder
emitir um atestado com certificação digital.

Figura 5 - Tela de Login - Atestado Médico Digital

A figura 6 mostra a tela de validação de documentos do sistema web Atestado Médico

Digital, onde a empresa que estiver de posse do documento em mãos poderá verificar a
autenticidade do mesmo.

14
 Figura 6 - Tela de Validação de Documentos

 Atestify

O Atestify é um sistema de emissão de atestados médicos utilizado na cidade de Goiás, o

sistema garante a veracidade do documento emitido pelo mesmo. A figura 7 nos mostra a tela
de acesso ao sistema. A validação do documento só pode ser feita se a pessoa, física ou
jurídica, estiver devidamente cadastrado no sistema. O sistema perde neste aspecto pois é
preciso ter uma gama de clientes e parcerias muito alta para atender todas as organizações da
cidade.

15
 Figura 7 - Tela de Login Atestify

1.3 PROBLEMA

A emissão de receituários e atestados falsificados tem se tornado uma prática comum

na vida de muitos brasileiros por diversos motivos como afirmar não ter tempo de ir ao
médico, achar que pode se tratar com o mesmo remédio que um conhecido por uma simples
comparação de sintomas. Outros compram atestados médicos simplesmente para não
comparecer ao trabalho. Estes atos podem acarretar em problemas graves de saúde pública,
assim como também um problema econômico. A saúde pública pode ser afetada custando
mais aos cofres públicos tratando de problemas de saúde causados por automedicação, o
paciente pode agravar seu estado de saúde ou até mesmo desencadear uma outra doença
necessitando no futuro de cuidados médicos reais e mais invasivos. Os atestados por sua vez
podem afetar a economia pois uma empresa pode vir a ter sérios problemas de produção e/ou
atendimento caso alguns funcionários venham a não comparecer para trabalhar, a empresa
mesmo que verifique que o funcionário não faltou por motivos reais ela não poderá demiti-lo
dado que ele está com o seu direito assegurado por um atesto, esse ato afeta a produtividade
da empresa podendo gerar péssimos resultados, por sua vez arrecada um montante menor
16
assim enviará menos impostos ao governo, somando a outras inúmeras outras empresas
poderá acarretar em uma desaceleração da economia.

1.4 SOLUÇÃO

O sistema proposto neste estudo pretende tentar solucionar os problemas de

falsificação de receituários médicos e atestados. A solução irá efetuar a emissão dos
documentos citados que conterão em seu escopo os dados de um médico real devidamente
cadastrado em um ou mais dos conselhos regionais de medicina, os dados do paciente, o
medicamento e a chave de validação, com esta chave o farmacêutico irá acessar o sistema e
verificar se o documento em mãos é legítimo. De maneira semelhante ocorrerá com o
atestado, a empresa que receber o documento poderá verificar a legitimidade do mesmo.

17
1.5 LEAN CANVAS

O Quadro 2, apresenta as informações gerais do projeto de desenvolvimento do sistema de emissão de receituários e atestados bem como outras
informações levantadas para o desenvolvimento do mesmo:

Quadro 2 - Lean Canvas do Produto

PROBLEMA SOLUÇÃO OFERTA VALOR VANTAGEM INJUSTA SEMENTO DE CLIENTES

 Validação de receituários
 Validação de atestados
 Redução de burocracia na
emissão de receituários
especiais.
 Criar um sistema de emissão
de receituários e atestados
com chave de validação,
emitidos apenas por médicos
cadastrados nos conselhos
regionais de medicina do
país.
RECURSOS-CHAVE
 Captação de recursos anjos e
investidores sócios.
 Validação on-line  Redução de custos com saúde  Médicos
pública
 Emissão de Receitas  Pacientes
controladas pela ANVISA  Melhores resultados
econômicos
 Conselhos Regionais de
 Dados estatísticos Medicina
CANAIS
 Assegurar a legitimidade dos
documentos
 E-mails

 Veiculação via redes sociais,

 Investir nos clientes outdoors, TV.

18
  Propagandas na própria
plataforma.

ESTRUTURA DE CUSTO FONTES DE RECEITA

 Hospedagem anual, desenvolvimento, loja de aplicativos, totem,  Conselhos Regionais de Medicina

tablet, impressora não-fiscal, internet e computadores

 Propaganda interna e parcerias com convênios.

19
 A sessão problema do lean canvas informa os principais problemas enfrentados em
questões de emissão de receitas médicas e atestados tais como:
 Validação de receituários com o intuito de evitar a emissão de receitas, tanto as
simples quanto as especiais, falsificadas.
 Validação de atestados para que as organizações sintam segurança no
documento entregue pelo funcionário e haja uma inibição ao ato de faltar o
trabalho.
 Redução de burocracia na retirada de talões de receitas especiais, não se
fazendo mais necessário que um médico tenha que se deslocar para adquirir o
talão especial disponibilizado apenas pela Agencia Nacional de Saúde
(ANVISA).
Como solução para estes problemas o presente estudo pretende elaborar um sistema de
emissão de receitas e atestados que conterão uma chave de validação para que possa ser
verificada a legitimidade do documento. No caso das receitas especiais apenas médicos
registrados e autorizados pelos conselhos regionais de medicina poderão emiti-las pelo
sistema.
Como proposta de valor o sistema terá as emissões controladas pelas regras da
ANVISA porém com muito mais rapidez e agilidade, para isso o médico só necessitará dispor
de um computador com acesso à internet. A validação das receitas e atestados serão feitas
online em segundos, assim as organizações poderão tomar as medidas cabíveis a cada caso. O
sistema contará também com a disponibilização de informações estatísticas que poderão ser
utilizadas para fins econômicos ou simplesmente informativos.
O segmento de clientes almejado pelo sistema é a classe médica, conselhos regionais
de medicina, clínicas médica e também os próprios pacientes pois terão a segurança de que
estão sendo atendidos por profissionais capacitados e regulamentados pelos conselhos de
medicina.

20
1.6 OBJETIVOS

Este estudo pretende contribuir com a qualidade de vida da população e facilitar a

emissão de recitas especiais feitas pela população médica ao oferecer uma ferramenta que irá
facilitar, agilizar e validar as receitas e atestados emitidos.

1.6.1. Objetivo geral

O objetivo geral deste estudo é o desenvolvimento de uma aplicação web para a

emissão de receitas médicas, simples e especiais, e de atestados médicos, os documentos
conterão em seu escopo uma chave de validação onde as farmácias e organizações poderão
acessar o sistema web para verificar a legitimidade do documento e assim poder vender os
medicamentos, no caso das receitas, e justificar faltas ao trabalho no caso dos atestados.

1.6.2. Objetivos específicos

O objetivo geral supracitado foi desdobrado nos seguintes objetivos específicos:

 Descrever o sistema web de emissão de receitas médicas e atestados;

 Desenvolvimento do requisito do sistema;
 Desenvolvimento do banco de dados do sistema;
 Desenvolvimento da aplicação back-end;
 Desenvolvimento da aplicação front-end;

1.7 INDICAÇÃO DE METODOLOGIA

A partir da ideia e do modelo de negócio elaborados foram feitas pesquisas de dados

estatísticos para verificar a necessidade e aceitação do sistema pelos usuários. Algumas
notícias a respeito de atestados médicos falsificados indicam que não existe uma base de
dados para tal informação, porém algumas relatam situações reais como por exemplo a revista

21
Fecormércio DF afirma que no setor são entregues aos empresários do setor varejista mais 1,8
mil atestados falsos por mês, segundo o sindicato varejista do distrito federal, o prejuízo
causado por faltas ao trabalho abonadas por atestados falsificados gira em torno de R$ 20
milhões ao ano para o comércio local do distrito federal.
Algumas notícias relatam que as receitas médicas são tão fáceis de se encontrar à
venda nas ruas quanto os atestados como a publicação do jornal Folha de São Paulo que diz
que receitas falsas de antibióticos são vendidas por camelôs custam muito menos que uma
consulta médica particular. Algumas receitas são de médicos que estão ativos, outras por
médicos já falecidos e outros nomes e registros falsos. Os vendedores de receitas falsas
também dispõem de receitas especiais já carimbadas e assinadas vendidas com a prescrição
em branco, quem compra poderá adquirir o remédio que quiser.
Sendo apurados todos os relatos possíveis a respeito da falsificação de documentação
médica deu-se início ao desenvolvimento do sistema web por meio da codificação da API e da
interface que o usuário irá manipular.

1.8 ESTRUTURA DO DOCUMENTO

Visando a melhor organização e estruturação este documento foi dividido nos

seguintes capítulos:
Capítulo 2: descreve o desenvolvimento da aplicação com embasamento teórico.
Capítulo 3: descreve os resultados obtidos com base na metodologia empregada.

2. DESENVOLVIMENTO DA SOLUÇÃO

Para o desenvolvimento da aplicação foi utilizado o framework Vue Js 1 no front-end,

a linguagem de programação java2 com o framework Spring 3para o desenvolvimento

1
https://vuejs.org/

2
https://www.java.com/pt_BR/about/whatis_java.jsp

3
https://spring.io/projects/spring-boot

22
comportamental da regra de negócio e o banco de dados relacional MySql 4. A arquitetura será
dividida em quatro camadas, a primeira para armazenar os dados, a segunda uma camada
visual desenvolvida no Vue Js e que irá consumir uma API, esta API compõe a terceira
camada que por sua vez será responsável pela comunicação do front com o back e a quarta
camada é a regra de negócio que delimita as funcionalidades do sistema.

2.1 LEAN STARTUP

A aplicação proposta por este estudo utiliza a metodologia lean startup muito utilizada
nos dias atuais, principalmente pela área de desenvolvimento tecnológico. O lean startup se
baseia em produzir o mínimo possível do produto para ser avaliado a cada etapa e caso o
produto seja reprovado pelo cliente ou pelos usuários a equipe de desenvolvimento pode fazer
alterações ou até mesmo pivotar para que as perdas sejam as mínimas possíveis. Para ter o um
melhor feedback dos clientes, ou do dono da aplicação, os desenvolvedores utilizam de
metodologias ágeis como o Scrum, assim os desenvolvedores conseguem uma maior
velocidade de informação a respeito da aplicação.

2.2.1 MVP - MINIMUM VIABLE PRODUCT

O produto mínimo viável (MVP) se trata de versões mínimas do sistema sendo

disponibilizadas para que sejam avaliadas pelos usuários, devendo dar feedbacks a respeito
das funcionalidades e da usabilidade do sistema web. O processo funciona da seguinte
maneira:
São realizadas Sprints: Iniciaremos um ciclo com desenvolvimento curto e simples
com aproximadamente uma semana para o desenvolvimento do sistema de emissão de
receitas e atestados, serão definidas as funcionalidades, participação, design e
desenvolvimento. Se encerrando com a publicação de um produto em funcionamento.
Com os Feedback: Quando o produto é publicado o ciclo volta para o início e a equipe
retorna as pesquisas relacionado aos feedbacks adquiridos.
4
https://www.mysql.com/

23
 Expansão: Cada versão publicada é um conjunto de funcionalidade fechadas, testadas
e prontas para uso.
A figura oito abaixo apresenta a estrutura organizacional de um MVP que é um
conjunto de testes primários feitos para validar a viabilidade do negócio. São diversas
experimentações práticas que serão desenvolvidas levando o produto a um seleto grupo de
clientes mas não é o produto final, estamos falando em um produto com o mínimo de recursos
possíveis, desde que (em sua totalidade) estes mantenham sua função de solução ao problema
para o qual foi criado.

Figura 8 - MVP - Minimum Viable Product

2.2 PROCESSO DE DESENVOLVIMENTO ÁGIL

O projeto foi desenvolvido em conjunto utilizando-se o Scrum, sendo dividos em

ciclos (Sprints). O Sprint representa um Time Box dentro do qual um conjunto de atividades
deve ser executado.
As funcionalidades a serem implementadas em um projeto foram mantidas em uma
lista (Product Backlog). No início de cada Sprint, realizou-se um Sprint Planning Meeting, ou
seja, uma reunião de planejamento para que o Product Owner apresentasse os itens do Product
Backlog, passo em que a equipe selecionou as atividades foram implementadas durante o

24
Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do Product Backlog
para o Sprint Backlog.
A cada dia de uma Sprint, a equipe realizou uma breve reunião (Daily Scrum), com
objetivo de disseminar conhecimento sobre o que foi feito no dia anterior, identificar
impedimentos e priorizar o trabalho do dia que se inicia.
Ao final de cada Sprint, a equipe apresentava as funcionalidades implementadas em
uma Sprint Review Meeting. Finalmente, realizava-se a Sprint Retrospective e a equipe parte
para o planejamento do próximo Sprint, reiniciando o ciclo.

2.3 DESCRIÇÃO SIMPLES DOS REQUISITOS

Nesta sessão apresentamos os requisitos funcionais e não funcionais, explicando a

funcionalidade que cada um deve ter no sistema.

2.3.1. Requisitos Funcionais

Os requisitos funcionais descrevem a funcionalidade ou os serviços que se espera que

o sistema realize em benefício dos usuários (FILHO, 2017). Eles variam de acordo com o tipo
de software em desenvolvimento, com usuários e com o tipo de sistema que está sendo
desenvolvido. Requisitos funcionais podem ser expressos de diversas maneiras e, como já foi
dito acima, em diferentes níveis de detalhamento. Os requisitos funcionais de usuários
definem recursos específicos que devem ser fornecidos pelo sistema (SOMMERVILLE,
2008).
É natural para um desenvolvedor de sistemas interpretar um requisito ambíguo para
simplificar sua implementação. Entretanto isso pode não ser necessariamente o que o cliente
necessita. Surgem então novos requisitos e é necessário realizar alterações no sistema, o que
afetará diretamente o tempo e o custo do projeto.
Inicialmente a especificação de requisitos funcionais deve ser completa – deve definir
todos os requisitos de usuário e refletir as decisões de especificação tomadas – e consistente –

25
os requisitos não devem ter definições contraditórias (FILHO, 2017). Entretanto, na realidade,
em sistemas complexos e grandes, é quase impossível atingir a consistência e a completeza
dos requisitos. Isso ocorre, principalmente, em função da complexidade inerente ao sistema e
porque as pessoas possuem diferentes pontos de vistas em relação a um problema. Esses
problemas somente emergem após uma análise mais aprofundada. À medida que os
problemas vão sendo descobertos, deve se ir atualizando o documento de requisitos
(SOMMERVILLE, 2008).
Esta seção descreve alguns dos requisitos funcionais do sistema de forma a facilitar a
compreensão do comportamento do sistema, além de possibilitar uma visão geral das
principais funções e serviços fornecidos.

Quadro 3 - Requisitos Funcionais

ID Descrição
RF01 AUTENTICAR USUÁRIO
RF02 GERENCIAR USUÁRIO
RF03 GERENCIAR ORGÃO FISCALIZADOR
RF04 GERENCIAR DASHBOARD
RF05 GERENCIAR RELATORIOS
RF06 GERENCIAR RECEITAS
RF07 GERENCIAR ATESTADO
RF08 GERENCIAR CHAVES DE VALIDAÇÃO

2.3.2 Requisitos Não Funcionais

Sommerville (2008) classifica os requisitos de sistema de software como funcionais,

não funcionais e como requisitos de domínio. Os requisitos não funcionais são restrições
sobre serviços ou funções oferecidas pelo sistema. Dentre elas destacam-se restrições de
tempo, sobre o processo de desenvolvimento e de padrões. A descrição das restrições
complementa a definição de requisitos. Já os requisitos de domínio são restrições originárias
do domínio da aplicação do sistema e refletem características do mesmo. Podem ser requisitos
funcionais ou não funcionais (FILHO, 2017).

26
 A distinção entre esses diferentes tipos de requisitos não é tão clara como sugere essas
definições. Um requisito pode parecer-se inicialmente não funcional, mas que quando
desenvolvido com mais detalhes pode dar origem a uma série de novos requisitos funcionais.
Ao discutirmos sobre requisitos devemos levar em conta que na realidade a distinção entre
eles é artificial (SOMMERVILLE, 2008).

Quadro 4 -Requisitos Não-Funcionais

ID Descrição
RNF01 Facilidade de uso - (Detalhe) Implementado com tecnologias que promovem
uma fácil utilização do sistema através de um WEB Browser e Internet.
RNF02 Hardware – Celeron ou superior, (2 Gbytes de RAM, HD 100 Gbytes, mouse,
teclado, monitor, kit-multimídia).
RNF03 Tipo de Interface - Utilizando o próprio browser do usuário.
RNF04 Segurança - Controle de senhas e de usuários.
RNF05 Sistema Operacional do Usuário - Microsoft Windows, Linux.
RNF06 Suporte – Via e-mail.

2.4 ANÁLISE DOS REQUISITOS

Na construção deste estudo utilizamos conceitos e práticas utilizadas pela engenharia

de software como a Unified Modeling Language (UML), é uma prática de modelar e
documentar a elaboração do sistema segundo Ribeiro (2012).
O diagrama de casos de uso ilustra o que o sistema faz do ponto de vista do usuário, as
principais funcionalidades do sistema e suas interações. Segundo Ribeiro (2012) ao diagrama
de casos de uso são compostos por quatro partes: o cenário onde é ilustrado a sequência de
eventos entre a interação do usuário com o sistema; o ator ou atores, dependendo do sistema,
que representa o usuário do sistema; o use case representa a funcionalidade realizada pelo
ator; e a comunicação que indica que existe uma ligação entre o usuário e a funcionalidade.
O diagrama de classes é uma ilustração da estrutura e os relacionamentos entre as
classes em um banco de dados. Segundo Tybel (2016) pode-se dizer que uma classe sería um
conjunto de objetos com as mesmas características. Cada classe desse relacionamento vai

27
representar uma tabela no banco de dados. Assim como o diagrama de casos de uso o
diagrama de classes também é composto por um cenário com retângulos, cada retângulo
representa uma classe deve conter o nome da classe, os atributos e os métodos.
Esta seção descreve e ilustra o sistema como um todo em sua forma arquitetural como
por exemplo o diagrama de casos de uso e os relacionamentos existentes no banco de dados.

2.4.1 Principais Diagramas de Caso de Uso

Na figura nove, apresentamos o diagrama de caso de uso, bem como o fluxo de acesso
por usuário.

Figura 9 - Diagrama de Caso de Uso

28
2.4.2 Diagrama de Classes

A Figura 10 apresenta as classes a serem utilizadas no desenvolvimento da aplicação back-end.

Figura 10 - Diagrama de Classe

29
2.4.3 Projeto de Banco de Dados

O banco de dados utilizado será o MySql5 por ser um banco open source de fácil
acesso e seguro. É um sistema gerenciador de banco de dados que conta com recursos como:
consultas SQL, chaves estrangeiras, integridade transacional, controle de concorrência multi-
versão, facilidade de acesso, gatilhos, visões e indexação por texto.

Figura 11 - Diagrama de Entidade-Relacionamento do Banco de Dados

2.5 ESPECIFICAÇÃO ARQUITETURAL E TECNOLOGIAS UTILIZADAS

A arquitetura de software é uma ilustração de como o sistema é estruturado e como as

aplicações se relacionam por trás da interface. Na figura 12 a ilustração nos mostra como é o
funcionamento da aplicação web, os relacionamentos entre as tecnologias utilizadas. O
usuário irá interagir em aplicação desenvolvida com o framework Vue.Js que se comunicará
com uma API Rest feita em Java utilizando o framework Spring, a API irá se comunicar com
o banco de dados.

5
https://www.mysql.com/products/workbench/

30
 Figura 12 - Arquitetura do Sistema

2.5.1. Tecnologias Utilizadas

Serão utilizadas tecnologias open-source para o desenvolvimento da aplicação entre

linguagens de programação e frameworks mais populares do mercado, conforme abaixo:

 Java

Java é uma linguagem de programação orientada a objetos desenvolvida na década de

90 por uma equipe de programadores chefiada por James Gosling, na empresa Sun
Microsystems. Em 2008 o Java foi adquirido pela empresa Oracle Corporation. Diferente das
linguagens de programação modernas, que são compiladas para código nativo, a linguagem
Java é compilada para um bytecode que é interpretado por uma máquina virtual (Java Virtual
Machine, mais conhecida pela sua abreviação JVM). A linguagem de programação Java é a
linguagem convencional da Plataforma Java, mas não é a sua única linguagem. J2ME Para

31
programas e jogos de computador, celular, calculadoras, ou até mesmo o rádio do carro
(DEITEL, 2005).
A Sun disponibiliza a maioria das distribuições Java gratuitamente e obtém receita
com programas mais especializados como o Java Enterprise System. Em 13 de novembro de
2006, a Sun liberou partes do Java como software livre, sob a licença GNU - General Public
License. A liberação completa do código fonte sob a GPL ocorreu em maio de 2007.
A principal finalidade da linguagem de programação java é a de desenvolvedores
elaborem programas que possam ser executas por qualquer hardware, segundo Content
(2020). Uma linguagem simples quando comparada a C e C++, orientada a objetos os dados
podem ser vinculados às suas operações, também possui uma vasta biblioteca e ferramentas. É
uma linguagem segura e sólida que permite desenvolver e executar aplicações que gerenciam
automaticamente a memória disponível, possui canais de comunicação seguros.

 Spring

O Spring6 é um framework Java criado para facilitar o trabalho dos desenvolvedores

de software, possui muitas características tais como: persistência de dados, integração,
segurança, desenvolvimento web e também os teste. Dispõe para o programador diversas
tecnologias, que simplificam o desenvolvimento de código de infraestrutura. Nesta iniciativa
encontra-se projetos que atendem desde a arquitetura da aplicação até sua implantação, sendo
o Spring Framework um dos mais utilizados.

 Hibernate

Ferramentas para auxiliar nesta tarefa tornaram-se populares entre os desenvolvedores

Java e são conhecidas como ferramentas de mapeamento objeto-relacional (ORM). O
Hibernate é uma ferramenta ORM open source e é a líder de mercado, sendo a inspiração para
a especificação Java Persistence API (JPA).
O Hibernate nasceu sem JPA mas hoje em dia é comum acessar o Hibernate pela
especificação JPA. Como toda especificação, ela deve possuir implementações, entre as mais
comuns podemos citar: Hibernate da Red Hat, EclipseLink da Eclipse Foundation e o

6
http://spring.io

32
OpenJPA da Apache. Apesar do Hibernate ter originado a JPA, o EclipseLink é a
implementação referencial.
O Hibernate abstrai o seu código SQL, toda a camada JDBC e o SQL será gerado em
tempo de execução. Mais que isso, ele vai gerar o SQL que serve para um determinado banco
de dados, já que cada banco fala um "dialeto" diferente dessa linguagem. Assim há também a
possibilidade de trocar de banco de dados sem ter de alterar código Java, já que isso fica como
responsabilidade da ferramenta.
Como usaremos JPA abstraímos mais ainda, podemos desenvolver sem conhecer
detalhes sobre o Hibernate e até trocar o Hibernate com uma outra implementação como
OpenJPA (KING, 2007).

 Apache Maven7

É uma ferramenta de automação e de gerenciamento de construção de projetos. O

desenvolvedor fica totalmente despreocupado quando o assunto for baixar bibliotecas para
que a aplicação funcione, o Maven se encarrega de todos os códigos extra que a aplicação
necessitar utilizando um simples comando segundo Ottero (2012).

 Apache Tomcat

O software Tomcat8 foi desenvolvido pela Apache9 permite a execução de aplicações

para web. É uma implementação referencia das especificações das tecnologias servlets e Jsp,
estas permitem a criação de conteúdos dinâmicos. Também é usado muitas vezes como um
servidor web atendendo as requisições dinâmicas da pagina web. (Devmeida, 2007).

 MySQL

7
https://maven.apache.org/

8
https://tomcat.apache.org/

9
https://www.apache.org/

33
 O MySQL é um sistema gerenciador de banco de dados relacional de código aberto,
usado na maioria das aplicações gratuitas para gerir suas bases de dados. O serviço utiliza a
linguagem SQL (Structure Query Language – Linguagem de Consulta Estruturada), que é a
linguagem mais popular para inserir, acessar e gerenciar o conteúdo armazenado num banco
de dados (VENTAVOLI, 2014).
Na criação de aplicações web abertas e gratuitas, o conjunto de aplicações mais usado
é o LAMP, um acrônimo para Linux, Apache, MySQL e Perl/PHP/Python. Nesse conjunto de
aplicações, inclui-se, respectivamente, um sistema operacional, um servidor web, um sistema
gerenciador de banco de dados e uma linguagem de programação. Assim, o MySQL é um dos
componentes centrais da maioria das aplicações públicas da Internet.
O sistema foi desenvolvido pela empresa sueca MySQL AB e publicado,
originalmente, em maio de 1995. Após, a empresa foi comprada pela Sun Microsystems e, em
janeiro de 2010, integrou a transação bilionária da compra da Sun pela Oracle Corporation.

 VueJs

Vue10 é utilizado para a construção de interfaces web modernas, é uma biblioteca

javascript. Suas interfaces podem ser facilmente reaproveitadas. Possui excelente
performance, pode ser utilizado por projetos backend feitos em qualquer linguagem.

2.5.3. Estratégias para o Design de Interface

Para a elaboração das telas de interface da aplicação foi utilizado o programa de

edição gráfica CorelDraw, buscando sempre uma aparência amigável para que os usuários
tenham uma boa experiência.

10
https://br.vuejs.org/

34
2.5.3.1. User Experience

A usabilidade é um método que visa facilitar a utilização de uma interface por um

usuário, sem perder a interação de suas funcionalidades com o sistema. No ambiente de
software os sistemas são as ferramentas utilizadas para execução de tarefas pelo usuário e
encontramos na usabilidade o momento do diálogo entre o usuário e a interface do software.
A usabilidade está intimamente ligada à experiência do usuário (UX – User
Experience). UX é como uma pessoa se sente ao usar um produto, ou mais formalmente de
acordo com a definição dada pela ISO 9241-210, são as respostas e percepção de uma pessoa
resultantes do uso de um produto, sistema ou serviço.
O sistema foi desenhado para que os clientes se sintam bem sempre, não sintam
ansiedade em estar utilizando a página web. A preocupação só deve vir caso o documento em
mãos não tenha uma chave de verificação valida no banco de dados do sistema.
Apresenta uma boa interface está na arquitetura de informação do aplicativo de
maneira organizada, coerente e intuitiva, alinhado com o perfil do cliente e dados das
pesquisas feitas até então. O objetivo dessa estruturação é tornar o mais fácil possível
encontrar o que se procura dentro do aplicativo web.
Através de menus, cores, símbolos informa ao usuário sobre qual lugar do ele se
encontra, quais são as suas opções e deixa claro que consequências cada ação irá gerar.
Aplicar arquitetura da informação é desenvolver um mapa do seu site e checar se o usuário
realmente segue um caminho interessante.

2.5.3.2. Protótipos de Interface

Nessa seção apresenta-se os protótipos das interfaces da aplicação.

35
2.5.3.3. Principais interfaces do Sistema

Nessa seção apresenta-se as telas finais da aplicação web que foram desenvolvidas a
partir do design de telas ilustrados na seção anterior.

2.6 PLANO DE TESTES DO PROTÓTIPO

Este documento relaciona os casos de uso a serem testados, os estágios de testes,

método de qualificação, detalhamento dos tipos de testes, alvos de testes, a estratégia adotada
para a execução dos testes, os recursos humanos necessários, bem como os produtos que serão
gerados.

 Escopo

No capítulo seguinte estão dispostos os principais tipos de testes que serão realizados
nos módulos do sistema de emissão de receitas e certificados médicos. Todos os planos e
condições de testes de sistema serão desenvolvidos a partir das histórias a serem descritas nas
tarefas e no conteúdo obtido nas reuniões realizadas entre os desenvolvedores.

 Estágio de Teste

Definem o momento do ciclo de vida do software em que são realizados testes por
pessoas diferentes daquelas que o programaram. Entretanto, considerando a divisão das
tarefas de teste em quatro níveis relacionados ao escopo do software, estão previstos para o
sistema web os seguintes estágios de teste:

36
 1. Teste de Integração: são realizados para verificar basicamente se as unidades
testadas de forma individual executam corretamente quando colocadas juntas,
isto é, quando integradas. Os testes são realizados pelo Analista de Testes.
2. Teste de Sistema: são realizados pelo Analista de Testes, visando a execução do
sistema, dentro de um ambiente operacional controlado, para validar a exatidão
e perfeição na execução de suas funções.
3. Teste de Aceitação ou Homologação: são os testes finais de execução do
sistema, realizados pelos usuários, visando verificar se a solução atende aos
objetivos do negócio e a seus requisitos, no que diz respeito à funcionalidade e
usabilidade, antes da utilização no ambiente de produção.

 Tipos de Testes

Seguem abaixo os tipos de testes a serem aplicados ao projeto proposto por este
estudo:
1. Configuração: verifica se o software está apto a rodar em diferentes versões ou
configurações de ambientes (hardware e software), como, por exemplo, em
diferentes browsers e celulares.
2. Funcional: grupos de testes que avaliam se o que foi especificado foi
implementado.
3. Integridade de dados: verificar se os dados do sistema foram incluídos, alterados,
excluídos e pesquisados corretamente no conteúdo de campos e listagens.
4. Performance: mede e avalia o tempo de resposta de cada transação dos requisitos
sensíveis ao tempo.
5. Usabilidade: verificam o nível de facilidade de uso do software pelos usuários.
6. Regressão: verifica a ocorrência de novos defeitos após a resolução de defeitos.
7. Acessibilidade: verifica se a interface do usuário fornece o acesso apropriado às
funções do sistema e a navegação adequada. Além disso, estes testes garantem que
os objetos dentro da interface do usuário funcionem de acordo com os padrões
definidos pelo cliente.

37
8. Disponibilidade: avaliam a capacidade do software em continuar operando mesmo
quando algum elemento (software ou hardware) fica inoperante ou para de
funcionar.

38
3 RESULTADOS

3.1 AMBIENTE DOS TESTES E AVALIAÇÃO

O sistema de emissão de receitas e atestados médicos será testado em sua própria

página web onde os usuários efetuarão consultas e avaliarão a usabilidade do sistema e
reportaram a equipe desenvolvedora os feedbacks a respeito de sua experiência.

3.2 AVALIAÇÃO DA SOLUÇÃO

3.2.1 Análise quantitativa

Foram coletadas informações através de formulário desenvolvido, onde os dados estão

sendo tratados e trabalhados, havendo uma expectativa de introduzir um software sob a forma
de piloto em uma empresa da grande João Pessoa, que durante 30 dias estaremos
acompanhando a evolução e satisfação pelo uso do mesmo, produzindo novos dados para
complementar este trabalho.

3.2.2 Análise qualitativa

Foram coletadas informações através de formulário desenvolvido, onde os dados estão

sendo tratados e trabalhados, havendo uma expectativa de introduzir um software sob a forma
de piloto em uma empresa da grande João Pessoa, que durante 30 dias estaremos
acompanhando a qualidade do produto em produção, produzindo novos dados para
complementar este trabalho.

39
40
CONSIDERAÇÕES FINAIS

A proposta deste estudo está focada em elaborar um sistema de emissão de receitas

médicas, simples e controladas, e de atestados médicos ambos com chave de validação para
que as farmácias e os empregadores verifiquem a legitimidade do documento apresentado,
confirmada a legitimidade a farmácia libera a venda do remédio prescrito e as organizações
podem abonar a falta do empregado. O sistema se utilizado corretamente pode vir a dar um
retorno positivo na qualidade de vida do Brasileiro tendo em vista que o médico terá mais
tempo para consultar pacientes ou para descansar pois não precisará mais dispor desse tempo
para ir ao órgão responsável por distribuir os talões de receitas especiais. Também poderá
haver uma redução significativa no ato de automedicação pois a forma de controle dos
medicamentos vendidos será muito mais ágil e fácil com a utilização do sistema. Já em
questões econômicas as empresas ganharão em produtividade dado que os atestados
falsificados não terão como ser validados e a empresa pode recusar podendo demitir o
funcionário que apresentar um documento falso. Como dito anteriormente neste estudo os
custos gerados por atestados falsos são muito altos para a organização bem como também
para o país.
Ainda não foram encontrados clientes para introduzir o sistema, mesmo em caráter de
testes sem algum tipo de ônus para a empresa.

41
REFERÊNCIAS
CONTENT Rock, O que é Java? Conheça as particularidades dessa linguagem de programação,
Stage 2020. Disponível em: < https://rockcontent.com/blog/o-que-e-java/>. Acessado em 25/03/2020.

CIMINO James, Camelô vende receita falsa de antibiótico. Disponível em: <
https://www1.folha.uol.com.br/fsp/cotidian/ff0902201109.htm>. Acessado em 24/03/2020.

DEITEL, Harvey M.; DEITEL, Paul J.; Java Como Programar. Pearson. 6ª Edição. 2005.

FILHO, Wilson de Paula Pádua. Engenharia de Software. Editora LTC. 2017.

MENDONÇA Maíra, Farra dos atestados: a cada 100 entregues no estados, 30 são falsos.
Disponível em: < https://www.agazeta.com.br/es/gv/farra-dos-atestados-a-cada-100-
entregues-no-estado-30-sao-falsos-0917>. Acessado em 24/03/2020.

MORAES Rafael, A prescrição digital pode combater as fraudes de receita médica?.

Disponível em :< https://panoramafarmaceutico.com.br/2020/01/30/a-prescricao-digital-pode-
combater-as-fraudes-de-receita-medica/>. Acessado em 20/03/2020.

NADER Danielle, 30% dos atestados médicos emitidos no Brasil são falsos. Disponível
em: <https://www.contabeis.com.br/noticias/42258/30-dos-atestados-medicos-emitidos-no-
brasil-sao-falsos/>. Acessado em 15/03/2020.

OTTERO Rodrigo, Introdução ao Maven. Devmedia, 2012. Disponível em: <

https://www.devmedia.com.br/introducao-ao-maven/25128>. Acessado em 25/03/2020.

REIS Vinicius, Por que VueJs é uma boa opção?, VueJs, 2016. Disponível em: <
https://vuejs-brasil.com.br/por-que-vuejs-e-uma-boa-opcao/>. Acessado em 25/03/2020.

RIBEIRO Leandro. O que é UML e Diagramas de Caso de Uso: Introdução Prática à

UML, 2012. Disponível em: < https://www.devmedia.com.br/o-que-e-uml-e-diagramas-de-
caso-de-uso-introducao-pratica-a-uml/23408>. Acessado em 24/03/2020.

SOMMERVILLE. Ian. Engenharia de Software. 8ª Ed., Editora Addison Wesley Bra. 2008.

42
TYBEL Douglas, Orientações básicas na elaboração de um diagrama de classes, 2016.
Disponível em: < https://www.devmedia.com.br/orientacoes-basicas-na-elaboracao-de-um-
diagrama-de-classes/37224>. Acessado em 24/03/2020.

VENTAVOLI, Fabíola. Sistema de Gerenciamento de Banco de Dados MySql. 2a. Edição,

2014.

WOLFF Italo, Startup goiana combate mercado negro de atestados médicos falsificados.
Disponível em :< https://www.jornalopcao.com.br/reportagens/startup-goiana-combate-
mercado-negro-de-atestados-medicos-falsificados-191875/>. Acessado em 15/03/2020.

Fim da farra dos atestados. FecomercioDF. Disponível em:

<https://www.fecomerciodf.com.br/fim-da-farra-dos-atestados/>. Acessado em 20/038/2020.

O que é lean startup e como aplicar na sua empresa?. HSM University,2019. Disponível
em: <https://hsmuniversity.com.br/blog/lean-startup/?gclid=CjwKCAjw3-
bzBRBhEiwAgnnLCqxTluFJR6-
GeLyYOCVnWZsh8mTunFHtJ5sOZHS8Vafnna7ZKhpyuRoCvtwQAvD_BwE>. Acessado
em 24/03/2020.

Como começar com Spring?. Devmedia. Disponível em: <

https://www.devmedia.com.br/exemplo/como-comecar-com-spring/73>. Acessado em
25/03/2020.

Devmedia, 2007. Disponível em: < https://www.devmedia.com.br/conheca-o-apache-

tomcat/4546>.

43