Priorização de requisitos Moscow - Requisitos-2018-1-iFood/iFood GitHub Wiki

Histórico de revisões:

Data Versão Descrição Autor(es)
27/03/2018 0.1 Criação do documento João Vitor, Paulo Lopes
28/03/2018 0.2 Correção de termos Would Have João Vitor
02/03/2018 0.3 Adicionando coluna de conflito . Bruno Dantas, Victor Gomide
08/04/2018 0.4 Adicionando links para página de conflitos Diego Resende, Victor Gomide
10/04/2018 1.0 Adicionando links para o léxico Martha Dantas
27/05/2018 1.1 Adicionando novos requisitos Martha Dantas, Victor Gomide
27/05/2018 1.2 Adicionando ata de reunião Paulo Lopes
09/06/2018 1.3 Adicionando novos requisitos não funcionais Martha Dantas

Pré-Rastreabilidade

Requisitos Funcionais:

ID Descrição Comentários Valor de Negócio Conflito de ideias
RF1 O sistema deve ser capaz de intermediar compras entre os usuários e os restaurantes Deve ser mais rápido e completo que qualquer outro modo de pedido Must Have ---
RF2 O sistema deve ser capaz de permitir o cadastro dos seus clientes Must Have ---
RF3 O sistema deve listar os restaurantes de acordo com a sua localização inserida Must Have ---
RF4 O sistema deve listar o cardápio do restaurante Must Have ---
RF5 O sistema deve permitir que os restaurantes modifiquem seus cardápios Isso traria uma liberdade de montar cardápios customizados para a necessidade do restaurante Must Have Conflito 5
RF6 O sistema deve permitir a busca por restaurantes e pratos Should Have Conflito 6
RF7 O sistema deve identificar a disponibilidade do restaurante Must Have ---
RF8 O sistema deve permitir a aplicação de filtros durante a busca A aplicação do filtro seria útil para o cliente, economizaria tempo na busca por pratos Could Have Conflito 8
RF9 O sistema deve disponibilizar filtros avançados para a busca, para que o usuário encontre o que deseja mais rápido e precisamente Would Have Conflito 9
RF10 O sistema deve possuir as seguintes informações sobre o restaurante: Formas de pagamento aceitas; Horário de funcionamento Cada restaurante tem uma forma específica de aceitar pagamentos e o horário de funcionamento é um fator decisivo para o pedido poder ser realizado Should Have Conflito 10
RF11 O sistema deve permitir ao usuário escolher a localização de entrega do pedido, as opções devem ser: - Usando a localização atual; Inserindo a localização manualmente (informando CEP e em seguida o número, ou informando campo por campo) e A partir do histórico de endereços (necessita estar logado e ter realizado ao menos um pedido). Pode acessar o localizador do celular Must Have ---
RF12 O sistema deve disponibilizar restaurantes com desconto e sugestões de restaurantes Would Have Conflito 12
RF13 O sistema deve disponibilizar o histórico completo dos pedidos do usuário Should Have Conflito 13
RF14 O sistema deve informar ao usuário através de uma mensagem que o restaurante está fechado O aplicativo permitirá o acesso ao cardápio do restaurante mas não será possível fazer o pedido Would Have Conflito 14
RF15 O sistema deve informar ao usuário a avaliação, a categoria, a distância de um restaurante e a média do tempo de entrega do prato Essas informações são importantes para a melhor escolha do restaurante e/ou a comida Could Have Conflito 15
RF16 O usuário deve ser capaz de avaliar os restaurantes O cliente fará a avaliação através de estrelas que vão de 1 a 5. Could Have ---
RF17 O usuário deve ser capaz de comentar suas avaliações dos restaurantes O cliente poderá também comentar o porque de sua avaliação Could Have Conflito 17
RF18 O usuário deve ser capaz de favoritar o restaurante Os restaurantes favoritados será salvo para facilitar a busca do restaurante posteriormente Would Have Conflito 18
RF19 O usuário devidamente logado deve ser capaz de recomendar um restaurante através do voto Além dos sugeridos o cliente pode sugerir um novo restaurante não listado (RF36) Would Have Conflito 19
RF20 O usuário deve ser capaz de cadastrar-se com a conta do facebook O Cadastro com o facebook se torna mais rápido que o método tradicional de inserir dados Should Have Conflito 20
RF21 O usuário deve ser capaz de editar seus dados, endereços e suas avaliações Must Have ---
RF22 O usuário deve ser capaz de receber notificações de novos restaurantes, promoções e avisos gerais Would Have ---
RF23 O usuário deverá ser capaz de limpar o histórico de busca Would have ---
RF24 O usuário deve ser capaz de efetuar pagamentos pelo aplicativo. O pagamento pelo aplicativo é uma facilidade a mais para o cliente fazer o pagamento Should Have Conflito 24
RF25 O usuário deve ser capaz de visualizar o status do pedido em: Realizado, Não Realizado O status do pedido é importante para a confirmação ou não do pedido realizado Must Have ---
RF26 O usuário deve ser capaz de visualizar o status do pedido em: Sendo Feito, Saindo para Entrega Dá mais conforto e tranquilidade ao usuário Could Have ---
RF27 O sistema deve mostrar “o carrinho”, contendo a lista de comidas selecionadas e a opção de adicionar mais itens. Must Have ---
RF28 Ao visualizar o carrinho o sistema deve mostrar a opção de confirmação do pedido. Must Have ---
RF29 Antes de finalizar o pedido o sistema deve mostrar o resumo do pedido. Should Have ---
RF30 O sistema deve permitir o usuário escolher a forma de pagamento, pelo próprio aplicativo ou pelo entregador No caso de pagamento direto ao entregador, deve ser informado se há a necessidade de troco Must Have ---
RF31 O sistema deve mostrar a lista de restaurantes favoritos do usuário logado. Would have ---
RF32 Ao realizar o pedido o sistema deve permitir ao usuário incluir adicionais ao seu pedido. Must Have ---
RF33 Antes de adicionar ao carrinho, o sistema deve permitir a inclusão de observações ao pedido. Must Have ---
RF34 O sistema de permitir a alteração de quantidades dos itens pedidos, no carrinho e ante da inclusão do item no carrinho. Must Have ---
RF35 O sistema deve sugerir ao usuário restaurantes e promoções disponíveis. Must Have ---
RF36 O sistema deve permitir ao usuário sugerir um restaurante que não esteja cadastrado e nem disponível para votação (RF19) Would have ---
RF37 O sistema deve permitir ao restaurante incluir imagem e descrição dos pratos ofertados. Must Have ---
RF38 O sistema deve mostrar ao usuário os histórico das avaliações realizadas pelo mesmo. Should Have ---
RF39 O sistema deve permitir ao usuário cadastrado logar e deslogar do aplicativo. Could Have ---
RF40 O sistema deve possuir informações para contato com a empresa IFOOD. Could Have ---
RF41 O sistema deve permitir ao usuário/visitante escolher um prato. Must Have ---
RF42 O sistema deve prover ao usuário o acesso à sua Política de Privacidade e aos Termos e Condições, de modo que o usuário esteja ciente das relações legais a qual está inserido. Must Have ---
RF43 O sistema deve permitir ao usuário o login. Must Have ---
RF44 O sistema deve permitir ao usuário a exclusão de sua conta. Should Have ---
RF45 O sistema deve permitir a inclusão de descontos no pagamento. Should Have ---
RF46 O sistema deve permitir que o usuário informe seu CPF/CNPJ para a inclusão na nota fiscal. Could Have ---
RF47 O sistema deve permitir que o usuário se comunique por mensagens com o restaurante. Should Have ---
RF48 O sistema deve permitir o rastreamento em tempo real do pedido. Could Have ---
RF49 O sistema deve permitir que o usuário cancele um pedido. Deve ocorrer antes que o pedido comece a ser preparado. Should Have ---

