PIM VI SISTEMA DE CONTROLE DE VENDAS DE UMA LOJA DE JOGOS, ACESSÓRIOS E PRODUTOS GEEK NOTA 10

Prévia do material em texto

UNIVERSIDADE PAULISTA – UNIP EaD 
Projeto Integrado Multidisciplinar 
Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas 
 
 
 
LUCAS VIEIRA GOMES - 2071490 
 
 
 
 
 
LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM SISTEMA DE CON-
TROLE DE VENDAS DE UMA LOJA DE JOGOS, ACESSÓRIOS E PRODUTOS GEEK. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ARACAJU – SE 
2021 
 
 
 
LUCAS VIEIRA GOMES – 2071490 
 
 
 
 
 
LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM SISTEMA DE CONTROLE DE 
VENDAS DE UMA LOJA DE JOGOS, ACESSÓRIOS E PRODUTOS GEEK. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ARACAJU -SE 
2021 
 
Projeto Integrado Multidisciplinar 
para a obtenção do título de graduação em 
Análise e Desenvolvimento de Sistemas 
apresentado à Universidade Paulista – 
UNIP EaD. 
Orientador(a): Profª Patrícia Toffolo 
 
 
 
RESUMO 
 
Este PIM tem por objetivo com base nas disciplinas de análise de sistemas 
orientada a objetos, banco de dados e gestão estratégica de recursos humanos fazer 
o levantamento e a análise dos requisitos de um sistema de controle de vendas de 
uma loja de jogos, acessórios e produtos geek. A fim de desenvolver e aplicar os co-
nhecimentos adquiridos nestas disciplinas. 
Atualmente, as pequenas tarefas gerenciadas para controlar vendas são mani-
puladas utilizando planilhas em Excel. Entretanto visando a melhoria no atendimento 
ao cliente e tornar seu controle de vendas mais rigoroso a empresa fechou contrato 
para o desenvolvimento de um sistema desktop para o controle e gerenciamento das 
suas vendas, sendo necessário a elaboração e levantamento dos requisitos e funcio-
nalidades tornando possível ao usuário realizar cadastros, alterações, consultas e ex-
clusões relacionadas aos produtos vendidos na loja, o sistema deverá contar com 
módulos de acessibilidade para o acesso de eventuais usuários portadores de defici-
ências. 
 
 
 
 
 
 
Palavras-chave: PIM; Loja de produtos; Sistema. 
ABSTRACT 
 This PIM aims to based on the disciplines of object-oriented systems analysis, 
database and strategic management of human resources to survey and analyze the 
requirements of a sales control system of a game store, accessories and geek prod-
ucts. In order to develop and apply the knowledge acquired in these disciplines. 
 Currently, small tasks managed to track sales are handled using Excel 
spreadsheets. However aiming at improving customer service and making its sales 
control more rigorous the company signed a contract for the development of a desktop 
system for the control and management of its sales, being necessary the elaboration 
and survey of requirements and functionalities making it possible for the user to make 
registrations, changes, queries and exclusions related to products sold in the store, the 
system must have accessibility modules for access to any users with disabilities. 
 
 
 
 
 
 
 
 
 
Keywords: PIM; Product store; system. 
SUMÁRIO 
 
 
 
1. INTRODUÇÃO ……………………………………………...………….…….............… 6 
2. O PROJETO...............................……………………………...…….............….…….. 7 
3. CENÁRIO PROPOSTO.…....……………………………………………..……............ 7 
4. FUNÇÕES DE NEGÓCIO .......................………………………………...............…. 7 
5. SOLUÇÕES DISPONÍVEIS NO MERCADO …..…………….............….………...... 8 
6. AUTOMATIZAÇÃO DAS OPERAÇÕES …………..….............…..……………........ 9 
 6.1 Casos de uso ................................................................................................................………... 9 
7. ANÁLISE E LEVANTAMENTO DOS REQUISITOS .............……………………....14 
 7.1 Plano de projeto ............................................................................................................………. .15 
 7.2 Requisitos funcionais ..................................................................................………….................15 
 7.3 Requisitos não funcionais...........................................................................………….................15 
 7.3.1 Requisitos não funcionais do sistema ..............................................…….............……..16 
 7.3.2 Requisitos não funcionais de usabilidade ........................................…………...............16 
