estudo requisitos
DESCRIPTION
estudo da disciplina de engenharia de softwareTRANSCRIPT
Unioeste - Universidade Estadual do Oeste do ParanáCENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICASColegiado de InformáticaCurso de Bacharelado em Informática
Estudo de Requisitos
Alunos: Fabio G. KoerichOsmar dos Santos
Professor: Victor F. A. SantanderDisciplina: PES III
CASCAVEL2009
Sumário
Sumário ii
1 Introdução 1
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 O Sistema Proposto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 1
2 Requisitos Funcionais 3
2.1 Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Endereço . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
2.3 Funcionário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5
2.4 Produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
2.5 Grupo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.6 Categoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
2.7 Tamanho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
2.8 Preço . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
2.9 Divisões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
2.10 Pedido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
2.11 Relatorios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 13
3 Modelagem Organizacional i* 15
3.1 Diagrama de Dependências Estratégicas (SD) . . . . . . . . . .. . . . . . . . . 15
3.2 Diagrama de Razões Estratégicas (SR) . . . . . . . . . . . . . . . . . .. . . . . 18
4 Requisitos Não-Funcionais 20
4.1 Requisitos de Processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . 20
4.2 Requisitos de Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 21
4.3 Requisitos de Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . 21
4.4 Requisitos de Performance . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 21
ii
4.5 Grafo SIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
4.6 Recursos Externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 24
4.6.1 Restrições econômicas . . . . . . . . . . . . . . . . . . . . . . . . . . .. 24
5 Casos de Uso 25
6 Diagrama de Classes 32
7 Conclusão 36
iii
Capítulo 1
Introdução
1.1 Motivação
Este trabalho foi realizado com o intuito de desenvolver um sistema computacional para
o controle de vendas de um restaurante, que também poderá disponibilizar entrega domiciliar,
mas pode ser estendido para outros estabelecimentos do gênero. Buscamos ainda projetar um
sistema que propicie agilidade, usabilidade e flexibilidade aos funcionários da empresa que
vierem a utilizá-lo.
1.2 O Sistema Proposto
O presente projeto visa desenvolver um sistema computacional para o controle de vendas de
um restaurante que também realize entregas domiciliares através de um serviço de Tele Entrega.
O sistema será desenvolvido tendo em vista a empresa Cantina da Pina (Restaurante e Piz-
zaria), podendo o mesmo ser fácilmente estendido para outros estabelecimentos do gênero que
possuam uma lógica de negócio semelhante.
O mesmo deverá ser capaz de realizar o cadastro e manutenção das informações de clientes,
funcionários e produtos, assim como possibilitar a venda deprodutos industrializados ou pro-
duzidos no próprio estabelecimento.
A empresa trabalha com dois modelos de venda, vendas por telefone, onde um cliente re-
aliza o seu pedido através do telefone podendo o mesmo decidir pela entregua de sue pedido
em sua residência ou efetuar a busca no estabelecimento. Além das vendas por telefone existe
ainda a venda no local, onde os clientes compram e consomem osprodutos no próprio esta-
belecimento, este também conhecido como pedido mesa ou compram e consomem os em sua
própria residência.
Um estudo de viabilidade anterior nos levou a escola do sistema que aqui citamos. Esse
documento visa, portanto, especificar os requisitos e a modelagem orientada a objetos desse
sistema que gerencia as vendas em um Restaurante que realiza vendas no local e que pode ter
serviço de Tele Entrega.
2
Capítulo 2
Requisitos Funcionais
A seguir, são apresentados os requisitos funcionais do sistema, assim como uma breve
descrição dos mesmos.
2.1 Cliente
[RF-1] - Cadastro de Cliente
O sistema deverá permitir a realização de cadastro de clientes, para tal será fornecido ao
menos o Nome do cliente, e os seguintes campos adicionais: RG,CPF e Data de Nascimento.
Durante a inserção o sistema deverá atribuir um identificador, código, único para o cliente.
Assim como registrar a o dia em que a operação foi realizada.
O sistema deverá exibir mensagens confirmando a inserção dosdados ou a existência de
algum erro durante a operação.
[RF-2] - Remoção de Cliente
O sistema deverá permitir a remoção de um cliente previamente inserido no sistema, esta
operação deverá estará disponível após a localização dos dados do cliente no sistema.
O sistema deverá exibir mensagens confirmando a remoção dos dados ou a existência de
algum erro durante a operação.
[RF-3] - Atualização de Cliente
O sistema deverá permitir a atualização dos dados de um cliente previamente cadastrado no
sistema, esta operação estará disponível após a localização dos dados do cliente no sistema.
O sistema deverá exibir mensagens confirmando a atualizaçãodos dados ou a existência de
algum erro durante a operação.
[RF-4] - Busca de Cliente
O sistema deverá permitir a realização da busca dos dados de um cliente através de seu
código ou nome.
O sistema deverá exibir mensagens informando a inexistência de um cliente com os dados
buscados, ou ainda a existência de algum erro durante a operação.
2.2 Endereço
[RF-5] - Cadastro de Endereço
O sistema deverá permitir a realização de cadastro de endereços para um cliente previa-
mente localizado, para tal será fornecido ao menos o Nome, Rua, Número e Bairro do endereço,
e os seguintes campos adicionais: Complemento e Dica.
O sistema deverá exibir mensagens confirmando a inserção dosdados ou a existência de
algum erro durante a operação.
[RF-6] - Remoção de Endereço
O sistema deverá permitir a remoção de um endereço previamente inserido no sistema
a partir de um cliente previamente localizado, esta operação deverá estará disponível após a
localização dos dados do endereço no sistema.
O sistema deverá exibir mensagens confirmando a remoção dos dados ou a existência de
algum erro durante a operação.
[RF-7] - Atualização de Endereço
O sistema deverá permitir a atualização dos dados de um endereço previamente cadastrado
no sistema, esta operação estará disponível após a localização dos dados do cliente e dos dados
do endereço em questão no sistema.
O sistema deverá exibir mensagens confirmando a atualizaçãodos dados ou a existência de
algum erro durante a operação.
4
[RF-8] - Busca de Endereço
O sistema deverá permitir a realização da busca dos dados de um endereço, a partir de um
cliente em especifico, através de seu nome ou rua.
O sistema deverá exibir mensagens informando a inexistência de um endereço com os
dados buscados, ou ainda a existência de algum erro durante aoperação.
2.3 Funcionário
[RF-9] - Cadastro de Funcionário
O sistema deverá permitir a realização de cadastro de funcionários, para tal será fornecido
ao menos o Nome do funcionário, e os seguintes campos adicionais: RG, CPF e Data de Nasci-
mento. Durante a inserção o sistema deverá atribuir um identificador, código, único para o
funcionário. Assim como registrar a o dia em que a operação foi realizada.
O sistema deverá exibir mensagens confirmando a inserção dosdados ou a existência de
algum erro durante a operação.
[RF-10] - Remoção de Funcionário
O sistema deverá permitir a remoção de um funcionário previamente inserido no sistema,
esta operação deverá estará disponível após a localização dos dados do funcionário no sistema.
O sistema deverá exibir mensagens confirmando a remoção dos dados ou a existência de
algum erro durante a operação.
[RF-11] - Atualização de Funcionário
O sistema deverá permitir a atualização dos dados de um funcionário previamente
cadastrado no sistema, esta operação estará disponível após a localização dos dados do fun-
cionário no sistema.
O sistema deverá exibir mensagens confirmando a atualizaçãodos dados ou a existência de
algum erro durante a operação.
[RF-12] - Busca de Funcionário
5
O sistema deverá permitir a realização da busca dos dados de um funcionário através de seu
código ou nome.
O sistema deverá exibir mensagens informando a inexistência de um funcionário com os
dados buscados, ou ainda a existência de algum erro durante aoperação.
2.4 Produto
[RF-13] - Cadastro de Produto
O sistema deverá permitir a realização de cadastro de produtos, para tal será fornecido ao
menos o Nome do produto e o grupo ao qual ele pertence, e ainda oseguinte campo adicional:
Descrição. Durante a inserção o sistema deverá atribuir um identificador, código, único para o
produto.
O sistema deverá exibir mensagens confirmando a inserção dosdados ou a existência de
algum erro durante a operação.
[RF-14] - Remoção de Produto
O sistema deverá permitir a remoção de um produto previamente inserido no sistema, esta
operação deverá estará disponível após a localização dos dados do produto no sistema.
O sistema deverá exibir mensagens confirmando a remoção dos dados ou a existência de
algum erro durante a operação.
[RF-15] - Atualização de Produto
O sistema deverá permitir a atualização dos dados de um produto previamente cadastrado
no sistema, esta operação estará disponível após a localização dos dados do produto no sistema.
O sistema deverá exibir mensagens confirmando a atualizaçãodos dados ou a existência de
algum erro durante a operação.
[RF-16] - Busca de Produto
O sistema deverá permitir a realização da busca dos dados de um produto através de seu
código ou nome.
O sistema deverá exibir mensagens informando a inexistência de um produto com os dados
buscados, ou ainda a existência de algum erro durante a operação.
6
2.5 Grupo
[RF-17] - Cadastro de Grupo
O sistema deverá permitir a realização de cadastro de grupos, onde os produtos serão sub-
divididos, para tal será fornecido o Nome do grupo e a categoria a qual ele pertence.
O sistema deverá exibir mensagens confirmando a inserção dosdados ou a existência de
algum erro durante a operação.
[RF-18] - Remoção de Grupo
O sistema deverá permitir a remoção de um grupo previamente inserido no sistema, esta
operação deverá estará disponível após a localização dos dados do grupo no sistema e somente
se não existir um produto que pertença ao grupo em questão.
O sistema deverá exibir mensagens confirmando a remoção dos dados, a existência de
algum produto no grupo em questão ou a existência de algum erro durante a operação.
[RF-19] - Atualização de Grupo
O sistema deverá permitir a atualização dos dados de um grupopreviamente cadastrado no
sistema, esta operação estará disponível após a localização dos dados do grupo no sistema.
O sistema deverá exibir mensagens confirmando a atualizaçãodos dados ou a existência de
algum erro durante a operação.
[RF-20] - Busca de Grupo
O sistema deverá permitir a realização da busca dos dados de um grupo através de seu
nome.
O sistema deverá exibir mensagens informando a inexistência de um grupo com a infor-
mação buscada, ou ainda a existência de algum erro durante a operação.
7
2.6 Categoria
[RF-21] - Cadastro de Categoria
O sistema deverá permitir a realização de cadastro de categorias, onde os grupos serão
subdivididos, para tal será fornecido o Nome da categoria.
O sistema deverá exibir mensagens confirmando a inserção dosdados ou a existência de
algum erro durante a operação.
[RF-22] - Remoção de Categoria
O sistema deverá permitir a remoção de uma categoria previamente inserida no sistema,
esta operação deverá estará disponível após a localização dos dados da categoria no sistema e
somente se não existir um grupo que pertença a categoria em questão.
O sistema deverá exibir mensagens confirmando a remoção dos dados, a existência de
algum grupo na categoria em questão ou a existência de algum erro durante a operação.
[RF-23] - Atualização de Categoria
O sistema deverá permitir a atualização dos dados de uma categoria previamente cadastrada
no sistema, esta operação estará disponível após a localização dos dados de uma categoria no
sistema.
O sistema deverá exibir mensagens confirmando a atualizaçãodos dados ou a existência de
algum erro durante a operação.
[RF-24] - Busca de Categoria
O sistema deverá permitir a realização da busca dos dados de um categoria através de seu
nome.
O sistema deverá exibir mensagens informando a inexistência de uma categoria com a
informação buscada, ou ainda a existência de algum erro durante a operação.
8
2.7 Tamanho
[RF-25] - Cadastro de Tamanho
O sistema deverá permitir a realização de cadastro de tamanhos, o qual será relacionado
com as categorias e os grupos, para tal será fornecido o Nome do tamanho.
O sistema deverá exibir mensagens confirmando a inserção dosdados ou a existência de
algum erro durante a operação.
[RF-26] - Remoção de Tamanho
O sistema deverá permitir a remoção de um tamanho previamente inserido no sistema, esta
operação deverá estará disponível após a localização dos dados do tamanho no sistema e se ele
não estiver relacionado com nenhuma categoria ou grupo.
O sistema deverá exibir mensagens confirmando a remoção dos dados ou a existência de
algum erro durante a operação.
[RF-27] - Atualização de Tamanho
O sistema deverá permitir a atualização dos dados de um tamanho previamente cadastrado
no sistema, esta operação estará disponível após a localização dos dados do tamanho no sistema.
O sistema deverá exibir mensagens confirmando a atualizaçãodos dados ou a existência de
algum erro durante a operação.
[RF-28] - Busca de Tamanho
O sistema deverá permitir a realização da busca dos dados de um tamanho através de seu
nome.
O sistema deverá exibir mensagens informando a inexistência de um tamanho com os dados
buscados, ou ainda a existência de algum erro durante a operação.
2.8 Preço
[RF-29] - Cadastro de Preço
O sistema deverá permitir a realização de cadastro de preços, para tal será fornecido o valor,
9
grupo e o tamanho ao qual ele pertence.
O sistema deverá exibir mensagens confirmando a inserção dosdados ou a existência de
algum erro durante a operação.
[RF-30] - Remoção de Preço
O sistema deverá permitir a remoção de um preços previamenteinserido no sistema, esta
operação deverá estará disponível após a localização dos dados do preço no sistema, e somente
se não existir nenhum relacionamento com o mesmo.
O sistema deverá exibir mensagens confirmando a remoção dos dados ou a existência de
algum erro durante a operação.
[RF-31] - Atualização de Preço
O sistema deverá permitir a atualização dos dados de um preçopreviamente cadastrado no
sistema, esta operação estará disponível após a localização dos dados do preço no sistema.
O sistema deverá exibir mensagens confirmando a atualizaçãodos dados ou a existência de
algum erro durante a operação.
[RF-32] - Busca de Preço
O sistema deverá permitir a realização da busca dos dados de um preço através das relações
do mesmo.
O sistema deverá exibir mensagens informando a inexistência de um preço com os dados
buscados, ou ainda a existência de algum erro durante a operação.
2.9 Divisões
[RF-33] - Cadastro de Divisões
O sistema deverá permitir a realização de cadastro de divisões que um produto pode sofrer,
para tal será fornecido uma quantidade de divisões e a categoria e o tamanho ao qual ela se
refere.
O sistema deverá exibir mensagens confirmando a inserção dosdados ou a existência de
algum erro durante a operação.
10
[RF-34] - Remoção de Divisões
O sistema deverá permitir a remoção de uma divisão previamente inserida no sistema, esta
operação deverá estar disponível após a localização dos dados da divisão no sistema.
O sistema deverá exibir mensagens confirmando a remoção dos dados ou a existência de
algum erro durante a operação.
[RF-35] - Atualização de Divisões
O sistema deverá permitir a atualização dos dados de uma divisão previamente cadastrada
no sistema, esta operação estará disponível após a localização dos dados da divisão no sistema.
O sistema deverá exibir mensagens confirmando a atualizaçãodos dados ou a existência de
algum erro durante a operação.
[RF-36] - Busca de Divisões
O sistema deverá permitir a realização da busca dos dados de uma divisão através das
relações da mesma.
O sistema deverá exibir mensagens informando a inexistência de uma divisão com os dados
buscados, ou ainda a existência de algum erro durante a operação.
2.10 Pedido
Para todas as operações sobre pedido o funcionário que esta logado no sistema realizando a
mesma deverá ser armazenado em um log.
[RF-37] - Cadastrar Pedido Mesa
O sistema deverá permitir o cadastro de pedido na mesa, também conhecido como no local,
para tal será fornecido os produtos do pedido e sua configuração - tamanho, divisões, observação
- assim como dados do cliente se assim ele quiser. Durante a inserção o sistema deverá atribuir
um identificador, código, único para o pedido.
O sistema deverá exibir mensagens confirmando a inserção dosdados ou a existência de
algum erro durante a operação.
11
[RF-38] - Cadastrar Pedido Telefone
O sistema deverá permitir o cadastro de pedido telefone, também conhecido como tele
entregas, para tal será fornecido os produtos do pedido e suaconfiguração - tamanho, divisões,
observação, - dados do cliente e local de entrega se assim elequiser. Durante a inserção o
sistema deverá atribuir um identificador, código, único para o pedido.
O sistema deverá exibir mensagens confirmando a inserção dosdados ou a existência de
algum erro durante a operação.
[RF-39] - Atualizar Pedido
O sistema deverá permitir a atualização dos dados de um pedido previamente cadastrada no
sistema, esta operação estará disponível após a localização dos dados do pedido no sistema.
O sistema deverá manter algum tipo de log da operação.
O sistema deverá exibir mensagens confirmando a atualizaçãodos dados ou a existência de
algum erro durante a operação.
[RF-40] - Cancelar Pedido
O sistema deverá permitir o cancelamento de um pedido previamente inserida no sistema,
esta operação deverá estar disponível após a localização dos dados do pedido no sistema. No
momento de sua efetivação uma justificativa deverá ser fornecida para tal operação.
O sistema deverá manter algum tipo de log da operação.
O sistema deverá exibir mensagens confirmando o cancelamento ou a existência de algum
erro durante a operação.
[RF-41] - Fechar Pedido
O sistema deve possibilitar o fechamento do pedido, que é o momento do pagamento, esta
operação deverá estar disponível após a localização do pedido no sistema.
O sistema deverá exibir mensagens confirmando o fechamento ou a existência de algum
erro durante a operação.
[RF-42] - Entregar Pedido
O sistema deverá possibilitar a associação de um funcionário, previamente cadastrado no
12
sistema, com um pedido telefone, também previamente cadastrado no sistema, de modo que
este funcionário é a pessoa que efetuou a entrega na residência do cliente.
O sistema deverá exibir mensagens confirmando esta associação ou a existência de algum
erro durante a operação.
[RF-43] - Busca Pedido
O sistema deverá permitir a realização da busca dos dados de um pedido através de seu
código.
O sistema deverá exibir mensagens informando a inexistência de um pedido com os dados
buscados, ou ainda a existência de algum erro durante a operação.
[RF-44] - Impressão Pedido
O sistema deverá permitir a impressão de todos os dados constantes em um pedido, previa-
mente inserido no sistema e estando o mesmo sendo visualizado pelo atendente, em duas vias:
uma de caráter cupom fiscal, com todos os dados, e outra com função de facilitar o trabalho da
cozinha, com o código do pedido e os produtos constantes no mesmo e suas características -
tamanho, divisões.
O sistema deverá exibir mensagens na existência de algum erro durante a operação.
2.11 Relatórios
[RF-45] - Pedidos Fechados
O sistema deverá listar os pedidos fechados entre um períodofornecido pelo usuário, ou
por funcionário que realizou a operação.
O sistema deverá exibir mensagens na existência de algum erro durante a operação.
[RF-46] - Pedidos Em Aberto
O sistema deverá listar os pedidos que não estão fechados e que não tenham sido cancelados
entre um período fornecido pelo usuário, ou por funcionárioque realizou a operação.
O sistema deverá exibir mensagens na existência de algum erro durante a operação.
13
[RF-47] - Pedidos Cancelados e ou Atualizados
O sistema deverá listar os pedidos cancelados ou e atualizados entre um período fornecido
pelo usuário, ou por funcionário que realizou a operação.
O sistema deverá exibir mensagens na existência de algum erro durante a operação.
[RF-48] - Pedidos Entregues
O sistema deverá listar os pedidos entregues entre um período fornecido pelo usuário, ou
por funcionário que realizou a operação.
O sistema deverá exibir mensagens na existência de algum erro durante a operação.
14
Capítulo 3
Modelagem Organizacional i*
Nesta seção serão apresentados os Diagramas de Dependênciae Razões Estratégicas, SD e
SR, e suas descrições.
3.1 Diagrama de Dependências Estratégicas (SD)
Na figura 3.1 temos o Diagrama de Dependências Estratégicas (SD).
Segue abaixo na tabela 3.1 que contém as dependências entre os atores do sistema, esta
tabela visa facilitar a visualização das dependências.
Numa visão mais geral do sistema, o atorCliente pode interagir com o sistema de duas
formas, quando faz um pedido por telefone aoAtendente ou no estabelecimento aoGarçom.
Esses por fim interagem com oSistema Gestoratendendo as solicitações doCliente.
O Objetivo principal do cliente para com o sistema é a realização de um pedido, que pode
ser satisfeito pelo sistema de duas formas diferentes. O pedido pode ser realizado por telefone
Pedido Telefonee no próprio estabelecimentoIniciar Pedido Mesa. Além do Pedido, oCliente
também pode verificar o preço de um dos produtos do estabelecimento através do recursoVer-
ificar Preço Telefone. Quando esta no estabelecimento o cliente pode solicitar novos produtos
e finalizar a venda, estas duas possibilidades são representadas respectivamente pelos objetivos
Adicionar Produto ao PedidoeFinalizar Pedido Mesaquando são solicitados aoGarçom eles são
representados pelas tarefasAtualizar Pedido eSolicitar Valor Final . Para realizar estes objetivos
o cliente espera eficiência no atendimento por parte do garçom, esta eficiência é representada
pelo objetivo-softEficiência no Atendimento. Ao final de cada solicitação de adição de um
produto ao pedido oGarçom solicita aoAtendenteos produtos, representada no diagrama pela
tarefaSolicitar Pedido. Se o cliente estiver solicitando um pedido via telefone além das opções já
Figura 3.1: Diagrama de Dependências Estratégicas(SD)
citadas ele pode querer modifar o seu pedido, está opção e representada pelo objetivoModificar
Pedido. Durante o processo de pedido via telefone o cliente espera uma agilidade doAtendente,
a representamos pelo objetivo-softAgilidade.
16
Depender Dependee Tipo de Dependência Descrição DependênciaCliente Garçom Objetivo Adicionar Produto ao Pedido
Iniciar Pedido MesaFinalizar Pedido Mesa
Objetivo-Soft Eficiência no AtendimentoAtendente Objetivo Pedido Telefone
Modificar PedidoRecurso Verificar Preço TelefoneObjetivo-Soft Agilidade
Atendente Sistema Gestor Objetivo Emitir RelatórioCRU
Tarefa Efetivar PedidoRealizar ModificaçãoFinalizar Pedido
Recurso Busca no Banco de DadosImprimir Cupom Fiscal
Objetivo-Soft ConfiabilidadeFlexibilidadeUsabilidade
Garçom Atendente Tarefa Solicitar Valor FinalSolicitar PedidoAtualizar Pedido
Tabela 3.1: Dependencias Entre os Atores no SD
O Atendentepode realizar uma busca no banco de dados, esta possibilidade é representada
pelo recursoBusca no Banco de Dados. Outro recurso éImprimir Cupom Fiscal a partir desse o
atendente obtém um cupom fiscal com os produtos vendidos e os dados do cliente que os solici-
tou. Como objetivos oAtendentetemEmitir Relatórios que possibilita a emissão de um relatório
especifico sobre as vendas eEfetuar Cadastro cadastrar produtos, funcionários ou clientes no
banco de dados. OAtendenterealiza também algumas solicitações, são elas a finalizaçãode um
pedido feito por um cliente e modificações nele realizadas, esteja o cliente as solicitando via
telefone ou no próprio estabelecimento. Essas opções são representadas respectivamente pelas
tarefasFinalizar Pedido e Realizar Modificação. Além das tarefas, recursos e objetivos já cita-
dos o Atendente espera do sistemaConfiabilidade, ou seja, garantias sobre os dados armazena-
dos,Flexibilidade caracterizada por mudanças que podem ser realizadas em diversos aspectos
e Usabilidade caracterizada pela facilidade na utilização do sistema. Essas possibilidades são
representadas pelos objetivos-softConfiabilidade, Flexibilidade e Usabilidade.
17
3.2 Diagrama de Razões Estratégicas (SR)
Realizamos a expansão nos atoresSistema Gestor, AtendenteeGarçom. Na figura 3.2 temos
o Diagrama de Razões Estratégicas (SR)
Ao expandirmos o atorGarçom verificamos que o objetivoAdicionar Produto ao Pedido,
consiste na tarefaDetalhamento da Modificação. Nesta tarefa pode-seAdicionar Produto ou
Remover Produto. O objetivoFinalizar Pedido Mesana verdade consiste no recursoValor Final
do Pedido.
Na expansão do Atendente percebemos que o objetivoPedido Telefonetrata-se da adição
de Produtos a venda, dessa forma foi gerada a tarefaAdicionar Produtos a Venda. O objetivo
Modificar Pedido também foi transformado em uma tarefa, se trata da tarefaDetalhamento da
Modificação assim como no atorGarçom pode-seAdicionar Produto ou Remover Produto da
venda.
Por fim, ao expandirmos o atorSistema Gestorverificamos que o recursoBusca no Banco
de Dados, gera a tarefaDetalhamento da Busca, está tarefa é decomposta em outras oito tarefas
disjuntas:Grupo para busca de grupo,Categoria para busca de categoria,Tamanho para busca
de tamanhos,Funcionário para busca de funcionario,Cliente para busca de clientes,Endereço
para busca de endereços,Produto para busca de produtos ePedido para buscar pedidos. O
objetivoEmitir Relatório gera a tarefaDetalhe do Relatório, essa tarefa é decomposta em quatro
recursos onde um deles é utilizado, são eles: relatório do pedidos fechados, representado pelo
recursoPedidos Fechados, em abertosPedidos Abertos, cancelados e ou atualizadosPedidos
Cancelados e ou Atualizadose entreguesPedidos Entregues.
O objetivoCRU, consiste na tarefaDetalhamento CRUestá tarefa é decomposta em outras
dez tarefas ambas disjuntas:Grupo para CRU de Grupo,Categoria para CRU de Categoria ,
Tamanho para CRU de Tamanho,Funcionário para CRU de Funcionários,Cliente para CRU de
Clientes,Endereçopara CRU de Endereço,Produto para CRU de Produto,Pedido para CRU
de Pedido,Divisoespara CRU de Divisoes ePreço para CRU de Preço. O recursoImprimir
Cupom Fiscal gera a tarefaVias, que visa fornecer ao sistema o numero de vias de Cupom
Fiscal necessárias. Temos, por fim, a tarefaRealizar Modificaçõesesta tarefa passa a ser repre-
sentada pela tarefaDetalhe da Modificação, esta assim com para os atoresAtendentee Garçom
e decomposta nasRemover Produtoe Adicionar Produto .
18
Figura 3.2: Diagrama de Razões Estratégicas(SR)
19
Capítulo 4
Requisitos Não-Funcionais
4.1 Requisitos de Processo
[RNF/PROC-1]
O sistema deverá ser desenvolvido de forma a ser compatível com o sistema operacional
Windows.
[RNF/PROC-2]
O programa deverá utilizar um sistema de gerenciamento de banco de dados.
[RNF/PROC-3]
Para a implementação do sistema, deverá ser utilizada a linguagem orientada a objetos Java,
pois ela proporciona uma interface amigável para o usuário efacilidade de manutenção.
[RNF/PROC-4]
O sistema deverá possuir uma documentação impressa que especifique sua utilização pelos
funcionários do restaurante que irão operá-lo.
[RNF/PROC-5]
É necessário um histórico do sistema, que permita a emissão de relatórios detalhados do
controle de vendas e cadastros do restaurante.
4.2 Requisitos de Usabilidade
[RNF/USA-6]
O sistema deverá possuir uma interface amigável e clara, visando facilitar a interação do
usuário (funcionário do restaurante) com o sistema.
[RNF/USA-7]
As mensagens de erro apresentadas ao usuário pelo sistema deverão ser claras e precisas.
4.3 Requisitos de Segurança
[RNF/SEG-8]
O sistema deve garantir a integridade dos dados armazenados, através do uso de um
gerenciador de banco de dados.
[RNF/SEG-9]
Os dados armazenados terão uma cópia atualizada (backup) a fim de evitar a perda de
informações relativas ao controle do restaurante. Essa cópia será realizada na própria máquina
cujo sistema está instalado.
4.4 Requisitos de Performance
[RNF/PER-10]
É esperado que o sistema tenha um tempo de resposta razoavelmente rápido no cadastro e
busca de clientes, produtos e funcionários, efetuados pelousuário do sistema (funcionário do
restaurante).
[RNF/PER-11]
O sistema deve possuir espaço disponível em disco para armazenar os dados de todos os
clientes e funcionários do restaurante, bem como a descrição dos produtos os grupos entre
21
outros dados.
4.5 Grafo SIG
O grafo SIG (Softgoal Interdependency Graph), que ilustra ointer-relacionamento entre os
requisitos não funcionais, é apresentado na próxima página.
Figura 4.1: Softgoal Interdependency Graph(SIG)
Por meio do SIG, observa-se como os requisitos não funcionais são decompostos e opera-
cionalizados. Segue uma explicação descritiva do grafo apresentado.
22
A Usabilidadedo sistema é um softgoal composto pelas operacionalizações: umainterface
amigávele umaboa identificação de erros, que possibilitam o fácil acesso ao sistema por usuários
leigos. Ela também associa-se ao softgoalDocumentação, que garante a criação de um manual
impresso orientando o usuário do sistema.
A Documentação, por sua vez, contribui para amanutençãodo sistema, uma vez que os
problemas podem ser mais facilmente identificados e tratados.
A usabilidade influencia negativamente nocusto previsto para o desenvolvimento do sistema,
visto que é necessária a contratação de designers, que são profissionais especializados, para
a criação de uma interface adequada aos usuários. Esta interface agradável também pode
confrontar-se com uma interface consistente, causando atraso notempo de respostado sistema.
O softgoalPortabilidade é alcançado pela junção dos softgoals compatibilidade com oWin-
dows, gerenciador debanco de dadose utilização da linguagem de programaçãoJava. A portabil-
idade ajuda nausabilidadedo sistema, proporcionando uma interface amigável e de fácil acesso
para o usuário.
A Performancedo sistema associa-se ao softgoalusabilidadee é operacionalizada através da
rapidez no tempo de respostado sistema, doespaço livre em discopara o armazenamento dos
cadastros e pedidos do restaurante.
Quanto melhor a performance do sistema, sua usabilidade poderá ser prejudicada, visto
que serão necessários mais recursos para o funcionamento dosistema. Quanto à rapidez de
processamento, é preciso um tempo de resposta satisfatóriotanto para as operações efetuados
pelo usuário do sistema como para a utilização do site pelo cliente. O site terá capacidade para
diversos acessos simultâneos à página.
A Segurançado sistema é operacionalizada pelaintegridade dos dados armazenados. O
backup dos dados contribui negativamente para o softgoalespaço livre em disco, visto que ele
ocupará o dobro de armazenamento.
O Custo de implantação do sistemaé um softgoal alcançado pela compra das máquinas
necessárias, pelo pagamento dos programadores visto que o software para o desenvolvimento é
freeware e não é necessário adquirir licença.
O softgoalManutençãodo sistema associa-se com o softgoalhistórico do sistema, que apre-
senta relatórios retirados do banco de dados.
23
4.6 Recursos Externos
4.6.1 Restrições econômicas
[RNF/ECO-12]
O custo do desenvolvimento e implantação do sistema (não incluindo os custos de
manutenção) não deverá ultrapassar em mais de 5% o valor previsto em seu estudo de
viabilidade.
24
Capítulo 5
Casos de Uso
Figura 5.1: Diagrama de Casos de Uso
[Caso de Uso 1] - Adição de produto ao pedido
Ator(es): Clientes, garçons e atendentes
Fluxo de Eventos:
Pegue número do pedido;
Se o pedido não estiver aberto:
Extended: Inicia pedido;
Adicione o produto ao pedido;
[Caso de Uso 2] - Alteração de cadastro de cliente
Ator(es): Atendente
Fluxo de Eventos:
Pegue o CPF do cliente;
Se houver um cliente cadastrado nesse CPF:
Altere os dados do cliente;
Senão: Mostre mensagem de erro.
[Caso de Uso 3] - Alteração de cadastro de funcionário
Ator(es): Atendente
Fluxo de Eventos:
Pegue o número do funcionário;
Se houver um funcionário cadastrado nesse número:
Altere os dados do funcionário;
Senão: Mostre mensagem de erro.
[Caso de Uso 4] - Alteração de cadastro de produto
Ator(es): Atendente
Fluxo de Eventos:
Pegue o número do produto;
Se houver um produto cadastrado nesse número:
Altere os dados do produto;
Senão: Mostre mensagem de erro.
[Caso de Uso 5] - Consulta de dados de clientes
Ator(es): Atendente
Fluxo de Eventos:
Pegue o CPF do cliente;
Se houver um cliente cadastrado nesse CPF:
Mostre os dados do cliente;
26
Senão: Mostre mensagem de erro.
[Caso de Uso 6] - Consulta de dados de funcionários
Ator(es): Atendente
Fluxo de Eventos:
Pegue o número do funcionário;
Se houver um funcionário cadastrado nesse número:
Mostre os dados do funcionário;
Senão: Mostre mensagem de erro.
[Caso de Uso 7] - Consulta de dados de produtos
Ator(es): Atendente
Fluxo de Eventos:
Pegue o número do produto;
Se houver um produto cadastrado nesse número:
Mostre os dados do produto;
Senão: Mostre mensagem de erro.
[Caso de Uso 8] - Consulta de dados de vendas
Ator(es): Atendente
Fluxo de Eventos:
Pegue o número do cupom fiscal;
Se houver um cupom fiscal do número:
Mostre os dados da venda;
Senão: Mostre mensagem de erro.
[Caso de Uso 9] - Cadastro de clientes
Ator(es): Atendente
Fluxo de Eventos:
Pegue os atributos do cliente (CPF, telefone, nome, endereço);
Adicione o cliente ao sistema.
27
[Caso de Uso 10] - Cadastro de funcionários
Ator(es): Atendente
Fluxo de Eventos:
Pegue os atributos do funcionário (documentação, telefone, nome, endereço);
Adicione o funcionário ao sistema.
[Caso de Uso 11] - Cadastro de produtos
Ator(es): Atendente
Fluxo de Eventos:
Pegue os atributos do produto (nome, descrição, preço);
Adicione o produto ao sistema.
[Caso de Uso 12] - Efetivar pedido por telefone
Ator(es): Atendente
Fluxo de Eventos:
Pegue CPF do cliente;
Se o cliente não estiver cadastrado:
Extended: Cadastro de cliente.
Pegue os atributos do pedido;
Efetive o pedido;
[Caso de Uso 13] - Emissão de cupom de controle interno
Ator(es): Atendente
Fluxo de Eventos:
Pegue o número do pedido;
Se houverem produtos não industrializados no pedido:
Selecione os produtos a serem produzidos;
Imprima o cupom de controle interno;
[Caso de Uso 14] - Emissão de cupom fiscal
28
Ator(es): Atendente
Fluxo de Eventos:
Pegue o número do pedido;
Se o pedido já estiver finalizado:
Imprima cupom fiscal.
[Caso de Uso 15] - Emissão de relatório de funcionários
Ator(es): Atendente
Fluxo de Eventos:
Pegue o número do funcionário;
Imprima o relatório que descreve suas vendas;
[Caso de Uso 16] - Emissão de relatório de vendas
Ator(es): Atendente
Fluxo de Eventos:
Imprima o relatório de todas as vendas realizadas;
[Caso de Uso 17] - Emissão de relatório do dia
Ator(es): Atendente
Fluxo de Eventos:
Pegue o dia;
Imprima relatório de vendas do dia;
[Caso de Uso 18] - Faz pedido por telefone
Ator(es): Cliente
Fluxo de Eventos:
Atendente pega os CPF do cliente;
Se o cliente não estiver cadastrado:
Extended: Cadastro de cliente;
Atendente pega os dados do pedido;
29
[Caso de Uso 19] - Faz pedido no local
Ator(es): Cliente
Fluxo de Eventos:
Se o Cliente quiser se identificar: Atendente pega os CPF do cliente;
Se o cliente não estiver cadastrado:
Extended: Cadastro de cliente;
Atendente pega os dados do pedido;
[Caso de Uso 20] - Finaliza pedido
Ator(es): Cliente, Garçom e Atendente
Fluxo de Eventos:
Pegue o número do pedido;
Finalize pedido;
Mostre valor final;
[Caso de Uso 21] - Inicia pedido
Ator(es): Cliente, Garçom e Atendente
Fluxo de Eventos:
Abra um novo pedido;
[Caso de Uso 22] - Remoção de cliente
Ator(es): Atendente
Fluxo de Eventos:
Pegue CPF do cliente;
Exclua o cadastro do cliente;
[Caso de Uso 23] - Remoção de funcionário
Ator(es): Atendente
Fluxo de Eventos:
Pegue o número do funcionário;
30
Exclua o cadastro do funcionário;
[Caso de Uso 24] - Remoção de produto
Ator(es): Atendente
Fluxo de Eventos:
Pegue o número do produto;
Exclua o cadastro do produto;
[Caso de Uso 25] - Remoção de produto do pedido
Ator(es): Cliente, Garçom e Atendente
Fluxo de Eventos:
Pegue o número do pedido;
Pegue o número do produto;
Exclua o produto do pedido;
31
Capítulo 6
Diagrama de Classes
Abaixo se encontra a figura com o diagrama de classes do sistema. Uma breve descrição
textual das classes apresentadas no diagrama segue na próxima pagina:
Pessoa
A classe Pessoa possui os camposid, um identificador único gerado automaticamente,
nomeque contem o seu nome,rg que contem o seu RG,cpf que contem seu CPF e o campo
datanascimentoque contem a data de nascimento da pessoa.
Cliente
A classe Cliente herda todos os campos da classe Pessoa além deum campoclientedesde
que contem a data de cadastro do Cliente e o campocódigoque contem um código único.
Funcionário
A classe Funcionário herda todos os campos da classe Pessoa além de um campofuncionar-
iodesdeque contem a data de cadastro do Funcionário e o campocódigoque contem um código
único.
Produto
A classe Produto possui os camposid, um identificador único gerado automaticamente,
nomeque contem o seu nome,descriçãoque contem uma descrição breve do produto ecódigo
um código pra identificação do produto que será utilizado para busca e inserção no pedido.
Grupo
Figura 6.1: Diagrama de Classes
A classe Grupo possui os camposid, um identificador único gerado automaticamente e
nomeque contem o seu nome para futura busca.
33
Tamanho
A classe Tamanho possui os camposid, um identificador único gerado automaticamente e
nomeque contem o seu nome para futura busca.
Categoria
A classe Categoria possui os camposid, um identificador único gerado automaticamente e
nomeque contem o seu nome para futura busca.
Divisões
A classe Divisões possui o campodivideemque é utilizado para se definir em quantas partes
um Produto pertencente ao um Grupo e Categoria pode ser dividido.
Preço
A classe Divisões possui o campopreço que é utilizado para se definir o preço de um
Produto pertencente ao um Grupo e Tamanho.
SubItem
A classe SubItem possui os camposid um identificador único,quantidadeque representa
a quantidade de um produto,subtotalo valor parcial do subitem edescriçãoque contem uma
descrição do subitem.
Item
A classe Item possui os camposid um identificador único edivisoesque representa a
quantidade de divisoes escolhidas para um produto a ser inserido no pedido.
Pedido
A classe Pedido possui os camposid um identificador único,datapedidoa data de realização
do pedido, umcódigopra identificação e umaobservação.
PedidoMesa
34
A classe PedidoMesa herda todos os atributos da classe Pedido e possui o camponumero
que contem o numero da mesa do estabelecimento de onde o pedido foi realizado.
PedidoTelefone
A classe PedidoTelefone herda todos os atributos da classe Pedido e possui o campotelefone
que contem o telefone de onde o pedido foi realizado.
PedidoCancelado
A classe PedidoTelefone herda todos os atributos da classe Pedido e possui o campos
datacancelamentoque contem a data do cancelamento do pedido emotivoque contem o motivo
do cancelamento.
PedidoFechado
A classe PedidoFechado herda todos os atributos da classe Pedido e possui o campo
datafechamentoque contem a data de fechamento do pedido.
PedidoEntregue
A classe PedidoFechado herda todos os atributos da classe PedidoTelefone e possui o
campodataentregaque contem a data de entrega do pedido.
Endereço
A classe Endereço possui os camposid um identifador único do endereço,nome uma
identificação para busca do endereço,rua a rua do local,numerocom o numero do local,bairro
o bairro do local,complementoum complemento ao endereço edica uma dica.
35
Capítulo 7
Conclusão
A especificação de requisitos e também a modelagem orientadaa objetos apresentados neste
documento nos mostrou que o sistema consiste na comunicaçãoentre o cliente e a empresa, de-
pendendo também em grande parte do banco de dados para armazenagem de dados de clientes,
produtos e também das vendas.
Também é importante enfatizar que esse sistema, deve facilitar para os clientes do estab-
elecimento uma maior facilidade na hora da realização de um pedido, seja ele por telefone, via
internet e até mesmo se o cliente estiver no estabelecimento.
Finalmente o sistema visa suprir os requisitos que foram apresentados pelos funcionários
durante o período de entrevista e coleta dos dados.