Requisitos não Funcionais:

ID Descrição Comentários Valor de Negócio
RNF1 O sistema deve estar disponível para todas as principais plataformas (Android, IOS e Windows Phone) Ótimo para atrair mais usuários Should Have
RNF2 O sistema deve se conectar com o sistema de localização do aparelho do usuário Facilitar o processo do pedido Must Have
RNF3 O sistema deve otimizar a utilização de dados móveis Apesar de maioria dos usuários realizarem o pedido em casa, possuindo geralmente acesso à conexão Wi-Fi, é importante também que o usuário possa ter uma boa experiência do aplicativo, usando dados móveis Would Have
RNF4 O sistema deve se mostrar disponível 24 horas por dia, 7 dias na semana Sempre atender ao usuário para manter a fidelidade Must Have
RNF5 O sistema deve ser responsável pela segurança e privacidade dos dados bancários dos usuários É fundamental manter o usuário confiando no uso do aplicativo Must Have
RNF6 O sistema deve efetuar a transação corretamente no caso do pagamento pelo aplicativo É fundamental manter os restaurantes parceiros confiando no aplicativo, para aumentar a nossa rede Must Have
RNF7 O sistema deve informar o usuário sobre eventuais falhas na conexão Evitar estresse do usuário utilizando a aplicação mantendo-o informado Must Have
RNF8 O sistema deve permitir ao usuário realizar pedido em qualquer lugar A praticidade deve ser um dos objetivos do sistema Must Have
RNF9 O sistema deve permitir ao usuário escolher o meio de utilização do sistema, pelo aplicativo ou via web A flexibilidade na ultilização do sistema aumenta a adesão do mesmo Should Have
RNF10 Computador com sistema operacional Windows e acesso à internet O restaurante que deseja utilizar o aplicativo deve possuir um computador com acesso à internet e sistema operacional Windows para se conectar a aplicação Must Have
RNF11 Sistema próprio de entregas e CNPJ regularizado O restaurante que deseja utilizar o aplicativo deve ter meios próprio de entregar os pedidos realizados via aplicativo e CNPJ regularizado Must Have
RNF12 Variedade de restaurantes É importante para os clientes ter variedade de escolha, no aplicativo Should Have
RNF13 Transparência no andamento do pedido É importante para cliente saber o status do seu pedido Should Have