8. CONTEXTO DE USO ............................................................................................18 
9. REGRAS DE NEGÓCIO .......................................................................................18 
10. GLOSSÁRIO DO SISTEMA ............................................................................... 21 
11. CLASSES E OBJETO ...... ................................................................................. 21 
12. ENCAPSULAMENTO ......................................................................................... 22 
13. HERANÇA E POLIMORFISMO ...........................................................................22 
 13.1 Herança .................................................................................................................................. 23 
 13.2 Polimorfismo ........................................................................................................................... 23 
13. DIAGRAMA DE CLASSES ...... ...........................................................................23 
14. MODELO DE DADOS (MER) .. ...........................................................................25 
15. CONCLUSÃO ..................................................................................................... 26 
REFERÊNCIAS ………………………………………….………………….............…… 27
 
 
 
 
 
 
6 
 
1. INTRODUÇÃO 
O projeto integrado multidisciplinar faz parte do programa pedagógico de dos 
cursos superiores de tecnologia a distância da UNIP EaD, a fim de propiciar ao aluno 
a fundamentação prática dos conceitos teóricos das disciplinas estudadas no bimestre 
estimulando a solução de problemas relacionados à área e fomentar a execução de 
projeto envolvendo múltiplas disciplinas. 
O PIM VI tem por objetivo principal descrever como será realizado o levan-
tamento e análise dos requisitos necessários para a elaboração de um sistema de 
controle de vendas para uma loja de jogos, acessórios e produtos geek, onde será 
necessário colocar em prática todo aprendizado adquirido através das aulas e livros 
do período atual. com base nos conhecimentos adquiridos será realizado o levanta-
mento das funcionalidades para o gerenciamento do sistema com a finalidade de 
proporcionar ao usuário final o sistema de gerenciamento de cadastros , alterações, 
consultas e exclusão dos produtos vendidos na loja, cadastros de clientes e realizar 
o controle de acesso ao sistemas através de níveis de login. 
 
7 
 
2. O PROJETO 
Um sistema de informação pode ser definido como um conjunto de compo-
nentes inter-relacionados que coletam, processam, armazenam e distribui informa-
ções a fim de apoiar a tomada de decisões, a coordenação e o controle de uma orga-
nização. Além disso também auxiliam gerentes e trabalhadores a analisar problemas, 
visualizar assuntos complexos e criar novas soluções. (LAUDON & LAUDON, 2004). 
 
3. CENÁRIO PROPOSTO 
 “Uma loja de venda de jogos eletrônicos, acessórios e produtos geek fechou 
um contrato com uma empresa para o desenvolvimento de um software de controle e 
gerenciamento de vendas de produtos e acessórios na área de jogos e cultura geek. 
Atualmente, as pequenas tarefas gerenciadas para controlar vendas são manipuladas 
utilizando planilhas em Excel. 
 Para atender o cliente será desenvolvido um sistema desktop, e por isso, con-
tratou-se uma fábrica de software (grupo PIM) para o desenvolvimento. Nessa fase foi 
solicitada a elaboração do levantamento de requisitos do sistema e pede-se que: o 
sistema deve ser desenvolvido para plataforma desktop, deve possuirmódulos de 
acessibilidade para que eventuais portadores de deficiência consigam utilizá-lo. 
A empresa possui alguns produtos em estoque que, eventualmente por grau 
de raridade e disponibilidade na plataforma de desenvolvimento dos jogos, não podem 
ser mais adquiridos pelo cliente, tornando seu controle de venda um pouco mais rigo-
roso, pois alguns produtos, após serem baixados do estoque, dificilmente poderão ser 
adquiridos por encomenda devido seu grau de raridade (item exclusivo/colecionador). 
No entanto, o foco é gerenciar as vendas efetuadas ao cliente.” (Manual PIM VI, 2021, 
p. 24). 
 
4. FUNÇÕES DE NEGÓCIO 
 Pode-se dizer que funções de negócio são fundamentos que servem para re-
