PIM VI - LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM SISTEMA DE CONTROLE DE VENDAS DE UMA LOJA DE JOGOS, ACESSÓRIOS E PRODUTOS GEEK

Prévia do material em texto

UNIP EAD 
PROJETO INTEGRADO MULTIDISCIPLINAR PIM VI CURSOS 
SUPERIORES DE TECNOLOGIA 
 
 
 
 
 
 
 
 
 
 
 
LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM SISTEMA DE 
CONTROLE DE VENDAS DE UMA LOJA DE JOGOS, ACESSÓRIOS E 
PRODUTOS GEEK 
 
 
 
 
 
 
 
SUPERIOR TÉCNICO EM ANALISE E DESENVOLVIMENTO DE 
SISTEMAS 
 
 
 
 
 UNIP EAD SÃO GABRIEL DA CACHOEIRA 
2020 
 
 
 
UNIP EAD 
 
SUPERIOR TÉCNICO EM ANALISE E DESENVOLVIMENTO DE 
SISTEMAS 
 
 
 
 
 
 
 
LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM SISTEMA DE 
CONTROLE DE VENDAS DE UMA LOJA DE JOGOS, ACESSÓRIOS E 
PRODUTOS GEEK 
 
 
 
 
 
 
 
 
 
 DIONES SAMPAIO ARAÚJO RA:1975397 
 
 
 
 
 
 
 
 
 
EAD SÃO GABRIEL DA CACHOEIRA 
2020
 
 
 
SUPERIOR TÉCNICO EM ANALISE E DESENVOLVIMENTO DE 
SISTEMAS 
 
 
 
 
 
 
 
 
 
LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM SISTEMA DE 
CONTROLE DE VENDAS DE UMA LOJA DE JOGOS, ACESSÓRIOS E 
PRODUTOS GEEK 
 
 
 
 
 
 
 
 
Projeto integrado multidisciplinar Apresentado 
à Unip Ead como exigência do curso de 
superior técnico em análise e desenvolvimento 
de sistemas. 
 Orientador: Profa. Sandra Bozolan 
 
 
 
 
EAD SÃO GABRIEL DA CACHOEIRA 
2020 
https://ava.ead.unip.br/webapps/blackboard/execute/courseMain?course_id=_37709_1
 
 
 
RESUMO 
 
O presente projeto integrado multidisciplinar que está inserido no programa 
pedagógico dos cursos superiores de tecnologia da Universidade Paulista, consiste 
na elaboração um Levantamento e a Análise de requisitos de um sistema para 
empresa destinada à venda de jogos eletrônicos, acessórios e produtos geek, utilizada 
mediante das técnicas aprendidas. A elaboração será baseada conforme nos 
conhecimentos adquiridos nas disciplinas de: Análise de Sistemas Orientadas a 
Objetos; Banco de Dados; Gestão Estratégica de RH. Com avanço da tecnologia 
atualmente as pequenas tarefas gerenciadas para controle de vendas são 
manipuladas pelas planilhas do Excel, tendo vista um pouco mais rigoroso para 
melhoria do atendimento ao cliente, a empresa fechou um contrato para 
desenvolvimento de um software de controle e gerenciamento de vendas, solicitando 
o Levantamento e a Análise de requisitos de um sistema, para que seja organizada 
nos cadastros, alterações, consultas e exclusões, o sistema será utilizado por 
atendentes, estoquistas e o supervisor da loja. 
 
Palavras chaves: Jogos, Vendas, Empresa. 
 
 
 
 
 
 
 
ABSTRACT 
 
 The present integrated multidisciplinary project that is not included in the 
pedagogical program of higher technology courses at the Universidade Paulista, 
consists of the preparation of a Survey and the Analysis of system requirements for a 
company destined to the sale of electronic games, accessories and geek products, 
used Of learned techniques. The elaboration will be based on the knowledge acquired 
in the disciplines of: Analysis of Object Oriented Systems; Database; Strategic HR 
Management. With the advancement of technology today, how small tasks managed 
to control sales are handled by Excel spreadsheets, having a little more stringent to 
improve customer service, a company that has a contract for the development of 
software for control and management of sales, requesting the Survey and 
Requirements Analysis of a system, so that it is organized in the records, changes, 
consultations and exclusions, or the system will be used by solicitors, stockists and 
store supervisor. 
 
 
Keywords: Games, Sales, Company 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
SUMÁRIO 
 
