Buteco Do Fundão 2.

0
Especificação de Objetivos e Requisitos

BUTECO2.0

Autores: Gabriel Silva, Lucas Ricardo, Luís Garcês, Joao Vitor Bonifácio

Goiânia 11/2023
EOR Versão: 2.0
Buteco do Fundão 2.0 Data/Hora: 11/2023

Revisões
A primeira versão deste documento é criada após a sua aprovação e é vinculada a uma
baseline do software. Esta versão, portanto, não pode ser modificada. As modificações
que se fizerem necessárias após a criação da baseline farão parte de uma versão seguinte
que será vinculada a uma outra baseline. Este procedimento pode se repetir
sucessivamente. As modificações introduzidas em cada versão devem ser registradas
seguindo o modelo do quadro abaixo. Desta forma, será possível perceber as diferenças
entre as diversas versões geradas.
Data Descrição Autor
Incluir a data da Descrever resumidamente o Informar o nome do responsável pela
modificação motivo da revisão modificação

Conteúdo
Incluir índice de conteúdo do documento que estiver sendo elaborado, conforme
exemplo abaixo usado para esta proposta de metadocumento:

1. Introdução................................................................................................................3
1.1. Objetivos..............................................................................................................3
1.2. Público Alvo........................................................................................................3
1.3. Organização do documento..................................................................................3
2. Casos de Uso............................................................................................................3
2.1. Atores...................................................................................................................3
2.2. Lista de casos de uso............................................................................................4
2.3. Descrição de Casos de Uso..................................................................................4
3. Requisitos e restrições funcionais (RFUN)..............................................................4
4. Requisitos e restrições não funcionais.....................................................................4
4.1. Requisitos e restrições de informação (RINF).....................................................5
4.1 Requisitos e restrições de interface Homem-Computador (RHIC).....................5
4.2 Requisitos de Interface Externa (RIEX)..............................................................6
4.3 Requisitos e Restrições de Projeto (RPRO).........................................................6
4.4 Requisitos e restrições de arquitetura de software (RARQ)................................7
4.5 Requisitos e restrições de plataforma de hardware (RPHW)...............................7
4.6 Requisitos e restrições de plataforma de software (RPSW)................................7
4.7 Requisitos e restrições de desempenho (RDES)..................................................8
4.8 Requisitos e restrições de disponibilidade (RDIS)..............................................8
4.9 Requisitos e restrições de segurança (RSEG)......................................................8

EOR: Estrutura do Documento 2

EOR Versão: 2.0
Buteco do Fundão 2.0 Data/Hora: 11/2023

4.10 Requisitos e restrições de manutenibilidade (RMAN)........................................9

4.11 Requisitos e restrições de portabilidade (RPOR).................................................9
4.12 Requisitos de documentação (RDOC)...............................................................10
5. Requisitos Futuros (RFUT)....................................................................................10
6. Referências cruzadas complementares..................................................................10

Figuras e Tabelas

1. Introdução
Apresentar o documento ao leitor, descrevendo sucintamente o software que é objeto
deste projeto e as informações contidas neste documento.

1.1.Objetivos
Objetivo O sistema será feito com o objetivo de identificar informações, características
e os elementos importantes que irão integrar no processo de desenvolvimento do
software pela equipe.

1.2.Público Alvo
O software é destinado a equipe de funcionários que atuarão dentro da Academia, e/ou
os usuários irão que utilizar o sistema para fazer a comunicação com o sistema da
academia para comunicação, avisos ou para obter informações com os funcionários.

1.3.Organização do documento
O documento trará de técnicas de levantamento dos requisitos, detalhes, e/ou será feito
com a participação do cliente. No qual a e licitação dos requisitos irão fazer parte do
sistema, onde será aplicado para o desenvolvimento do software.

EOR: Estrutura do Documento 3

EOR Versão: 2.0
Buteco do Fundão 2.0 Data/Hora: 11/2023

2. Casos de Uso

2.1. Atores
1-Cliente
2-Chefe de Cozinha
3-Atendente
4-Gerente

2.2. Lista de casos de uso

Listar todos os casos de uso do software. Para cada caso de uso identificar sua categoria
(primário, secundário ou opcional). Casos de uso primários são aqueles que representam
processos comuns principais; casos de uso secundários representam processos menos
importantes ou raros; casos de uso opcionais representam processos que talvez não
sejam considerados. Quando define a categoria de um caso de uso é mais fácil de
perceber quais casos de uso deverão ser expandidos primeiramente.
Exemplo:
Ref. Descrição Atores Categoria

CSU1 Cliente faz o pedido. Cliente Primário

CSU2 Cliente solicita o pagamento. Cliente Primário
CSU3 Garçom atende o cliente. Garçom Primário
CSU4 Garçom faz a entrega do pedido. Garçom Primário

EOR: Estrutura do Documento 4

EOR Versão: 2.0
Buteco do Fundão 2.0 Data/Hora: 11/2023