tratar o compromisso de uma corporação. Funções de negócio bem definidas são per-
duráveis ao longo do tempo, mesmo diante de uma reestruturação na empresa. 
 Uma função é uma série de atividades relacionadas, que abrange uma ou mais 
entidade de dados, e são executadas com a finalidade de cumprir os propósitos da 
empresa. 
8 
 
As funções de negócio deste projeto têm por finalidade realizar o controle de 
vendas dos produtos disponíveis na empresa, através do gerenciamento, monitora-
mento e controle das atividades, trazendo assim um resultado financeiro e que servirá 
as necessidades dos clientes. 
 
5. SOLUÇÕES DISPONÍVEIS NO MERCADO 
 É de suma importância para qualquer loja independentemente do seu seg-
mento, dispor de uma ferramenta que auxilie no seu gerenciamento. Os sistemas de 
gerenciamento de loja têm um papel fundamental no contexto operacional da empresa, 
pois será responsável por controlar o fluxo financeiro através da entrada e saída de 
recursos, gerenciar o estoque, através do controle das mercadorias que se encontram 
disponíveis. 
 Existem inúmeras ferramentas disponíveis no mercado, e seus valores variam 
de acordo com o que será oferecido ao cliente, segue abaixo algumas das ferramentas 
disponíveis e que foram pesquisadas no desenvolvimento do projeto. 
• Programa NEX: Sistema de gestão comercial onde é possível controlar o 
estoque, registrar vendas, controle de caixa, emitir notas fiscais, dentre ou-
tras funcionalidades. Seus preços variam de R$ 39,00 a R$ 99,00 mensais 
e cada valor de plano alguns recursos a mais. 
• Hiper: Sistema que oferece gestão financeira, controle de estoque, docu-
mentos fiscais, dentre outras funções. 
• Sistema Raposa: Sistema de gestão e emissão de NF-E e NFC-E, oferece 
sistema de Frente de caixa, Gestão comercial, Controle de estoque, entre 
outras funcionalidades. 
 
O sistema desenvolvido no projeto será capaz de atender toda demanda do 
cliente, atendendo os requisitos funcionais e não funcionais do software, o que possi-
bilitará desenvolver uma ferramenta de acordo com as necessidades do cliente o que 
a torna economicamente mais viável e a diferencia daquelas já disponíveis no mer-
cado. 
O desenvolvimento de um sistema sob medida traz diversas vantagens, pois 
o mesmo será construído pensando especificamente nas peculiaridades da empresa, 
o que possibilitara que o mesmo tenha menos erros e proporcione uma maior produ-
tividade. Dentre as diversas vantagens podemos citar ainda: 
9 
 
• Facilidade na implementação; 
• Custo benefício; 
• Flexibilidade; 
• Facilidade no treinamento. 
 
6. AUTOMATIZAÇÃO DAS OPERAÇÕES 
 Segundo o dicionário inFormal, automação é o processo ao qual o homem 
deixa de executar as suas tarefas, passando a utilizar maquinas. De acordo com o 
problema proposto no projeto algumas operações serão automatizadas são elas: 
• Envio de Email aos clientes onde o mesmo será informado sobre os produtos 
reservados pelo mesmo. 
• Email marketing que será enviado as clientes que concordarem com o envio, 
informando sobre promoções. 
 
6.1 Casos de uso 
 O diagrama de casos de uso descreve a funcionalidade proposta para um novo 
sistema que será projetado e é uma excelente ferramenta para o levantamento de re-
quisitos funcionais do sistema. Casos de uso são narrativas em texto, amplamente 
utilizadas para descobrir e registrar requisitos. LARMAN, 2007. 
 O caso de uso busca expor o que o sistema faz, e não como ele executa de-
terminada funcionalidade. 
 Larman (2007) destaca alguns elementos fundamentais na construção de ca-
sos de uso são eles: 
• Ator: algo com comportamento como uma pessoa, um sistema ou uma or-
ganização, no caso proposto o ator será o caixa e o cliente. 
• Cenário: sequencia especifica de ações e interações entre os atores e o 
sistema. 
 
 A UML, linguagem de modelagem unificada, traz para o contexto computacional 
