VI- (PIM VI)

Prévia do material em texto

UNIP EaD 
Projeto Integrado Multidisciplinar 
Curso Superior 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. 
 
 
 
 
 
 
 
 
 
 
UNIP ALEXÂNIA 
2020 
 
 
 
 
UNIP EaD 
Projeto Integrado Multidisciplinar 
Curso Superior 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. 
 
Nomes completos dos alunos: Deaa Jehad al 
Refaie, Lucas Farias de Moura, Mateus Alves 
Figueiró e Talisson Cleofas Pereira dos Santos. 
RA’s: 1985525, 1864071, 1961046 e 191341. 
Curso: Análise e Desenvolvimento de Sistemas. 
Semestre: 3°. 
 
 
 
 
 
 
UNIP ALEXÂNIA 
2020 
 
 
 
 
 
RESUMO 
O projeto consiste na ideia de um levantamento e a análise de requisitos de um 
sistema para empresa destinada à venda de jogos eletrônicos, acessórios e produtos 
geek. Em que, a seguinte loja contratou-se uma fábrica de software para o 
desenvolvimento de uma plataforma para ajudar ao gerenciamento de vendas 
efetuadas ao cliente. 
Com base no conteúdo das disciplinas, será elaborado o levantamento e a 
análise de requisitos para a criação de um sistema para controlar as vendas da loja. 
Será desenvolvido e aplicado os demais conhecimentos com os métodos e técnicas 
para ser desenvolvido um sistema prático e de fácil acesso para todos os usuários 
conseguir utilizá-lo. 
 
 
 
 
 
 
 
 
 
 
 
 
 
Palavras-chaves: levantamento, análise, venda, software e plataforma. 
 
 
 
 
ABSTRACT 
 
The project consists of the idea of a survey and requirements analysis of a 
system for a company destined to the sale of electronic games, accessories and geek 
products. In which, the following store hired a software factory to develop a platform to 
help manage sales to the customer. 
Based on the content of the disciplines, the survey and analysis of requirements 
will be elaborated to create a system to control store sales. Other knowledge with 
methods and techniques will be developed and applied to develop a practical and 
easily accessible system for all users to be able to use it. 
 
 
 
 
 
 
 
 
 
 
 
 
 
Keywords: survey, analysis, sale, software and platform. 
 
 
 
 
 
 
SUMARIO 
Resumo......................................................................................................................3 
Abstract.....................................................................................................................4 
Introdução........................................................................................................6 
1. Cenário proposto.............................................................................................7 
2. Casos de uso....................................................................................................7 
2.1 Caso de uso – Cadastro de cliente......................................................8 
2.2 Caso de uso – Consulta de Preço........................................................9 
2.3 Caso de uso - Realização da venda.................................................10 
2.4 Caso de uso – Excluir produto da venda.........................................12 
2.5 Caso de uso – Cancelamento da venda...........................................13 
2.6 Caso de uso – Cadastrar Produto.....................................................14 
3. Modelo Entidade Relacionamento ..............................................................16 
4. Requisitos não funcionais...........................................................................17 
4.1 Requisitos de Usabilidade..........................................................................17 
5. Usuários do sistema...................................................................................18 
5.1 Estoquista...............................................................................................18 
5.2 Atendente................................................................................................18 
5.3 Supervisor ...............................................................................................19 
6. Contexto do uso do sistema........................................................................19 
6.1 Quem?.....................................................................................................19 
6.2 O que?.....................................................................................................19 
6.3 Onde?......................................................................................................19 
7. Regras de Negócios.....................................................................................20 
8. Classes de analise.........................................................................................20 
8.1 Diagrama de classes................................................................................21 
Conclusão............................................................................................................22 
Referências bibliográficas.................................................................................23 
 
 
 
 
6 
 
 
INTRODUÇÃO 
O projeto tem como objetivo a criar uma solução para uma loja de venda de 
eletrônicos, acessórios e produtos geek, onde a seguinte loja fechou um contrato com 
uma empresa de desenvolvimento de um software e também com uma fábrica para o 
desenvolvimento. 
Atualmente, as pequenas tarefas gerenciadas para o controle de vendas são 
feitas utilizando planilhas em Excel. Portanto, a loja decidiu uma elaboração do 
levantamento de requisitos do sistema e com base nisso, as informações passadas é 
que deve desenvolver-se uma plataforma desktop. 
A seguinte plataforma, deve possuir módulos de acessibilidade para que 
eventuais portadores de deficiência consigam utilizá-lo. A loja tem como foco é o 
gerenciamento de vendas efetuadas ao cliente, portanto há também produtos em 
estoque que devido ao grau de raridade não pode ser mais adquirido ao cliente. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
7 
 
