Especificações de Requisitos de Software

SISTEMA DE GERENCIAMENTO DE RESTAURANTE

Version: 1.1

Código do Projeto C 01
Supervisor Sra. Faiza Sattar
Co Supervisor Senhor Muhammad Nadeem

Equipe do Projeto Muhammad Anas

Muhammad Safi
Abdullah Siraj
Waleed Hasan

Submission Date 24/09/17

<Projeto CS491-I> Especificações de Requisitos de Software <Version 1.5>

Page 2 of 21
<CS491 Projeto-I> Especificações de Requisitos de Software <Versão 1.5>

Histórico do Documento
[O histórico de revisões será mantido para acompanhar as alterações feitas por qualquer pessoa no documento.]

Nome da versão da pessoa Data Descrição da mudança

15/09/2017 Documento Criado
18/10/2017 Documento Revisado
18/10/2017 Documento Editado
22/10/2017 Documento Revisado
24/10/2017 Casos de uso adicionados e Documento Revisado.

Página 3 de 21
<Projeto CS491-I> Especificações de Requisitos de Software <Version 1.5>

Lista de Distribuição
[A tabela a seguir conterá uma lista de pessoas para as quais o documento será distribuído após cada aprovação]

Name Função
Sra. Faiza Sattar Supervisor
Senhor Muhammad Nadeem Co-Supervisor

Página 4 de 21
<CS491 Projeto-I> Especificações de Requisitos de Software <Version 1.5>

Assinatura do Documento

Versão Autoridade de aprovação Data de aprovação

1.1 Sir Muhammad Nadeem
1.2
1.3
1.4
1.5

Página 5 de 21
<CS491 Projeto-I> Especificações de Requisitos de Software <Version 1.5>

Table of Contents

EuINTRODUÇÃO...................................................................................................................................... 7
1.1. Objetivo do Documento. 7
1.2. Público Alvo. 7
1.3 Abreviações………………………………………………………………………………………...7
1.4. Documento de Convençãon ............................................................................................................. 7
2. OVERALLSSISTEMADESCRIPTION ............................................................................................................ 8
2.1. Contexto do Projeto. 8
2.2. Project Scope .......................................................................................................................... 8
2.3. Fora do escopo. 9
2.4. Objetivos do Projeto ................................................................................................................... 9
2.5. Partes interessadas. 9
2.6. Ambiente de Operação. 9
2.7. System Constraints ................................................................................................................. 9
2.8. Suposições e Dependências. 10
3. EXTERNALEuINTERFACERREQUISITOS................................................................................................. 11
3.1. Interfaces de Hardware. 11
3.2. Interfaces de Software. 11
3.3. Interfaces de Comunicação. 11
4. FFUNCIONALRREQUISITOS ............................................................................................................... 12
4.1. FFUNCIONALHHIERARQUIA.............................................................................................................. 12
4.2. Caso de Usos ............................................................................................................................. 13
4.2.1. [Título do caso de uso] ....................................................................Erro! Marcador não definido.
5. NLIGADO-FUNCIONALRREQUISITOS....................................................................................................... 18
5.1. Requisitos de Desempenho. 18
5.2. Requisito de Seguranças ............................................................................................................. 19
5.3. Requisito de Seguranças .......................................................................................................... 19
5.4. User Documentation.............................................................................................................. 19
6. RREFERÊNCIAS...................................................................................................................................... 20
7. AAPÊNDICES....................................................................................................................................... 21

Página 6 de 21
<CS491 Projeto-I> Especificações de Requisitos de Software <Versão 1.5>

1. Introduction
1.1 Objetivo do Documento
O objetivo deste documento é apresentar uma descrição detalhada do sistema como um todo.
o documento explicará o propósito e as características do sistema, a interface do sistema,
o que o sistema fará, as restrições sob as quais o sistema deve operar e o final se
as situações anormais ocorrem, como o sistema deve responder.

1.2 Intended Audience

O público-alvo deste documento são tanto as partes interessadas quanto os desenvolvedores, e ele irá
ser proposto ao Júri do FYP.