a padronização de uma linguagem utilizada para representar informações referentes 
a um sistema. 
 Segue abaixo os modelos de caso de uso do sistema. 
10 
 
Figura 1: Escolha do produto 
 
Fonte: Autoria própria 
 
 
Tabela 1: Gabarito do caso de uso 
Nome do caso de uso: Escolher produto 
Escopo: Escolha do produto 
Ator: Cliente / Atendente 
Interessados: Cliente /Atendente / Loja 
Pré-condições: O atendente deve estar autenticado no sistema. 
Pós condição: O atendente / cliente escolhe o produto 
Fluxo básico: - O Sistema busca o produto no controle de vendas 
- O sistema exibe na tela o resultado da busca 
 
Nome do caso de uso: Filtrar consulta 
Escopo: Escolha do produto 
Ator: Cliente / Atendente 
Interessados: Cliente /Atendente / Loja 
Pré-condições: O atendente deve estar autenticado no sistema. 
Pós condição: O atendente / cliente tem o resultado da consulta 
11 
 
Fluxo básico: - O atendente / cliente fornece os dados do produto a 
ser consultado. 
- O sistema usa os dados fornecidos e busca na base 
de dados do sistema os produtos com características 
semelhantes. 
- Após a busca o sistema exibe em tela todo o resultado 
da pesquisa. 
 
Nome do caso de uso: Adicionar ao carrinho 
Escopo: Escolha do produto 
Ator: Cliente / Atendente 
Interessados: Cliente /Atendente / Loja 
Pré-condições: O atendente deve estar autenticado no sistema. 
Pós condição: Carrinho de compras 
Fluxo básico: - O atendente seleciona o produto desejado e clica em 
adicionar ao carrinho; 
- O sistema armazena a informação do pedido em uma 
tabela. 
 
 
Nome do caso de uso: Remover do carrinho 
Escopo: Escolha do produto 
Ator: Cliente / Atendente 
Interessados: Cliente /Atendente / Loja 
Pré-condições: O atendente deve estar autenticado no sistema. 
Pós condição: Ter produtos no carrinho de compras 
Fluxo básico: - O atendente acessa a página do carrinho de compras, 
seleciona o produto e clica em remover; 
- O sistema remove o produto da tabela e em seguida 
recalcula o valor final da compra. 
 
 
12 
 
Figura 2: Finalizar compra 
 
Fonte: Autoria própria 
Nome do caso de uso: Finalizar compra 
Escopo: Finalização da compra 
Ator: Cliente / Atendente 
Interessados: Cliente /Atendente / Loja / Operadora 
Pré-condições: O atendente deve estar autenticado no 
sistema. 
Pós condição: Ter produtos no carrinho de compras 
Fluxo básico: - O Atendente informa a quantidade de-
seja do produto e clica em finalizar com-
pra. 
 
Nome do caso de uso: Registrar venda 
Escopo: Finalização da compra 
Ator: Cliente / Atendente 
Interessados: Cliente /Atendente / Loja / Operadora 
13 
 
Pré-condições: O atendente deve estar autenticado no sistema. 
Pós condição: Ter produtos no carrinho de compras 
Fluxo básico: - O Sistema envia para o estoque a quantidade de pro-
dutos vendidos e da baixa no mesmo. 
 
 
Nome do caso de uso: Efetuar pagamento 
Escopo: Escolha do produto 
Ator: Cliente / Atendente 
Interessados: Cliente /Atendente / Loja / Operadora 
Pré-condições: O atendente deve estar autenticado no sistema. 
Pós condição: Ter produtos no carrinho de compras 
Fluxo básico: - O Sistema calcula o valor total da compra 
- O atendente informa ao cliente o valor total 
- O cliente informa a forma de pagamento se em di-
nheiroou em cartão. 
 
 
Nome do caso de uso: Pagamento em dinheiro 
Escopo: Finalização da compra 
Ator: Cliente / Atendente 
Interessados: Cliente /Atendente / Loja / Operadora 
Pré-condições: Ter produtos no carrinho de compras 
Pós condição: O atendente termina o processo de compra 
Fluxo básico: - O atendente registra a quantia recebida; 
- O sistema mostra o troco e gera o recibo; 
-O sistema registra o final da transação. 
 
