pim-vi-2099284-0569502-2094399-2086535-2095311 perfeito

Prévia do material em texto

StuDocu is not sponsored or endorsed by any college or university
PIM VI 2099284 0569502 2094399 2086535 2095311
projeto integrado multi pim (Universidade Paulista)
StuDocu is not sponsored or endorsed by any college or university
PIM VI 2099284 0569502 2094399 2086535 2095311
projeto integrado multi pim (Universidade Paulista)
Downloaded by Lais Cristina (laiscristina.lc37@gmail.com)
lOMoARcPSD|13480535
https://www.studocu.com/en-us?utm_campaign=shared-document&utm_source=studocu-document&utm_medium=social_sharing&utm_content=pim-vi-2099284-0569502-2094399-2086535-2095311
https://www.studocu.com/en-us/document/universidade-paulista/projeto-integrado-multi-pim/pim-vi-2099284-0569502-2094399-2086535-2095311/15967877?utm_campaign=shared-document&utm_source=studocu-document&utm_medium=social_sharing&utm_content=pim-vi-2099284-0569502-2094399-2086535-2095311
https://www.studocu.com/en-us/course/universidade-paulista/projeto-integrado-multi-pim/4524541?utm_campaign=shared-document&utm_source=studocu-document&utm_medium=social_sharing&utm_content=pim-vi-2099284-0569502-2094399-2086535-2095311
https://www.studocu.com/en-us?utm_campaign=shared-document&utm_source=studocu-document&utm_medium=social_sharing&utm_content=pim-vi-2099284-0569502-2094399-2086535-2095311
https://www.studocu.com/en-us/document/universidade-paulista/projeto-integrado-multi-pim/pim-vi-2099284-0569502-2094399-2086535-2095311/15967877?utm_campaign=shared-document&utm_source=studocu-document&utm_medium=social_sharing&utm_content=pim-vi-2099284-0569502-2094399-2086535-2095311
https://www.studocu.com/en-us/course/universidade-paulista/projeto-integrado-multi-pim/4524541?utm_campaign=shared-document&utm_source=studocu-document&utm_medium=social_sharing&utm_content=pim-vi-2099284-0569502-2094399-2086535-2095311
UNIVERSIDADE PAULISTA – UNIP EAD
CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE
SISTEMAS
ANDERSON LUIS DA SILVA PIRES – RA 2099284
MATEUS ANTÔNIO MOREIRA MARTINS – RA 2095311
MATHEUS DE SOUZA MENEZES – RA 0569502
MURILO BOTTENE TUNDISI – RA 2094399
THAYS REGALLO DE OLIVEIRA – RA 2086535
PROJETO INTREGRADO MULTIDISCIPLINAR VI
LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM
SISTEMA DE CONTROLE DE VENDAS
SÃO PAULO
2021
Downloaded by Lais Cristina (laiscristina.lc37@gmail.com)
lOMoARcPSD|13480535
https://www.studocu.com/en-us?utm_campaign=shared-document&utm_source=studocu-document&utm_medium=social_sharing&utm_content=pim-vi-2099284-0569502-2094399-2086535-2095311
ANDERSON LUIS DA SILVA PIRES – RA 2099284
MATEUS ANTÔNIO MOREIRA MARTINS – RA 2095311
MATHEUS DE SOUZA MENEZES – RA 0569502
MURILO BOTTENE TUNDISI – RA 2094399
THAYS REGALLO DE OLIVEIRA – RA 2086535
PROJETO INTREGRADO MULTIDISCIPLINAR VI
LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM
SISTEMA DE CONTROLE DE VENDAS
Projeto Integrado Multidisciplinar VI para a
obtenção do título de graduação em
Análise e Desenvolvimento de Sistemas,
apresentado à Universidade Paulista –
UNIP EaD.
Orientador: Profa. Sandra Bozolan
SÃO PAULO
2021
Downloaded by Lais Cristina (laiscristina.lc37@gmail.com)
lOMoARcPSD|13480535
ANDERSON LUIS DA SILVA PIRES – RA 2099284
MATEUS ANTÔNIO MOREIRA MARTINS – RA 2095311
MATHEUS DE SOUZA MENEZES – RA 0569502
MURILO BOTTENE TUNDISI – RA 2094399
THAYS REGALLO DE OLIVEIRA – RA 2086535
PROJETO INTREGRADO MULTIDISCIPLINAR VI
LEVANTAMENTO E ANÁLISE DE REQUISITOS DE UM
SISTEMA DE CONTROLE DE VENDAS
Projeto Integrado Multidisciplinar VI para a
obtenção do título de graduação em
Análise e Desenvolvimento de Sistemas,
apresentado à Universidade Paulista –
UNIP EaD.
Aprovado em:
BANCA EXAMINADORA
________________________________ ___/___/___ 
Prof. ....
Universidade Paulista - UNIP
________________________________ ___/___/___ 
Prof. ....
Universidade Paulista - UNIP
________________________________ ___/___/___ 
Prof. ....
Universidade Paulista – UNIP
SÃO PAULO
2021
Downloaded by Lais Cristina (laiscristina.lc37@gmail.com)
lOMoARcPSD|13480535
https://www.studocu.com/en-us?utm_campaign=shared-document&utm_source=studocu-document&utm_medium=social_sharing&utm_content=pim-vi-2099284-0569502-2094399-2086535-2095311
RESUMO
Este presente trabalho tem como objetivo apresentar o levantamento e a análise de
requisitos de um sistema de controle de vendas de uma loja de jogos, acessórios e
produtos geek utilizando todo conhecimento adquirido nas matérias cursadas neste
bimestre (Análise de sistemas orientada a objetos; Banco de dados; Gestão
estratégica de recursos humanos). Considerando um sistema com funcionalidades
de cadastramento, alterações, consultas e exclusões, dos produtos vendidos na loja,
o sistema também terá cadastro de clientes e controle de acesso dos funcionários
validados por login e senha. Serão abordados os processos de negócio, assim como
as operações que serão automatizadas. O trabalho mostrará os modelos de casos
de uso destas operações e contará com a descrição de seus comportamentos e
fluxos principais. O projeto conta com o levantamento dos requisitos funcionais/não
funcionais e das regras de negócio. Além de utilizar conhecimentos obtidos em
matérias passadas como Metodologia Científica, base da formatação do trabalho
(padrão ABNT).
Palavras-chave: Jogos, sistema, geek, requisitos, negócio, vendas.
Downloaded by Lais Cristina (laiscristina.lc37@gmail.com)
lOMoARcPSD|13480535
ABSTRACT
This work aims to present the survey and requirements analysis of a sales control
system of a game store, accessories and geek products using all knowledge
acquired in the subjects studied in this two-month period (Object-oriented systems
analysis; Database; Strategic human resources management). Considering a system
with registration, alterations, consultations and exclusions, of the products sold in the
store. The system will also have customer records and employee access control
validated by login and password. Business processes will be covered, as well as
operations that will have automation. The work will show the use case models of
these operations and will describe their main behaviors and flows. The project
includes a survey of functional and non-functional requirements, and the business
rule. In addition to using knowledge obtained in past subjects such as Scientific
Methodology, the basis for the format of the work (ABNT standard).
Keywords: Game, system, geek, requirements, business, sales.
Downloaded by Lais Cristina (laiscristina.lc37@gmail.com)
lOMoARcPSD|13480535
https://www.studocu.com/en-us?utm_campaign=shared-document&utm_source=studocu-document&utm_medium=social_sharing&utm_content=pim-vi-2099284-0569502-2094399-2086535-2095311
LISTA DE FIGURAS
Imagem 1 - Modelo de roteiro de teste.......................................................................17
Imagem 2 - Tela de login.............................................................................................19
Imagem 3 - Home do usuário......................................................................................20
Imagem 4 - Home do administrador............................................................................21
Imagem 5 - Lista de usuários......................................................................................22
Imagem 6 - Login........................................................................................................27
Imagem 7 - Mensagem de erro ao logar.....................................................................27
Imagem 8 - Esqueceu a senha...................................................................................28
Imagem 9 - Logar como administrador.......................................................................28
Imagem 10 - Dificuldades de acesso..........................................................................29
Imagem 11 - Home do usuário....................................................................................29Imagem 12 - Hover......................................................................................................30
Imagem 13 - Reservando o equipamento...................................................................30
Imagem 14 - Reservado com sucesso........................................................................31
Imagem 15 - Reservas................................................................................................31
Imagem 16 - Home do administrador..........................................................................32
Imagem 17 - Hover do administrador..........................................................................32
Imagem 18 - Hover do administrador de equipamento reservado.............................33
Imagem 19 - Editar equipamento................................................................................33
Imagem 20 - Novo equipamento.................................................................................34
Imagem 21 - Equipamento adicionado com sucesso.................................................34
Imagem 22 - Listagem de usuários.............................................................................35
Imagem 23 - Novo usuário..........................................................................................35
Imagem 24 - Usuário excluído com sucesso..............................................................36
Imagem 25 - Usuário com reserva não pode ser excluído.........................................36
 
