Escopo e critérios de aceite
Nesta aula
Uma versão precisa ter fronteiras
Escopo é o acordo sobre o que uma versão deverá oferecer e sobre o que ficará fora dela. Serve para decidir o trabalho, não apenas descrevê-lo depois. Na Oficina Caracol, dizer um catálogo com reservas pode sugerir pagamento, agenda e confirmação de atendimento. O projeto didático oferece outra coisa: catálogo público e uma operação simulada para estudar repetição de solicitações com efeito único.
A diferença deve aparecer no objetivo da versão e na interface. A simulação usa memória do processo; reiniciá-lo apaga as reservas. Não há compromisso real de disponibilidade, autenticação ou atendimento. Explicitar essas exclusões evita que uma demonstração técnica seja aceita como serviço operacional.
Um critério de aceite relaciona uma condição de entrada a um resultado observável. Não precisa prescrever todos os detalhes internos. Exigir o uso de determinada variável raramente demonstra valor para o visitante; exigir que um serviço inativo não apareça na resposta pública demonstra uma regra relevante.
Acordo da versão didática completa
| Requisito | Cenário de aceite | Evidência aplicável |
|---|---|---|
| REQ-001 | Uma entrada válida com serviços ativos produz a listagem pública desses serviços. | Verificação da seleção e do caminho até a página. |
| REQ-002 | Uma entrada mista não revela registros inativos na resposta pública nem na interface. | Inspeção da resposta e verificação do consumidor. |
| REQ-003 | Lista válida vazia e catálogo inválido geram respostas explícitas e diferentes. | Casos de teste e observação dos estados da interface. |
| REQ-004 | A tarefa prevista pode ser percorrida por teclado, com foco e feedback perceptíveis. | Registro de verificação manual, sem declarar conformidade automática. |
| REQ-005 | Repetir a mesma chave para o mesmo caso mantém um único efeito; reutilizá-la para outro caso gera conflito. | Teste do registrador e do caminho HTTP da simulação. |
O primeiro incremento pode demonstrar o catálogo; outro integra a simulação. Um incremento é uma parcela utilizável ou verificável do trabalho. A conclusão do primeiro não autoriza anunciar a versão completa como aceita. Os cinco requisitos continuam no acordo final, mesmo quando são implementados em momentos distintos.
Procedimento para negociar uma mudança
- Escreva o objetivo da versão em uma frase que mencione seu caráter didático.
- Associe cada capacidade obrigatória a entradas, resultados e verificação.
- Registre exclusões: cadastro, dados pessoais reais, banco externo, pagamentos e reserva efetiva.
- Ao receber um pedido novo, identifique quais requisitos, dados, interface e verificações ele afeta.
- Decida incluir agora, trocar por outro item ou adiar. Registre a decisão com a autoridade do produto, sem esconder a troca dentro de uma tarefa técnica.
Um pedido adicional analisado
O solicitante pede enviar a confirmação para o e-mail do visitante. Parece um pequeno campo, mas introduz coleta de dado pessoal e integração externa. Ambos estão excluídos. A decisão coerente para esta edição é adiar a função e manter a confirmação simulada na própria interface. Uma versão futura precisaria rediscutir finalidade, tratamento de dados, segurança e operação antes de assumir essa capacidade.
Compare com corrigir a mensagem que aparece quando não há serviços. Essa correção ajuda a cumprir REQ-003 sem acrescentar uma nova finalidade. A análise de impacto permite diferenciar expansão de escopo e reparo de um requisito já assumido.
Falhas de aceite e condição de avanço
| Falha | Reparo |
|---|---|
| Aceitar porque todos os comandos terminaram | Examinar se os testes cobrem os requisitos e realizar a verificação manual aplicável. |
| Chamar toda falha de ressalva | Classificar impacto; requisito essencial descumprido impede a liberação da capacidade afetada. |
| Marcar tarefa técnica como requisito atendido | Confrontar o comportamento integrado com o cenário de aceite. |
O recorte está pronto para execução quando os requisitos obrigatórios, as exclusões e os cenários de verificação estão acordados. A liberação da versão exige resultado aceitável, classificação das lacunas não impeditivas e aceitação do risco pela autoridade competente. Apenas registrar que uma falha existe não a torna aceitável.
Exercício com decisão resolvida
Cenário: listagem, ocultação e mensagens foram demonstradas; a simulação repete corretamente uma chave; teclado ainda não foi verificado. O responsável pede liberar a versão completa e incluir e-mail no mesmo dia. Defina o que já pode ser afirmado e as próximas ações.
Ver solução comentada
Solução: podemos afirmar os resultados efetivamente demonstrados e seu alcance, sem estendê-los a REQ-004. Primeiro devemos executar a verificação manual de teclado e feedback, corrigindo impedimentos encontrados. O pedido de e-mail deve ser tratado como mudança de escopo e, no contrato atual, adiado. A resposta não deve declarar a simulação pronta para reservas reais: seu estado permanece local e transitório. Uma solução completa separa estado da entrega, evidência ausente e pedido novo.
Referências para aprofundamento
Consulte S01, Software Requirements, para especificação e validação; e S06, WCAG 2.2, critérios 2.1.1 Keyboard, 2.4.7 Focus Visible e 4.1.3 Status Messages. Esses critérios orientam verificações pertinentes à oficina e não representam toda a avaliação de acessibilidade.
Fontes relacionadas
Consulte os limites e as seções de apoio de cada referência.
S01 S06Tente o exercício antes de consultar a solução. Marque a aula para organizar sua leitura.
A conclusão desta leitura não equivale a certificação ou aceite de um projeto real. Teste os exemplos no escopo indicado e registre as limitações.