1. Cenário Proposto 
A proposta de cenário consiste em ser um sistema de gerenciamento de uma 
loja de produtos geek. O cenário é toda base para efetuar o desenvolvimento do 
projeto, porque nele consta os dados que são pedidos para ser feito no sistema, as 
informações principais e o que pede para ser feito. 
Uma loja de acessórios e produtos geek, contratou a empresa para a 
elaboração de um sistema de gestão da loja, onde seu alvo principal e controlar as 
vendas na loja, onde são realizadas por planilhas de Excel. 
Por fim, a loja quer um sistema com uma plataforma para ser utilizada no 
desktop e também possuir módulos acessíveis para usuários portadores de 
deficiência. E por fim também e pedido um controle de estoque para a realização de 
cadastro de novos produtos. 
2. Casos de uso 
Caso de uso é a descrição de uma sequência de atividades executadas por um 
agente externo ao sistema sem que sejam revelados detalhes do funcionamento 
interno ao sistema, por isso dizemos que o caso de uso mostra a visão 
comportamental externa ao sistema (BEZERRA, 2006). 
Se bem descritos e definidos, casos de uso definem um denominador comum, 
de conhecimento do domínio do problema e das funcionalidades do sistema, que pode 
ser interpretado facilmente por usuários, analistas e desenvolvedores (BOOCH; 
JACOBSON; RUMBAUGH, 2006). 
Caso de uso é, de forma genérica, a descrição detalhada dos requisitos de um sistema 
de software que seguem uma determinada metodologia e um determinado padrão. 
 
 
 
 
 
 
 
8 
 
2.1 Caso de uso – Cadastro de cliente 
 
 
Imagem 1 – Cadastro de Cliente 
NOME: Cadastrar Cliente. 
BREVE DESCRIÇÃO: Este caso de uso permite que o atendente possa 
cadastrao cliente no sistema da loja. 
ATORES: Atendente. 
PRÉ-CONDIÇÕES: O atendente precisa estar logado no sistema com o seu 
perfil. 
PÓS-CONDIÇÕES: Cadastro do cliente. 
FLUXO PRINCIPAL: 
P1- O fluxo de eventos principal se inicia quanto o Atendente entra no sistema 
e faz o login. 
P2- O sistema apresenta ao ator o campo de dados para realizar o cadastro do 
cliente. Os dados são: 
 Nome; 
 RG; 
 CPF; 
 Data do cadastro; 
 Endereço; 
 Telefone; 
 E-mail. 
P3- O sistema gera o código do cliente. 
P4- O cliente está cadastrado no sistema. 
 
FLUXO ALTERNATIVO: 
A1- Atendente fazendo o cadastro do cliente. 
 
 
9 
 
O sistema apresenta ao ator o formulário para realizar o cadastro do cliente. 
O ator informa os dados do cliente. 
O ator retorna para o passo 2 (P2) do fluxo principal. 
FLUXO DE EXCEÇÃO: 
E1 – Atendente não informa algum dado do cliente. 
O sistema exibe a mensagem “Favor informar todos os dados do cliente”. 
O sistema retorna para o passo 2 do fluxo principal. (P2) 
 
2.2 Caso de uso – Consulta de Preço 
 
Imagem 2 – Consulta de preço 
NOME: Consultar Preço. 
BREVE DESCRIÇÃO: Este caso de uso permite que o atendenteconsulta o 
preço de um produto no sistema da loja. 
ATORES: Atendente. 
PRÉ-CONDIÇÕES: O atendente precisa estar logado no sistema com o seu 
perfil. 
PÓS-CONDIÇÕES: A consulta do preço. 
FLUXO PRINCIPAL: 
P1 - O fluxo de eventos principal se inicia quando o Atendente entra no sistema. 
P2 - O sistema apresenta ao ator o campo de dados para digitar o código do 
produto. Os dados são: 
• Código de barras. 
P3 - O sistema informa o preço do produto. 
FLUXO ALTERNATIVO: 
 
 
10 
 