Downloaded by Lais Cristina (laiscristina.lc37@gmail.com)
lOMoARcPSD|13480535
LISTA DE TABELAS
Tabela 1 - Divisão de tarefas.......................................................................................10
Tabela 2 - Custo mensal com equipe..........................................................................10
Tabela 3 - Outras despesas.........................................................................................11
Tabela 4 - Requisitos funcionais.................................................................................12
Tabela 5 - Requisitos não funcionais..........................................................................13
Tabela 6 - Requisitos de negócio................................................................................13
Tabela 7 - Modelo de roteiro de teste..........................................................................15
Downloaded by Lais Cristina (laiscristina.lc37@gmail.com)
lOMoARcPSD|13480535
https://www.studocu.com/en-us?utm_campaign=shared-document&utm_source=studocu-document&utm_medium=social_sharing&utm_content=pim-vi-2099284-0569502-2094399-2086535-2095311
SUMÁRIO
1. INTRODUÇÃO........................................................................................................8
2. ECONOMIA E MERCADO.....................................................................................9
2.1 Custo-benefício.......................................................................................................9
3. ENGENHARIA DE SOFTWARE...........................................................................12
3.1 Engenharia de Requisitos....................................................................................12
3.2 Testes de Softwares.............................................................................................14
3.2.1 Roteiro de teste..............................................................................................14
3.2.2 Modelo de roteiro de testes...........................................................................15
3.3 Normas de qualidade............................................................................................16
4. INTERFACE COM O USUÁRIO...........................................................................19
5. PROGRAMAÇÃO ORIENTADA A OBJETOS......................................................23
6. CONSIDERAÇÃO FINAIS....................................................................................24
REFERÊNCIAS...........................................................................................................25
APÊNDICE I – TELAS DE INTERFACE COM USUÁRIO..........................................27
Downloaded by Lais Cristina (laiscristina.lc37@gmail.com)
lOMoARcPSD|13480535
8
1. INTRODUÇÃO
O controle de vendas é essencial para qualquer tipo de negócio: seja físico ou
virtual; prestação de serviços ou vendas de produtos; administrar o que entra e sai é
vital para a sobrevivência do negócio.
Controlar as vendas utilizando planilhas em Excel, não apresenta garantia de
centralização dos dados e consistência nas informações. É impossível configurar
níveis de acesso por hierarquia de cargos. Um bom sistema disponibiliza
informações integradas, relatórios em tempo real e assegura a integridade dos
dados.
Tendo isso em mente, o objetivo deste projeto é desenvolver um sistema
Desktop de controle e gerenciamento de vendas de produtos e acessórios na área
de jogos e cultura geek. Acompanhando o mercado, nota-se que sistemas, como o
Programa NEX, proporcionam um sistema completo de gestão. Com ele, se tem
total controle do estoque, além de cadastro de produtos, cadastro de fornecedores,
conferência de estoque, valor total em estoque, histórico de movimentação de
estoque, custo dos produtos, notificação de estoque mínimo e fim de estoque,
controle de data de validade e entrada de estoque via XML. Portanto, para o
desenvolvimento deste software, será implementado junto ao que já foi definido pelo
cliente, o histórico de movimentação de estoque, notificação de estoque mínimo e
fim de estoque, tomando como referência o programa em questão.
Como parte da elaboração deste trabalho, o projeto será baseado nos
conhecimentos obtidos nas disciplinas de Análise de Sistemas Orientada a Objetos,
Banco de Dados e Gestão Estratégica de Recursos Humanos.
Downloaded by Lais Cristina (laiscristina.lc37@gmail.com)
lOMoARcPSD|13480535
https://www.studocu.com/en-us?utm_campaign=shared-document&utm_source=studocu-document&utm_medium=social_sharing&utm_content=pim-vi-2099284-0569502-2094399-2086535-2095311
9
2. LEVANTAMENTO E ANÁLISE DE REQUISITOS
O levantamento de requisitos identifica as necessidades que o cliente espera
que o sistema solucione. É a primeira etapa do ciclo de desenvolvimento de
software, onde as funcionalidades e escopo do projeto são definidos. Existem dois
tipos de requisitos que compõem um sistema: os Requisitos Funcionais (RF) e os
Requisitos Não Funcionais (RNF).
Para o levantamento de requisitos há diversas técnicas para serem utilizadas
de acordo com o perfil do cliente. A escolha foi pela entrevista desde o primeiro
momento para coletar os requisitos e observar o cenário apresentado. Em seguida,
a fim de filtrar as informações, finalizamos com um questionário.
2.1 Requisitos Funcionais
Os Requisitos Funcionais são as necessidades que devem ser atendidas pelo
sistema, por meio de suas funcionalidades. O sistema proposto pelo cliente deve
possuir três níveis de acesso: atendente; estoquista; e supervisor. O atendente deve
ser capaz de realizar uma venda, cadastrar ou editar clientes, consultar produtos e
preços, e excluir produtos de uma venda, mas para isso, será necessário que o
supervisor autorize por meio de sua autenticação no sistema. O estoquista terá
permissão somente para cadastrar ou editar produtos e o mesmo deve respeitar o
grau de hierarquia dos produtos. Por fim, o supervisor terá acesso completo ao
sistema.
Tabela 1 - Requisitos funcionais
Identificador Requisito
RF01 Cadastrar clientes
RF02 Editar clientes
RF03 Excluir clientes
RF04 Consultar clientes
RF05 Cadastrar produtos
Downloaded by Lais Cristina (laiscristina.lc37@gmail.com)
lOMoARcPSD|13480535
10
RF06 Editar produtos
RF07 Excluir produtos
RF08 Consultar produtos
RF09Inserir venda
RF10 Cancelar venda
RF11 Consultar venda
RF12 Cadastrar funcionário
RF13 Excluir funcionário
Fonte: Próprio autor.
2.2 Requisitos Não Funcionais
“Requisitos Não Funcionais são premissas ou restrições que o sistema deverá
atender, mas que não são realizados através de funcionalidades.” (VENTURA,
2016), ou seja, apenas os requisitos funcionais não bastam para o desenvolvimento
do software, é necessário ser levado em conta outros aspectos que não estão
ligados diretamente as funcionalidades do sistema, mas que são essenciais para
determinar como será executada as ações do sistema e aspectos de qualidade do
projeto.
A figura abaixo é uma adaptação de Sommerville (2007) onde apresenta os
subconjuntos de quesitos a serem atendidos no software.
Downloaded by Lais Cristina (laiscristina.lc37@gmail.com)
lOMoARcPSD|13480535
https://www.studocu.com/en-us?utm_campaign=shared-document&utm_source=studocu-document&utm_medium=social_sharing&utm_content=pim-vi-2099284-0569502-2094399-2086535-2095311
11
Figura 1 - Requisitos não funcionais
F
onte: Sommerville, 2007.
Contudo neste projeto será abordado as seguintes categorias:
 Desempenho: Categoria voltada a garantir que o software seja executado 
