Prática 5 / Escopo do produto

Definir e refinar os requisitos

Um caso de logística para analisar entregáveis, transformar necessidades em especificações verificáveis e tomar decisões de escopo.

AdministraçãoEAPRequisitosRastreabilidade

Projeto Expedição Certa — Distribuidora Boa Mesa

A Boa Mesa é uma pequena distribuidora de materiais de limpeza para restaurantes. Em um único depósito, quatro auxiliares separam e conferem cerca de 40 pedidos por dia, com até 10 itens por pedido, de um catálogo de 120 produtos. Hoje, pedidos em papel e endereços de armazenagem pouco claros provocam trocas de produtos e quantidades.

Objetivo do projeto: implantar, em seis semanas, um processo padronizado de separação e conferência, apoiado por cadastro, identificação física, controle digital simples e painel de acompanhamento. No piloto de cinco dias úteis, com 200 pedidos de teste de 10 itens cada, a solução deverá alcançar pelo menos 98% de pedidos sem divergências e tempo médio de preparação de até 12 minutos por pedido. A situação inicial é de 90% e 18 minutos, respectivamente.

Produto a entregar: solução de expedição pronta para uso no depósito existente. São admitidos planilha ou formulário digital com controle de acesso; desenvolver um sistema próprio não é obrigatório. Não fazem parte do escopo compras, faturamento, roteirização de veículos, integração com fornecedores ou reforma do depósito.

Condições do caso: orçamento de implantação de até R$ 8.000, dois computadores existentes, uma impressora e rede local. Esse orçamento e o prazo são restrições do projeto; as características e os limites de desempenho da solução são requisitos do produto. Os números são premissas didáticas de uma empresa fictícia.

Interlocutores: Ana, gerente de logística e responsável pelo aceite; Bruno, supervisor da expedição e responsável pelo detalhamento; Carla, analista administrativa responsável pelos dados e indicadores; Diego, assistente de TI responsável pela configuração e pelos testes técnicos. A equipe deve distribuir as responsabilidades de detalhamento, validação e verificação conforme cada requisito.

Entregas e marcos numerados

A decomposição abaixo está organizada por entregas do produto. O código indica a hierarquia: 1 é o produto, 1.1 é uma entrega e 1.1.1 é um componente. Para esta prática, os marcos aparecem na mesma estrutura, identificados explicitamente; representam eventos de duração zero e não acrescentam entregáveis ao produto.

1 Solução de expedição padronizada
  1.1 Base de produtos e endereços
    1.1.1 Cadastro mestre de produtos
    1.1.2 Mapa de armazenagem e etiquetas
    1.1.3 Marco: base e endereços aprovados
  1.2 Kit de operação da expedição
    1.2.1 Controle digital de pedidos e conferência
    1.2.2 Procedimento e guia de trabalho
    1.2.3 Marco: operação pronta para o piloto
  1.3 Painel e solução homologada
    1.3.1 Painel de indicadores
    1.3.2 Dossiê de resultados do piloto
    1.3.3 Marco: solução aceita para uso

Os itens 1.1, 1.2 e 1.3 consolidam seus componentes; o item 1 consolida o conjunto. As especificações e condições de aprovação estão a seguir. A numeração organiza o escopo e não determina, por si só, a sequência de execução.

Informações levantadas com os interessados

Extraia requisitos atômicos: uma capacidade ou condição verificável por registro. A classificação não foi preenchida para que a equipe a justifique. Os limites apresentados são condições de aceitação; quando houver lacunas ou conflitos nas declarações complementares, será necessário refiná-los antes da validação.

1.1.1 — Cadastro mestre de produtos

O cadastro deverá permitir incluir, consultar e atualizar código, descrição, unidade de separação e endereço de armazenagem. Cada produto terá um código exclusivo e um único endereço principal. O catálogo de referência, aprovado por Carla, contém os 120 produtos ativos.

Na entrega, os 120 produtos deverão estar cadastrados, com todos os quatro campos preenchidos, sem códigos duplicados e com unidade e endereço iguais aos da referência. A conferência abrangerá todos os registros. A tentativa de salvar um código já existente ou um campo obrigatório vazio deverá ser bloqueada, sem alterar a base. Consultar e alterar um produto válido deverá preservar os demais registros.

Essa base é indispensável ao piloto e fornece os códigos utilizados nas etiquetas, nos pedidos e no painel.

1.1.2 — Mapa de armazenagem e etiquetas