Nome do caso de uso: Pagamento em cartão 
Escopo: Finalização da compra 
Ator: Cliente / Atendente 
Interessados: Cliente /Atendente / Loja / Operadora 
Pré-condições: Ter produtos no carrinho de compras 
14 
 
Pós condição: Operadora de cartões disponível 
Fluxo básico: - O atendente passa o cartão; 
- O cliente digita a senha do cartão 
 
Nome do caso de uso: Enviar dados do cartão 
Escopo: Finalização da compra 
Ator: Cliente / Atendente 
Interessados: Cliente /Atendente / Loja / Operadora 
Pré-condições: Operadora de cartões disponível 
Pós condição: Ter produtos no carrinho de compras 
Fluxo básico: - O sistema envia os dados do cliente à operadora de 
cartões que fará a validação dos mesmos. 
 
Nome do caso de uso: Validar dados do cartão 
Escopo: Finalização da compra 
Ator: Cliente / Atendente 
Interessados: Cliente /Atendente / Loja / Operadora 
Pré-condições: Operadora de cartões disponível 
Pós condição: Efetiva a compra mediante autorização da operadora 
Fluxo básico: - A operadora de cartões valida os dados do cliente; 
- Se houver crédito disponível 
- O sistema exibe a mensagem de compra autorizada e 
registra o final da transação 
Fluxo alternativo: - Não havendo credito disponível o sistema informa que 
a compra não foi autorizada e oferece outra forma de 
pagamento. 
 
7. ANÁLISE E LEVANTAMENTO DOS REQUISITOS 
Um sistema computacional atende a diversas demandas quase que simulta-
neamente. Para isso, eles devem trazer entre suas funcionalidades características 
que atendam essas diferentes vertentes. Dentre elas podemos destacar as necessi-
dades de um cliente, de negócio, de sistema e até de usuário. 
15 
 
O levantamento do das funcionalidades é o meio para que o software atinja 
as necessidades do cliente. 
• Requisitos do usuário: Restrições e serviços que serão ofertados ao 
cliente. 
• Requisitos do sistema: Funções e limitações funcionais, podendo tra-
zer ainda detalhes técnicos. 
 
7.1. Plano de projeto 
O planejamento de um software tem como uma de suas principais atividades 
a obtenção de requisitos. Pois o mesmo tem a finalidade de fazer com que o software 
atenda às necessidades do cliente. 
Segundo SOMERVILLE, 2011. O momento da coleta de requisitos é o pro-
cesso de reunir informações sobre o sistema requerido e os sistemas existentes e 
separar dessas informações os requisitos de usuário e de sistema. 
Formas de coleta de requisitos: 
• Entrevistas; 
• Cenários; 
• Casos de Uso: Trazem definições estabelecidas pela linguagem unifi-
cada (UML), que é o modo que será feito neste projeto. 
• Etnografia. 
 
7.2 Requisitos funcionais 
 São declarações de serviços que o sistema deve fornecer, de como o sistema 
deve agir a entradas especificas, de como o sistema deve se comportar em determi-
nadas situações. Em alguns casos também podem explicar o que o sistema não deve 
fazer (SOMMERVILLE, 2011). 
 
7.3 Requisitos não funcionais 
 Pode ser descrito como um atributo de qualidade, de desempenho, de segu-
rança ou como restrição geral em um sistema (PRESSMAN; MAXIM, 2016). 
 Para SOMMERVILLE, 2011. Esses requisitos podem estar relacionados as pro-
priedades emergentes do sistema, como confiabilidade, tempo de resposta, e ocupa-
ção de área. 
16 
 
 Os requisitos não funcionais são chamados de atributos de qualidade de um 
sistema. Outros termos para requisitos não funcionais são qualidades, objetivos de 
qualidade, requisitos de qualidade de serviço, restrições e requisitos não comporta-
mentais. Informalmente, podem, também, serem chamados de qualidades, de atribu-
tos, como estabilidade e portabilidade. As qualidades que são requisitos não funcio-
nais podem ser divididas em duas categorias principais (CHUNG, 2012). 
• Qualidades de execução: como segurança e usabilidade 
• Qualidades de evolução: como testabilidade, capacidade de manutenção, ex-
tensibilidade e escalabilidade. 
 
