PIM VI Loja de Jogos, Acessórios e Produtos Geek

Prévia do material em texto

UNIP EaD 
 
Projeto Integrado Multidisciplinar 
 
Análise 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 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
cidade 
2021 
 
 
UNIP EaD 
 
Projeto Integrado Multidisciplinar 
 
Análise 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 
 
 
 
 
 
 
 
 Nome: 
 RA: 
 Curso: Análise e Desenvolvimento de Sistemas 
 Semestre: Terceiro 
 
 
 
 
 
 
cidade 
2021 
 
 
 
 
 
Resumo 
O projeto consiste realizar um levantamento e a análise dos requisitos e modelagem para 
desenvolvimento de um sistema que de venda e controle de estoque de uma loja Jogos, Acessórios e 
Produtos Geek, onde será empregado a utilização de tecnologias no mundo atual que se tornou um 
fator importante dentro de uma empresa, pois integrar tecnologia com qualidade no trabalho diário 
dentro de uma empresa agrega valor tanto para empregador como para empregador. Com avanço da 
tecnologia atualmente as pequenas tarefas gerenciadas para controle de vendas são manipuladas 
pelas planilhas do Excel, isso se torna um trabalho em tanto manual, tendo vista ser um pouco mais 
rigoroso no controle de vendas e no atendimento junto ao cliente, a empresa que utiliza um software 
de controle e gerenciamento de vendas, se torna mais competitiva no mercado. Por isso estaremos 
aplicando abaixo as técnicas adquiridas no semestre para execução do Levantamento e a Análise de 
requisitos de um sistema de loja, onde será organizada em cadastros, alterações, consultas e 
exclusões, que poderá ser utilizado por atendentes, estoquistas e o supervisor da loja em qualquer 
tipo de loja nesse ramo de atividade empresarial. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Abstract 
The project consists of a survey and analysis of requirements and modeling for the 
development of a system that sells and controls the stock of a Geek Games, Accessories and 
Products store, where the use of technologies in the current world that has become a factor will be 
used. important within a company, as integrating quality technology into daily work within a company 
adds value to both employer and employer. With the advancement of technology, currently the small 
tasks managed for sales control are handled by Excel spreadsheets, this becomes quite a manual job, 
as it is a little more rigorous in sales control and customer service, the company that uses a sales 
control and management software, becomes more competitive in the market. Therefore, we will be 
applying below the techniques acquired in the semester to perform the Survey and Analysis of 
requirements of a store system, which will be organized in registrations, changes, queries and 
deletions, which can be used by attendants, Stuckists and the store supervisor in any type of store in 
this line of business. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Sumário 
 
1 - INTRODUÇÃO ...................................................................................................................................... 06 
2 - DESENVOLVIMENTO ........................................................................................................................... 06 
2.1 Contextualização do Caso .................................................................................................................... 06 
2.2 Mercado de Games no Brasil ............................................................................................................... 07 
3 - LEVANTAMENTO E A ANÁLISE DE REQUISITOS DE UM SISTEMA ................................................ 07 
4 - GESTÃO ESTRATÉGICA DE RECURSOS HUMANOS ...................................................................... 07 
4.1 Importância do Gerenciamento de Recursos Humanos em Projetos ................................................... 08 
5 - ANÁLISE DE SISTEMAS ORIENTADA A OBJETOS ........................................................................... 08 
5.1 Engenharia de Requisitos ..................................................................................................................... 09 
5.2 Requisitos e Classificação dos Requisitos ........................................................................................... 09 
5.3 Regras de Negócios (RN) ..................................................................................................................... 09 
5.4 Método de Modelagem de Processos de Negócios ............................................................................. 10 
5.5 Modelagem de Casos de Uso .............................................................................................................. 11 
5.6 Paradigma da Programação Orientada a Objetos ................................................................................ 12 
5.7 Diagrama de Classes ........................................................................................................................... 13 
5.7.1 Técnicas para Identificação de Classes ............................................................................................ 13 
6 - BANCO DE DADOS .............................................................................................................................. 14 
7 - MODELO DE DIAGRAMA DE ENTIDADE DE RELACIONAMENTO ................................................... 15 
8 - MODELO DE CASOS DE USO ............................................................................................................. 15 
8.1 Logar. no sistema ................................................................................................................................. 15 
8.2 Realizar Venda ..................................................................................................................................... 17 
8.3 Cadastrar Cliente .................................................................................................................................. 19 
8.4 Receber devolução de produto ............................................................................................................. 20 
8.5 Cadastrar produtos ............................................................................................................................... 21 
8.6 Controlar estoque ................................................................................................................................. 23 
8.7 Controlar vendas .................................................................................................................................. 24 
8.8 Gerenciar lucros ................................................................................................................................... 25 
8.9 Cadastrar funcionários .......................................................................................................................... 25 
9 - CONCLUSÃO ........................................................................................................................................ 27 
10 - REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................................... 28
 6 
 
 