CSU5 Garçom fecha a conta do cliente. Garçom Primário

CSU6 Chefe de Cozinha prepara pedido. Chefe Primário
CSU7 Chefe de cozinha da baixa no pedido. Chefe Primário
CSU8 Gerente gerência troca de mesa. Gerente Primário
CSU9 Gerente gerencia o estoque. Gerente Primário
CSU10 Gerente gerencia o fluxo de cliente. Gerente Primário

2.3. Descrição de Casos de Uso

Descrição de Casos de Uso
CSU1- Cliente faz o pedido.
CSU2 - Cliente solicita o pagamento.
CSU3 - Garçom atende o cliente.
CSU4 - Garçom faz a entrega do pedido.
CSU5 - Garçom fecha a conta do cliente.
CSU6 - Chefe de Cozinha prepara pedido.
CSU7 - Chefe de cozinha da baixa no pedido.
CSU8 - Gerente gerência troca de mesa.
CSU9 - Gerente gerencia o estoque.
CSU10 - Gerente gerencia o fluxo de cliente.

3. Requisitos e restrições funcionais (RFUN)

Ref. Função Categoria Prioridade Referencia

RFUN1 Garantir que os pedidos dos Evidente Alta Cliente
clientes sejam registrados
corretamente.
RFUN2 Assegurar a satisfação do Evidente Alta Garçom
cliente ao receber um bom
atendimento.
RFNU3 Assegurar a satisfação do Evidente Alta Garçom
cliente ao receber seu pedido
no tempo prometido.
RFNU4 Facilitar transações Oculta Média Gerente
financeiras flexíveis para os
clientes.

EOR: Estrutura do Documento 5

EOR Versão: 2.0
Buteco do Fundão 2.0 Data/Hora: 11/2023

RFNU5 Fornecer um fechamento Oculta Média Garçom

eficiente da conta para os
clientes.
RFNU6 Garantir a qualidade e a Oculta Alta Chefe de cozinha
satisfação do cliente ao
preparar os pedidos
corretamente.
RFNU7 Manter um registro preciso Oculta Média Chefe de cozinha
do processo dos pedidos.
RFNU8 Assegurar a satisfação do Oculta Baixa Gerente
cliente ao acomodá-los de
forma eficiente
RFNU9 Evitar a falta de itens e Oculta Alta Gerente
amenizar o desperdício.
RFNU10 Assegurar a satisfação do Oculta Alta Gerente
cliente ao minimizar o tempo
de espera.

3.1. Regras de Negócio

1. *CSU1 - Cliente faz o pedido*: O cliente tem a liberdade de fazer um pedido a
qualquer momento durante o horário de funcionamento do bar. O pedido pode incluir
alimentos, bebidas ou ambos.

2. *CSU2 - Cliente solicita o pagamento*: O cliente pode solicitar o pagamento a

qualquer momento. O pagamento pode ser feito em dinheiro, cartão de crédito/débito ou
por meio de aplicativos de pagamento.

3. *CSU3 - Garçom atende o cliente*: O garçom é responsável por atender o cliente,

anotar o pedido e encaminhá-lo para a cozinha. O garçom também deve verificar
regularmente se o cliente precisa de algo.

4. *CSU4 - Garçom faz a entrega do pedido*: Após o preparo do pedido pelo chefe de
cozinha, o garçom é responsável por entregar o pedido ao cliente de maneira oportuna.

5. *CSU5 - Garçom fecha a conta do cliente*: Quando o cliente solicita o pagamento, o

garçom é responsável por fechar a conta do cliente, fornecer a nota fiscal e processar o
pagamento.

6. *CSU6 - Chefe de Cozinha prepara pedido*: O chefe de cozinha é responsável por

preparar o pedido do cliente de acordo com as especificações fornecidas.

EOR: Estrutura do Documento 6

EOR Versão: 2.0
Buteco do Fundão 2.0 Data/Hora: 11/2023

7. *CSU7 - Chefe de cozinha da baixa no pedido*: Após o preparo do pedido, o chefe

de cozinha deve marcar o pedido como concluído no sistema.

8. *CSU8 - Gerente gerência troca de mesa*: O gerente é responsável por gerenciar a

troca de mesas, garantindo que os clientes possam mudar de mesa se necessário e que a
mudança seja refletida corretamente na conta do cliente.

9. *CSU9 - Gerente gerencia o estoque*: O gerente é responsável por gerenciar o

estoque do bar, garantindo que todos os itens estejam disponíveis e repondo o estoque
conforme necessário.

10. *CSU10 - Gerente gerencia o fluxo de cliente*: O gerente é responsável por

gerenciar o fluxo de clientes, garantindo que o bar não fique superlotado e que todos os
clientes sejam atendidos de maneira oportuna.

4. Requisitos e restrições não funcionais