O mapa deverá relacionar cada produto ao endereço composto por corredor, estante e posição. As 120 posições principais deverão ter etiquetas com o mesmo código e endereço do cadastro, além da descrição do produto. Não poderá haver posição principal compartilhada por produtos diferentes.

Na inspeção de todas as posições, serão aceitas apenas correspondências exatas entre mapa, cadastro, etiqueta e produto armazenado. Sob a iluminação habitual do depósito e a um metro de distância, cada um dos quatro auxiliares deverá ler corretamente código e endereço de pelo menos 19 das mesmas 20 etiquetas sorteadas, sem ajuda.

O desenho do mapa e o modelo da etiqueta podem ser preparados enquanto o cadastro é organizado. A impressão final e a aprovação dependem da base consolidada. Etiquetas legíveis são essenciais; código de barras é uma proposta adicional discutida na seção seguinte.

1.2.1 — Controle digital de pedidos e conferência

O controle deverá registrar número exclusivo do pedido, cliente, produtos, quantidades e horário de liberação para separação. Deverá gerar uma lista de separação ordenada por endereço e registrar o resultado da conferência de produto e quantidade. Quantidades deverão ser inteiras e maiores que zero; produtos inexistentes no cadastro e números de pedido repetidos deverão ser rejeitados.

Os estados serão “liberado”, “em separação”, “aguardando conferência” e “conferido”. A mudança para “conferido” só poderá ocorrer quando todos os itens coincidirem com o pedido. Havendo divergência, o pedido permanecerá “aguardando conferência”, com motivo registrado. Somente após correção e nova conferência poderá avançar. O controle deverá guardar responsável e horário de cada mudança de estado.

Os auxiliares poderão consultar pedidos e registrar separação e conferência; apenas Bruno poderá alterar o cadastro de produtos. A verificação usará uma conta de cada perfil: todas as operações autorizadas deverão funcionar e todas as tentativas de alteração do cadastro por auxiliar deverão ser bloqueadas.

Nos dois computadores existentes, com duas sessões simultâneas e uma base de 200 pedidos de 10 itens, pelo menos 95 de 100 consultas deverão apresentar o pedido completo em até 3 segundos, contados do comando de consulta à exibição. Em 20 rodadas de gravações simultâneas de pedidos distintos, nenhum registro poderá ser perdido ou sobrescrito.

Nos ensaios de cada regra de negócio, serão usados um caso válido e um inválido, incluindo duplicidade, quantidade zero, produto inexistente e divergência na conferência; todos deverão produzir o resultado previsto. O controle usa a base 1.1.1 e os endereços 1.1.2. O bloqueio de divergências tem prioridade sobre recursos de conveniência.

1.2.2 — Procedimento e guia de trabalho

O kit deverá conter um procedimento de até quatro páginas e um guia visual de uma página, disponíveis em PDF e em uma cópia impressa junto à bancada. Deverá explicar liberação, separação, conferência, correção de divergências e responsabilidades, usando os mesmos estados e nomes de campos do controle digital.

Após uma orientação de 30 minutos, cada auxiliar executará cinco pedidos de teste com 10 itens, sendo um pedido com divergência proposital. Usando apenas o guia, cada participante deverá concluir corretamente pelo menos quatro dos cinco pedidos e, obrigatoriamente, identificar e impedir a liberação do pedido divergente. O avaliador registrará acertos e intervenções; uma tarefa com ajuda não contará como acerto.

A redação inicial pode ocorrer em paralelo à configuração do controle, depois de acordados os campos e estados. A edição final depende da versão demonstrável de 1.2.1. O guia é obrigatório para iniciar o piloto.

1.3.1 — Painel de indicadores

O painel deverá permitir escolher o período e exibir total de pedidos conferidos, percentual de pedidos sem divergência na primeira conferência e tempo médio de preparação. “Sem divergência” significa que todos os produtos e quantidades coincidem já na primeira conferência; uma correção posterior não apaga o erro inicial. O tempo de preparação vai da liberação do pedido para separação até a confirmação final da conferência, incluindo espera e retrabalho.

O percentual será o número de pedidos sem divergência inicial dividido pelo total de pedidos conferidos no período, multiplicado por 100. O tempo médio será a soma dos tempos de preparação desses pedidos dividida pelo mesmo total. Pedidos ainda não conferidos não entram nos cálculos. Sem pedidos conferidos, o painel deverá apresentar total zero e “sem dados” para percentual e média.