1. INTRODUÇÃO....................................................................................................6 
2. TÍTULO................................................................................................................7 
3. O PROJETO........................................................................................................7 
4. REQUISITOS DO SOFTWARE..........................................................................8 
4.1. REQUISITOS FUNCIONAIS.......................................................................................8 
4.1.2 REQUISITOS NÃO FUNCIONAIS......................................................................8 
 
4.1.3 REQUISITOS DE NEGÓCIO.............................................................................9 
4.2 REGRAS DE NEGÓCIO....................................................................................9 
4.2.1 INTERFACE DAS REGRAS DE NEGÓCIO.......................................................9 
 
4.3 QUALIDADE......................................................................................................10 
 
4.3.1 METODOLOGIA DE QUALIDADE....................................................................10 
 
5. OBJETOS...........................................................................................................12 
 
6. CLASSES...........................................................................................................12 
 
7. HERANÇA..........................................................................................................13 
 
8. POLIMORFISMO................................................................................................14 
 
9. ENCAPSULAMENTO..........................................................................................15 
 
10. ELEMENTOS TÉCNICOS DO SISTEMA..........................................................16 
 
10.1. DIAGRAMA DE CLASSES................................................................................16 
 
10.2. DIAGRAMA DE OBJETOS................................................................................17 
 
11. TELA DE CADASTRO........................................................................................18 
 
CONCLUSÃO.............................................................................................................26 
 
REFERÊNCIAS..........................................................................................................25 
 
6 
 
 
1. INTRODUÇÃO 
 
 O Projeto Integrado Multidisciplinar VI, é um trabalho que consiste em apresentar 
todas as disciplinas estudadas no bimestre. A princípio o presente trabalho visa em 
descrever toda prática que envolva a Análise e Desenvolvimento de Sistemas dentro 
do levantamento e análise de requisição de um sistema, na visão prática conforme o 
aprendizado dos livros, sites e em tele aulas no decurso do atual período. Mediante 
dessas fontes de informações obtidas acima, será apresentado um levantamento e 
análise de requisição de um sistema e abordadas pelas disciplinas de: Análise de 
Sistemas Orientadas a Objetos; Banco de Dados; Gestão Estratégica de RH. E para 
que tenha a melhor compreensão foi elaborado um Levantamento e a Análise de 
requisitos de um sistema para empresa destinada à venda de jogos eletrônicos, 
acessórios e produtos geek. Onde o módulo de acesso facilitará aos clientes, usuários 
portadores de deficiências, e o gerenciamento do sistema nos cadastros, alterações, 
consultas e exclusões, realizará por níveis de login dos atendentes, estoquistas e o 
supervisor da loja. Apesar a empresa possuir o grau de raridade e disponibilidade da 
plataforma de desenvolvimento dos jogos, não impede o trabalho de qualidade de 
software, pois o foco é gerenciar as vendas efetuadas ao cliente. Será abordado os 
casos de uso e seus relacionamentos de funcionamentos em detalhes e a justificativa 
da escolha do sistema, o protótipo de telas com alta fidelidade para osrequisitos 
funcionais, definido como funcionamento de cada tipo de entrada de dados, 
processamento ou saída de informação. Os dados construídos serão revisados 
conforme modelo (MER) para verificação das chaves primarias da tabela. 
 
 
 
 
 
 
 
 
 
 
7 
 
 
2. TÍTULO 
 
Levantamento e a Análise de requisitos de um sistema para empresa destinada à 
venda de jogos eletrônicos, acessórios e produtos geek PIM VI. 
 
3. O LEVANTAMENTO E A ANÁLISE DE REQUISITOS DE UM SISTEMA 
 
 Para iniciar o levantamento e a análise de requisitos de um sistema, foi necessário 