A1 – Atendente pesquisando o preço do produto. 
O sistema apresenta ao ator o campo para digitar o código do produto. 
O sistema informa o preço do produto. 
O sistema retorna ao passo 2 (P2) do fluxo principal. 
FLUXO DE EXCEÇÃO 
E1 – Atendente erra algum dígito no código do produto. 
O sistema exibe a mensagem “Produto não existente, verifique o código do 
produto.” 
O sistema retorna ao passo 2 (P2) do fluxo principal. 
2.3 – Caso de uso - Realização da venda 
 
Imagem 3 – Realização da venda 
NOME: Realizar venda. 
BREVE DESCRIÇÃO: Este caso de uso permite que o atendente realiza a 
venda de um produto no sistema da loja. 
ATORES: Atendente e Cliente. 
PRÉ-CONDIÇÕES: O atendente precisa estar logado no sistema com o seu 
perfil. 
PÓS-CONDIÇÕES: A realização da venda. 
FLUXO PRINCIPAL: 
 
 
11 
 
P1- O fluxo de eventos principal se inicia quando o Atendente entra no 
sistema. 
P2- O sistema apresenta ao ator o campo de dados para digitar os dados do 
cliente. Os dados são: 
 Código do cliente; 
 Nome. 
P3 - O sistema informa o preço da venda. 
P4 - O sistema exibe a forma do pagamento. 
P5 – O cliente efetua o pagamento. 
P6 - O sistema gera o código da venda. 
FLUXO ALTERNATIVO: 
A1 – Atendente realizando a venda do produto no sistema. 
O sistema apresenta ao ator o campo para digitar os dados do cliente. 
O sistema informa o preço da venda. 
O sistema informa o código da venda. 
O sistema retorna ao passo 2 (P2) do fluxo principal. 
FLUXO DE EXCEÇÃO 
E1 – Atendente erra ao colocar o código do cliente. 
O sistema exibe a mensagem “Cliente não encontrado.” 
O sistema retorna ao passo 2(P2) do fluxo principal. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
12 
 
2.4 Caso de uso – Excluir produto da venda 
 
 
Imagem 04 – Exclusão do produto da venda 
NOME: Excluir produto da venda. 
BREVE DESCRIÇÃO: Este caso de uso permite que o atendente a retirada de 
um produto da venda se o cliente querer. 
ATORES: Atendente e Supervisor. 
PRÉ-CONDIÇÕES: O atendente precisa estar logado no sistema com o seu 
perfil. 
PÓS-CONDIÇÕES: A exclusão do produto na venda. 
FLUXO PRINCIPAL: 
P1 - O fluxo de eventos principal se inicia quando o Atendente entra no sistema. 
P2 - O sistema apresenta ao ator a retirada do produto na venda. 
P3 - O sistema pede o login do supervisor. 
P4 - O sistema informa sobre a venda. 
FLUXO ALTERNATIVO: 
A1 – Atendente excluindo o produto da venda. 
 
 
13 
 
O sistema exibe a opção de excluir o produto da venda. 
O sistema verifica o login do supervisor. 
O sistema retorna ao passo 2 (P2) do fluxo principal. 
FLUXO DE EXCEÇÃO 
E1 – Supervisor erra o login. 
O sistema exibe a mensagem “Usuário ou senha incorretos.” 
O sistema retorna ao passo 3 (P3) do fluxo principal. 
2.5 Caso de uso – Cancelamento da venda 
 
Imagem 5 – Cancelamento da venda 
NOME: Excluir produto da venda. 
BREVE DESCRIÇÃO: Este caso de uso permite que o supervisor cancelar a 
venda. 
ATORES: Supervisor e Sistema Financeiro. 
PRÉ-CONDIÇÕES: O supervisor precisa estar logado no sistema com o seu 
perfil. 
PÓS-CONDIÇÕES: O cancelamento da venda . 
FLUXO PRINCIPAL: 
 
 
14 
 