Ao solicitar atualização, o painel deverá incorporar todos os registros gravados até esse instante e concluir em até 10 segundos, em cada uma de 10 execuções com a base de 200 pedidos. Percentual e tempo médio serão exibidos com uma casa decimal, com tolerância de 0,1 ponto percentual e 0,1 minuto em relação ao cálculo independente de Carla.

No teste conhecido de 20 pedidos conferidos, dos quais 18 sem divergência inicial, com soma de 240 minutos, os resultados deverão ser 20, 90,0% e 12,0 minutos. Também serão testados período vazio e pedidos ainda não conferidos. O painel depende dos estados, registros e horários de 1.2.1; seu desenho pode começar em paralelo ao guia. Os três indicadores são obrigatórios; apresentação visual adicional é negociável.

1.3.2 — Dossiê de resultados do piloto

O dossiê deverá reunir a versão dos componentes usados, os registros dos 200 pedidos do piloto, os resultados dos testes de cada requisito, as divergências encontradas, as correções e a decisão de Ana. Cada evidência deverá identificar requisito, método, resultado observado, data e responsável. Nenhum requisito poderá constar como atendido sem evidência.

O piloto terá cinco dias úteis, 40 pedidos por dia, 10 itens por pedido, distribuídos entre os quatro auxiliares, usando o depósito e os equipamentos descritos. Para atingir a meta, pelo menos 196 dos 200 pedidos deverão estar corretos na primeira conferência e a soma dos tempos de preparação deverá ser de, no máximo, 2.400 minutos. Os dois limites deverão ser atendidos simultaneamente. A análise também deverá confirmar todos os demais requisitos obrigatórios da solução.

O modelo do dossiê pode ser preparado antecipadamente. Seus resultados só poderão ser preenchidos após os testes e o piloto. A equipe da disciplina deverá planejar essa verificação; não precisa implantar o depósito nem inventar resultados para concluir a prática.

Condições dos marcos

1.1.3 — Base e endereços aprovados: Carla confere 1.1.1 e Bruno confere 1.1.2; Ana autoriza o uso da base quando todos os critérios desses componentes forem atendidos. Referência de planejamento: final da semana 2.
1.2.3 — Operação pronta para o piloto: exige 1.1.3, testes aprovados de 1.2.1, avaliação aprovada de 1.2.2 e painel 1.3.1 disponível e testado. Ana autoriza o piloto. Referência: final da semana 4.
1.3.3 — Solução aceita para uso: após 1.2.3 e o piloto da semana 5, Ana analisa 1.3.2 e registra o aceite somente se os requisitos obrigatórios e as duas metas do piloto tiverem sido atendidos. A semana 6 fica reservada à análise e, se necessárias, correções e novas verificações; o calendário não autoriza dispensar critérios.

Declarações que precisam ser negociadas

Os relatos abaixo são insumos ainda não aprovados. Compare-os às especificações. Identifique o que pode ser incorporado, o que exige esclarecimento e o que é incompatível. Registre propostas e decisões; não transforme uma suposição em decisão confirmada do interessado.

Concorrência por recursos e prioridade

Depois das funções obrigatórias, restam oito horas de Diego para melhorias opcionais dentro do prazo e do orçamento. Bruno pede leitura de código de barras nas etiquetas e no controle, estimada em oito horas. Carla pede gráficos adicionais no painel, estimados em seis horas. Cada melhoria cabe isoladamente, mas as duas juntas não cabem na disponibilidade restante. Ana orienta priorizar redução de erros de separação sobre apresentação gerencial. As estimativas são premissas do exercício; a equipe deverá justificar sua escolha e registrar a alternativa adiada.

Diferencie essa concorrência entre requisitos por um recurso limitado das atividades que podem ocorrer em paralelo, como elaborar o guia e desenhar o painel. Registre também as dependências da opção escolhida em relação às funções básicas.

Consistência entre solicitações

Para evitar atrasos, Bruno sugere: “Se o cliente estiver com pressa, qualquer auxiliar deve poder marcar o pedido como conferido mesmo com diferença de quantidade”. Compare essa proposta à regra de bloqueio de divergências e à meta de acurácia. A proposta ainda não foi autorizada por Ana.

Completude e possibilidade de teste

Ana acrescenta: “A solução deve ser fácil de usar e guardar os registros por bastante tempo”. Carla pede “um alerta quando o pedido estiver atrasado”. Não foram definidos prazo de retenção, evento inicial do atraso, limite de tempo, destinatário nem canal do alerta.

