FaciO Pedido

5W2H

• Nome do Projeto: FaciO Pedido

What

• Qual o objetivo deste projeto?

O FaciO Pedido é uma aplicação que pretende resolver certos problemas de um restaurante que atende pedidos por entregas. A aplicação serviria tanto para melhorar a organização interna do restaurante e seu sistema de pedidos, quanto para oferecer maior comodidade ao cliente que, uma vez logado no sistema, poderá fazer seus pedidos do conforto de sua casa, através de uma interface simples e amigável do celular, que ainda pode dar retornos interessantes ao usuario como tempo estimado de espera.

Além disso, o usuario pode deixar feedbacks sobre o restaurante, elogiando uma entrega rápida ou uma comida saborosa, fazendo da aplicação um portal de marketing interessante para restaurantes.

• Quais os maiores desafios, na sua opinião, para se realizar este trabalho?

Compreender exatamente quais são os requisitos funcionais de uma aplicação desse tipo para um restaurante.

• Quais os conhecimentos básicos que devemos ter para se implementar este projeto?

A aplicação que será apresentada ao usuario final (cliente do restaurante) será um app para smartphone, portanto devemos ter conhecimento desenvolvimento para tais aparelhos. Para melhor abrangencia de mercado, além da noção básica de desenvolvimento, são necessarios conhecimentos da API específica de cada sistema operacional atualmente utilizado (devemos ter versões para iOS, Android, Windows Mobile e outros que vierem a ser importantes).

Já para a aplicação que será implementada nos restaurantes parceiros, devemos ter conhecimento de ferramentas de desenvolvimento de aplicações comerciais. Além disso, serão necessarios conhecimentos de banco de dados e conexão deste com as outras aplicações via internet.

• Quais soluções similares existem no mercado?

Durante nosso Benchmarking encontramos o iFood. Entretanto, a solução ainda não abrange nossa cidade e região, portanto um diferencial que teriamos dessa outra solução seria simplesmente a presença no mercado local, que é bastante amplo.

Why

• Porque é interessante desenvolver este projeto?

Um aplicativo que ofereça a possibilidade de pedir comida no seu restaurante favorito com apenas alguns cliques na tela de um smartphone e que ainda ofereça um bom feedback ao cliente como por exemplo número de pedidos na fila e tempo estimado de espera, é uma excelente idéia em meio a uma sociedade que busca evoluir em praticidade até nas tarefas mais simples.

É um projeto tão interessante que já é amplamente usado em outras regiões do Brasil, porém não conta com nenhum parceiro em nossa região, o que nos mostra um grande mercado sendo desperdiçado nesse sentido.

• Porque deve usar a tecnologia escolhida?

Escolhemos apresentar o aplicativo para o usuario final como um App de smartphone pois estes são produtos cada vez mais comuns no bolso da população e em geral usuarios destes são grandes consumidores de produtos que substituem tecnologias que já existem por outras mais práticas.

Who

• Quem pode se beneficiar deste projeto?

Tanto restaurantes quanto clientes dos mesmos podem beneficiar-se do sistema. Os restaurantes terão em suas mãos uma solução que lhes permitirá fazer uma boa organização interna de pedidos de entrega e além disso, terão uma boa oportunidade de mostrar serviço na entrega de qualidade e beneficiarem-se dos feedbacks positivos dos clientes no aplicativo.

Os clientes terão a ganhar na praticidade em fazer pedidos nos seus restaurantes preferidos bem como terão vantagens quando quiserem pedir algo em um novo restaurante, podendo antes de fazer o pedido checar as avaliações dos clientes sobre a comida e tempo de entrega.

• Quem poderá operar o sistema?

No lado do restaurante, deverão haver responsaveis por receber os pedidos e encaminhá-los para a entrega (os mesmos que recebem entregas via telefone), bem como um administrador que terá acesso a contabilidade geral e todos os dados que venham a ser interessantes ao dono do restaurante.

Do lado do cliente, qualquer um que tenha acesso a um smartphone poderá cadastrar-se gratuitamente e após preencher dados de entrega, pagamento e afins, fazer pedidos de onde quer que esteja.

• Quem deverá participar do desenvolvimento do sistema?

Para o desenvolvimento devem ser contratados programadores que dominem as tecnologias de desenvolvimento mencionadas em um topico acima. É interessante que também contrate-se profissionais especializados em interfaces, de forma a otimizar a experiencia ao usuario, que deve ser a mais fácil e agradavel quanto possivel.

Where

• Onde os dados serão inseridos?

O usuario final (cliente do restaurante) irá inserir seus dados e pedidos através de um smartphone, enquanto o restaurante irá dispor de uma aplicação para desktop.

• Onde os dados serão externalizados, publicados?