*Requisitos de Informação*
- RNF1: O sistema deve manter um registro preciso de todos os pedidos feitos pelos
clientes.
- RNF2: O sistema deve manter um registro preciso do estoque disponível.
*Requisitos de Interface*
- RNF3: O sistema deve ter uma interface de usuário intuitiva e fácil de usar para os
garçons e gerentes.
- RNF4: O sistema deve fornecer feedback claro e imediato após cada ação.

*Requisitos de Projeto*
- RNF5: O sistema deve ser modular para permitir a adição de novas funcionalidades no
futuro.
- RNF6: O sistema deve seguir as melhores práticas de design de software.

*Requisitos de Arquitetura de Software*

- RNF7: O sistema deve ser construído usando uma arquitetura de software robusta e
escalável.

*Requisitos de Plataforma de Hardware*

EOR: Estrutura do Documento 7

EOR Versão: 2.0
Buteco do Fundão 2.0 Data/Hora: 11/2023

- RNF8: O sistema deve ser compatível com o hardware disponível no bar, como tablets
ou computadores.

*Requisitos de Plataforma de Software*

- RNF9: O sistema deve ser compatível com os sistemas operacionais mais comuns,
como Windows, MacOS e Linux.

*Requisitos de Plataforma de Comunicação*

- RNF10: O sistema deve ser capaz de operar em uma rede local, garantindo a
comunicação eficiente entre diferentes dispositivos.

*Requisitos de Desempenho*
- RNF11: O sistema deve ser capaz de processar pedidos e atualizações de estoque em
tempo real.

*Requisitos de Disponibilidade*
- RNF12: O sistema deve estar disponível durante o horário de funcionamento do bar.

*Requisitos de Segurança*
- RNF13: O sistema deve seguir as melhores práticas de segurança para proteger os
dados dos clientes e as informações de pagamento.

*Requisitos de Manutenibilidade*
- RNF14: O sistema deve ser fácil de manter e atualizar.

*Requisitos de Portabilidade*
- RNF15: O sistema deve ser portátil e capaz de operar em diferentes ambientes de
hardware e software.

*Requisitos de Documentação*
- RNF16: Toda a documentação do sistema deve ser clara, concisa e fácil de entender.

4.1. Requisitos e restrições de informação (RINF)

Códig Requisitos de Informação Classificação
o

EOR: Estrutura do Documento 8

EOR Versão: 2.0
Buteco do Fundão 2.0 Data/Hora: 11/2023

CSU1 Informações do pedido do cliente Informações

(itens, quantidade, observações) Cadastrais
CSU2 Informações de pagamento do cliente Informações
(valor total, método de pagamento) Gerenciais
CSU3 Informações do atendimento ao Informações
cliente (hora do atendimento, garçom Gerenciais
responsável)
CSU4 Informações de entrega do pedido Informações
(hora da entrega, itens entregues) Gerenciais

CSU5 Informações de fechamento da conta Informações

do cliente (valor total, hora do Gerenciais
fechamento)
CSU6 Informações do preparo do pedido Informações
(itens a serem preparados, hora do Gerenciais
início do preparo)
CSU7 Informações de baixa no pedido Informações
(itens concluídos, hora da conclusão) Gerenciais

CSU8 Informações de troca de mesa (mesa Informações

original, nova mesa) Cadastrais

CSU9 Informações de gerenciamento de Informações

estoque (itens em estoque, Gerenciais
quantidade)
CSU10 Informações de gerenciamento do Informações
fluxo de clientes (número de clientes, Gerenciais
hora de pico)

4.1Requisitos e restrições de interface Homem-Computador (RHIC)

*CSU1 - Cliente faz o pedido*
- RHIC1: A interface deve permitir que o cliente selecione itens do menu para fazer um
pedido.
- RHIC2: A interface deve fornecer feedback visual quando um pedido é feito com
sucesso.

*CSU2 - Cliente solicita o pagamento*

- RHIC3: A interface deve permitir que o cliente solicite o pagamento.
- RHIC4: A interface deve fornecer um resumo detalhado da conta quando o pagamento
é solicitado.

EOR: Estrutura do Documento 9

EOR Versão: 2.0
Buteco do Fundão 2.0 Data/Hora: 11/2023

*CSU3 - Garçom atende o cliente*

- RHIC5: A interface deve permitir que o garçom veja os pedidos dos clientes.
- RHIC6: A interface deve permitir que o garçom atualize o status do pedido.

*CSU4 - Garçom faz a entrega do pedido*

- RHIC7: A interface deve permitir que o garçom marque um pedido como entregue.

*CSU5 - Garçom fecha a conta do cliente*

- RHIC8: A interface deve permitir que o garçom feche a conta do cliente.

*CSU6 - Chefe de Cozinha prepara pedido*

- RHIC9: A interface deve permitir que o chefe de cozinha veja os pedidos que
precisam ser preparados.
- RHIC10: A interface deve permitir que o chefe de cozinha marque um pedido como
preparado.

*CSU7 - Chefe de cozinha da baixa no pedido*