sem problemas que possam impactar na qualidade do uso do sistema, como 
por exemplo lentidão.
 Disponibilidade: Nesse requisito é medido o tempo em que o sistema está
disponível para a utilização, por exemplo, as necessidades de paradas para
manutenção.
 Segurança: É a categoria onde são definidas as regras de proteção para 
criação e armazenamento de dados como, por exemplo implementação de 
senhas e a necessidade de criptografar os dados gerados.
 Interoperabilidade: Nesse requisito são especificadas as necessidades de 
implementação do sistema se comunicar com outras aplicações, isto é a 
habilidade do sistema tanto importar quanto exportar informações de maneira 
eficiente
 Usabilidade: Especifica o nível de desempenho e satisfação do usuário ao
usar o sistema como por exemplo: facilidade de aprender e facilidade de uso.
 Compatibilidade: Nessa categoria, são levantados os requisitos referentes a
compatibilidade para execução do software em versões diferentes de
navegadores e sistemas operacionais.
 Confiabilidade: Nessa categoria são definidos como devem funcionar as
rotinas de backup, formas de controle para garantir a integridade de dados
caso ocorra uma indisponibilidade do sistema.
Downloaded by Lais Cristina (laiscristina.lc37@gmail.com)
lOMoARcPSD|13480535
12
 Padrões: Por fim os requisitos de padrões definem qual será a metodologia