P1- O fluxo de eventos principal se inicia quando o Supervisor entra no sistema. 
P2- O sistema apresenta ao ator aopção de cancelar a venda. 
P3- O sistema pede o login do supervisor. 
P4- O sistema informa o código da venda. 
P5- O sistema envia o código ao sistema financeiro. 
FLUXO ALTERNATIVO: 
A1 – Supervisor cancelando a venda. 
O sistema exibe a opção de cancelar a venda. 
O sistema verifica o login do supervisor. 
O sistema retorna ao passo 2 (P2) do fluxo principal. 
FLUXO DE EXCEÇÃO 
E1 – Supervisor erra o login. 
O sistema exibe a mensagem “Usuário ou senha incorretos.” 
O sistema retorna ao passo 3 (P3) do fluxo principal. 
2.6 Caso de uso – Cadastro de Produto 
 
Imagem 6 – Cadastro de Produto 
 
 
15 
 
NOME: Cadastrar Produto. 
BREVE DESCRIÇÃO: Este caso de uso permite que o Estoquista cadastrar 
um novo produto no sistema da loja. 
ATORES: Estoquista. 
PRÉ-CONDIÇÕES: O Estoquista precisa estar logado no sistema com o seu 
perfil. 
PÓS-CONDIÇÕES: O cadastro de um novo produto. 
FLUXO PRINCIPAL: 
P1 - O fluxo de eventos principal se inicia quando o Estoquista entra no sistema. 
P2 - O sistema apresenta ao ator aopção de cadastro de novo produto. 
P3 - O sistema informa os dados para o cadastro do produto. Os dados são: 
 Código de barras; 
 Nome do produto; 
 Categoria; 
 Fabricante; 
 Quantidade; 
 Valor. 
P4 - Se o novo produto for jogos ou acessorios, o sistema informa os dados 
para o cadastro. Os dados são: 
 Plataforma utilizada; 
 Prazo de Garantia. 
P5 - Por fim, o sistema cadastra o produto. 
FLUXO ALTERNATIVO: 
A1 – Estoquista cadastrando o produto.. 
O sistema apresenta ao ator o formulário para realizar o cadastro do novo 
produto. 
O ator informa os dados do produto. 
 
 
16 
 
O sistema retorna ao passo 2 (P2) do fluxo principal. 
FLUXO DE EXCEÇÃO 
E1 – Estoquista não informa algum dado do produto. 
O sistema exibe a mensagem “Favor informar todos os dados do produto” 
O sistema retorna ao passo 2 (P2) do fluxo principal. 
 
3. Modelo Entidade Relacionamento (MER) 
É um modelo abstrato desenvolvido pelo Prof. Peter Chen, a fim de representar 
as estruturas de dados de forma mais natural e mais próxima do mundo real dos 
negócios. Seus aspectos estruturais formalizam matematicamente a maneira como os 
dados estão organizados no modelo relacional. 
É composto por entidades, que são caracterizadas por atributos e que se 
relacionam entre si. Dentro do MER, utilizamos algumas formas geométricas para a 
representação das entidades, seus atributos e seus relacionamentos. 
 
Imagem 7 – Modelo de Entidade Relacionamento (MER) 
 
 
17 
 
4. Requisitos não funcionais 
Os requisitos funcionais são insuficientes para descrever o sistema de software, 
pois é necessário descrever outros aspectos: atributos do sistema e atributos do 
ambiente do sistema, normalmente classificados como requisitos não funcionais. Os 
requisitos não funcionais (RNF) descrevem restrições sobre os serviços oferecidos 
pelo sistema de software (SOMMERVILLE, 2010). 
 
 
 
 
 
 
 
 
 
 
 
 
Tabela1 – Requisitos não funcionais 
4.1 Requisitos de usabilidade 
Os requisitos de usabilidade, tem como o objetivo trazer o fácil acesso dos 
usuários ao sistema. Há três aspectos importantes direcionados aos requisitos de 
usabilidade que são a integridade, facilidade e operacionalidade. 
 Inteligibilidade: medida da facilidade do usuário para reconhecer a lógica 