- RHIC11: A interface deve permitir que o chefe de cozinha marque um pedido como
concluído.

*CSU8 - Gerente gerência troca de mesa*

- RHIC12: A interface deve permitir que o gerente gerencie a troca de mesas.

*CSU9 - Gerente gerencia o estoque*

- RHIC13: A interface deve permitir que o gerente veja o estoque atual.
- RHIC14: A interface deve permitir que o gerente atualize o estoque.

*CSU10 - Gerente gerencia o fluxo de cliente*

- RHIC15: A interface deve permitir que o gerente veja o número atual de clientes.
- RHIC16: A interface deve permitir que o gerente gerencie o fluxo de clientes.

4.2Requisitos de Interface Externa (RIEX)

1. *CSU1 - Cliente faz o pedido:*

EOR: Estrutura do Documento 10

EOR Versão: 2.0
Buteco do Fundão 2.0 Data/Hora: 11/2023

- A interface deve oferecer uma opção amigável e intuitiva para os clientes

visualizarem o cardápio, selecionarem os itens desejados, especificarem preferências e
confirmarem o pedido.

2. *CSU2 - Cliente solicita o pagamento:*

- Deve haver uma funcionalidade clara na interface que permita aos clientes solicitar a
conta e realizar o pagamento de maneira eficiente e direta.

3. *CSU3 - Garçom atende o cliente:*

- A interface deve fornecer uma plataforma eficaz para os garçons receberem
notificações de novos pedidos, acompanharem o status dos pedidos e registrarem
interações com os clientes.

4. *CSU4 - Garçom faz a entrega do pedido:*

- Os garçons devem ter a capacidade de atualizar o status de entrega na interface,
fornecendo informações em tempo real aos clientes e à cozinha.

5. *CSU5 - Garçom fecha a conta do cliente:*

- A interface deve permitir que os garçons fechem a conta, registrando os itens
consumidos e processando o pagamento de forma eficaz.

6. *CSU6 - Chefe de Cozinha prepara pedido:*

- O chefe de cozinha deve ter uma interface que lhe permita visualizar os pedidos em
tempo real, priorizar a preparação e marcar os itens à medida que são concluídos.

7. *CSU7 - Chefe de cozinha dá baixa no pedido:*

- Após a preparação, a interface deve permitir que o chefe de cozinha dê baixa nos
itens do estoque, garantindo uma atualização precisa das quantidades disponíveis

4.3Requisitos e Restrições de Projeto (RPRO)

Requisitos de Projeto (RPRO):
Design Responsivo:
CSU11 - A interface deve ser responsiva para garantir uma experiência consistente em
diferentes dispositivos.

Arquitetura Modular:

EOR: Estrutura do Documento 11

EOR Versão: 2.0
Buteco do Fundão 2.0 Data/Hora: 11/2023

CSU12 - A arquitetura do sistema deve ser modular para facilitar atualizações e

incorporação de novos recursos.

Integração com Hardware Existente:

CSU13 - O projeto deve considerar a integração com o hardware existente, como tablets
e terminais de pagamento.

Eficiência no Uso de Recursos:

CSU14 - O sistema deve otimizar o uso de recursos para garantir um desempenho
eficiente.

Segurança da Informação:
CSU15 - Práticas de segurança robustas devem ser implementadas, incluindo
criptografia, autenticação segura e controle de acesso.

Restrições de Projeto (RPRO):

Orçamento Limitado:
CSU16 - O projeto deve ser desenvolvido dentro de um orçamento específico.

Tempo de Implementação:
CSU17 - O projeto deve ser implementado dentro de prazos específicos.

Treinamento Mínimo para Usuários:

CSU18 - A interface deve ser intuitiva, minimizando a necessidade de treinamento
extensivo para os usuários.

Compatibilidade com Navegadores:

CSU19 - O sistema deve ser compatível com uma variedade de navegadores web.

Manutenibilidade:
CSU20 - O projeto deve ser estruturado para facilitar a manutenção contínua.

Escalabilidade:

EOR: Estrutura do Documento 12

EOR Versão: 2.0
Buteco do Fundão 2.0 Data/Hora: 11/2023

CSU21 - O sistema deve ser projetado de forma escalável para atender ao crescimento.

4.4Requisitos e restrições de arquitetura de software (RARQ)

CSU11 - Design Responsivo:
O sistema deve ser desenvolvido com uma arquitetura que permita a adaptação da
interface para diferentes dispositivos, mantendo uma experiência de usuário consistente.

CSU12 - Arquitetura Modular:

A arquitetura do software deve ser modular, permitindo a fácil integração de novos
módulos e atualizações sem impactar negativamente outras partes do sistema.

CSU13 - Integração com Hardware Existente:

A arquitetura deve suportar a integração eficiente com o hardware existente no buteco,
como tablets e terminais de pagamento, garantindo interoperabilidade.

CSU14 - Eficiência no Uso de Recursos:

A arquitetura deve ser otimizada para garantir o uso eficiente de recursos, minimizando
a carga sobre servidores e dispositivos.

CSU15 - Segurança da Informação:

A arquitetura deve incorporar práticas de segurança robustas, incluindo criptografia,
autenticação segura e controle de acesso, para proteger dados sensíveis.
Restrições de Arquitetura de Software (RARS):

CSU16 - Orçamento Limitado:

O desenvolvimento da arquitetura deve respeitar as restrições orçamentárias específicas
do projeto.

CSU17 - Tempo de Implementação:

A arquitetura deve ser desenvolvida considerando prazos específicos para garantir uma
implementação oportuna.

CSU18 - Treinamento Mínimo para Usuários:

A arquitetura deve suportar uma interface intuitiva, minimizando a necessidade de
treinamento extensivo para usuários, como garçons e gerentes.

EOR: Estrutura do Documento 13

EOR Versão: 2.0
Buteco do Fundão 2.0 Data/Hora: 11/2023

CSU19 - Compatibilidade com Navegadores:

A arquitetura deve garantir a compatibilidade do sistema com uma variedade de
navegadores web para atender às necessidades dos usuários.

CSU20 - Manutenibilidade:
A arquitetura do software deve ser projetada para facilitar a manutenção contínua,
permitindo correções de bugs, atualizações e melhorias eficientes.

CSU21 - Escalabilidade:
A arquitetura deve ser escalável, possibilitando a expansão do sistema para lidar com
um aumento no número de clientes e transações.

4.5Requisitos e restrições de plataforma de hardware (RPHW)

CSU13 - Integração com Hardware Existente:
A plataforma de hardware deve ser capaz de integrar-se eficientemente com os
dispositivos existentes no Buteco, como tablets e terminais de pagamento.

CSU14 - Eficiência no Uso de Recursos:

A plataforma de hardware deve suportar a eficiente utilização de recursos, garantindo
um desempenho adequado do sistema.
Restrições de Plataforma de Hardware (RPH):

CSU16 - Orçamento Limitado:

A escolha da plataforma de hardware deve respeitar as restrições orçamentárias
específicas do projeto.

CSU17 - Tempo de Implementação:

A seleção e implementação da plataforma de hardware devem ser realizadas dentro de
prazos específicos para garantir uma integração oportuna.

CSU19 - Compatibilidade com Navegadores:

A plataforma de hardware deve ser compatível com uma variedade de navegadores web,
garantindo acesso consistente e sem problemas.

CSU20 - Manutenibilidade:

EOR: Estrutura do Documento 14

EOR Versão: 2.0
Buteco do Fundão 2.0 Data/Hora: 11/2023

A plataforma de hardware deve ser escolhida considerando a facilidade de manutenção

contínua, permitindo correções, atualizações e melhorias eficientes.

CSU21 - Escalabilidade:
A plataforma de hardware deve ser escalável para lidar com um aumento no número de
clientes e transações, garantindo a eficácia a longo prazo do sistema.

4.6Requisitos e restrições de plataforma de software (RPSW)

CSU11 - Design Responsivo:

A plataforma de software deve suportar a criação de uma interface responsiva para
garantir uma experiência consistente em diferentes dispositivos.

CSU12 - Arquitetura Modular:

A plataforma de software deve permitir o desenvolvimento de uma arquitetura modular
para facilitar a integração de novos módulos e atualizações.

CSU15 - Segurança da Informação:

A plataforma de software deve oferecer suporte a práticas de segurança robustas, como
criptografia, autenticação segura e controle de acesso.

Restrições de Plataforma de Software (RPS):

CSU16 - Orçamento Limitado:

A escolha da plataforma de software deve respeitar as restrições orçamentárias
específicas do projeto.

CSU17 - Tempo de Implementação:

A seleção e implementação da plataforma de software devem ocorrer dentro de prazos
específicos para garantir uma integração oportuna.

CSU19 - Compatibilidade com Navegadores:

A plataforma de software deve ser compatível com uma variedade de navegadores web
para garantir uma ampla acessibilidade.

CSU20 - Manutenibilidade:

EOR: Estrutura do Documento 15

EOR Versão: 2.0
Buteco do Fundão 2.0 Data/Hora: 11/2023

A plataforma de software escolhida deve ser facilmente mantida, permitindo correções,

atualizações e melhorias eficientes ao longo do tempo.

CSU21 - Escalabilidade:
A plataforma de software deve ser escalável para acomodar o crescimento do sistema,
suportando um aumento no número de clientes e transações.

4.7Requisitos e restrições de desempenho (RDES)

*Cliente faz o pedido*
- RDES1: O sistema deve ser capaz de processar um pedido do cliente em menos de 1
segundo.

*Cliente solicita o pagamento*

- RDES2: O sistema deve ser capaz de calcular o total da conta e processar o pedido de
pagamento em menos de 2 segundos.

*Garçom atende o cliente*