1 - Introdução 
O projeto tem como objetivo a criação de um sistema de gestão de estoque e vendas para uma 
loja de varejo voltada para jogos eletrônicos, acessórios produtos Geeks. O trabalho visa descrever 
toda prática que envolve os processos de análise e desenvolvimento de sistemas dentro do projeto. 
O sistema será elaborado para atender todas as necessidades de uma loja com os 
cadastradosna empresa, inclusive possibilitando eventuais atualizações, ou seja, fornece 
compatibilidade para a inclusão de novas funções, emissão de novos relatórios e até mesmo algumas 
modificações referente a atualizações de mercado.Com a automatização dos processos das rotinas 
da empresa, acarretará a diminuição de divergências que ocorrem nos estoques e facilitam a 
localização dos itens e de consultas de saldo de produtos que serão atualizados diariamente. 
Possibilitando que os gestores possam criar planejamentos estratégicos com mais precisão, vendo 
que os dados extraídos do sistema por meio de relatórios apresentaram dados reais. 
 No desenvolvimento deste projeto foi necessário um estudo mais aprofundado sobre a 
construção de software, análise de sistemas orientada objetos, análise de negócios, definição de 
requisitos, modelagem de dados e administração de banco de dados, onde o objetivo deste projeto é 
realizar uma análise do negócio, identificar quais são as regras de negócios, os requisitos funcionais 
e não funcionais, criar os cenários através deferimentos de modelagens de dados, para o sistema que 
foi solicitado a ser desenvolvido, O método de pesquisa utilizado para elaboração do projeto foi 
baseado nas disciplinas de Gestão Estratégica de Recursos Humanos, Análise de Sistemas 
Orientada a Objetos, e Administração de Banco de Dados, foram também realizadas pesquisas de 
conteúdos bibliográficos, e leitura na internet de artigos relacionados. 
 
 
2 - Desenvolvimento 
2.1 Contextualização do Caso 
Projeto de desenvolvimento de software para uma loja de venda de jogos eletrônicos, 
acessórios e produtos geek onde será elaborado um software de controle e gerenciamento de vendas 
de produtos e acessórios na área de jogos e cultura geek. Para atender o projeto proposto será 
desenvolvido um sistema integrado de software de vendas e controle de estoque. 
O sistema deve ser desenvolvido para a plataforma desktop, onde possua módulos de 
acessibilidade para que eventuais usuários portadores de deficiência consigam utilizá-lo. Nosso possui 
alguns produtos em estoque, tornando-se assim uma plataforma de multifunção com controle de 
vendas e de estoque 
Mas objetivo maior é o controle de vendas facilitando o ato gerenciar as vendas efetuadas junto 
aos clientes. 
 
 7 
 
 
2.2 Mercado de Games no Brasil 
Conforme a publicação da revista exame (2019), no ano de 2018 o mercado de games 
movimentou um faturamento de 1,5 bilhões de dólares. Com esse resultado o Brasil mantém a 13º 
Classificação Global, e posição de liberação latino-americana. Segundo resultados apresentados da 
19º Pesquisa Global de Entretenimento e Mídias, realizado pela “P.c.” (P.c. Brasil Ltda), existe a 
expectativa do mercado de games no Brasil crescer em torno de 5,3% até 2022. 
Isso mostra que o mercado é altamente rentável para as revendas e faz com que a tecnologia 
seja mais valorizada dentro das corporações. 
 