adquirir as práticas para captar e mapear necessidades das organizações em um 
mercado mais competitivos, de forma eficiente no futuro do projeto de software, e 
utilizado o paradigma da orientação a objetos, por ser mais difundido no mercado, no 
padrão da evolução voltadas para segurança e reaproveitamento de código, no 
desenvolvimento de aplicação moderna. 
Considerada a engenharia de requisitos como fase fundamental dentro do projeto de 
desenvolvimento, por especificar, implementar, validar, e implantar o software, a 
importância no relacionamento de atividade com os clientes e usuários finais para 
descobrir o problema a ser resolvido, os serviços do sistema, o desempenho, 
restrições de hardware e outras informações. 
Com esse novo mercado a competição visa para empresa obter foco mais completa, 
na abordagem nas atividades, interação profissional, relação com outra organização, 
utilização e funcionamento dos recursos físicos e sistemas computacional. Para 
entendermos melhor essas abordagens técnicas são expostas através da modelagem 
de processos de negócio ou diagramas de processos, utilizada diagramas da UML 
(Unifield Modeling Language) como ferramenta de apoio, para representar, modelar o 
sistema de software, compondo atividades das áreas de negócios ou da empresa, 
proporcionando a otimização no processo atual. 
Neste caso conforme a evolução do sistema e paradigma da orientação mais difundido 
no mercado, cabe à nossa Fábrica de software PIMVI para nosso cliente, a loja de 
venda de jogos eletrônicos, acessórios e produtos geek, e vem representado pela 
nossa instituição para a elaboração do levantamento de requisitos do sistema desktop. 
Apesar da empresa possuir produtos no grau de raridade e disponibilidade da 
plataforma de desenvolvimento dos jogos, o foco é gerenciar as vendas efetuadas ao 
cliente. 
 
 
8 
 
 
4. REQUISITOS DO SOFTWARE 
 
 Os requisitos de um software são as condições minúsculas que o mesmo deve 
atender a fim de solucionar os problemas e, dessa forma, satisfazerem as 
necessidades do cliente contratante. No caso de um software por demanda, produto 
deste projeto, o atendimento destes requisitos e os de qualidade é o principal foco 
desta empresa no desenvolvimento do software. Para tanto, é necessário definir e 
documentar os requisitos funcionais, não funcionais e os de negócios que o software 
deve atender. 
 
4.1 REQUISITOS FUNCIONAIS 
 
 Os requisitos funcionais são as aplicações que o software deve possuir no intuito 
de atender a demanda do cliente. É a razão de ser de um software. No nosso projeto, 
o software deve atender, a título de requisitos funcionais as seguintes demandas: 
 
 Possuir um Banco de Dados no qual serão elencados todos cadastros, alterações, 
consultas e as exclusões dos produtos vendidos na loja, e os cadastros dos 
clientes, controle de acesso ao sistema com níveis de login; 
 Gerar um código único para cada item, de forma que um produto não possa ser 
emprestado para mais de um usuário ao mesmo tempo; 
 Funcionalidade para tornar indisponível qualquer produto que apresentar defeito 
ou estiver em manutenção; 
 Possuir outro Banco de Dados ao qual serão vinculados todos os usuários do 
sistema, atendentes, estoquistas e o supervisor da loja e etc. 
 
4.1.2 REQUISITOS NÃO FUNCIONAIS 
 
 Os requisitos não funcionais são aqueles intrínsecos ao funcionamento do software 
em sua relação com o sistema e o hardware. Dessa forma, os requisitos não 
funcionais a serem verificados são: 
 O espaço que este ocupará na memória quando não executado (kbytes) e 
quando executado (RAM); 
9 
 
 
 Sua velocidade está atrelada ao tempo de utilização da tela, ou a transações 
processadas por segundo (CODIFICAR, 2017); 
 A facilidade de utilização poder ser medida pelo número de janelas ou tempo 
de treino (CODIFICAR, 2017); 
 A confiabilidade é inerente ao tempo médio de utilização antes do sistema 
falhar, à disponibilidade ou à taxa de ocorrências de falhas (CODIFICAR, 
2017). 
 
4.1.3 REQUISITOS DE NEGÓCIO 
 
 Os requisitos de negócio são aqueles que definem a forma como loja de venda de 
jogos eletrônicos, pretende atingir os objetivos estratégicos do negócio. Dessa forma, 
os requisitos a serem verificados são: 
 Registros; 
 Relatórios; 
 Controle de fluxo; 
 Consultas; 
 Cadastros; 
 
4.2 REGRAS DE NEGÓCIO 
 
 Segundo Dextra, 2013, as Regras de Negócio definem a forma de como a 
instituição deve fazer negócio, refletindo a política interna, regras básicas de conduta, 
etc. ou seja, o estipula o comportamento ao qual os usuários são submetidos dentro 
do negócio. Restrições, validações, condições e exceções do processo são exemplos 
clássicos de regras de negócio. 
 
4.2.1 INTERFACE DAS REGRAS DE NEGÓCIO 
 
 A interface das regras de negócio é o ambiente no qual os usuários estão 