Todas as informações inseridas ambos tipos de usuarios passarão serão armazenadas em um servidor externo de onde podem ser publicadas através do aplicativo para smartphone ou do aplicativo para desktop (no restaurante) dependendo do dado e do interesse da aplicação naquele dado.

• Onde esta aplicação poderá ser usada?

Qualquer restaurante que disponha de um computador simples com acesso a internet pode tornar-se parceiro do sistema e qualquer usuario com um smartphone com acesso a internet e que tenha um restaurante parceiro próximo a ele poderá fazer pedidos.

• Onde as informações serão armazenadas?

Como o objetivo é conseguir o maior número de restaurantes parceiros quanto for possivel, pode ser interessante e menos custoso que armazene-se todos os dados necessários numa nuvem.

• Onde o software deverá ser hospedado?

Em cada restaurante parceiro será instalada a aplicação para uso interno do restaurante e o aplicativo para o usuario final pode ser disponibilizado através das lojas virtuais de aplicativos dos sistemas operacionais de smartphones (App Store da Apple e Play Store da Google, por exemplo).

When

• Em quanto tempo pretende desenvolver o sistema?

Dadas as pequenas proporções das duas aplicações que comporão esse sistema, é razoavel fazer uma previsão de 3 meses de desenvolvimento continuo e paralelo (trabalhando-se no desenvolvimento das 3 frentes propostas na divisão do sistema ao mesmo tempo)

• Quais serão as fases e em quanto tempo cada uma?

Apesar de envolver um certo número de requisitos e funcionalidades, o desenvolvimento de um produto final que possa ir pro mercado não necessitará de mais do que tres etapas :

• Desenvolvimento inicial - 1 mes;

• Closed beta - Testes feitos com um restaurante ficticio e usuarios sendo os proprios desenvolvedores. Nessa fase ainda pode-se identificar requisitos não pensados anteriormente e implementá-los facilmente - 1 Mes

• Open beta - Nesse momento pode-se fazer parceria com algum restaurante e abrir um open beta para alguns usuarios selecionados. Outra possibilidade interessante é contratar algum serviço de comunidades de teste, como o "uTest", para encontrar bugs de forma mais rápida. - 1 mes

How

• Como será dividido o desenvolvimento do sistema?

O sistema será dividido em 3 linhas de desenvolvimento. A primeira tratará do código do aplicativo para smartphone e da implementação de suas funcionalidades, bem como a portabilidade para diferentes sistemas. A segunda será similar a primeira, mas pensando na aplicação para desktop que atenderá ao lado dos restaurantes. E finalmente a terceira que tratará das interfaces pensando na melhor organização das mesmas para otimizar a experiencia.

• Como será feita a entrada de dados?

Através da tela de toque no caso e envio para o servidor via internet móvel ou fixa no caso dos smartphones e teclado/mouse e envio para o servidor via conexão com a internet, no caso dos restaurantes.

• Como será feita a saída de dados?

A saída será apresentada através das interfaces disponiveis no restaurante e para o usuario em seu smartphone, permitindo em alguns sentidos a comunicação entre os dois.

FUNCIONALIDADES PARA O CLIENTE :

• Como será o procedimento para a 1a. funcionalidade?

• Cadastro de Cliente :
  • Verifica localização geografica do smartphone. Caso existam restaurantes parceiros próximos ao cliente, prossegue normalmente. Caso contrario, informa o usuario de que o serviço ainda não tem parceiros próximos e oferece possibilidade de um cadastro para demonstrar interesse no serviço (requisita apenas nome e email para contato futuro)
  • Caso existam parceiros próximos, solicita dados pessoais, endereço de entrega e forma de pagamento preferencial (opcional, pode ser concluido no momento da entrega)

• Como será o procedimento para a 2a. funcionalidade?

• Procurar restaurantes próximos :
  • Faz novamente verificação da localização geografica (o cliente pode ter se mudado ou estar em viagem);
  • Lista todos os restaurantes próximos ao cliente;

• Como será o procedimento para a 3a. funcionalidade?

• Fazer pedido em restaurante :
  • Após escolher o restaurante da lista de restaurantes proximos, o cliente pode fazer um pedido naquele restaurante.
  • As informações do pedido devem conter : todos os dados do cliente inclusive de pagamento, que devem ser preenchidos caso não tenham sido ainda, todos os dados do prato selecionado e uma "senha" na fila de pedidos que é individual a cada restaurante e diz respeito a quantos pedidos ainda existem na frente daquele
  • Baseado nessa senha e no tempo médio de preparo de cada prato e no tempo de entrega, o sistema retorna para usuario um tempo médio de espera daquele pedido.

• Como será o procedimento para a 4a. funcionalidade?

