Modelagem

de Software
Desenvolvedores: Carlos
Moura, Isaac Penaforte,
Vinícius Santana, Pedro
Henrique, Jezreel Anderson
Estrutura do Projeto
• Quem nós somos e nosso objetivo
• Levantamento de requisitos funcionais e não
funcionais
• Lista de caso de uso (fluxo principal e alternativo)
• Diagrama de caso de uso
• Diagrama de Classes
• Diagrama Entidade-Relacionamento
 m os
So
ue m
Q
 O nosso objetivo é ofertar um
software de gestão e atendimento ao
cliente para restaurantes. Através de

Objetivo um sistema inteligente, iremos

proporcionar um serviço de reserva
de mesas e pedidos para o usuário,
realizado através de um cadastro em
nosso software
Levantamento
Requisitos
Levantamento de Requisitos
Requisitos Funcionais

RF001: Cadastrar o cliente no sistema

RF002: Realizar reserva de mesa para o cliente, quando solicitado
RF003: Gerar cardápio digital para clientes cadastrados
RF004: Gerar previsão de vendas com base nas vendas realizadas no último
mês
RF005: Gerar relatório de feedback com base nas avaliações dos clientes
RF006: Processar pagamento
RF007: Registar os pedidos do cliente
RF008: Emitir relatórios de clientes ou vendas
RF009: Deve possibilitar ao cliente acessar o seu histórico de pedidos
RF010: Realizar pagamento de funcionários até o quinto dia útil do mês
Levantamento de Requisitos
Requisitos não Funcionais
RNF001: Software deve ter suporte para Android, Web, IOs, windows, Linux
RNF002: Aceitar pagamento via Pix, boleto, debito ou credito com 10% de desconto
no pix
RNF003: O computador para rodar o software deverá ter um processador de 8
núcleos
RNF004: Apresentar eficiência na interface responsiva
RNF005: O sistema deverá ter alta disponibilidade, p.exemplo, 99% do tempo
RNF006: O sistema deverá seguir o princípio da interoperabilidade, se adequando ao
meio
externo.
RNF007: A interface deve ser intuitiva e responsiva
RNF008: Um relatório de acompanhamento deverá ser fornecido toda (X) dia da
semana.
RNF009: O sistema deve ter segurança para manter em sigilo dados de transações
feitas online.
Lista de
caso de
uso
Ator: Cliente
Caso de Uso: Realizar Cadastro

Fluxo Principal:

O Sistema oferece a interface dos campos a serem preenchidos

O Ator inicia o preenchimento das informações
Realizar Cadastro

Fluxo Alternativo: 

• Sistema com Indisponibilidade

• Se algum dos dados informados forem inválidos
retorna a mensagem de erro: "Dados inválidos" 
• Se algum identificador único já estiver em uso
retorna a mensagem de erro: “Pessoa já cadastrada “.

Pré-condições: O cliente precisa ter preenchido e finalizado o cadastro para

prosseguir, além de estar logado no sistema

Pós-condições: o sistema liberará as mesas disponíveis para o cliente possa

escolher e reservar.
Ator: Cliente
Caso de uso: Reservar mesa

Fluxo Principal:

Selecionar o número da mesa desejada

Confirmar reserva

Fluxo alternativo:

• Se a mesa selecionada estiver indisponível, retornar a mensagem: “Mesa já

reservada ou indisponível, favor escolher outra mesa” 
• Dessincronização do sistema mediante a alta demanda de reservas
• Instabilidade na conexão com o servidor

Pré-condições: O cliente precisa ter selecionado uma mesa ou mais para prosseguir

Pós-condições: logo após o cliente ter selecionado a mesa o sistema deverá abrir um novo
guia com
o cardápio.
Ator: Sistema
Caso de uso: Registrar pedido

Fluxo principal: 

Registra e confirma o pedido realizado pelo cliente, armazenando

e registrando o método de pagamento, o valor total do pedido, a
quantidade de itens comprados e os dados do cliente no banco de dados

Fluxo alternativo:

• Indisponibilidade do banco de dados

• O cliente não selecionou o pedido
• Método de pagamento indisponível

Pré-condições: O sistema deverá confirmar e registrar os pedidos do cliente, armazenar o

método de
pagamento, valor total do pedido, quantidade de itens comprados e os dados do cliente