Verifique se a avaliação dos auxiliares em 1.2.2 já cobre o significado pretendido de “fácil de usar”. Para os demais pontos, formule perguntas e proponha condições verificáveis, com unidades, limites e método de teste. Até haver decisão, mantenha os registros provisórios. No exercício, o professor representa os interessados para confirmar ou rejeitar propostas.

Definir e refinar os requisitos do escopo do produto

Utilize a ferramenta Web como referência para organizar o trabalho, mantendo a rastreabilidade entre objetivo, entrega, requisito e verificação.

Aplicação Web: definição de requisitos →

1. Contextualizar e decompor. Cadastre o projeto, os objetivos e o produto a entregar. Em “EAP e entregáveis”, reproduza os códigos e a hierarquia apresentada, incluindo os marcos com essa identificação explícita. Use a descrição de cada elemento para registrar sua abrangência e condição de conclusão.
2. Identificar e classificar. Extraia requisitos de cada componente, separando enunciados compostos. Vincule cada registro ao elemento da EAP correspondente e classifique-o como funcional ou não funcional, justificando a escolha na descrição. Distinga a capacidade que a solução deve oferecer da qualidade ou do limite sob o qual ela deve operar. Não cadastre prazo e orçamento do projeto como se fossem características do produto.
3. Refinar os limites. Para cada requisito, preencha definição, descrição, responsáveis pelo detalhamento, validação e verificação e avaliação de viabilidade. Para cada não funcional, explicite o limite mínimo aceitável de qualidade: pode ser um piso (pelo menos), um teto (no máximo), uma faixa ou ausência de falhas. Informe grandeza ou condição verificável, valor esperado e unidade ou escala. Para uma condição binária, use “conforme/não conforme” e descreva o que determina a conformidade.
4. Analisar relações e escolhas. Relacione os IDs em “Depende dos requisitos” e “Concorre com os requisitos”. Identifique também quais trabalhos podem ocorrer em paralelo. Atribua prioridade alta, média ou baixa aos concorrentes e justifique o uso das oito horas disponíveis. Registre dependências sem ciclos, conflitos, perguntas em aberto e decisões confirmadas na descrição ou na avaliação de viabilidade.
5. Planejar testes. Para cada requisito, descreva método, cenário, dados ou amostra, resultado esperado, condição de aprovação e evidência a guardar. Inclua testes de limites e de rejeição de entradas ou ações inválidas quando aplicáveis. Em “Verificação e cronograma”, planeje atividades ou marcos com datas coerentes com as seis semanas, adotando uma data inicial para o exercício. A aplicação exige que a atividade de verificação vinculada pertença ao mesmo elemento da EAP do requisito: crie testes por componente e use os marcos numerados para consolidar as aprovações.
6. Revisar antes de validar.
  • Consistência: os requisitos concordam entre si, com os objetivos, com os perfis de acesso e com as regras do processo? Há pedidos incompatíveis ou dependências circulares?
  • Completude: todas as entregas e condições necessárias estão cobertas? Há atores, dados, exceções ou decisões ainda sem definição?
  • Medida e teste: outra equipe conseguiria repetir o teste e decidir aprovação ou reprovação usando o texto, sem adivinhar limites, amostras ou unidades?
Marque as três confirmações apenas quando a revisão as sustentar. Se uma delas não puder ser confirmada, registre a razão e mantenha o requisito provisório. A ferramenta verifica campos e registra a declaração da equipe; a qualidade técnica depende da análise realizada.
7. Entregar o resultado. Apresente a EAP, os requisitos refinados, as justificativas de classificação, relações, prioridades, plano de testes e registro das pendências e decisões. Salve a cópia do projeto em JSON. Quando todos os requisitos cadastrados estiverem resolvidos e validados, gere e exporte a matriz de rastreabilidade em CSV. Se houver pendências, entregue o JSON e a lista de questões em aberto; não confirme itens apenas para liberar a matriz. Propostas adiadas devem ter sua decisão registrada, sem serem apresentadas como obrigações aprovadas para este ciclo.
Validar a especificação não é aprovar o produto. Nesta prática, o resultado esperado é um conjunto de requisitos claros e um plano de verificação. Deixe resultados e aceite pendentes enquanto os testes não forem executados. A geração da matriz encerra o ciclo na ferramenta; novas alterações exigem abrir outro ciclo.

A ferramenta salva os dados neste navegador. Use “Salvar cópia do projeto” para preservar e entregar seu trabalho.