1.3Abbreviations
RMS - Sistema de Gestão de Restaurantes
1.4Document Convention
Font: - Times New Roman
Tamanho da Fonte do Título: - 16 em Negrito
Tamanho da Fonte do Subtítulo: - 12 com Negrito
Tamanho da Fonte do Parágrafo: - 12

Página 7 de 21
<CS491 Projeto-I> Especificações de Requisitos de Software <Version 1.5>

2 Overall System Description

2.1 Contexto do Projeto

A indústria alimentícia é uma proposta de negócios de alto risco. Você tem um nível elevado de concorrência.
e muitos detalhes para aperfeiçoar.
Problemas comuns enfrentados pelos consumidores ao visitar restaurantes que levam a
descontentamento;
●Péssimo Atendimento ao Cliente

●Incompetent Staff
●Grande variação no atendimento ao cliente entre horários de pico e fora de pico
Solução:
Um 'Sistema de Pedidos Automatizado' em restaurantes permitiria que os clientes não precisassem mais
esperar em filas ao fazer e receber pedidos.
● Os benefícios para o restaurante seriam economia de custos e tempo, utilização eficaz de recursos.
Market Size:
Pesquisas iniciais da FCP sugerem que os paquistaneses gastam mais de 1 bilhão de dólares em refeições fora de casa em um ano.

Pesquisas adicionais indicaram que há cerca de 2000 restaurantes de alto padrão nos principais
cidades do Paquistão ou seja, nosso mercado-alvo
2.2 Project Scope

Este sistema ajudará a gerenciar e operar o negócio de restaurante de forma sistemática. Neste
sistema de gestão, forneceremos um aplicativo que pode ser usado pelos clientes para pedir comida.
Os clientes também podem dar feedback através deste aplicativo. Assim, o proprietário do restaurante pode
avaliar o sistema como um todo. Isso levará, em última análise, a contratar menos garçons e criar um
oportunidade de recrutar mais chefs e um melhor espaço na cozinha para servir a comida mais rápido. Clientes
também é possível fazer pagamentos através de cartões de débito ou crédito que serão integrados com o
software de gestão. Os clientes podem ver a atual facilidade de desconto do restaurante. Todos os
As informações sobre despesas diárias e lucros serão salvas no sistema. Além disso, o necessário
As informações sobre os funcionários serão salvas no sistema, que pode ser acessado apenas por
o administrador do sistema.

Os limites do sistema são:

a. O usuário deve ter instalado o aplicativo.
b. O caixa deve estar logado no sistema.
c. O restaurante deve adquirir a aplicação para usar.
d. O usuário deve seguir o guia de instruções antes de usar o aplicativo, guia de instruções
será útil

Página 8 de 21
<CS491 Projeto-I> Especificações de Requisitos de Software <Versão 1.5>

As características do sistema são:

2.3 Fora do Escopo

O sistema é limitado apenas ao mesmo restaurante, isso significa que o sistema não deve
desenvolver para o restaurante cruz.

2.4 Objetivos do Projeto

Este documento apresenta uma explicação detalhada dos objetivos, características, interface do usuário e
aplicação do Sistema de Gestão de Restaurantes na vida real. Também descreverá como o
o sistema realizará e sob o qual deve operar. Neste documento também será mostrado
interface do usuário. Tanto os compradores quanto os desenvolvedores do sistema podem se beneficiar disso.
documento.
2.5 Partes Interessadas

Primary: Customer and Staff.

Secondary: Database servers and Bank Debit/credit card verification.

2.6 Operating Environment

O sistema requer um aparelho móvel (Android).
O sistema será compatível com Windows 7 e versões posteriores.
O sistema requer um sistema de rede.

2.7 Restrições do Sistema

Restrições de software
Versões do Android abaixo de 4.4 não são suportadas.
Versões do Windows abaixo do 7 não são suportadas.

É necessária uma conexão de rede entre as duas interfaces.