- RDES3: O sistema deve ser capaz de registrar o atendimento do garçom ao cliente em
tempo real.

*Garçom faz a entrega do pedido*

- RDES4: O sistema deve ser capaz de registrar a entrega do pedido pelo garçom em
tempo real.

*Garçom fecha a conta do cliente*

- RDES5: O sistema deve ser capaz de fechar a conta do cliente e processar o
pagamento em menos de 2 segundos.

*Chefe de Cozinha prepara pedido*

- RDES6: O sistema deve ser capaz de registrar o início e o fim do preparo do pedido
pelo chefe de cozinha em tempo real.

*Chefe de cozinha da baixa no pedido*

- RDES7: O sistema deve ser capaz de registrar a baixa no pedido pelo chefe de cozinha
em tempo real.

EOR: Estrutura do Documento 16

EOR Versão: 2.0
Buteco do Fundão 2.0 Data/Hora: 11/2023

*Gerente gerência troca de mesa*

- RDES8: O sistema deve ser capaz de registrar a troca de mesa pelo gerente em tempo
real.

*Gerente gerencia o estoque*

- RDES9: O sistema deve ser capaz de atualizar o estoque em tempo real conforme os
pedidos são feitos e preparados.

*Gerente gerencia o fluxo de cliente*

- RDES10: O sistema deve ser capaz de registrar o fluxo de clientes em tempo real para
ajudar o gerente a gerenciar a capacidade do bar.

4.8Requisitos e restrições de disponibilidade (RDIS)

Requisitos de Disponibilidade (RDI):

CSU1 - Cliente faz o pedido:

O sistema deve estar disponível (RDI1) para que os clientes possam fazer pedidos a
qualquer momento durante o horário de funcionamento do buteco.

CSU2 - Cliente solicita o pagamento:

A funcionalidade de solicitação de pagamento deve estar disponível (RDI2) sempre que
um cliente desejar encerrar sua conta.

CSU3 - Garçom atende o cliente:

O sistema deve estar operacional (RDI3) para que os garçons possam atender os clientes
durante o expediente.

CSU4 - Garçom faz a entrega do pedido:

A funcionalidade de entrega de pedidos deve estar disponível (RDI4) para que os
garçons possam concluir a entrega dos itens aos clientes.

CSU5 - Garçom fecha a conta do cliente:

O sistema deve estar acessível (RDI5) para que os garçons possam fechar a conta dos
clientes quando solicitado.

CSU6 - Chefe de Cozinha prepara pedido:

EOR: Estrutura do Documento 17

EOR Versão: 2.0
Buteco do Fundão 2.0 Data/Hora: 11/2023

A plataforma deve estar disponível (RDI6) para o chefe de cozinha preparar os pedidos
dos clientes conforme necessário.

CSU7 - Chefe de cozinha dá baixa no pedido:

A funcionalidade de dar baixa nos pedidos deve estar operacional (RDI7) para manter o
fluxo adequado na cozinha.

CSU8 - Gerente gerencia troca de mesa:

O sistema deve estar acessível (RDI8) para que o gerente possa gerenciar a troca de
mesas conforme necessário.

CSU9 - Gerente gerencia o estoque:

A funcionalidade de gerenciamento de estoque deve estar disponível (RDI9) para que o
gerente possa monitorar e ajustar os níveis de estoque conforme necessário.

CSU10 - Gerente gerencia o fluxo de cliente:

O sistema deve estar operacional (RDI10) para que o gerente possa gerenciar
eficientemente o fluxo de clientes durante o horário de funcionamento.

Essas associações corrigidas garantem que os requisitos e restrições de disponibilidade

estejam alinhados aos códigos específicos mencionados (CSU1 a CSU10).

4.9Requisitos e restrições de segurança (RSEG)

Requisitos de Segurança (RSEG):

CSU1 - Cliente faz o pedido:

Os dados pessoais e de pagamento dos clientes transmitidos durante o pedido devem ser
protegidos por protocolos de criptografia robustos (RSEG1).

CSU2 - Cliente solicita o pagamento:

A funcionalidade de pagamento online deve garantir transações seguras, incluindo
autenticação forte e proteção contra fraudes (RSEG2).

CSU3 - Garçom atende o cliente:

EOR: Estrutura do Documento 18

EOR Versão: 2.0
Buteco do Fundão 2.0 Data/Hora: 11/2023

O acesso à interface de atendimento do garçom deve ser protegido por autenticação

segura para evitar acessos não autorizados (RSEG3).

CSU4 - Garçom faz a entrega do pedido:

As atualizações de status e confirmações de entrega devem ser registradas de forma
segura para garantir a integridade das informações (RSEG4).

CSU5 - Garçom fecha a conta do cliente:

As transações de pagamento e fechamento de contas devem ser registradas de forma
segura e auditável (RSEG5).
CSU6 - Chefe de Cozinha prepara pedido:
O acesso à interface do chefe de cozinha deve ser restrito e protegido por autenticação
forte para evitar manipulação indevida de pedidos (RSEG6).