adotada para o desenvolvimento do projeto como por exemplo linguagem de
programação e hardware.
Tabela 2 - Requisitos não funcionais
Identificador Requisito
RNF01 Sistema multiplataforma
RNF02 Design responsivo
RNF03 Informações em tempo real
RNF04 Adoção de boas práticas de 
usabilidade
RNF05 Vídeo tutorial e documentação 
disponível para acesso no 
sistema
RNF06 Apenas usuários cadastrados 
conseguem logar no sistema
RNF07 Tempo de resposta e 
recuperação mais curtos 
possíveis
RNF08 Programação orientada a objeto
RNF09 Rotina de backup diário ou 
semanal
 Fonte: Próprio autor.
2.3 Casos de Uso
Uma forma de especificar requisitos é através do diagrama de Caso de Uso.
Nele, nós temos um cenário, onde um ou mais atores executam uma sequência de
eventos. Estes eventos são tarefas realizadas pelos atores. Ventura (2016) define
“...representar 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”.
Downloaded by Lais Cristina (laiscristina.lc37@gmail.com)
lOMoARcPSD|13480535
https://www.studocu.com/en-us?utm_campaign=shared-document&utm_source=studocu-document&utm_medium=social_sharing&utm_content=pim-vi-2099284-0569502-2094399-2086535-2095311
13
2.3.1 Modelagem de Casos de Uso
Abaixo é possível verificar como será o fluxo de funcionamento dos casos de
uso aplicados neste trabalho e como o sistema funcionará.
Figura 2 – Diagrama de cadastro de produtos
Fonte: Próprio autor.
Tabela 3 – Cadastro de Produtos
UC001 - Cadastro de Produtos
Objetivo:
Realizar o cadastro de novos produtos ou editar
produtos existentes
Requisitos:
Cadastrar produtos, Editar produtos, Excluir 
produtos, Consultar produtos
Atores: Estoquista, Supervisor
Prioridade: Alta
Pré-Condições:
Os usuários devem estar cadastrados no 
sistema, tendo usuário e senha
Frequência de uso: Média
Pós-Condições:
Os produtos terão cadastro no sistema e 
contagem de estoque
Downloaded by Lais Cristina (laiscristina.lc37@gmail.com)
lOMoARcPSD|13480535
14
Campos:
Categoria (jogos, acessórios e produtos geek), 
código de barras, nome do produto, fabricante,
quantidade e valor do produto. Para os jogos e 
os acessórios: em qual plataforma serão 
utilizados e qual o prazo de garantia que o 
produto possui;
Fluxo principal:
1) Estoquista ou Supervisor clica em "Cadastrar
produto";
2) Sistema valida o login através de usuário e 
senha;
3) O sistema exibe os campos obrigatórios para
cadastrar o produto;
4) Atendente ou Supervisor preenche todos os 
dados e clica em "Salvar produto";
5) Sistema efetiva o cadastro atribuindo um 
código ao produto cadastrado.
Fluxo alternativo:
1) Estoquista ou Supervisor clicará em "Editar 
produto";
2) Sistema mostrará os campos para pesquisa;
3) Estoquista ou Supervisor preenche o campo 
que deseja pesquisar;
4) Sistema mostra o cadastro existente do 
produto;
5) Estoquista ou Supervisor pode fazer 
alterações nas informações do produto e clicar 
em "Salvar produto" ou clicar em "Excluir 
produto";
6) Sistema efetiva a alteração ou exclusão.
Fluxo de exceção:
No fluxo principal 2:
2.1) Caso não tenha validação, aparecerá 
mensagem de erro;
2.2) Caso o usuário ou senha estejam 
incorretos, aparecerá mensagem de erro;
No fluxo principal 4:
4.1) Mensagem de erro caso falte informação 
obrigatória;
No fluxo alternativo 4:
A4.1) Caso não tenha cadastro, o sistema 
mostrará uma mensagem de erro;
Validações:
Todos os campos serão obrigatórios, com 
exceção da garantia e plataforma para os 
produtos geek
Fonte: Próprio autor.
Downloaded by Lais Cristina (laiscristina.lc37@gmail.com)
lOMoARcPSD|13480535
https://www.studocu.com/en-us?utm_campaign=shared-document&utm_source=studocu-document&utm_medium=social_sharing&utm_content=pim-vi-2099284-0569502-2094399-2086535-2095311
15
Figura 3 – Diagrama cadastro de cliente e vendas
Fonte: Próprio autor.
Tabela 4 – Cadastro de Clientes
UC002 - Cadastro de Clientes
Objetivo:
Realizar o cadastro de novos clientes ou 
editar clientes existentes
Downloaded by Lais Cristina (laiscristina.lc37@gmail.com)
lOMoARcPSD|13480535
16
Requisitos:
Cadastrar clientes, Editar clientes, Excluir 
clientes, Consultar clientes
Atores: Atendente, Supervisor
Prioridade: Alta
Pré-Condições:
Os usuários devem estar cadastrados no 
sistema, tendo usuário e senha
Frequência de uso: Alta
Pós-Condições:
Os clientes terão cadastro no sistema e 
poderão realizar as compras na loja
Campos:
Código, RG, CPF, nome, data do cadastro,
endereço, telefone e e-mail do cliente
Fluxo principal:
1) Atendente ou Supervisor clica em 
"Cadastrar cliente";
2) Sistema valida o login através de usuário e
senha;
3) O sistema exibe os campos obrigatórios 
para cadastrar o cliente;
4) Atendente ou Supervisor preenche todos 
os dados e clica em "Salvar cliente";
5) Sistema efetiva o cadastro atribuindo um 
código ao cliente cadastrado.
Fluxo alternativo:
1) Atendente ou Supervisor clicará em "Editar
cliente";
2) Sistema mostrará os campos para 
pesquisa;
3) Atendente ou Supervisor preenche o 
campo que deseja pesquisar;
4) Sistema mostra o cadastro existente do 
cliente;
5) Atendente ou Supervisor pode fazer 
alterações nas informações do cliente e clicar
em "Salvar cliente"ou o Supervisor pode 
clicar em "Excluir cliente";
6) Sistema efetiva a alteração ou exclusão.
Fluxo de exceção:
No fluxo principal 2:
2.1) Caso não tenha validação, aparecerá 
mensagem de erro;
2.2) Caso o usuário ou senha estejam 
incorretos, aparecerá mensagem de erro;
No fluxo principal 4:
4.1) Mensagem de erro caso falte informação 
obrigatória;
No fluxo alternativo 4:
A4.1) Caso não tenha cadastro, o sistema 
mostrará uma mensagem de erro;
Validações:
Apenas os campos telefone e e-mail do 
cliente não serão obrigatórios
Fonte: Próprio autor.
Downloaded by Lais Cristina (laiscristina.lc37@gmail.com)
lOMoARcPSD|13480535
https://www.studocu.com/en-us?utm_campaign=shared-document&utm_source=studocu-document&utm_medium=social_sharing&utm_content=pim-vi-2099284-0569502-2094399-2086535-2095311
17
Tabela 5 – Efetuar Vendas
UC003 - Efetuar vendas
Objetivo: Realizar vendas
Requisitos:
Cadastrar produtos, Editar produtos, Excluir 
produtos, Consultar produtos
Atores: Atendente, Supervisor
Prioridade: Alta
Pré-Condições:
Os usuários devem estar cadastrados no 
sistema, tendo usuário e senha; Os produtos e 
os clientes devem ter cadastro no sistema
Frequência de uso: Alta
Pós-Condições:
O sistema deve atualizar a quantidade do 
produto no estoque e atualizar o sistema 
financeiro
Campos:
Dados do cliente, todos os produtos, código 
único da venda, data da venda, valor da venda,
opções para pagamento (dinheiro e/ou cartão), 
status de pagamento e status da venda
Fluxo principal:
1) Atendente ou Supervisor clica em "Realizar 
venda";
2) Sistema valida o login através de usuário e 
senha;
3) Atendente ou Supervisor preenche um dos 
dados do cliente (código, RG ou CPF) e clica 
em "Vender";
5) Sistema traz o código do cliente e exibe a 
tela de vendas;
4) Atendente ou Supervisor faz a leitura do 
código de barras dos produtos que serão 
vendidos e seleciona o método de pagamento;
5) Cliente realiza o pagamento;
6) Sistema efetiva a venda, processa o 
recibo/comprovante e atualiza o estoque e o 
sistema financeiro.
Downloaded by Lais Cristina (laiscristina.lc37@gmail.com)
lOMoARcPSD|13480535
18
Fluxo alternativo:
1) Cliente solicita o preço do produto;
2) Atendente ou Supervisor clica em "Consultar 
produto";
3) Sistema traz a tela para scannear o código 
de barras;
4) Atendente ou Supervisor faz a leitura do 
código de barras;
5) Sistema traz todas as informações do 
produto;
6) Atendente ou Supervisor clica em "Voltar" ou 
scanneia outro produto.
Fluxo de exceção:
No fluxo principal 4:
4.1) Cliente desiste de comprar um dos 
produtos;
4.2) Atendente deve excluir o produto da venda 
e acionar o Supervisor;
4.3) Supervisor insere usuário e senha;
4.4) Sistema efetiva e exclusão do(s) 
produto(s).
Validações: Todos os campos serão obrigatórios
Fonte: Próprio autor.
2.4 Regras de Negócio
Os Requisitos de Negócios (ou Regras de Negócios) são premissas e/ou
restrições aplicadas a uma operação comercial de uma empresa, que devem ser
atendidas para que o negócio funcione de maneira esperada. Um software tendo
como objetivo automatizar atividades de uma empresa, através de funcionalidades
que atenderão requisitos funcionais. Já uma regra de negócio definirá a forma que o
sistema fará este atendimento de necessidades definidas.
“São regras que servem para definir ou restringir alguma ação nos processos
de sua empresa. São declarações que irão descrever como determinadas operações
devem ser realizadas e se há algum limite que precisa ser aplicado.” (OLIVEIRA,
2018).
Tabela 2 – Regras de Negócios
Identificador Requisito
RN01 Não é possível aplicar descontos 
Downloaded by Lais Cristina (laiscristina.lc37@gmail.com)
lOMoARcPSD|13480535
https://www.studocu.com/en-us?utm_campaign=shared-document&utm_source=studocu-document&utm_medium=social_sharing&utm_content=pim-vi-2099284-0569502-2094399-2086535-2095311
19
sem cadastro prévio
RN02 A venda só será efetivada se o 
pagamento for realizado
RN03 Um produto só poderá ser 
vendido se estiver disponível no 
estoque ou se o fornecedor 
trabalhar com pré-vendas
RN04 Não serão aceitas devoluções 
após a data de garantia
RN05 Funcionário ao ser demitido terá 
o login excluído
 Fonte: Próprio autor.