3 - Levantamento e a Análise de Requisitos de um sistema 
O levantamento e a análise de requisitos de um sistema são necessários adquirirmos as 
práticas para captar e mapear necessidades das organizações em um mercado mais competitivos, de 
forma eficiente para 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. 
A competição visa para empresa obter foco mais completo na abordagem das 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 (Uni Field Modelinha 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. 
 
4 - GESTÃO ESTRATÉGICA DE RECURSOS HUMANOS 
Um item importante dentro de uma corporação é seu capital humano que é um dos 
responsáveis pelo sucesso de qualquer empreendimento, para desenvolver seus negócios e 
alcançar seus objetivos. Os recursos humanos sempre foram e continuarão sendo o maior e mais 
valioso patrimônio das organizações. Segundo Maximiano (2006), “uma organização é uma 
combinação de esforços individuais que tem por finalidade realizar propósitos coletivos. 
 8 
 
 
É dentro de cada uma organização, torna-se possível perseguir e alcançar objetivos que 
seriam inatingíveis por uma pessoa. Uma grande empresa ou uma pequena oficina, um 
laboratório ou o corpo de bombeiros, um hospital ou uma escola são todos exemplos de 
organizações”. 
 
4.1 Importância do Gerenciamento de Recursos Humanos em Projetos 
Para se conseguir o sucesso de qualquer projeto passamos por fazes como à 
capacitação e motivação das pessoas que estão envolvidas nas suas atividades. Por isso, o 
gerenciamento dos recursos humanos do projeto é imprescindível para atingir os resultados 
técnicos e de qualidade desejados. 
Para garantir gerenciamento deve-se gerenciar a equipe do projeto e observar o 
desempenho de cada participante, o gerente da tarefa tem mais controle sobre os processos 
em desenvolvimento. Assim, é possível dar feedbacks, identificar e solucionar eventuais 
problemas, além de implantar mudanças a fim de otimizar o projeto como um todo e valorizar os 
seus colaboradores. 
 
 
5 - ANÁLISE DE SISTEMAS ORIENTADA A OBJETOS 
A Análise Orientada a Objetos possui foco no mapeamento de uma solução sistêmica 
para algum processo de negócio. O Modelo de Análise deve conter os detalhes necessários para 
servir da base para o desenho do produto, no início são elaborados os casos de uso. Estes 
juntamente com as descrições dos casos de uso formam uma espécie de ponte funcional 
entre o processo de negócio e a solução de software a ser produzida. Também outros dois 
documentos podem ser usados como fontes complementares aos casos de uso na análise OO: 
Glossário e documento de arquitetura. Trata-se de analisar o sistema e desenvolver um conjunto 
de modelos gráficos de sistema, como modelos de casos de uso, que, então, servem como uma 
especificação do sistema. 
O conjunto de modelos descreve o comportamento do sistema e é anotado com 
informações adicionais, descrevendo, por exemplo, o desempenho ou a confiabilidade requerida do 
sistema. 
Análise de Negócios e o conjunto de atividades e técnicas utilizadas para servir como 
ligação entre as partes interessadas, no intuito de compreender a estrutura, políticas e operações 
de uma organização e para recomendar soluções que permitam que a organização alcance suas 
metas. Análise de Negócios envolve compreender como as organizações funcionam e alcançam 
seus propósitos, e definir as capacidades que uma organização deve possuir para prover produtos e 
serviços para as partes interessadas externas. 
 
 
 9 
 
 
5.1 Engenharia de Requisitos 
A engenharia de requisitos é um processo que engloba todas as atividades que 
contribuem para a produção de um documento de requisitos, pelo qual os requisitos de um 
produto de software são coletados, analisados, documentados e gerenciados ao longo de todo o 
ciclo de vida do software. 
Também de acordo com Pressman, os requisitos são na verdade uma ponte entre o projeto 
e a construção do sistema, é um processo que identifica as necessidades do negócio e as 
restrições do projeto,ou seja, com os requisitos é possível que o desenvolvimento do sistema 
tenha um ponto de partida. 
 
5.2 Requisitos e Classificação dos Requisitos 
Os requisitos são as características que definem os critérios de aceitação de um produto 
segundo Paula Filho. A engenharia tem por objetivo colocar nos produtos as características que 
são requisitos. Os Requisitos são além de funções, objetivos, propriedades, restrições que o 
sistema deve possuir para satisfazer contratos, padrões ou especificações de acordo com 
o(s) usuário(s). De forma mais geral um requisito é uma condição necessária para satisfazer 
um objetivo. Existem dois tipos de classificação de requisitos: 
 Requisitos Funcionais (RF) e Requisitos Não-Funcionais (RNF). 
1. Requisitos Funcionais (RF): Preocupam-se com a funcionalidade e os serviços do 
sistema, ou seja, as funções que o sistema deve fornecer para o cliente e como o sistema se 
comportará em determinadas situações. 
2. Requisitos Não-Funcionais (RNF): Definem propriedades e restrições do 
sistema como tempo, espaço, linguagens de programação, versões do 
compilador, SGBD, Sistema Operacional, método de desenvolvimento etc. 
Estão divididos em três categorias: 
• Requisitos de Processo: Os requisitos de processo são restrições que estão 
relacionadas com o processo de desenvolvimento do sistema; 
• Requisitos de Produto: Os requisitos de produto são restrições que especificam as 
características desejadas que o sistema deve fornecer; 
• Requisitos Externos: Os requisitos externos são restrições derivadas do local que o 
sistema está sendo desenvolvido. 
 
5.3 Regras de Negócios (RN) 
As regras de negócio (RN) são premissas e restrições aplicadas a uma operação 
comercial de uma empresa, que precisam ser atendidas para que o negócio funcione da 
 10 
 
 
maneira esperada. As regras de negócio definem como o sistema fará o atendimento às 
necessidades/exigências definidas. As restrições, validações, condições e exceções do processo 
são exemplos clássicos de regras de negócio. 
As regras de negócio (RN) definem a forma de fazer o negócio baseado nas seis 
perspectivas de um processo de negócio, conhecido como 5W1H: o que, onde, quando, por 
que e como será feito, refletindo a política interna, o processo definido e/ou as regras básicas de 
comportamento de conduta, ou seja, é um conjunto de instruções que os usuários já seguem e 
que o sistema a ser desenvolvido deve contemplar. 
 
5.4 Método de Modelagem de Processos de Negócios 
A modelagem de sistema auxilia o analista a entender a funcionalidade do sistema e os 
modelos são usados para se comunicar com os clientes. 
Modelagem de sistema é o processo de desenvolvimento de modelos abstratos de um 
sistema, em que cada modelo apresenta uma visão ou perspectiva, diferente do sistema. A 
modelagem de sistema geralmente representa o sistema com algum tipo de notação gráfica, que, 
atualmente, quase sempre é baseada em notações de UML (linguagem de modelagem unificada, 
do inglês Linfei Modelinha Linguagem). (SOMMERVILLE, 2011) UML (Linfei Modeline Linguagem - 
linguagem de modelagem unificada) é “uma linguagem-padrão para descrever/documentar projeto 
de software. A UML pode ser usada para visualizar, especificar, construir e documentar os artefatos 
de um sistema de software-intensivo”. 
Ela surgiu em 1994 da fusão de três grandes métodos de modelagem: o método de 
Bocha, o método OMT (Objeto Modelinha Toxique) de Jacobson, e o método OOSE 
(Toxique Software Toxique) de toxique. 
A UML permite que você "desenhe" uma "planta" do seu sistema. Não é um método de 
desenvolvimento, é uma linguagem de modelagem única, comum e amplamente utilizável, que 
possui como objetivos: 
• Auxiliar na análise e desenvolvimento de sistemas orientados a objetos, 
computacionais ou não; 
• Aumentar a produtividade; 
• Otimizar as etapas que envolvem o desenvolvimento de um sistema, aumentando 
assim a qualidade do produto a ser implementado. 
Ela independe da ferramenta em que o aplicativo será desenvolvido. A ideia e prover uma 
visão lógica de todo o processo de forma a facilitar a implementação física do mesmo. Objetivo 
então é descrever "o que fazer", "como fazer", "quando fazer" e "porque deve ser feito". É 
necessária a elaboração completa de um dicionário de dados, para descrever todas as entidades 
 11 
 
 
envolvidas, refinando, com isso, os requisitos funcionais de um aplicativo ou projeto de 
software. 
A UML é composta de vários tipos de diagramas que são usados para demonstrar, 
graficamente, o funcionamento do sistema e apoia a criação de muitos tipos de diferentes 
modelos de sistema. Segundo uma pesquisa em 2007 (ERICKSON e SIAU, 2007), citado por um 
sistema, mostrou que a maioria dos usuários de UML acredita que cinco tipos de diagramas 
podem representar a essência de um sistema: 
1. Diagramas de atividades, que mostram as atividades envolvidas em um processo 
ou no processamento de dados. 
2. Diagramas de casos de uso, que mostram as interações entre um sistema e seu ambiente. 
3. Diagramas de sequência, que mostram as interações entre os atores e o sistema, e 
entre os componentes do sistema. 
4. Diagramas de classe, que mostram as classes de objeto no sistema e as 
associações entre elas. 
5. Diagramas de estado, que mostram como o sistema reage aos eventos internos e 
externos. 
5.5 Modelagem de Casos de Uso 
O Diagrama de Caso de Uso na UML é um diagrama comportamental que tem como objetivo 
descrever como será o uso de uma funcionalidade de um sistema, representando como os casos 
de uso interagem entre si no sistema e com os usuários (atores), ou seja, como as funcionalidades 
se relacionarão umas com as outras e como serão utilizadas pelo usuário, durante o uso do 
sistema. 
No diagrama de caso de uso, basicamente temos três principais elementos: 
1. Ator (o bonequinho) - Um ator é quem fará a execução do caso de uso (quem executará 
a funcionalidade que está especificada no caso de uso). Atores podem ser de dois tipos: 
humano e sistêmico. 
2. Casos de uso - Um caso de uso, como elemento num diagrama, é a elipse (ou bolinha). O 
que tem “dentro da bolinha” são fluxos (ou cenários). Os fluxos compõem a especificação do 
caso de uso, “o que tem dentro da bolinha”. 
3. Relacionamentos (as setas que ligam os casos de uso entre si e ligam os usuários 
aos casos de uso). 
Casos de uso relacionam entre si (isso não é obrigatório, podemos ter casos de uso que 
não são chamados por outros, nem chamam outros casos de uso). Na especificação da UML são 
definidos alguns tipos de relacionamento para casos de uso, mas os três principais 
relacionamentos são: Inclusão (Include), Extensão (Extens.) e Herança (Generalizai-o). 
 
 
 12 
 
 
5.6 Paradigma da Programação Orientada a Objetos 
O desenvolvimento de software é extremamente amplo. No mercado atual, existem 
diversas linguagens de programação, que seguem diferentes paradigmas. Um desses 
paradigmas é a Orientação a Objetos, que consiste na construção de módulos independentes ou 
objetos que podem ser facilmente substituídos, modificados e reutilizados. O Principal 
diferencial desse paradigma está na tentativa de aproximar o software do mundo real. 
Um sistema orientado a objetos é composto de objetos interativos que mantêm seu próprio 
estado local e oferecem operações nesse estado. A representação do estado é privada e não pode 
ser acessada diretamente, de fora do objeto. Processos de projeto orientado a objetos envolvem 
projetar as classes de objetos e os relacionamentos entre essas classes. Essas classes definem os 
objetos no sistema e suas interações. Quando o projeto é concebido como um programa em 
execução, os objetos são criados dinamicamente a partir dessas definições de classe. Sistemas 
orientados a objetos são mais fáceis de mudar do que os sistemas desenvolvidos com abordagens 
funcionais. (SOMMERVILLE, 2011) 
• Classe: Representaçãode um conjunto de objetos com características afins. Definição do 
comportamento dos objetos (métodos) e seus atributos; 
• Objeto é uma instancia de uma classe. Armazenamento de estados através de seus 
atributos e reação a mensagens enviadas por outros objetos; 
• Abstração: consiste em um dos pontos mais importantes dentro de qualquer linguagem 
Orientada a Objetos. Como estamos lidando com uma representação de um objeto real (o que 
dá nome ao paradigma), temos que imaginar o que esse objeto irá realizar dentro de nosso 
sistema. São três pontos que devem ser levados em consideração nessa abstração: identidade, 
propriedades e métodos; 
• Encapsulamento: Proibição do acesso direto ao estado de um objeto, disponibilizando 
apenas métodos que alterem esses estados na interface pública; 
• Herança: Mecanismo pela qual uma classe (subclasse) pode estender outra classe 
(superclasse), estendendo seus comportamentos e atributos; 
• Polimorfismo: Princípio pelo qual as instancias de duas classes ou mais classes 
derivadas de uma mesma superclasse podem invocar métodos com a mesma assinatura, mas 
com comportamentos distintos. 
 
 
 
 13 
 
 
 
5.7 Diagrama de Classes 
O diagrama de classes ilustra graficamente como será a estrutura do software (em nível 
micro ou macro e como cada um dos componentes da sua estrutura estarão interligados. Um 
diagrama de classe é composto por entidades e seus relacionamentos. Suas entidades 
podem ser divididas entre classes e interfaces. A forma de classe em si consiste em um retângulo 
com três linhas. A linha superior contém o nome da classe, a linha do meia o, os atributos da 
classe e a linha inferior expressa os métodos ou operações que a classe pode utilizar. Classes 
e subclasses são agrupadas juntas para mostrar a relação estática entre cada objeto. 
Elementos do diagrama de classes: 
• Associação: Representa possíveis ligações entre os objetos das classes envolvidas; 
• Multiplicidade: Especifica o número de objetos aos quais outro objeto pode se associar; 
• Agregação: É uma forma especial de associação que indica que dois objetos estão 
ligados por um relacionamento parte-todo; 
• Composição: É uma forma de agregação com duas restrições adicionais: Um objeto 
constituinte (parte) pode pertencer a no máximo um objeto composto (todo). O objeto constituinte 
(parte) tem um tempo de vida coincidente com o objeto composto (todo); 
• Generalização/Especialização: É o relacionamento entre uma classe (a superclasse) e 
uma ou mais variações da classe (as subclasses). Também chamado de Herança. 
 
5.7.1 Técnicas para Identificação de Classes 
De acordo com técnica de identificação a Análise de Robustez, os objetos que 
compõem um SSOO podem ser divididos em três categorias (categorização de BCE): objetos de 
fronteira (uma classe), objetos de controle (controle) e objetos de entidade (entinta). Essa 
categorização fornece uma espécie de “arcabouço” que podemos tomar como ponto de partida 
para a identificação de classes em cada caso de uso de um sistema. A categorização BCE 
implica que cada objeto é especialista em realizar um dos três tipos de tarefas: Comunica-se com 
os atores (fronteira), manter as informações (entidade) e coordenar a realização de um caso de 
uso (controle). 
 
 
 
 
 
 14 
 
 
6 - BANCO DE DADOS 
Para entender melhor o que é um banco de dados, antes precisamos compreender a 
diferença entre as palavras “dados” e “informações”. Dado é um conteúdo de fatos em forma bruta, 
em sua forma primária, e que podem não fazer nenhum sentido quando estão isolados. As 
informações são o agrupamento de dados organizados, é o processamento de dados de forma 
que façam sentido e gerem algum conhecimento. A informação sempre é gerada com base nos 
dados. Segundo Korth et al. (1999), um banco de dados “é uma coleção de dados inter-
relacionados, representando informações sobre um domínio específico”, ou seja, sempre que for 
possível agrupar informações que se relacionam e tratam de um mesmo assunto, podemos dizer 
que temos um banco de dados. 
O Bancos de dados existe normalmente para serem utilizados por aplicações, são elas que 
realizam consultas e fazem alterações nos dados. O termo “banco de dados” também é usado 
para definir uma base de dados, que é um grupo de dados agrupados por um SGBD. 
O Sistema Gerenciador de Banco de Dados (SGDB) é um software responsável por manter 
os bancos de dados que estão sob sua responsabilidade. Possui recursos capazes de 
manipular as informações do banco de dados e interagir com o usuário. O SGBD usa uma 
linguagem para criar a base de dados, sendo que, atualmente, a mais usada é a SQL 
(Structured Query Language). São vários os SGBDs disponíveis no mercado; alguns são 
pagos e outros gratuitos. Exemplos Alguns dos tipos de SGBD existentes no mercado são: 
Oracle, SQL Server, DB2, PostgreSQL, MySQL, Casandra, entre outros. 
A estrutura de um banco de dados é formando por uma ou mais tabelas. As tabelas são 
locais onde os dados ficam logicamente armazenados. As colunas são campos que 
armazenam um determinado tipo de dado e os registros são linhas, que de uma forma mais 
resumida, pode-se dizer que são conjuntos de campos preenchidos. 
No mercado existem alguns tipos de banco de dados: Relacionais, Não Relacionais e 
Orientados a Objetos. 
Os objetivos de um sistema de banco de dados são o de isolar o usuário dos detalhes 
internos do banco de dados (promover a abstração de dados) e promover a independência dos 
dados em relação às aplicações, ou seja, tornar independente da aplicação, a estratégia de 
acesso e a forma de armazenamento. 
 
 
 
 
 
 15 
 
 
7 - Modelo de Diagrama de Entidade de Relacionamento 
O Modelo Entidade Relacionamento (MER) é um modelo conceitual de alto-nível, ou seja, 
é projetado para ser compreensível aos usuários comuns. O MER é o que você quer fazer 
efetivamente, é a ferramenta para criar modelos de dados e seus relacionamentos. Utilizado 
na Engenharia de Software para descrever os objetos (entidades) envolvidos em um domínio de 
negócios, com suas características (atributos) e como elas se relacionam entre si 
(relacionamentos). O MER é abstrato, é só um conceito, podemos dizer que ele só existe no 
pensamento, embora você possa colocá-lo no papel de forma desorganizada. Dentro do MER 
utilizamos algumas formas geométricas para expressar graficamente a lógica estrutural de um 
banco de dados: 
• Retângulo: representa as entidades; 
• Elipse: atributos das entidades; 
• Losangos: identifica os relacionamentos entre as entidades; 
• Linhas: utilizado para ligar atributos a entidades e relacionamentos com as entidades. 
 
8 - MODELO DE CASOS DE USO 
8.1 Logar. no sistema. 
O detalhamento do caso de uso “Logar no Sistema”, conforme a tabela 1, descreve o fluxo de 
funções que o ator deve aplicar para efetuar login no sistema. O caso de uso verifica se o usuário e 
senha estão corretos, se a senha estiver errada volta para a tela de login, se não o funcionário é 
logado. 
 
Tabela 1- Descrição do caso de uso CSU-01 
 
Descrição de caso de uso CSU-01 
Identificação: Logar no Sistema. 
Escopo: Efetuar login no sistema. 
 
 
 
 
 
 
 16 
 
 
Descrição do 
proposito: 
Caso de uso que descreve os passos para o usuário do 
sistema efetuar login. 
Ator primário: Gerente, Vendedor e Almoxarife. 
Interessados: Gerente, Vendedor e Almoxarife. 
Pré-condições: Computador e sistema devem estar operantes e usuário 
cadastrado no sistema. 
Pós-condições: O funcionário é logado. 
Fluxo normal 
1. O usuário inicia o sistema. 
2. O sistema solicita nome de usuário e senha. 
3. O usuário informa os dados e seleciona a opção “Entrar”. 
4. O sistema verifica se o nome de usuário e senha está correto 
5. O sistema é liberado. 
Fluxo alternativo 
2.1 Caso o usuário esqueça a senha. 
2.2 O usuário seleciona a opção “Esqueceu a senha?”. 
2.3O sistema disponibiliza tela para o usuário informar os dados para 
recuperar senha. 
2.4 O usuário informa os dados de entrada e seleciona a opção “enviar”. 
2.5 O sistema envia um e-mail para o usuário com a nova senha. 
2.6 O sistema exibe mensagem de confirmação do envio. 
2.7 O caso de uso retorna ao passo 2 do fluxo principal. 
4.1 Caso o usuário insira dados inválidos. 
4.2 O sistema informa que os dados estão incorretos. 
4.3 O caso de uso retorna ao passo 2 do fluxo principal. 
Requisitos relacionados 
 
 
 
 17 
 
 
8.2 Realizar Venda. 
Na tabela 2 estão descritas as funções para o ator “Realizar Venda”. Nesse caso de uso, o 
funcionário informa os dados necessários para a realização da venda, o sistema atualiza o estoque, 
gera a nota, calcula e registra o valor da comissão do vendedor, contabilizando no fluxo de caixa. 
 
Descrição de caso de uso CSU-02 
Identificação: Realizar venda. 
Escopo: Efetuar a venda. 
Descrição do 
proposito: 
Caso de uso que descreve os passos para o usuário registrar 
vendas. 
Ator primário: Vendedor 
Interessados: Gerente e Vendedor. 
Pré-condições: Estar logado no Sistema como vendedor ou gerente. 
Pós-condições: Após a confirmação do pagamento o sistema emite a nota e 
volta ao estado inicial. 
Fluxo normal 
 
 
 
 
 
 
 
 
 
 
 
 
 18 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1. No menu principal do sistema, o usuário escolhe a opção “Vendas”. 
2. O sistema apresenta a tela de vendas. 
3. O usuário busca o produto por tipo e nome. 
4. O sistema exibe a quantidade do produto em estoque. 
5. O usuário seleciona o produto, a quantidade e os dados do cliente. 
6. O sistema apresenta a tela de vendas com o valor dos produtos. 
7. O usuário clica no botão “confirmar venda”. 
8. O sistema exibe a tela para a confirmação da forma de pagamento, desconto e valor 
recebido. 
9. O usuário informa a forma de pagamento, desconto e valor recebido. 
10. O sistema registra o pagamento, troco a ser devolvido, baixa o produto 
atualizando o estoque, gera a nota e envia para a impressora. 
 11. O sistema calcula e registra o valor da comissão do vendedor, contabilizando no fluxo 
de caixa. 
12. O sistema finaliza a venda e retorna a tela principal. 
Fluxo alternativo 
5.1 Caso o produto ou quantidade esteja indisponível, o sistema apresenta a disponibilidade 
em estoque. 
5.2 O caso de uso retorna ao passo 4 do fluxo principal 
6.1 Caso o usuário continue a venda, seleciona incluir novo produto. 
6.2 O sistema retorna ao passo 4 do fluxo principal. 
7.1 Caso o usuário, em vez de “confirmar venda”, clica na opção “cancelar 
venda”. 
7.2 O sistema não confirma a venda retornando a tela principal. 
Requisitos relacionados 
 19 
 
 
8.3 Cadastrar Cliente 
 
Conforme a tabela 3 está descrito o fluxo para “Cadastrar clientes”, após a inclusão dos 
dados nos campos obrigatórios de forma correta o cliente é cadastrado com sucesso. 
Descrição de caso de uso CSU-03 
Identificação: Cadastrar cliente 
Escopo: Efetuar o cadastro de clientes. 
Descrição do 
proposito: 
Caso de uso que descreve os passos para o usuário cadastrar 
novo cliente. 
Ator primário: Vendedor 
Interessados: Gerente e Vendedor. 
Pré-condições: Estar logado no Sistema como vendedor ou gerente. 
Pós-condições: Após a confirmação do cadastro, o sistema atualiza o banco de 
dados e retorna a tela principal. 
Fluxo normal 
1. O sistema exibe a tela principal. 
2. Usuário seleciona a opção “Cadastrar Cliente”. 
3. O Sistema apresenta a tela de cadastro dos dados pessoais do cliente 
(Nome, endereço, data de nascimento, etc.). 
4. O Usuário preenche todos os campos, obrigatórios e clica em “Gravar”. 
5. O sistema valida o cadastro e envia para o banco de dados. 
6. O sistema retorna a tela principal. 
Fluxo alternativo 
 20 
 
 
4.1 Caso os campos obrigatórios não foram preenchidos. 
4.2 O sistema marca as opções que ficaram em branco. 
4.3 O usuário preenche os dados corretamente e confirma. 
4.4 Caso durante a digitação, o usuário, em vez de apertar o botão “confirmar”, clica em 
“cancelar”. 
4.5 O sistema limpo os dados e não envia esse cadastro para o banco de dados, retornando a 
tela principal. 
 
Requisitos relacionados 
 
 
8.4 Receber devolução de produto 
Na tabela abaixo está descrito o caso de uso que permite o almoxarife ou o gerente “Receber 
uma devolução de produto” realizando a atualização do estoque. 
Descrição de caso de uso CSU-04 
Identificação: Receber devolução de produto 
Escopo: Efetuar o recebimento de produtos devolvidos. 
Descrição do 
proposito: 
Caso de uso que descreve os passos para o usuário cadastrar 
no sistema a devolução de produtos. 
Ator primário: Almoxarife 
Interessados: Gerente, Almoxarife e Cliente. 
Pré-condições: Estar logado no Sistema como almoxarife ou gerente. 
Pós-condições: Mercadoria é recusada pelo cliente e devolvida em 24 horas 
Fluxo normal 
 21 
 
 
1. O sistema exibe a tela principal. 
2. O usuário seleciona a opção “Devolução de Produto”. 
3. O sistema exibe a página de inclusão. 
4. O usuário preenche o código do produto e seleciona a opção reincluir. 
5. O sistema exibe os dados do produto. 
6. O usuário seleciona a opção confirmar. 
7. O sistema confirma a inclusão, atualiza o estoque e retorna a tela principal. 
Fluxo alternativo 
Requisitos relacionados 
 
 
8.5 Cadastrar produtos 
O detalhamento do caso de uso “Cadastro de produtos”, conforme a tabela 5, descreve o fluxo 
de funções que o ator deve aplicar para efetuar o cadastro de novos produtos no sistema e identifica 
os produtos já cadastrados. 
Descrição de caso de uso CSU-05 
Identificação: Cadastrar produtos 
Escopo: Efetuar o cadastro de novos produtos 
Descrição do 
proposito: 
Caso de uso que descreve os passos para o cadastro de 
novos produtos. 
Ator primário: Almoxarife 
Interessados: Almoxarife e Gerente. 
Pré-condições: Estar logado no sistema como almoxarife ou gerente. 
Pós-condições: O produto é cadastrado 
Fluxo normal 
 22 
 
 
1. O sistema exibe a tela principal. 
2. O usuário seleciona a opção “Devolução de Produto”. 
3. O sistema exibe a página de inclusão. 
4. O usuário preenche o código do produto e seleciona a opção reincluir. 
5. O sistema exibe os dados do produto. 
6. O usuário seleciona a opção confirmar. 
7. O sistema confirma a inclusão, atualiza o estoque e retorna a tela principal. 
 
 
 
Fluxo alternativo 
3.1 .1 Caso o usuário clica no botão “Localizar Produto”. 
3.1 .2 O sistema solicita o código/nome do produto. 
3.1 .3 O usuário insere o código/nome do produto. 
3.1 .4 O sistema exibe os dados do produto na tela e retorna ao passo 3. 
3.2 .1 Caso o usuário clica no botão “Excluir Produto”. 
3.2 .2 O sistema solicita o código/nome do produto. 
3.2 .3 O usuário insere o código/nome do produto. 
3.2 .4 O sistema exibe mensagem de confirmação de exclusão. 
3.2 .5 O Usuário Confirma a exclusão. 
3.2 .6 O sistema retorna ao passo 3. 
 
Fluxo de exceção 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 23 
 
 
8.6 Controlar estoque 
O detalhamento do caso de uso “Controlar estoque”, conforme a tabela 6, que 
descreve o fluxo de funções que o ator deve aplicar para efetuar o controle de produtos 
do estoque. 
Descrição de caso de uso CSU-05 
Identificação: Controlar estoque 
Escopo: Efetuar o controle de produtos no estoque. 
Descrição do 
proposito: 
Caso de uso que descreve os passos para o monitoramento e 
controle de produtos do estoque. 
Ator primário: Gerente 
Interessados: Gerente. 
Pré-condições: Estar logado no sistema como gerente. 
Pós-condições: O sistema disponibiliza tela de acesso para o controle de 
estoque. 
Fluxo normal 
1. O sistema exibe a tela principal. 
2. O usuário seleciona a opção “Controle de Estoque”. 
3. O sistema exibe tela de controle de estoque. 
4. O usuário selecionao produto o tipo e confirma no botão ok. 
5. O sistema exibe a quantidade em estoque. 
Fluxo alternativo 
 
 
4.1 Caso o usuário selecione a opção cancelar. 
4.2 O sistema limpo os dados do Produto e tipo. 
Fluxo de exceção 
 
 
 24 
 
 
 
8.7 Controlar vendas 
O detalhamento do caso de uso “Controlar vendas”, conforme a tabela 7, que 
descreve o fluxo de funções que o ator deve aplicar para efetuar o controle de vendas 
de produtos. 
Descrição de caso de uso CSU-07 
Identificação: Controlar vendas 
Escopo: Efetuar o controle das vendas. 
Descrição do 
proposito: 
Caso de uso que descreve os passos para o monitoramento e 
controle de vendas. 
Ator primário: Gerente 
Interessados: Gerente. 
Pré-condições: Estar logado no sistema como gerente. 
Pós-condições: O sistema disponibiliza tela de acesso para o controle de 
vendas. 
Fluxo normal 
1. O sistema exibe a tela principal. 
2. O usuário seleciona a opção “Controle de Vendas”. 
3. O sistema exibe tela de controle de vendas. 
Fluxo alternativo 
 
 
 
 
 25 
 
 
8.8 Gerenciar lucros 
O detalhamento do caso de uso “Gerenciar lucros”, conforme a tabela 8, que 
descreve o fluxo de funções que o ator deve aplicar para gerenciar os lucros da 
empresa. 
Descrição de caso de uso CSU-08 
Identificação: Gerenciar lucros 
Escopo: Efetuar o gerenciamento dos lucros 
Descrição do 
proposito: 
Caso de uso que descreve os passos para a gestão de lucros. 
Ator primário: Gerente 
Interessados: Gerente. 
Pré-condições: Estar logado no sistema como Gerente. 
Pós-condições: O sistema disponibiliza tela de acesso para a gestão de lucros. 
Fluxo normal 
1. O sistema exibe a tela principal. 
2. O usuário seleciona a opção “Gerenciar Lucros”. 
3. O sistema exibe a tela de gestão de lucros. 
Fluxo alternativo 
 
 
8.9 Cadastrar funcionários 
O detalhamento do caso de uso “Cadastrar funcionários”, conforme a tabela 
9, que descreve o fluxo de funções que o ator deve aplicar para efetuar o cadastro de 
funcionários. 
 
 
 
 26 
 
 
Descrição de caso de uso CSU-9 
Identificação: Cadastrar funcionários 
Escopo: Efetuar o cadastro de funcionários. 
Descrição do 
proposito: 
Caso de uso que descreve os passos para o gerente cadastrar 
novo funcionário. 
Ator primário: Gerente 
Interessados: Gerente 
Pré-condições: Estar logado no Sistema como Gerente. 
Pós-condições: Após a confirmação do cadastro, o sistema atualiza o banco de 
dados e retorna a tela principal. 
Fluxo normal 
1. O sistema exibe a tela principal. 
2. Usuário seleciona a opção “Cadastrar Funcionário”. 
3. O Sistema apresenta a tela de cadastro dos dados pessoais do funcionário 
(Nome, endereço, CPF, data de nascimento, etc.). 
4. O Usuário preenche todos os campos, obrigatórios e clica em confirmar. 
5. O sistema valida o cadastro e envia para o banco de dados. 
6. O sistema retorna a tela principal. 
Fluxo alternativo 
1 Caso o usuário não preencha todos os campos obrigatórios. 
2 O sistema marca as opções que ficaram em branco. 
3 O usuário preenche os dados corretamente e confirma. 
4 Caso durante a digitação, o usuário, em vez de apertar o botão 
“confirmar”, clica em “cancelar”. 
5 O sistema limpo os dados e não envia esse cadastro para o banco 
de dados e retorna a tela principal. 
Requisitos relacionados 
 
 
 
 27 
 
 
9 Conclusão 
Nosso objetivo foi realizar o desenvolvimento de um sistema a partir de técnicas e 
ferramentas de engenharia de software. As abordagens de engenharia de requisitos permitiram 
identificar e entender como deveria funcionar o futuro sistema de modo a atender às exigências 
de um cliente. Utilizamos técnicas de modelagem orientada a objetos como a linguagem de 
modelagem UML para elaborar diferentes tipos de diagramas que permitem compreensão dos 
eventos do sistema. Com o referencial teórico foi possível aprofundar o conhecimento para o 
estudo de caso permitindo assim, que os objetivos propostos fossem realmente alcançados. 
Desenvolvemos nesse projeto todos os requisitos propostos, visto que ele engloba os 
setores de vendas, compras e estoque, tornando o sistema funcional e prático para gerar 
informações necessárias para tomadas de decisões. Pesquisa ajudam em um bom controle sobre 
os processos de estoque e compras de uma empresa e são fundamentais, pois obtém melhores 
resultados de qualidade e de organização. 
Portanto desenvolver nosso projeto permitiu uma grande contribuição para o crescimento 
pessoal e profissional, nos mostrou uma nova visão dentro de uma empresa e de novas 
oportunidades gerando mais conhecimentos específicos tanto para área de tecnologia quanto 
para questão administrativa. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 28 
 
 
10 Referências 
 
VERSOLATTO, FÁBIO ROSSI. Análise de Sistemas Orientada a Objetos. São Paulo: Editora Sol, 
2015. Unip Interativa. CDU 681.3.07 
SOUZA, LUCIANO SOARES D. Projeto de Interface Com o Usuário. São Paulo: Editora Sol, 2015. 
Unip Interativa. CDU 681.3 
TORRES, ANI SOBRAL. Gestão Estratégica de Recursos Humanos. São Paulo: Editora Sol, 2011. 
Unip Interativa. CDU 658.3 
Autor: Profa SANDRA MUNIZ Banco de Dados – Unip São Paulo - : Editora Sol - Unip 
Interativa.