Pós-condições: Registrar pedido

Ator: Sistema
Caso de Uso: Registar Histórico de Vendas no Mês

Fluxo Principal: 

O Sistema deve filtrar o perfil do cliente e buscar todos os pedidos (como o total de itens,
valor, horário) realizados por ele e os armazena no banco de dados

Fluxo Alternativo:

• A data e hora do sistema pode estar dessincronizado do banco de dados, causando o

conflito de informações com o sistema
• O cliente cadastrar seus dados de forma incorreta
• O faturamento do setor financeiro pode atrasar
• Senha de login inserida incorretamente

Pré-condições: O sistema deverá registar o valor total da venda do mês

Pós-condições: Exibir histórico das vendas do mês

Ator: Sistema
Caso de uso: Processar pagamento

Fluxo Principal:

Receber o pagamento e o método de pagamento escolhido pelo cliente e em

seguida retornar para o cliente a mensagem: “Seu pedido foi realizado com sucesso”

Fluxo Alternativo:

• Erro de indisponibilidade do sistema ao processar pagamento

• Saldo insuficiente na conta do cliente
• Número do cartão inserido inválido ou inexistente
• Método de pagamento indisponível

Pré-condições: O sistema deverá processar a forma de pagamento e o em seguida receber

o pagamento

Pós-condições: exibir para o cliente “Seu pedido foi realizado com sucesso”
Ator: Gerente
Caso de uso: Gerir usuários do sistema

Fluxo Principal:

O gerente administra os usuários do sistema, podendo adicionar, remover e

bloquear contas, além de limitar o número de contas abertas por cliente e enviar para o
Email dos usuários cadastrados promoções, novos pratos e novos produtos

Fluxo Alternativo:

• O gerente pode esquecer o login e a senha de administrador do sistema

• O sistema pode ficar indisponível
• A configuração de servidor POP3 pode estar fora do ar

Pré-condições: O cliente deve ter realizado o seu cadastro com sucesso

Pós-condições: O Gerente deve conseguir editar, remover ou excluir informações do

usuário
Ator: Gerente
Caso de uso: Realizar pagamento de funcionários

Fluxo Principal: 

Até o quinto dia útil do mês o gerente realiza o pagamento dos funcionários com base na
máquina de ponto de horas trabalhadas, que deve ser preenchida por cada funcionário
onde o mesmo apropria as horas e o sistema armazena as informações no banco de dados
para o gerente ter o controle de cada colaborador

Fluxo Alternativo:

• Os funcionários podem apropriar horas excessivas na folha de apropriação

• O funcionário pode apropriar as horas depois do quinto dia útil do mês
• O gerente pode procastinar o pagamento e se deparar com uma queda de rede,
atrasando os pagamentos

Pré-condições: A folha de apropriação deve estar online 

Pós-condições: O pagamento dos funcionários deve ser realizado com sucesso

Ator: Gerente
Caso de uso: Gerir cardápio

Fluxo Principal:

O Gerente deverá realizar o login e ser capaz de alterar as opções do menu, alterando o
valor, as opções e promoções dos produtos, assim como a disponibilidade dos pratos

Fluxo Alternativo:

• O gerente pode adicionar um prato que não está disponível no dia

• O cardápio pode se encontrar indisponível para o cliente durante as alterações do
menu
• As promoções podem estar em desacordo com a diretoria

Pré-Condições: O gerente deve ter acesso a aba de alterações após a validação do login.

Pós-Condições: As alterações, caso sejam feitas, devem ser aplicadas com sucesso
Ator: Gerente
Caso de uso: Dar baixa no estoque

Fluxo Principal: 

Ao final do mês, o gerente deve realizar o login no sistema, conferir os pedidos e dar
baixa nos produtos do estoque

Fluxo Alternativo:

• O gerente pode esquecer a senha cadastrada

• O gerente pode ser incoerente na sua análise de pedidos, cometer erros na contagem
de pedidos e apresentar um resultado incorreto
• O banco de dados pode estar indisponível

Pré-condições: O gerente deve ter realizo login com sucesso, e os pedidos devem estar
corretos

Pós-condições: A baixa deve ser realizada com sucesso

Diagrama
de caso de
uso
Diagrama
de classes
Diagrama entidade-
relacionamento
FIM!!