de funcionamento do software. 
 Facilidade no aprendizado: medida da facilidade encontrada pelo 
usuário para aprender a utilizar o software. 
Requisitos não funcionais do sistema 
RNF001 
 
O sistema irá permitir 3 tentativas de login seguidas. 
RNF002 
 
Haverá o usuário e a senha para cada funcionário. 
RNF003 
 
O cadastro do cliente ficará salva para realização de vendas 
futuramente. 
RNF004 
 
Cada cliente cadastrado terá o código que será gerado ao final 
do cadastro. 
RNF005 
 
O sistema permitirá o cancelamento da venda apenas com o 
login do supervisor. 
RNF006 
 
O código gerado da venda cancelada será encaminhado 
diretamente ao sistema financeiro 
RNF007 O cadastro de novos produtos é feito somente através do login 
do estoquista. 
 
 
18 
 
 Operacionalidade: medida da facilidade para operar o produto com 
segurança e sem falhas. 
Requisitos de usabilidade 
RU001 Facilidade ao acesso no sistema. 
RU002 Sistema simples e prático. 
RU003 Sistema com resposta ágil. 
RU004 Objeção no cadastro dos clientes e produtos. 
RU005 Limitação as tentativas de login. 
RU006 Códigos de clientes e de produtos gerado 
automaticamente. 
RU007 Facilidade nas realizações das vendas. 
Tabela 2- Requisitos de usabilidade 
5. Usuários do sistema 
A empresa consiste num grupo dividido em 3 cargos de funcionário que são o 
estoquista, atendente e o supervisor da loja. Para cada funcionário haverá o login para 
entrar no sistema e após terá o painel com as funcionalidades para cada cargo. 
 
5.1 , Atendente 
O atendente é o que atende o cliente no caso um vendedor também. No painel 
do cliente, haverá diversas opções como o cadastro de novos clientes, consulta de 
preços e realizações de vendas. E ao cadastro de um novo cliente, o atendente 
informa os dados do cliente como o nome , CPF, RG, endereço, e-mail, e telefone e 
depois do novo cadastro gera automaticamente o código do novo cliente da loja 
 
5.2 Estoquista 
O estoquista é o funcionário responsável pelo a organização do estoque da 
loja. Portanto, o estoquista tem como opção ao sistema o cadastro de novo produto 
que se baseia em adicionar dados de novos produtos como o código de barras, nome, 
quantidade, fabricante, valor. E para os jogos e acessórios o prazo de garantia e 
plataforma utilizada. 
 
 
19 
 
5.3 Supervisor 
O supervisor é como um gerente na loja, ele fiscaliza as operações da loja. 
Somente o supervisor poderá cancelar ou excluir um produto da venda, por medidas 
de segurança. Então após o cancelamento também será gerado um código único de 
venda que deve ser enviado ao sistema financeiro. 
6. Contexto de uso do sistema 
O questionamento é o principal meio de análise da contextualização do uso do 
sistema. É o meio que designa informações contidas ao contexto em que o sistema 
pode ser colocado e que acaba sendo muito útil para o desenvolvimento do sistema. 
Através da resposta de três questões é possível chegar ao conhecimento do cenário 
proposto. Onde são as questões: Quem (usuários)?, O que (tarefas)? e onde 
(ambiente)? 
6.1 Quem? 
O funcionário da loja irá utilizar o sistema para diversas funcionalidades como 
o controle do estoque, o cadastro de clientes e as realizações de venda. O sistema irá 
trazer um melhor gerenciamento na loja, porque será um meio de administrar tudo. 
6.2 O que? 
As principais funcionalidades são o cadastro de cliente no sistema, o 
cadastramento de novos produtos, a realizações de venda e também outras 
complementações como cancelar venda, excluir produto da venda e a consulta de 
preço. 
6.3 Onde? 
Por meio dos computadores da loja, onde o funcionário faz login com seu 
usuário e senha. Após entrar no sistema, haverá as funcionalidades disponíveis para 
o funcionário utilizar. 
Exemplo: Estoquista entra no sistema, no entanto aparecerá a função de 
adicionar novo produto. 
 
 
 
 
20 
 