submetidos a tais regras. Neste caso, as atividades nas quais serão empregados os 
produtos poderão ser classificadas conforme o grau de importância ou visibilidade e 
10 
 
 
assistência prevista para esta. Desta forma, evita o emprego do erro de busca de 
informações. 
Assim sendo, na tabela abaixo, será especificada a regra de negócio para cotar o grau 
de importância de cada atividade: 
N_Pedido C_Produto N_Produto Status Usuários 
1 1234 Jogos1 Prior 1 SUPERVISOR 
2 2345 Jogos2 Prior 2 ESTOQUISTA 
3 3456 Jogos3 Prior 3 ATENDENTE 
Tabela 1: Interface de regras de negócios – grau de importância da atividade 
 
4.3 QUALIDADE 
 
 Os modelos de qualidade são ferramentas poderosas que auxiliam na criação dos 
fundamentos de uma empresa se software, a fim de torna-la apta a evoluir à medida 
que atinge os mais elevados graus de maturidade e, dessa forma, se consolidarem no 
mercado como empresas que gozem de pleno reconhecimento, confiabilidade e 
renome. 
 
4.3.1 METODOLOGIA DE QUALIDADE 
 Por se tratar de uma norma nacional, a qual torna o processo de melhoria de 
qualidade adaptada à realidade local, e por se tratar de um projeto feito por demanda 
para uma instituição nacional, o modelo de qualidade a ser empregado para estipular 
o grau de maturidade da empresa e os testes a serem realizados no software será o 
de Melhoria de Processo de Software Brasileiro (MPS.BR). 
Segundo RIBEIRO, 2015, o modelo MPS.BR está estruturado em 4 componentes 
(modelos de referência), 7 níveis de maturidade e 19 processos, distribuídos em seus 
respectivos níveis. 
 Os componentes são modelos de referência para desenvolvimento, aquisição e 
avaliação do processo de software e são divididos em Modelo de referência para 
software, Modelo de referência para serviços, Método de avaliação e Modelo de 
negócios. 
 Os níveis de maturidade compõem um indicador de evolução da qualidade e 
permite definir o grau de maturidade o qual se encontra o modelo de qualidade da 
empresa. Os processos são os requisitos que o modelo precisa cumprir para atingir 
11 
 
 
os níveis de maturidade imediatamente superior. Dessa forma, os processos estão 
divididos por níveis de maturidade conforme o quadro abaixo: 
 
Nível de maturidade Processos 
A – Otimizado Não há processos específicos 
B – Gerenciado quantitativamente Não há processos específicos 
C – Definido 
Gerência de decisões 
Gerência de riscos 
Desenvolvimentopara reutilização 
D – Largamente definido 
Desenvolvimento de requisitos 
Projeto e construção do produto 
Integração do produto 
Verificação 
Validação 
E – Parcialmente definido 
Definição do processo organizacional 
Avaliação e melhoria do processo 
organizacional 
Gerência para reutilização 
Gerência de recursos humanos 
F – Gerenciado 
Garantia da qualidade 
Gerência da configuração 
Medição 
Aquisição 
Gerência de portifólio 
G – Parcialmente gerenciado 
Gerência de projetos 
Gerência de requisitos 
Tabela 2: Processos por níveis de maturidade (RIBEIRO, 2015) 
 
12 
 
 
5. OBJETOS 
 Um objeto é um elemento computacional que representa, no domínio da solução, 
alguma entidade (abstrata ou concreta) do domínio de interesse do problema sob 
análise. Objetos similares são agrupados em classes. 
No paradigma de orientação a objetos, tudo pode ser potencialmente representado 
como um objeto. Sob o ponto de vista da programação, um objeto não é muito 
diferente de uma variável no paradigma de programação convencional. Por exemplo, 
quando se define uma variável do tipo int em C ou em Java, essa variável tem: 
 Um espaço em memória para registrar o seu estado atual (um valor); 
 Um conjunto de operações associadas que podem ser aplicadas a ela, através 
dos operadores definidos na linguagem que podem ser aplicados a valores 
inteiros (soma, subtração, inversão de sinal, multiplicação, divisão inteira, resto 
da divisão inteira, incremento, decremento). 
Da mesma forma, quando se cria um objeto, esse objeto adquire um espaço em 
memória para armazenar seu estado (os valores de seu conjunto de atributos, 
definidos pela classe) e um conjunto de operações que podem ser aplicadas ao objeto 
(o conjunto de métodos definidos pela classe). 
Um programa orientado a objetos é composto por um conjunto de objetos que 
interagem através de "trocas de mensagens". Na prática, essa troca de mensagem 
traduz-se na invocação de métodos entre objetos. 
 
6. CLASSES 
 
 O desenvolvimento de classes é o resultado da abstração. Uma vez definidos os 