• Verificar status do pedido
  • Após pedir, é possivel o usuario verificar o status do pedido que pode ser mudado no restaurante, que vai de "Não recebido" (quando o restaurante ainda não abriu o pedido), "Na cozinha" (quando o restaurante ja abriu o pedido e o enviou para a cozinha) e "Em entrega" (quando o pedido ja estiver pronto e puder ser enviado).

• Como será o procedimento para a 5a. funcionalidade?

• Dar feedback
  • Após receber seu pedido, o usuario pode voltar a pagina do restaurante e informar sobre a qualidade da entrega e do produto, além de dar uma avaliação em nota para o restaurante

FUNCIONALIDADES PARA O RESTAURANTE :

• Como será o procedimento para a 1a. funcionalidade?

• Cadastrar prato
  • Através desta função o restaurante pode inserir novos pratos ao seu cardápio.
  • Nessa função deve se incluir informações como ingredientes, preço, nome e um tempo médio de preparo, que será utilizado para estimar o tempo de entrega

• Como será o procedimento para a 2a. funcionalidade?

• Verificar pedidos
  • Uma vez iniciado o expediente e aberto o sistema, essa funcionalidade será executada automaticamente de tempo em tempo (a cada alguns segundos) e exibirá algum tipo de alerta quando encontrar um novo pedido na fila de pedidos

• Como será o procedimento para a 3a. funcionalidade?

• Alterar status de pedido
  • Mais uma ferramenta de feedback para o usuario, para que ele tenha mais controle sobre o processo de entrega. Os status do pedido podem ser "Nao recebido", "Na cozinha" e "Em entrega" e cabe ao restaurante alterar esses status para dar um feedback ao usuario sobre o atual estágio do processo

• Como será o procedimento para a 4a. funcionalidade?

How much

• Quanto deverá custar o sistema?
  • Estimativa inicial de 10 mil reais investidos em :
  • Crowdtesting : a partir de 990 reais;
  • Desenvolvedores e designers : preço fixo a ser combinado pelo trabalho;
  • Servidores : é possivel usar do serviço de armazenamento da Amazon gratuitamente por um periodo inicial e de baixa frequencia de acesso, e é possivel comprar espaço de armazenamento e outras ferramentas por preços razoavelmente acessiveis, dadas as proporções pequenas da base de dados

• Quantas pessoas deverão ser usadas?
  • A principio, a equipe de desenvolvimento seria composta por 3 pessoas mais uma possivel comunidade de crowdtesting e os próprios projetistas.

• Qual deverá ser o preço de aquisição do seu software para o usuário final?
  • O software pode ser disponibilizado gratuitamente para o usuario final (cliente do restaurante) e pode ser vendido por 2 mil reais + taxa de manutenção mensal (opcional) para os restaurantes.

DFD

DER

DD

• CadCliente
  • CPF : Cadastro de Pessoa Física
    • Deve-se validar a inserção através do algoritmo da “Regra dos 9”
  • Email: endereço eletrônico que deve conter com certeza um @ na sua composição
  • Senha: deve conter pelo menos 6 dígitos e pelo menos um caractere numérico e um não-numérico
  • idCliente : numero de identificação do cliente que é atribuido a ele pelo sistema no ato do cadastro. Servirá apenas de identificador interno. Deve conter, a principio, 6 dígitos numéricos

• CadPedido
  • idPedido : Identificador numérico com, a principio, 6 digitos, criado a cada novo pedido.

• ItensPedido
  • Como um mesmo pedido pode ter um número variado de pratos inclusos, em diferentes quantidades, foi criada uma base de dados que relaciona pedidos e pratos
  • Composto pela associação de duas chaves estrangeiras : idPedido e idPrato. Como o idPedido é unico para todo novo pedido, a combinação idPrato + idPedido é unica.

• CadFeedback
  • idComentario: Como um mesmo cliente pode dar mais de um feedback, é criado um identificador para o comentário, que tem associado a ele um idRestaurante (identificando pra onde é o feedback) e um idCliente (identificando quem deu o feedback)

• CadRestaurante
  • idRestaurante : Identificador gerado para identificar os restaurantes internamente no sistema
  • CNPJ : Cadastro Nacional de Pessoa Juridica
    • Deve ser validado através do algoritmo específico do CNPJ, conferindo os dois ultimos digitos a partir dos outros, que são identificadores.

• CadPrato
  • Cada prato tem uma idPrato que não necessáriamente é unica, porém deve formar uma combinação unica juntamente ao idRestaurante. Ou seja, cada restaurante nao pode ter o mesmo idPrato em dois pratos.

Diagrama de Classes

Caso de Uso

Detalhamento do Casos de Uso

Arquivo:Detalhamento do Caso de Uso.pdf