Os requisitos funcionais são descritos com uso de uma escrita continua ou de 
tabelas (EELES,2005). 
 
7.3.1 Requisitos não funcionais do sistema 
Identificador RNF001 
Nome Segurança de acesso 
Categoria Segurança 
Prioridade Essencial 
Descrição Cada usuário terá uma senha pessoal e intransferível, para que ne-
nhum outro usuário possa fazer alterações no sistema com a senha 
de terceiros. 
Todas as transações devem ser criptografadas. 
 
Identificador RNF002 
Nome Desempenho do sistema 
Categoria Desempenho 
Prioridade Essencial 
Descrição Visando um maior desempenho do sistema, o mesmo usará os re-
quisitos mínimos de hardware. 
 
 
Identificador RNF003 
Nome Operadora de cartões 
17 
 
Categoria Vendas 
Prioridade Essencial 
Descrição Uma operadora de cartões é essencial para o sistema, pois é um 
meio para a finalização das compras. 
 
Identificador RNF004 
Nome Disponibilidade do sistema 
Categoria Disponibilidade 
Prioridade Essencial 
Descrição O mesmo contará com um sistema de backup, a rede que de com-
putadores onde será usado o sistema contará também com um fire-
wall, visando evitar ataques externos a rede que possam prejudicar 
o seu funcionamento. 
 
7.3.2 Requisitos não funcionais de usabilidade 
 De acordo com os requisitos não funcionais de usabilidade, um sistema deve 
ser projetado tendo em vista a expectativa dos usuários e a facilidade de uso. 
Identificador RNF005 
Nome Usabilidade do sistema 
Categoria Usabilidade 
Prioridade Essencial 
Descrição O sistema será elaborado para rodar em desktop, entretanto seu 
design será responsivo o que permitira que o mesmo se adapte a 
diversos formatos de dela sem que sua interface seja prejudicada. 
 
Contará com um layout fácil e intuitivo que facilitará o uso por parte 
dos usuários novatos e dos veteranos. 
 
Todos os menus terão um formato consistente e de fácil compreen-
são. 
 
 
 
18 
 
8. CONTEXTO DE USO 
 O Contexto de uso nada mais é que o local onde acontece a interatividade entre 
usuário e produto. Com o avanço da tecnologia este tema ganhou muita importância, 
pois é nesse contexto que são definidas a experiencia que será proporcionada em 
cada situação, Locais onde o produto ou serviço pode ser utilizado e por fim que ex-
pectativas o usuário terá dentro de cada contexto. 
• Quem: O sistema será utilizado por todos que possuam credenciais (login 
e senha). Dentro do contexto serão os funcionários e o proprietário da loja. 
• O que: O sistema será utilizado para processar as vendas dos produtos 
disponíveis na loja. 
• Onde: O sistema será desenvolvido para desktop. 
 
9. REGRAS DE NEGOCIO 
 Um dos elementos mais importantes a serem observados durante a fase de 
levantamento e modelagem de requisitos, bem como em todo processo de criação de 
um software, são as regras de negócio. As regras de negócio definem o modelo ao 
qual a empresa realiza suas atividades e entrega seus produtos e serviços. 
 Segundo YOSHIHARA, 2016. As regras de negócio são caracterizadas pelos 
seguintes itens: 
• Para tornar os processos de negócios mais flexíveis, as regras devem 
ser armazenadas de forma separada e possuir fácil acesso durante um 
projeto. 
• É importante prever as evoluções e modificações das regras de negócio, 
independente do modelo de processo de negócios. 
• É comum que as regras de negócio de alterem com maior frequência 
que os processos de negócio. 
 
Segue abaixo as regras de negócio do projeto em desenvolvimento: 
Identificador RN0001 
Nome Acessar sistema 
Módulo N/A 
DescriçãoTodo acesso é feito na loja por meio de login e senha. 
Autor Lucas 
19 
 