Página 9 de 21
<CS491 Projeto-I> Especificações de Requisitos de Software <Versão 1.5>

Restrições de hardware
PC:
Processador Intel core 2 duo
Mínimo de 50 MB de espaço no disco rígido.

Mínimo de 512 MB de RAM.

Mobile:
Processador dual core de 1 GHz.
ROM 50 MB
RAM 1 GB
Restrições culturais (inclui língua etc.)
A língua inglesa é utilizada.

Restrições legais
O software deve ser comprado e licenciado por um restaurante para ser utilizado.
A proteção de dados é garantida.
Restrições ambientais
TBD
Restrições do usuário

A Definir

2.8 Suposições e Dependências

Se este sistema usar um tipo de sistema operacional, então será benéfico. Se houver mais tablets para cada um.
tabela o desempenho de todo o sistema será melhor.

Página 10 de 21
<CS491 Project-I> Especificações de Requisitos de Software <Version 1.5>

3 Requisitos de Interface Externa

3.1 Interfaces de Hardware
Existem três dispositivos de hardware externos usados pelo FOS, cada um relacionado a uma interface de usuário.
Estes dispositivos são os computadores de superfície, os tablets sem fio e os displays sensíveis ao toque. Todos
três dispositivos devem ser fisicamente robustos e imunes a danos por líquidos e manchas. O
os dispositivos (com a possível exceção de displays) também devem ter um bom design industrial
estéticas, uma vez que devem ser usadas no lugar de mesas de restaurante normais e blocos de notas e irão
esteja em contato direto com os clientes. Os dispositivos se comportam como 'terminais' no sentido de que eles
nunca ter uma imagem completa do sistema, não armazenar dados e não serem usados para a lógica central do
sistema. No entanto, eles devem ser computadores totalmente capazes que podem usar dados textuais de
servidor junto com código local de interface/interpretação para exibir elementos da interface e receber entrada. Todos
os registros de pedidos e transações devem ser armazenados no servidor.
Dispositivos necessários são: Como o aplicativo é baseado em Windows, então tablets PCs baseados em Windows.
Laptops ou Desktop são necessários para fazer o sistema funcionar.

3.2 Interfaces de Software

O sistema deve ser capaz de se comunicar com a pessoa responsável pelas operações para obter
atualizar versão das especificações do produto. O RMS irá interagir com um Banco de Dados
Sistema de Gerenciamento de Banco de Dados (SGBD) que armazena as informações necessárias para o funcionamento do RMS.
O SGBD deve ser capaz de fornecer, mediante solicitação e com baixa latência, dados relativos a
restaurant's menu, employees (and their passwords) and available dietary requirements.
Além disso, ele deve receber e arquivar dados fornecidos a ele pelo RMS. Esses dados irão
incluir registros de todos os pedidos e transações (estados do sistema e alterações de estado) executados por
o RMS. O DBMS deve armazenar todos os dados de forma que possam ser usados para contabilidade, assim como
responsabilidade.

3.3 Interfaces de Comunicação

O RMS irá se conectar a uma Rede Local (LAN) para manter a comunicação com todos.
seus dispositivos. Ele deve usar um protocolo IP de tipo confiável, como TCP/IP ou UDP/IP confiável para
máxima compatibilidade e estabilidade. Todos os dispositivos com os quais interagirá devem conter padrão
Placas de LAN compatíveis com Ethernet e acessíveis por software para manter a comunicação entre o
servidor e os computadores de superfície, tablets, displays e o sistema de pagamento externo. Dispositivos que
os dispositivos sem fio também devem usar placas compatíveis com Ethernet, utilizando o padrão IEEE 802.11b/g e
tendo suporte para criptografia WPA2-PSK. O uso do padrão de transmissão IEEE 802.11n
o hardware também é aceitável se todo o outro hardware local estiver em conformidade com o mesmo padrão.

Página 11 de 21
<CS491 Projeto-I> Especificações de Requisitos de Software <Version 1.5>