CSU7 - Chefe de cozinha dá baixa no pedido:

As atualizações de estoque realizadas pelo chefe de cozinha devem ser monitoradas e
registradas para garantir a precisão e a segurança dos dados (RSEG7).

CSU8 - Gerente gerencia troca de mesa:

As autorizações e ações do gerente relacionadas à troca de mesa devem ser controladas
e auditadas para evitar atividades suspeitas (RSEG8).

CSU9 - Gerente gerencia o estoque:

O acesso às funções de gerenciamento de estoque deve ser restrito e monitorado para
evitar manipulação indevida de dados de estoque (RSEG9).

CSU10 - Gerente gerencia o fluxo de cliente:

As decisões e ações do gerente relacionadas ao fluxo de clientes devem ser registradas e
monitoradas para garantir transparência e segurança operacional (RSEG10).

Restrições de Segurança (RSEG):

CSU16 - Orçamento Limitado:

As soluções de segurança implementadas devem estar alinhadas com as restrições
orçamentárias do projeto (RSEG11).

CSU19 - Compatibilidade com Navegadores:

EOR: Estrutura do Documento 19

EOR Versão: 2.0
Buteco do Fundão 2.0 Data/Hora: 11/2023

As medidas de segurança devem ser compatíveis com uma variedade de navegadores

para garantir uma experiência segura e consistente (RSEG12).

4.10 Requisitos e restrições de manutenibilidade (RMAN)

Requisitos e restrições de manutenibilidade (RMAN)
Modularidade: O software deve ser projetado de forma modular, o que significa que ele
deve ser dividido em partes menores e independentes (módulos). Isso facilita a
manutenção, pois as alterações em um módulo não afetam os outros.

Documentação: A documentação do código e do sistema deve ser mantida atualizada.

Isso inclui comentários no código, bem como documentos de design e requisitos.

Testes: Deve haver testes automatizados para cada parte do sistema. Isso garante que as
alterações não quebrem a funcionalidade existente.

Padrões de Codificação: O código deve seguir os padrões de codificação acordados.

Isso torna o código mais legível e fácil de manter.

Ferramentas de Controle de Versão: O uso de ferramentas de controle de versão, como

Git, facilita o rastreamento das alterações e a identificação de quando e onde os bugs
foram introduzidos.

Refatoração: O código deve ser regularmente refatorado para melhorar a qualidade do

código e torná-lo mais fácil de entender e manter.

Treinamento: A equipe de desenvolvimento deve receber treinamento regular sobre as

melhores práticas de codificação e manutenção de software.

4.11 Requisitos e restrições de portabilidade (RPOR)

Requisitos e restrições de portabilidade (RPOR)
Plataformas de Desenvolvimento: O software deve ser desenvolvido em uma linguagem
de programação que seja suportada em várias plataformas, como Java ou Python. Além
disso, as ferramentas de desenvolvimento utilizadas, como IDEs e sistemas de controle
de versão, devem ser compatíveis com várias plataformas.

Plataformas de Produção: O software deve ser capaz de rodar em várias plataformas de

produção. Isso pode incluir diferentes sistemas operacionais (Windows, MacOS,
Linux), navegadores da web (Chrome, Firefox, Safari) e dispositivos móveis (iOS,
Android).

EOR: Estrutura do Documento 20

EOR Versão: 2.0
Buteco do Fundão 2.0 Data/Hora: 11/2023

Banco de Dados: O software deve ser compatível com vários sistemas de gerenciamento
de banco de dados, como MySQL, PostgreSQL e SQLite.

Hardware: O software deve ser capaz de funcionar eficientemente em hardware com

diferentes capacidades. Isso pode incluir computadores com diferentes quantidades de
memória, velocidades de processador e capacidades de armazenamento.

Rede: O software deve ser capaz de funcionar em diferentes tipos de redes, incluindo
LANs, WANs e redes móveis.

Internacionalização: O software deve ser capaz de suportar vários idiomas e formatos de

data/hora.

Acessibilidade: O software deve ser acessível para usuários com deficiências, incluindo
suporte para tecnologias assistivas.

Segurança: O software deve ser capaz de funcionar em ambientes com diferentes

requisitos de segurança, incluindo a capacidade de criptografar dados e autenticar
usuários.

4.12 Requisitos de documentação (RDOC)

Requisitos de documentação (RDOC)
Documento de Visão: Este documento deve conter uma visão geral do sistema,
incluindo os principais recursos, benefícios, stakeholders e restrições do sistema.

Especificação de Requisitos de Software (SRS): Este documento deve detalhar todos os