Versão 1.0 
 
Identificador RN0002 
Nome Cadastro de produtos 
Módulo N/A 
Descrição O estoquista cadastra os produtos que serão vendidos na loja, 
os quais deverão ser divididos por categorias: jogos, acessó-
rios e produtos geek. 
Autor Lucas 
Versão 1.0 
 
Identificador RN0003 
Nome Cadastro de clientes 
Módulo N/A 
Descrição Os cadastros dos clientes devem possuir: código, RG, CPF, 
nome, data do cadastro, endereço, telefone e e-mail do cliente. 
Autor Lucas 
Versão 1.0 
 
Identificador RN0004 
Nome Especificações dos produtos 
Módulo N/A 
Descrição Todos os produtos devem possuir: código de barras, nome 
do produto, categoria, fabricante, quantidade e valor do pro-
duto. Para os jogos e os acessórios, devem ser informados 
em qual plataforma serão utilizados e qual o prazo de garan-
tia que o produto possui. 
Autor Lucas 
Versão 1.0 
 
Identificador RN0005 
Nome Venda de produtos 
Módulo N/A 
20 
 
Descrição A venda deverá possuir os dados do cliente e todos os pro-
dutos adquiridos. Deverá ser gerado um código único da 
venda, com a data da venda, o valor da venda, opções para 
pagamento (dinheiro/cartão), o status de pagamento e o sta-
tus da venda. 
Autor Lucas 
Versão 1.0 
 
Identificador RN0006 
Nome Excluir produtos 
Módulo N/A 
Descrição O atendente poderá excluir produtos da venda caso o cliente 
não queira mais adquiri-los. Apenas o supervisor da loja po-
derá excluir o produto da venda, devendo informar um usuá-
rio e senha válidos. 
Autor Lucas 
Versão 1.0 
 
Identificador RN0007 
Nome Consulta de preços 
Módulo N/A 
Descrição O atendente poderá consultar os preços dos produtos caso o 
cliente solicite. 
Autor Lucas 
Versão 1.0 
 
 
Identificador RN0008 
Nome Cancelamento de vendas 
Módulo N/A 
Descrição a venda pode ser cancelada apenas pelo supervisor da loja, 
que deve informar usuário e senha válidos. No momento do 
21 
 
cancelamento, o código da venda deve ser enviado para o 
sistema financeiro. 
Autor Lucas 
Versão 1.0 
 
Estas regras de negócio foram tiradas no Manual do PIM VI. 
 
10.GLOSSÁRIO DO SISTEMA 
Termo English Term Descrição 
Geek Geek Segundo o site significados.com, Geek é 
uma gíria da língua inglesa cujo signifi-
cado é alguém viciado em tecnologia, em 
computadores e internet 
Usabilidade Usability Conforme o dicionário online português 
(Dicio), usabilidade é a facilidade com a 
qual um equipamento ou programa pode 
ser usado. 
Login Login Conforme o dicionário online português 
(Dicio), login é o modo de ligação a uma 
rede protegida que da acesso ao usuário 
a um sistema informático, por meio da in-
trodução de uma identidade e senha. 
Requisitos Requirements Conforme o dicionário online português 
(Dicio), requisitos pode ser definido como 
condições necessárias, geralmente obri-
gatórias, para se conseguir algo. 
 
11.CLASSES E OBJETO 
A programação orientada a objetos é constituída de classes e objetos. O objeto 
é criado a partir de uma classe e são extensões do mundo real para o mundo da 
programação (KOLLING, 2004). 
 Os objetos correspondem a elementos da vida real e classes agrupam esses 
objetos. Uma classe e seus objetos podem ser representados da seguinte maneira: 
22 
 
 
Figura: Classe 
 
Fonte:https://arquivo.devmedia.com.br/REVISTAS/easynet/ima-
gens/36/1/1.png 
 Classes, assim como seus atributos, podem ser privadas ou públicas. Natural-
mente, uma classe que inicie com o termo “public” significa que é pública. Um atributo, 
ou seja, um objeto que é iniciado com “private” é visível apenas a classe pertencente. 
 