4 Requisitos Funcionais
4.1 Hierarquia Funcional
O sistema é decomposto em três módulos/componentes principais.
a. Client Side (User Application)
[Link]’sInterface
Interface da Cozinha
d. Autorização Bancária
A parte seguinte da seção descreve brevemente os três módulos listados acima.
1. Pedido de comida via aplicativo Android

2. Pedido recebido pela equipe da cozinha

3. Notificação de entrega do pedido

4. Two possible payment methods (cash or card)
5. Conclusão instantânea do pedido e confirmação de informações
6. Faturamento Computadorizado

7. Atualização do sistema

8. Salvar registros automaticamente no banco de dados

Página 12 de 21
<CS491 Projeto-I> Especificações de Requisitos de Software <Versão 1.5>

4.2 Casos de Uso

Página 13 de 21
<CS491 Projeto-I> Especificações de Requisitos de Software <Version 1.5>

Página 14 de 21
<CS491 Projeto-I> Especificações de Requisitos de Software <Version 1.5>

4.2.1 Caso de Uso :-

Use Case : Process Sale
Primary Actor:Cashier
Partes interessadas e interesses: -
Caixa: Deseja uma entrada precisa, rápida e sem erros de pagamento, pois faltas na gaveta do caixa são
descontado de seu/sua salário.
Cliente: Quer comprar e receber um serviço rápido com esforço mínimo. Quer prova de compra para
suporte a devoluções.
Pré-condições:
O caixa é identificado e autenticado.
Postconditions:
A venda está salva. O imposto é calculado corretamente. A contabilidade e o inventário estão atualizados. Comissões
Registrado. Recibo gerado. As aprovações de autorização de pagamento são registradas via banco.
sistema de autorização finalmente o banco de dados foi atualizado.
Cenário Principal de Sucesso (ou Fluxo Básico):
1. O cliente chega ou envia o cartão de crédito pelo garçom ao caixa.
Página 15 de 21
<CS491 Projeto-I> Especificações de Requisitos de Software <Version 1.5>

2. O caixa inicia uma nova venda.

3. O sistema registra o preço calculado a partir de um conjunto de regras de preço.
4. O sistema apresenta o total com os impostos calculados.
5. O cliente paga e o sistema processa o pagamento.
6. O sistema registra a venda concluída e envia as informações de venda e pagamento para o externo
Sistema contábil (para contabilidade e comissões) e sistema de estoque (para atualizar)
inventário).
9. O sistema imprime recibo.
10. O cliente sai com o recibo e os produtos (se houver).
11.O caixa atualiza o banco de dados.
Extensions:-
1. O caixa reinicia o sistema, faz login e solicita a recuperação do estado anterior.
2. Identificador inválido, portanto o sistema sinaliza erro e rejeita a entrada.
3. Pagando com cartão de crédito O cliente insere as informações da sua conta de crédito. O sistema envia o pagamento.
solicitação de autorização a um sistema externo de Serviço de Autorização de Pagamento e solicitações
aprovação de pagamento. O sistema detecta falha em colaborar com o sistema externo Sistema
sinais de erro para o Caixa. O Caixa pede ao Cliente uma forma de pagamento alternativa.
4. Pagando em dinheiro O sistema registra o pagamento em dinheiro.

Special Requirements: -
O texto deve ser visível a 1 metro.
Resposta de autorização de crédito em até 30 segundos 90% do tempo.
Internacionalização de idioma no texto exibido.

4.2.2 Caso de Uso :-