requisitos funcionais e não funcionais do sistema. Ele deve incluir casos de uso,
diagramas de fluxo de dados e qualquer outra informação relevante para entender o que
o sistema deve fazer. Para o seu sistema, os casos de uso podem ser os seguintes:
CSU1: Cliente faz o pedido.
CSU2: Cliente solicita o pagamento.
CSU3: Garçom atende o cliente.
CSU4: Garçom faz a entrega do pedido.
CSU5: Garçom fecha a conta do cliente.
CSU6: Chefe de Cozinha prepara pedido.
CSU7: Chefe de cozinha da baixa no pedido.
CSU8: Gerente gerência troca de mesa.

EOR: Estrutura do Documento 21

EOR Versão: 2.0
Buteco do Fundão 2.0 Data/Hora: 11/2023

CSU9: Gerente gerencia o estoque.

CSU10: Gerente gerencia o fluxo de cliente.

Diagramas de Arquitetura: Estes devem mostrar a estrutura geral do sistema, incluindo

os principais componentes e como eles interagem entre si.

Plano de Teste: Este documento deve detalhar como o sistema será testado para garantir
que ele atenda a todos os requisitos especificados.

Manual do Usuário: Este documento deve fornecer instruções passo a passo sobre como
usar o sistema. Ele deve ser escrito de uma maneira fácil de entender para os usuários
finais.

Documentação de Código: O código deve ser bem documentado com comentários

explicando o que cada parte do código faz.

Plano de Implantação: Este documento deve detalhar como o sistema será implantado,
incluindo qualquer hardware ou software necessário, e quaisquer etapas necessárias para
configurar o sistema.

Plano de Manutenção: Este documento deve detalhar como o sistema será mantido após
a implantação, incluindo qualquer atualização ou correção de bugs planejada.

5. Requisitos Futuros (RFUT)

Descrever os requisitos que poderão ser especificados em uma nova versão do produto.
Exemplo:
Códig Requisitos Futuros (RFUT) Descrição
o
CSU1 Cliente faz o pedido. Implementar um sistema de pedidos online para
permitir que os clientes façam pedidos através de
um aplicativo móvel ou site.
CSU2 Cliente solicita o pagamento. Adicionar suporte para pagamentos móveis e
carteiras digitais para facilitar o processo de
pagamento.
CSU3 Garçom atende o cliente. Implementar um sistema de feedback para
permitir que os clientes avaliem o atendimento do
garçom.
CSU4 Garçom faz a entrega do Adicionar a opção de rastreamento de pedidos em
pedido. tempo real para os clientes.

EOR: Estrutura do Documento 22

EOR Versão: 2.0
Buteco do Fundão 2.0 Data/Hora: 11/2023

CSU5 Garçom fecha a conta do Implementar um sistema de faturamento digital

cliente. para reduzir o uso de papel e melhorar a
eficiência.
CSU6 Chefe de Cozinha prepara Implementar um sistema de gerenciamento de
pedido. pedidos na cozinha para melhorar a eficiência na
preparação dos pedidos.
CSU7 Chefe de cozinha da baixa no Adicionar a opção de notificações automáticas
pedido. para o garçom quando o pedido estiver pronto.
CSU8 Gerente gerência troca de Implementar um sistema de gerenciamento de
mesa. mesas digital para otimizar a alocação de mesas.
CSU9 Gerente gerencia o estoque. Implementar um sistema de gerenciamento de
estoque inteligente que possa prever a demanda e
sugerir pedidos de reposição.
CSU10 Gerente gerencia o fluxo de Implementar um sistema de reservas online para
cliente. gerenciar melhor o fluxo de clientes.

6. Referências cruzadas complementares

1. *Entre Requisitos:*
- O requisito de eficiência no uso de recursos (RDE1) (CSU14) está relacionado à
disponibilidade para garantir um desempenho eficiente (RDI1).

- A segurança na transmissão de dados durante o pedido (RSEG1) (CSU1)

complementa o requisito de disponibilidade durante o pedido (RDI1).

- O requisito de proteção contra fraudes no pagamento (RSEG2) (CSU2)

complementa o requisito de solicitação segura de pagamento (RDI2).

2. *Entre Casos de Uso:*

- O caso de uso "Cliente faz o pedido" (CSU1) está relacionado ao caso de uso
"Garçom atende o cliente" (CSU3) para garantir uma transição suave durante o
atendimento.

- O caso de uso "Garçom faz a entrega do pedido" (CSU4) está vinculado ao caso de
uso "Garçom fecha a conta do cliente" (CSU5) para garantir a conclusão adequada do
serviço.

- O caso de uso "Gerente gerencia o estoque" (CSU9) está relacionado ao caso de uso
"Chefe de cozinha dá baixa no pedido" (CSU7) para manter a consistência entre pedidos
e estoque.

EOR: Estrutura do Documento 23

EOR Versão: 2.0
Buteco do Fundão 2.0 Data/Hora: 11/2023

Essas referências cruzadas buscam fortalecer a coesão entre requisitos e casos de uso,
garantindo uma implementação consistente e integrada do sistema de atendimento em
um buteco.

EOR: Estrutura do Documento 24