12.ENCAPSULAMENTO 
Um dos destaques da programação orientada a objetos é a capacidade de jun-
tar um determinado tipo de programa em partes, ou seja, o software tem pedaços 
isolados entre si, que podem ser acessados de modo independente. Essa possibili-
dade de juntar partes e conectá-las é chamada de encapsulamento. 
 
Pode-se concluir que o encapsulamento pode ser utilizado na POO como 
forma de restringir a visibilidade de informações e detalhes de implementações (FER-
NANDES, 2016). 
 
13.HERANÇA E POLIMORFISMO 
 A programação orientada a objetos é um tipo de linguagem de programação 
que traz padrão de segurança e reaproveitamento de código. 
 
 
23 
 
13.1 Herança 
 A herança é uma maneira de reutilizar o código. Nela uma nova classe é criada, 
absorvendo os membros de uma classe já existente. A partir da herança é possível 
economizar tempo no desenvolvimento de um programa, já que pode utilizar códigos 
já testados e aprovados. 
 
13.2 Polimorfismo 
 Parte essencial das hierarquias e herança, o polimorfismo permite programar 
de forma ampla em vez de perder tempo no desenvolvimento de códigos específicos. 
Ou seja, com ele é possível escrever sistemas que processam objetos que comparti-
lham a mesma superclasse como se eles fossem parte dela diretamente (DEI-
TEL,2005). 
 
14.DIAGRAMA DE CLASSES 
 Segue abaixo o diagrama de classes do sistema para a realização de um pe-
dido, onde mostra todos os campos necessários que devem ser preenchidos para sua 
conclusão. 
24 
 
Figura 3: Diagrama de classes 
 
Fonte: Autoria própria 
 
 
 
 
 
 
 
 
 
 
25 
 
15.MODELO DE DADOS (MER) 
 Segue abaixo o modelo entidade relacionamento do projeto. 
Figura 4: Modelo Entidade Relacionamento (MER) 
 
Fonte: Autoria própria 
 
 
 
 
 
 
 
 
 
 
 
 
 
26 
 
16. CONCLUSÃO 
 O PIM VI foi elaborado com a finalidade de colocar em prática o conteúdo das 
disciplinas estudadas no bimestre atual. Para isso foi necessário desenvolver um sis-
tema de controle de vendas de uma loja de produtos geek, conforme caso proposto 
no próprio manual do PIM VI. 
 Foi realizado o levantamento dos requisitos para fazer com que o sistema aten-
desse toda a demanda do solicitante, através do levantamento das suas funcionalida-
des. Foi levado em consideração todas as regras de negócio estabelecidas. A fim de 
mostrar para o cliente as vantagens de se ter um sistema desenvolvido de acordo com 
a suas necessidades, foi feita uma pesquisa das soluções disponíveis no mercado 
comparando-as com a solução proposta no projeto. 
Foi elaborado também um diagrama de classes e construído o modelo de da-
dos (MER). 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
27 
 
REFERÊNCIAS 
 
Análise de requisitos, disponível em: https://www.infoescola.com/engenharia-de-sof-
tware/analise-de-requisitos/, acessado em 03 jun. 2021 as 09:00. 
POO: o que é programação orientada a objetos, disponível em: 
https://www.alura.com.br/artigos/poo-programacao-orientada-a-objetos, acessado em 
31 mai. 2021 as 10:00. 
PRESSMAN, R. Engenharia de Software. Rio de Janeiro: McGraw-Hill, 2002. 
UNIP -Universidade Paulista. Ref.: Análise de Sistemas Orientada a Objetos. Ara-
caju, 2021. 
 
UNIP -Universidade Paulista. Ref.: Banco de dados. Aracaju, 2021. 
 
UNIP -Universidade Paulista. Ref.: Gestão Estratégica de Recursos humanos. Ara-
caju, 2021. 
 
UNIP -Universidade Paulista. Ref.: Manual PIM VI. Aracaju, 2021. 
 
 
 
 
https://www.infoescola.com/engenharia-de-software/analise-de-requisitos/
https://www.infoescola.com/engenharia-de-software/analise-de-requisitos/
https://www.alura.com.br/artigos/poo-programacao-orientada-a-objetos