devidos escopos, teremos condições de pensar em termos de classes. 
 
 É fácil notar que muitos objetos possuem características estruturais semelhantes, 
embora todo objeto seja único. Um bom exemplo disso são os objetos que recebem a 
denominação genérica de “carro”. Todos os carros possuem uma mesma estrutura, 
ou seja, todos os objetos carro implementam os mesmos métodos e mantém 
13 
 
 
informações sobre os mesmos atributos. O fato de que cada objeto mantém seus 
próprios atributos de forma encapsulada confere uma identidade única a cada objeto 
e também permite que dois objetos possam, eventualmente, possuir valores iguais 
para seus atributos. 
 Esses grupos de objetos com estruturas semelhantes são definidos em termos de 
classes. Classes consistem na unidade básica da construção de um programa OO e 
definem o conjunto de atributos mantidos por um conjunto de objetos e o 
comportamento que esses objetos devem respeitar. Segue exemplo de uma classe: 
 
(Ilustração criada na ferramenta draw.io) 
 
 
 
7. HERANÇA 
 Herança é um conceito muito parecido com a delegação. No entanto, seu objetivo 
é a derivação de classes, ou seja, a criação de uma classe (classe filha) onde sua 
base é uma classe já existente (classe pai), sendo adicionados a essa nova classe 
apenas atributos e métodos que não existam na classe original ou a execução de um 
método que seja diferente do método da classe original. 
 
 Em outras palavras, a herança é um mecanismo de reaproveitamento em que as 
classes originais ficam contidas na nova classe. A reutilização de classes via 
mecanismo de delegação é útil quando consideramos que a classe que reutiliza 
14 
 
 
instâncias de outras classes é composta destas. Um bom exemplo é a classe Data 
Hora, que é composta das classes Data e Hora. 
 
 A solução é a reutilização de classes por meio do mecanismo de herança, no qual 
podemos criar uma classe usando outra como base e descrevendo ou implementando 
as diferenças e adições da classe usada como base, isso com a reutilização dos 
campos e métodos não privados da classe base. O mecanismo de herança é o mais 
apropriado para criar relações entre classes. Segue ex. de herança, onde cliente e 
fornecedor herdam atributos de pessoa. 
 
(Ilustração criada na ferramenta draw.io) 
8. POLIMORFISMO 
 O polimorfismo está relacionado com o conceito de herança, especificamente em 
relação a métodos. O mecanismo de herança permite a criação de classes a partir de 
outras já existentes com relações “é-um-tipo-de”, de forma que, a partir de uma classe 
genérica, classes mais especializadas possam ser criadas. 
 Quando uma nova classe necessita de todos os atributos e métodos de uma já 
existente, porém a nova classe possui a execução de um ou mais métodos 
diferenciados, é possível herdarmos todos os métodos e atributos da classe original e 
realizar a alteração do comportamento do método somente na nova. 
 O termo polimorfismo tem origem na composição de duas palavras gregas: Poli = 
muitas. Morphos = formas. Em termos de programação, muitas formas significam que 
15 
 
 
um único nome pode representar um código diferente, selecionado por algum 
mecanismo automático. Assim, o polimorfismo permite que um único nome expresse 
muitos comportamentos diferentes (SINTES, 2002, p. 122). 
 
9. ENCAPSULAMENTO 
 O encapsulamento é uma das principais técnicas que define a programação 
orientada a objetos. Se trata de um dos elementos que adicionam segurança à 
aplicação em uma programação orientada a objetos pelo fato de esconder as 
propriedades, criando uma espécie de caixa preta. 
A maior parte das linguagens orientadas a objetos implementam o encapsulamento 
baseado em propriedades privadas, ligadas a métodos especiais chamados getters e 
setters, que irão retornar e inserir o valor da propriedade, respectivamente. Essa 
atitude evita o acesso direto a propriedade do objeto, adicionando uma outra camada 
de segurança à aplicação. 
Para fazermos um paralelo com o que vemos no mundo real, temos o encapsulamento 
em outros elementos. Por exemplo, quando clicamos no botão ligar da televisão, não 
sabemos o que está acontecendo internamente. Podemos então dizer que os métodos 
que ligam a televisão estão encapsulados. 
Exemplo: Encapsulando em C# e aplicação Desktop. 
 
(Imagens: Portfólio pessoal) 
 
 
 
 
 
 
16 
 
 
10. ELEMENTOS TÉCNICOS DO SISTEMA 
10.1 DIAGRAMA DE CLASSES 
 
 Este diagrama de classe representa o usuário entrando no sistema e realizando o 