Downloaded by Lais Cristina (laiscristina.lc37@gmail.com)
lOMoARcPSD|13480535
20
3. DIAGRAMA DE CLASSES DE ANÁLISE
3.1 Diagrama de Classes
O diagrama de classes é considerado por muitos autores o diagrama mais
utilizado da UML. Segundo Versolato (2015), em seu livro Análise Orientada a
Objetos, o diagrama de classes tem como objetivo modelar a visão estática do
sistema, mostrando um conjunto de classes, interfaces, colaborações e os seus
relacionamentos. 
O propósito é de facilitar a divisão das classes do sistema, bem como de
demonstrar como as classes do sistema se interagem entre si. Esse diagrama pode
ser visto de três perspectivas:
 Conceitual: O modelo conceitual é um modelo dedicado ao cliente, nele é
abordado os conceitos do domínio em estudo.
 Especificação: Nele são observados as interfaces de arquitetura e os
métodos que serão implementados. Destina-se a quem não precisa saber dos
detalhes do desenvolvimento do software.
 Implementação: É a perspectiva mais usada, visto que aborda mais detalhes
de implementação. Destina-se a desenvolvedores.
3.1.1 Classe, Atributos e Métodos
A classe é representada por um retângulo com até três divisões. Na primeira
divisão, coloca-se o nome da classe. Enquanto a segunda armazena os atributos e
seus tipos de dados. Por fim, a última divisão fica para os métodos.
3.2 Diagrama de Objetos
De acordo com Booch (2000, p.193) é: “Um diagrama de objetos é um diagrama
que mostra um conjunto de objetos e seus relacionamentos em um ponto no tempo.
Graficamente, o diagrama de objetos é uma coleção de vértices e de arcos”. Pode-
se concluir que o Diagrama de Objetos é uma instância do Diagrama de Classes em
Downloaded by Lais Cristina (laiscristina.lc37@gmail.com)
lOMoARcPSD|13480535
https://www.studocu.com/en-us?utm_campaign=shared-document&utm_source=studocu-document&utm_medium=social_sharing&utm_content=pim-vi-2099284-0569502-2094399-2086535-2095311
21
um determinado tempo. Ele captura um conjunto de objetos e seus relacionamentos
no tempo, facilitando examinar uma interação específica de um sistema geral. Ele
obtém uma visão geral de alto nível do sistema que será desenvolvido. Abaixo, os
principais elementos de um diagrama de objetos:
 Objetos: São instâncias de uma classe.
 Títulos de classe: São os atributos específicos de uma classe. Pode-se lista-