Use Case 2: Manage Order
Primary Actor:
Kitchen Staff Worker
Partes interessadas e interesses:
Para buscar pedidos e adicioná-los à fila da cozinha e remover pedidos concluídos da fila da cozinha.
Pré-condições:
A interface mostra a Fila de Pedidos (com pedidos de clientes) e a Fila da Cozinha (pode ou
pode não ter pedidos).
Pós-condições:
O pedido foi removido de ambas as filas e o garçom foi notificado para a coleta.
Cenário Principal de Sucesso:
1. O trabalhador da equipe da cozinha se aproxima da tela para visualizar e buscar pedidos.
2. O sistema exibe tanto a Filas de Pedidos quanto a Filas da Cozinha, que são atualizadas automaticamente para
contabilizar novos pedidos recebidos. Suponha que a Fila da Cozinha esteja inicialmente vazia.
3. O trabalhador da equipe de cozinha pressiona o botão "Transferir para a fila da cozinha" para cada pedido que deseja
para preparar da Fila de Pedidos.
4. O sistema transfere apenas o nome do item de comida para a Fila da Cozinha e remove o
Botão "Transferir para a Fila da Cozinha" para cada pedido pressionado para evitar múltiplos cliques no mesmo
pedido.
5. O funcionário da cozinha pressiona o botão "Completar" após concluir um pedido.

Página 16 de 21
<CS491 Projeto-I> Especificações de Requisitos de Software <Version 1.5>

6. O sistema sinaliza o garçom para retirar o pedido e remove o pedido da fila da cozinha
e Fila de Pedidos.
Extensions:
1. O cliente cancela um pedido. O sistema é atualizado e o pedido é removido do Pedido
Fila.
2. O cliente tenta cancelar um pedido após o pedido ter sido movido para a cozinha
Fila. O sistema não cancela o pedido porque o botão "Excluir" na Fila de Pedidos
não está lá.

4.2.3 Caso de Uso :-

Use Case 3: Serve Table

Primary Actor:
Garçom
Stakeholder and interests:
Manter o atendimento de diferentes mesas para os clientes, trazendo comida para os clientes.
Pré-condições:
A interface do garçom mostra o status da comida para as mesas atribuídas a ele/ela.
Postconditions:
O status da comida torna-se "Pronto" para ser entregue ao cliente do restaurante.
Cenário Principal de Sucesso:
1. O sistema exibe os números das mesas que o garçom deve servir, o status dos pedidos da mesa.
e a conta da mesa.
2. O garçom seleciona um dos números das mesas a que está designado.
3. O sistema exibe os detalhes do pedido da mesa
4. Kitchen queue reports "Order Ready" for a given table number.
5. O garçom seleciona o botão "Reconhecido" após servir a comida à mesa.
6. O sistema altera o status da mesa para "Servido".
7. Sistema alerta o garçom que a mesa quer pagar em dinheiro.
8. Alertas do gerente para a mesa ser limpa.
9. O sistema remove a tabela da lista de tabelas para servir.
Extensions:
A qualquer momento, a equipe alerta o garçom para ajudar na mesa. O sistema altera ou exclui o pedido da mesa.
detalhes quando o pedido está no status "Na Fila de Pedidos" e quando a mesa quer adicionar/excluir seu pedido.

4.2.4Use Case :-
Use Case 4: Order Food
Primary Actor:
Cliente do Restaurante
Partes interessadas e interesses:
Para ver o menu, selecione os itens preferidos e faça o pedido da comida.
Condições prévias:
A tela do tablet exibe a interface principal com opções para ver homens
Pós-condições:
Voltar ao menu principal ou mostrar o status da comida.
Página 17 de 21
<CS491 Project-I> Especificações de Requisitos de Software <Version 1.5>

Cenário de Sucesso Principal:

1. O cliente do restaurante vê o número da mesa no Menu Principal e seleciona a opção "Ver Menu" 7-8
tablet de polegadas.
2. O sistema exibe categorias de menu (bebidas, aperitivos, specials, almoço, jantar, etc.).
3. O cliente do restaurante seleciona uma categoria.
4. O sistema exibe todos os itens dessa categoria.
5. O cliente do restaurante seleciona a opção 'Adicionar ao Carrinho' para o item.
6. O sistema conta o número de itens.
7. O sistema envia automaticamente os pedidos do carrinho para a Fila de Pedidos da Cozinha.
8. O sistema exibe o status do pedido (se são opções para "Adicionar Mais Itens" ou "Remover
Itens.
9. Quando o sistema exibir "Comida está Pronta e a Caminho".
Extensions:
1. O cliente do restaurante seleciona a opção "Chamar o Garçom" para ajuda. O sistema exibe um pop-up.
mensagem de minuto e o sistema volta para a janela visitada anteriormente.
2. O cliente do restaurante seleciona a opção "Voltar ao Menu Principal" para retornar.

4.2.5 Caso de Uso :-

Use Case 5: Preparing Order
Primary Actor:
Cozinhar
Partes interessadas e interesses:
Prepare a comida para o pedido e notifique o garçom quando estiver pronta.
Pré-condições:
Um pedido foi feito por um cliente e o garçom o trouxe para o cozinheiro.
Postconditions:
O garçom é notificado quando a comida está pronta para ser entregue à mesa. Também cada vez que um
o item alimentar é preparado, os itens de inventário correspondentes são diminuídos pela quantidade pré-especificada
quantidade.
Cenário Principal de Sucesso:
1. O cozinheiro seleciona um dos pedidos pendentes do banco de dados e clica no item para cozinhar.
2. O sistema altera o status do item para 'pronto'.
3. O garçom é então notificado pelo sistema de que o pedido está pronto.

5 Requisitos Não Funcionais

5.1 Requisitos de Desempenho
•The product will be based on network connectivity. The performance will depend upon
componentes de hardware, por exemplo: (1 GB de RAM) do tablet. O sistema de pagamento será totalmente seguro.
através do sistema POS
Requisitos de Segurança
Página 18 de 21
<CS491 Projeto-I> Especificações de Requisitos de Software <Version 1.5>

Um valor será cobrado por qualquer dano causado ao tablet ou a outros bens do restaurante.
5.2 Safety Requirements
Os possíveis requisitos de segurança do sistema.
Falha/Queda do Servidor/Superlotado
Muitos pedidos ao mesmo tempo podem causar a falha do servidor, o sistema deve se comportar
de acordo com o erro.
Erro de Banco de Dados

O sistema deve gerar erro, se ocorrer um erro.

O aplicativo pode não ter respondido
A atualização do aplicativo deve ser verificada mensalmente, ou o sistema deve gerar.
notificação se houver alguma atualização sobre a aplicação.

Os requisitos que estão relacionados com a possível perda, dano ou prejuízo que podem resultar
do uso do sistema.

5.3 Requisitos de Segurança

As informações pessoais serão protegidas.
•Dados criptografados.

O pagamento através de cartões de crédito será seguro e confiável.

5.4 Documentação do Usuário

Um guia do usuário será fornecido ao usuário final para facilitar o uso do aplicativo.

Página 19 de 21
<CS491 Projeto-I> Especificações de Requisitos de Software <Versão 1.5>

6 Referências
[1].[Link]

[2].[Link]

[3].[Link]
Changer-pour-Institutio-Financiè[Link]

[4]. [Link]

[5].[Link]

Peterson, David, e Ronnie McCulloch. "Depósito de cheque remoto." EUA.

Pedido de Patente 11/340.537.

[7]. Ballard, Claudio R. "Captura de imagem remota com processamento centralizado e

armazenamento. "Patente dos EUA nº 5.910.988. 8 jun. 1999.

[8]. Fisher, Dan M. "Home Banking in the 21st Century: Remote Capture Has
Gone Retail." (2008).

Uhland Sr, Joseph C. "Verifique o sistema de captura de imagem." Patente dos EUA No.
5.444.794, 22 de agosto de 1995.

[10]. Oakes III, Charles Lee, et al. "Sistemas e métodos para depósito remoto de
verificações." Registro de Patente dos EUA n° 7.876.949. 25 de jan. de 2011.

Peterson, David, e Ronnie McCulloch. "Depósito de cheque remoto." EUA.

Pedido de Patente 11/114.254.

Page 20 of 21
<Projeto CS491-I> Especificações de Requisitos de Software <Versão 1.5>

6 Apêndices
Apêndice A: Proposta de projeto (assinada pelo supervisor)

Page 21 of 21