pedido, demonstrando os campos que devem ser preenchidos para concluir o 
cadastro de pedidos, apresenta os campos de cadastro das tabelas pertencentes a 
tela de cadastro de pedidos. Onde é possível ver todos os campos necessários para 
completar o pedido. 
 
 
 
(Imagem portfólio) 
 
 
 
 
 
 
17 
 
 
10.2 DIAGRAMA DE OBJETOS 
 
 O diagrama de objetos representa um detalhamento do que é a real construção da 
marcação do pedido, é apresentado a descrição do real pedido que o sistema trabalha. 
Demonstrando os nomes que são gravados nas variáveis para consolidar a reserva 
no banco de dados. 
 
(foto portfolio) 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
18 
 
 
11. TELA DE CADASTRO 
Nesta tela apresenta os Perfis do Usuários, e suas Atividades. 
 
 
Figura 2 – Tela Inicial 
 
 
Selecione seu perfil para acesso nas informações, ou clique no Home para 
retornar na tela inicial da loja. 
 
 
 
 
19 
 
 
Aqui nesta tela digite a sua ID e a senha, e clique no botão entrar para continuar no 
acesso ou sair para retornar na tela dos usuários. 
 
 
 
 
 
Apresenta esta tela de opções de Cliente, Produto, após se identificar na tela de login. 
Escolha a opção Cliente para verificar cadastros. Caso contrário clique em Home para 
retornarna tela de usuários. 
 
 
 
 
20 
 
 
Na tela Cliente, apresenta o botão Cadastro, Consulta, Alterar e Excluir. Para 
incluir cliente, clique no cadastro; verificar se já existe cliente, clique em consultar; 
corrigir erros ou atualizar dados do cliente, clique em alterar, ou caso queira 
eliminar cliente, clique em excluir. Se não houver nenhuma necessidade clique no 
botão Home para voltar na tela anterior. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
21 
 
 
Na tela Produto, há também o botão Cadastro, Consulta, Alterar e Excluir. Se há 
necessidade de incluir produto, clique no cadastro; verificar se já existe cliente, 
clique em consultar; corrigir erros ou atualizar dados do produto, clique em alterar, 
ou caso queira eliminar produto, clique em excluir. Se não houver nenhuma 
necessidade clique no botão Home para voltar na tela anterior. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
22 
 
 
Na Venda, apresenta também o botão Cadastro, Consulta, Alterar e Excluir. Onde 
pode incluir venda, verificar se já existe cliente, corrigir erros ou atualizar dados 
do produto, se queira eliminar venda. Observação: A exclusão de venda 
concretizada só poderá executado através do perfil supervisor da loja, pois 
atendente somente eliminar da venda não concretizada. Caso se não houver 
nenhuma necessidade clique no botão Home para voltar na tela anterior. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
23 
 
 
CONCLUSÃO 
 
 Esse projeto ponderou a importância da evolução no mercado das empresas e 
softwares, trazendo a melhoria no atendimento aos clientes com geração de desktop, 
facilitando em agilizar os cadastramentos de usuários e produtos, tendo em vista se 
fez necessário fazer um Levantamento de análise de requisitos de sistemas, para 
obter um software atualizado, em cadastro de produtos jeek e acessórios, atender 
necessidades aos usuários, portadores de deficiências, clientes, produtos no sistema, 
feitas o controle de acessos por meio login personalizado. 
Apesar a empresa possuir controle de estoque no grau raridade, o principal foco foi 
desenvolver o gerenciador em Desktop, e que tornou o processo mais rápido 
organizado no controle de vendas, cadastros de clientes para loja de jogos. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
24 
 
 
REFERÊNCIAS 
 
Internet 
 
Disponível em https://www.devmedia.com.br/os-4-pilares-da-programacao-orientada-
a-objetos/9264; 
Disponível em https://www.devmedia.com.br/artigo-engenharia-de-software-4-
modelagem-de-processos-de-negocio/9880; 
CODIFICAR. O que são requisitos funcionais e não funcionais?, 2017. 
Disponível em https://codificar.com.br/requisitos-funcionais-nao-funcionais/#. Acesso 
em 16 abr 2020; 
DEXTRA. Requisito ou Regra de Negócio?, São Paulo, 2013. Disponível em: 
https://dextra.com.br/pt/requisito-ou-regra-de-negocio/.Acesso em: 16 abr 2020.