los como itens ou propriedades dos objetos.
 Atributos de classe: Cada atributo permite definir um intervalo de valores que
as instâncias dessa propriedade podem apresentar.
 Links: Trata-se das ligações ou linhas que conectam duas formas, uma a
outra, de um diagrama de objetos.
Colocar o Diagrama!
Downloaded by Lais Cristina (laiscristina.lc37@gmail.com)
lOMoARcPSD|13480535
22
4. MODELO DE ENTIDADE E RELACIONAMENTO (MER)
Downloaded by Lais Cristina (laiscristina.lc37@gmail.com)
lOMoARcPSD|13480535
https://www.studocu.com/en-us?utm_campaign=shared-document&utm_source=studocu-document&utm_medium=social_sharing&utm_content=pim-vi-2099284-0569502-2094399-2086535-2095311
	1. INTRODUÇÃO
	2. LEVANTAMENTO E ANÁLISE DE REQUISITOS
	2.1 Requisitos Funcionais
	2.2 Requisitos Não Funcionais
	2.3 Casos de Uso
	2.3.1 Modelagem de Casos de Uso
	2.4 Regras de Negócio
	3. DIAGRAMA DE CLASSES DE ANÁLISE
	3.1 Diagrama de Classes
	3.1.1 Classe, Atributos e Métodos
	3.2 Diagrama de Objetos
	4. MODELO DE ENTIDADE E RELACIONAMENTO (MER)