7. Regras de Negócios 
As regras de negócio são um aspecto muito importante quando estamos 
falando em modelagem de processos de negócio. Elas são um conjunto de restrições 
que definem como um processo de negócio de uma organização deve ser executado, 
que, além de representar determinados conhecimentos a respeito de um processo, 
também representam importantes aspectos restritivos na execução deste processo 
(BUSINESS RULES GROUP, 2000). 
Regras de Negócios 
RN001 Possuir módulos de acessibilidade. 
RN002 Acesso ao sistema através do login. 
RN003 Cadastrar o cliente no sistema. 
RN004 Cadastro de produto no sistema. 
RN005 Possuir dados do cliente na venda. 
RN006 Gerar código único na venda. 
RN007 Cliente pode excluir produto da venda se caso o cliente não queira 
adquiri-lo. 
RN008 Atendente consulta os preços dos produtos. 
RN009 
 
Apenas o supervisor pode excluir produto da venda, com usuário e senha 
validos. 
RN010 Apenas o supervisor cancela a venda, com usuário e senha válidos. 
Tabela 3 – Regras de Negócios 
8. Classes de análise 
Como observa Bezerra (2006), a responsabilidade de um objeto é a “obrigação” 
que ele deve cumprir no sistema de software do qual faz parte. Todavia, em alguns 
casos, o objeto não consegue cumprir com a sua “obrigação” de forma autônoma, 
precisando da colaboração de outros objetos. 
Os objetos são divididos e categorizados em três grupos de acordo com seu 
tipo de responsabilidade: classe entidade, classe de controle e classe de fronteira. 
A forma de organizar essas classes, também chamadas de classes de análise, 
vai ao encontro de um dos princípios fundamentais da orientação a objetos: divisão 
de responsabilidades. 
 
 
21 
 
A divisão de responsabilidades é uma das características fundamentais em 
uma boa modelagem de sistemas. Objetos com responsabilidades bem definidas 
aumentam a sua capacidade de reúso. 
Organizar e dividir os objetos por responsabilidade é a base para o conceito de 
padrões de projeto, que vem a ser um conjunto de soluções e organização sistêmica 
com um objetivo específico. 
8.1 Diagrama de classes 
Segundo Booch, Jacobson e Rumbaugh (2006), diagrama de classes é um 
diagrama UML que tem como objetivo representar a estrutura estática das classes de 
um sistema de software. 
O modelo de classes é mais abrangente. Nele não representamos apenas as 
classes, mas também devemos nos atentar em descrever detalhadamente o que cada 
classe representa dentro do domínio do problema. 
Assim sendo, podemos considerar que um modelo de classes se utiliza do 
diagrama de classes como ferramenta para representar uma determinada visão ou 
um determinado tipo do modelo de classes. 
Segue abaixo o diagrama de classes do sistema: 
 
Imagem 8 – Diagrama de classe de análise 
 
 
22 
 
CONCLUSÃO 
O projeto aprimorou o conhecimento a elaboração de um sistema. 
Proporcionou – se um bom aprendizado as práticas de requisitos, onde foi feita a 
análise para saber o que o cliente queria e o que podia ser aprimorado e adquirido ao 
sistema. 
Os diagramas foram essenciais para o projeto, onde foi colocado as práticas, 
as soluções, o que deve ser feito e a maneira certa de se fazer. E o modelo de entidade 
também porque é onde entra a parte da elaboração do sistema e de como ele vai ser 
produzido. 
Por fim, entende – se que tudo foi desenvolvido é a complementação. E que 
leva a ser um benefício devido aos estudos, no final fica a visão que tudo fez sentido, 
em que foi tudo desenvolvido com a atenção e os ensinamentos dos materiais de 
curso. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
23 
 
REFERÊNCIAS BIBLIOGRAFICASVersolatto, Fábio Rossi. Análise de Sistemas Orientada a Objetos. / Fábio Rossi Versolatto. – 
São Paulo: Editora Sol, 2015. 172 p., il 
Pinto, Gisele Lopes Batista Administração de banco de dados / Gisele Lopes Batista Pinto; Luiz 
Fernando Lima dos Santos. São Paulo: Editora Sol, 2020