Critérios de aceite em projetos: como saber se uma entrega está realmente pronta

O fornecedor informa que a entrega está pronta. A equipe técnica responde que os testes terminaram. A área de negócio diz que ainda não conseguiu usar o resultado. O gerente registra 100% de conclusão, mas ninguém assina o aceite.

Então aparece a frase mais perigosa dessa etapa:

Está pronto, mas ainda faltam alguns detalhes.

“Pronto, mas” costuma esconder uma destas situações:

• o executor terminou sua atividade, mas não produziu uma entrega utilizável;
• o requisito foi atendido tecnicamente, mas não validado pelo usuário;
• faltam documentos ou evidências;
• o responsável pelo aceite não participou da definição;
• existem defeitos que impedem o uso;
• surgiram novas expectativas que não faziam parte do combinado;
• ninguém definiu o que significava terminar.

Critérios de aceite existem para impedir que a decisão dependa de opinião, pressão ou memória.

Resposta direta

Um bom critério de aceite descreve uma condição observável, verificável e ligada ao resultado da entrega. Ele também identifica quem verifica, qual evidência será usada, quando a validação acontece e como os desvios serão tratados.

Expressões como “adequado”, “completo”, “intuitivo” ou “de boa qualidade” não bastam sem uma condição objetiva.

Para cada entrega, responda sete perguntas:

1. Qual entrega será avaliada?
2. Que condição precisa ser atendida?
3. Como essa condição será verificada?
4. Qual evidência comprovará o resultado?
5. Quem possui autoridade para validar e aceitar?
6. Até quando a decisão precisa ocorrer?
7. O que acontece quando existe desvio?

Se essas respostas não estão definidas, a equipe não possui um critério de aceite. Possui apenas uma expectativa.

Por que “concluído” significa coisas diferentes?

Uma entrega pode atravessar vários estados antes de ser aceita.

Esses estados não precisam virar uma burocracia com seis aprovações. Eles ajudam a localizar a ambiguidade.

Exemplo: um arquivo de migração pode ter sido produzido, enviado e tecnicamente carregado. Ainda assim, não deve ser aceito se os saldos não foram reconciliados ou se os campos críticos estão incompletos.

A Association for Project Management define aceite como o processo formal de receber uma entrega e critérios de aceite como as condições essenciais que precisam ser atingidas antes disso. Também diferencia verificação, que demonstra conformidade com requisitos, de validação, que produz evidência de atendimento às necessidades do usuário.

Critério de aceite, requisito, teste, evidência e definição de pronto

Esses termos trabalham juntos, mas não são sinônimos.

O requisito diz o que é necessário

Um requisito pode ser funcional, técnico, operacional, regulatório ou de qualidade. Ele não precisa conter sozinho todo o processo de validação.

O critério transforma a necessidade em decisão

O critério precisa permitir uma resposta clara: a condição foi atendida, não foi atendida ou foi atendida dentro de uma tolerância previamente autorizada?

O teste é apenas um dos métodos de verificação

Uma entrega pode ser verificada por:

• teste;
• inspeção;
• análise;
• demonstração;
• medição;
• revisão documental;
• conciliação;
• simulação;
• observação de execução.

Evidência não é a mesma coisa que reunião

“Foi demonstrado na reunião” é fraco quando ninguém registrou cenário, versão, resultado e aprovador. A evidência precisa permitir que outra pessoa entenda o que foi verificado.

Definição de pronto não substitui critérios específicos

No Scrum, a Definição de Pronto descreve formalmente o estado do incremento quando ele atende às medidas de qualidade do produto. Ela cria um padrão comum. Um item específico ainda pode precisar de critérios próprios ligados ao seu comportamento ou resultado.

Exemplo:

• Definição de pronto comum: testes automatizados aprovados, revisão concluída e documentação atualizada.
• Critério específico: ao cancelar o pedido, o estoque é liberado em até 30 segundos e a trilha registra usuário, data e motivo.

Quem define, verifica e aceita?

Aceite sem autoridade clara gera duas falhas. Uma pessoa aprova algo que não poderia aprovar, ou todos esperam uma decisão que ninguém assume.

Separe quatro papéis.

Solicitante ou responsável pela necessidade

Explica o resultado esperado e participa da definição dos critérios.

Executor

Produz a entrega e apresenta evidências de que o trabalho está pronto para verificação.

Validador

Executa testes, inspeções, análises ou revisões. Pode ser especialista técnico, qualidade, segurança, dados ou usuário-chave.

Responsável pelo aceite

Possui autoridade para decidir se a entrega atende ao compromisso e pode seguir adiante.

Uma pessoa pode exercer mais de um papel, dependendo do risco e da complexidade. O que não pode acontecer é deixar a autoridade implícita.

Exemplo de divisão

Use a matriz RACI para organizar papéis quando várias áreas participam. A RACI não substitui o critério. Ela esclarece quem executa, responde, é consultado e informado.

Seis características de um critério de aceite útil

1. Específico

O critério identifica exatamente qual comportamento, atributo ou resultado será avaliado.

Fraco: “o relatório deve funcionar”.

Melhor: “o relatório deve exibir pedidos por unidade, período, situação e canal”.

2. Observável

É possível perceber o resultado sem interpretar intenção.

Fraco: “o usuário deve achar fácil”.

Melhor: “no teste com dez usuários representativos, pelo menos nove concluem a tarefa principal sem ajuda e em até três minutos”.

3. Verificável

Existe um método capaz de provar atendimento.

Fraco: “a base deve ter alta qualidade”.

Melhor: “a completude dos cinco campos obrigatórios deve ser igual ou superior a 99,5%, medida pelo relatório de qualidade”.

4. Relevante

A condição protege uma necessidade real, não uma preferência sem relação com o resultado.

Um critério pode ser mensurável e ainda inútil. Exigir 80 páginas de documentação não garante que a operação consiga usar o sistema.

5. Inequívoco

Duas pessoas razoáveis devem interpretar a condição do mesmo modo.

Termos como rápido, moderno, adequado, amigável, robusto e completo precisam de referência ou medida.

6. Decidível

O resultado permite tomar uma decisão dentro de prazo e tolerância definidos.

Um critério impossível de verificar antes da implantação não serve para decidir o aceite daquela etapa. Talvez seja necessário usar piloto, simulação, amostra ou acompanhamento posterior.

Modelo ORQENA de Critério de Aceite em Sete Campos

Use esta estrutura para cada entrega relevante.

Fórmula de redação

A entrega [nome] será aceita quando [condição observável], verificada por [método], comprovada por [evidência] e validada por [papel] até [prazo]. Se houver [desvio], será aplicado [tratamento].

Exemplo preenchido

A base de clientes migrada será aceita quando 100% dos registros obrigatórios forem processados, a completude dos cinco campos críticos for igual ou superior a 99,5% e os totais de controle estiverem conciliados. A verificação ocorrerá pelo relatório de carga, análise de qualidade e conciliação de uma amostra estratificada. A proprietária dos dados validará as evidências em até dois dias úteis. Registros críticos rejeitados exigem correção e nova carga; inconsistências não críticas serão registradas com responsável e prazo aprovado.

O critério deixa claro o que precisa acontecer e como a exceção será tratada.

Como escrever condições observáveis

Comece por verbos e resultados que possam ser demonstrados.

Verbos úteis

• processar;
• exibir;
• bloquear;
• registrar;
• reconciliar;
• calcular;
• disponibilizar;
• responder;
• concluir;
• aprovar;
• recuperar;
• executar;
• identificar.

Perguntas úteis

1. Que comportamento precisa ocorrer?
2. Em qual situação?
3. Qual resultado deve aparecer?
4. Existe limite, tolerância ou faixa?
5. Como será testado?
6. Qual evidência permanecerá?
7. Quem decide?

Cuidado com números arbitrários

Colocar um percentual não torna o critério automaticamente melhor.

“Disponibilidade de 99,9%” só é útil quando também se define:

• período de medição;
• horário considerado;
• fonte dos dados;
• exclusões autorizadas;
• tratamento de indisponibilidade parcial;
• responsável pela validação.

Precisão sem regra de medição é falsa objetividade.

Exemplos ruins e versões corrigidas

1. Funcionalidade de sistema

Critério ruim:

O cancelamento de pedidos deve funcionar corretamente.

Por que falha: não define quais pedidos podem ser cancelados, efeitos esperados, mensagens nem evidência.

Versão verificável:

Quando um usuário autorizado cancelar um pedido ainda não faturado, o sistema deverá alterar a situação para “cancelado”, liberar a reserva de estoque em até 30 segundos, impedir faturamento posterior e registrar usuário, data e motivo. Serão executados cenários de cancelamento válido, pedido já faturado e usuário sem permissão.

2. Base de dados migrada

Critério ruim:

Os dados precisam estar completos e corretos.

Por que falha: completo e correto não possuem campos, limites nem método de conciliação.

Versão verificável:

A carga será aceita quando todos os registros obrigatórios forem processados, a completude de CPF ou CNPJ, nome, situação, unidade e data de cadastro for igual ou superior a 99,5%, não existirem duplicidades críticas e os totais por unidade coincidirem com a origem. Exceções autorizadas devem constar em lista aprovada pelo proprietário dos dados.

3. Processo operacional

Critério ruim:

O novo processo de devolução deverá estar implantado.

Por que falha: não informa o que muda, onde será testado nem como saber se a equipe consegue executar.

Versão verificável:

O processo será aceito após execução de dez devoluções representativas na unidade-piloto, incluindo produto íntegro, danificado e sem nota. Pelo menos nove casos devem ser concluídos sem intervenção da equipe do projeto, todos devem gerar o registro obrigatório e nenhum pode produzir divergência de estoque não resolvida.

4. Treinamento

Critério ruim:

Treinamento realizado para toda a equipe.

Por que falha: presença não comprova compreensão nem capacidade de executar.

Versão verificável:

O treinamento será aceito quando pelo menos 95% do público-alvo concluir a sessão, 90% obtiver nota igual ou superior a 80% na avaliação prática e todos os supervisores demonstrarem os três procedimentos críticos sem consulta ao instrutor. Ausentes deverão concluir a reposição antes da implantação.

5. Documento

Critério ruim:

Manual completo e atualizado.

Por que falha: não define público, conteúdo mínimo, versão nem revisão.

Versão verificável:

O manual deverá conter propósito, pré-requisitos, procedimento principal, cinco exceções conhecidas, responsáveis pelo suporte e data de revisão. Todas as telas deverão corresponder à versão candidata à implantação. Um supervisor e dois usuários deverão executar o procedimento usando apenas o documento, sem bloqueio crítico.

6. Infraestrutura

Critério ruim:

Ambiente de produção disponível.

Por que falha: um servidor ligado não significa ambiente pronto para uso.

Versão verificável:

O ambiente será aceito após confirmação de capacidade, conectividade, certificados, acessos, monitoramento, cópia de segurança e restauração. O teste de restauração deverá recuperar a base de validação dentro do tempo definido no plano de continuidade, com evidência anexada.

Critérios em projetos preditivos, ágeis e híbridos

Critérios de aceite não pertencem a um único método.

Projetos preditivos

Os critérios costumam ser definidos junto com requisitos, escopo, especificações, contratos e planos de qualidade. O aceite pode ocorrer por entrega, fase ou pacote.

Cuidados:

• não esperar o final do projeto para validar tudo;
• revisar critérios quando uma mudança for aprovada;
• prever tempo para análise e correção;
• evitar termos amplos em documentos contratuais.

Abordagens ágeis

Critérios específicos podem acompanhar itens do backlog, enquanto a Definição de Pronto estabelece o padrão comum de qualidade do incremento.

O Guia do Scrum afirma que um item só integra o incremento quando atende à Definição de Pronto. Também exige que equipes que trabalham no mesmo produto compartilhem o mesmo padrão mínimo.

Cuidados:

• não confundir demonstração com aceite automático;
• não usar a revisão da iteração como único momento de descobrir expectativa;
• manter critérios ligados ao resultado, não apenas à tarefa técnica;
• não considerar pronto um trabalho que ainda precisa de integração essencial.

Abordagens híbridas

É possível combinar critérios iterativos para funcionalidades com marcos formais para integração, segurança, migração, implantação e transição.

Exemplo:

• funcionalidades validadas durante ciclos curtos;
• teste integrado aceito ao final da etapa;
• migração aprovada por reconciliação;
• entrada em produção autorizada por decisão executiva.

A ISO 21502 reconhece abordagens preditivas, incrementais, iterativas, adaptativas e híbridas. O método muda a cadência do aceite, não elimina a necessidade de evidência.

Aceite integral, parcial, condicionado e rejeição

A decisão não precisa ser apenas “sim” ou “não”. Porém, categorias intermediárias precisam de regras claras.

Aceite integral

Todos os critérios foram atendidos e não existem pendências que impeçam a conclusão.

Registre:

• entrega e versão;
• critérios avaliados;
• evidências;
• responsável;
• data;
• eventuais observações sem ação pendente.

Aceite parcial

Uma parte independente e utilizável da entrega foi aceita, enquanto outra permanece pendente.

Use quando o escopo puder ser separado sem criar uma falsa conclusão.

Exemplo: três relatórios são aceitos e dois continuam em correção. O pacote total não deve aparecer como concluído.

Aceite condicionado

A entrega pode avançar apesar de uma pendência não crítica, desde que exista condição explícita.

Registre:

• pendência;
• impacto;
• justificativa para aceitar;
• responsável pela correção;
• prazo;
• evidência esperada;
• consequência se o prazo não for cumprido.

Não use aceite condicionado para defeito crítico, exposição regulatória, risco de segurança ou incapacidade de executar a função principal.

Rejeição

Um ou mais critérios essenciais não foram atendidos.

A rejeição precisa indicar:

• critério violado;
• evidência;
• correção necessária;
• responsável;
• prazo de reapresentação;
• impacto no plano.

“Não gostei” não é uma rejeição adequada. A decisão deve voltar ao compromisso definido.

Como registrar evidências

Uma evidência útil precisa permitir rastrear:

• qual entrega foi avaliada;
• qual versão foi testada;
• qual critério estava em análise;
• qual método foi aplicado;
• quais dados foram usados;
• qual resultado foi observado;
• quem executou a verificação;
• quem validou;
• quando ocorreu;
• onde o registro está armazenado.

Exemplos de evidência

• relatório de testes;
• captura de tela com identificação da versão;
• registro de sistema;
• relatório de conciliação;
• lista de verificação assinada;
• laudo ou parecer técnico;
• vídeo curto de demonstração;
• ata de validação;
• resultado de pesquisa ou avaliação prática;
• termo de aceite.

O termo de aceite não substitui as evidências

O termo formaliza uma decisão. Ele não precisa repetir todos os testes, mas deve apontar para as evidências e identificar com precisão a entrega aceita.

Um termo genérico assinado sob pressão não corrige critérios ruins.

O que fazer quando o responsável demora para aceitar?

O atraso no aceite paralisa entregas seguintes, distorce o status e pode criar conflito com fornecedores.

Defina antes:

• quem aceita;
• substituto autorizado;
• prazo de análise;
• canal de submissão;
• informações obrigatórias;
• regra para dúvidas;
• limite de escalonamento.

Fluxo recomendado

1. O executor submete a entrega com evidências completas.
2. O responsável confirma o recebimento.
3. A validação ocorre dentro do prazo acordado.
4. Dúvidas são registradas contra critérios específicos.
5. A decisão é formalizada.
6. Ausência de decisão é escalada antes de afetar o marco seguinte.

Exemplo de regra

O responsável terá três dias úteis para aceitar, rejeitar com referência aos critérios ou solicitar esclarecimento. Se não houver manifestação, o gerente escalará ao patrocinador no quarto dia útil.

Não presuma aceite por silêncio, a menos que uma regra contratual ou organizacional válida estabeleça isso de forma explícita. Em caso de dúvida contratual, envolva as áreas responsáveis.

Correção, melhoria ou mudança de escopo?

Quando a entrega chega, novas solicitações podem ser apresentadas como “correção”. A distinção depende da referência aprovada.

Exemplo

Critério aprovado:

O relatório deve permitir filtro por unidade e período.

Na validação, a área solicita exportação automática diária.

Se a exportação não fazia parte do requisito, não é correção. É uma mudança ou melhoria a ser avaliada. Chamar tudo de defeito transfere escopo sem analisar consequência.

O importante é rastrear a solicitação à referência aprovada. Quando a expectativa não foi registrada, pode existir uma lacuna de definição que precisa ser resolvida com honestidade, não uma culpa automática.

Exemplo preenchido: pacote de implantação comercial

Exemplo ilustrativo, com dados fictícios.

Considere um projeto de implantação de uma plataforma comercial. O pacote possui quatro entregas principais.

Matriz de aceite preenchida

O que ocorreu

• a funcionalidade passou em dois cenários, mas permitiu que um usuário sem autorização cancelasse o pedido;
• a migração atingiu 99,7% de completude, mas 42 clientes ficaram duplicados;
• o processo-piloto alcançou nove casos corretos, sem divergência crítica;
• o treinamento atingiu 96% de presença, mas apenas 82% alcançou o desempenho mínimo.

Decisões

Funcionalidade: rejeitada, porque um cenário essencial falhou. Correção e novo teste obrigatórios.

Migração: rejeitada. As duplicidades críticas violam um critério explícito e precisam ser corrigidas antes da carga final.

Processo: aceito. O critério foi atendido e a ocorrência menor do décimo caso foi registrada como melhoria não bloqueante.

Treinamento: rejeitado para efeito de prontidão operacional. A realização do evento foi comprovada, mas o critério de desempenho não foi atendido. Os usuários abaixo do limite precisam de reforço e nova avaliação antes de receber acesso.

Por que o exemplo é útil?

Ele impede quatro simplificações:

• presença não equivale a aprendizado;
• percentual médio não apaga um defeito crítico;
• melhoria desejável não precisa bloquear o aceite;
• atividade concluída não significa resultado aceito.

Indicadores para acompanhar o processo de aceite

Aceite na primeira apresentação

Fórmula: entregas aceitas sem correção relevante ÷ entregas apresentadas.

Ajuda a medir clareza e qualidade, mas precisa ser analisado por tipo de entrega.

Tempo entre apresentação e decisão

Mostra gargalos de validação e falta de disponibilidade dos aprovadores.

Taxa de rejeição por causa

Classifique causas como:

• requisito ambíguo;
• critério ausente;
• defeito de execução;
• ambiente inadequado;
• dados incorretos;
• mudança tardia;
• evidência incompleta;
• aprovador indisponível.

Aceites condicionados vencidos

Pendências aceitas podem desaparecer do acompanhamento. Meça quantidade, idade e criticidade.

Retrabalho após aceite

Indica critérios insuficientes, validação superficial ou mudanças posteriores mal classificadas.

Entregas sem responsável pelo aceite

Deveria ser zero antes do início da execução.

Esses indicadores podem aparecer no status report de projetos quando afetam marcos, riscos ou decisões executivas.

Lista de verificação antes de aceitar uma entrega

Definição

• ☐ A entrega e a versão estão identificadas?
• ☐ Os requisitos relacionados estão rastreados?
• ☐ Os critérios foram definidos antes da apresentação?
• ☐ Os critérios são observáveis e verificáveis?
• ☐ Tolerâncias e exceções foram estabelecidas?

Responsabilidade

• ☐ Existe executor identificado?
• ☐ Existe responsável pela verificação?
• ☐ Existe pessoa com autoridade para aceitar?
• ☐ Há substituto e regra de escalonamento?
• ☐ O prazo para decisão foi acordado?

Evidência

• ☐ O método de verificação foi aplicado?
• ☐ A evidência identifica versão, data e resultado?
• ☐ Os dados usados são representativos?
• ☐ As falhas e exceções estão registradas?
• ☐ A evidência pode ser consultada depois?

Decisão

• ☐ O tipo de aceite está claro?
• ☐ Pendências possuem responsável e prazo?
• ☐ Defeitos foram separados de melhorias e mudanças?
• ☐ O impacto no cronograma foi atualizado?
• ☐ A decisão foi comunicada às partes afetadas?

Dez erros comuns nos critérios de aceite

1. Definir o critério depois que a entrega chega

A validação vira negociação de expectativa.

2. Usar adjetivos sem medida

Completo, intuitivo e robusto não permitem decisão sozinhos.

3. Colocar apenas o resultado ideal

Sem método, evidência e responsável, o critério fica incompleto.

4. Confundir atividade com entrega

“Treinamento realizado” mede evento, não aprendizagem.

5. Usar o mesmo aprovador para tudo

Entregas técnicas, dados, processos e operação exigem autoridades diferentes.

6. Não reservar tempo para validar

O cronograma marca entrega e próxima etapa na mesma data, sem espaço para análise e correção.

7. Aceitar parcialmente e declarar o pacote concluído

O status esconde trabalho restante.

8. Usar aceite condicionado para qualquer falha

Pendências críticas são empurradas para depois da implantação.

9. Tratar expectativa nova como defeito

O escopo cresce sem decisão de mudança.

10. Guardar evidências em mensagens dispersas

O projeto perde rastreabilidade e reabre discussões já encerradas.

Qual é o papel do PMaaS no aceite?

O PMaaS pode organizar:

• escopo e entregas;
• definição antecipada dos critérios;
• papéis de verificação e aceite;
• calendário de validação;
• produção e armazenamento das evidências;
• triagem de defeitos, melhorias e mudanças;
• acompanhamento das correções;
• escalonamento de decisões atrasadas;
• atualização do plano e do status.

O serviço não deve substituir o responsável de negócio ou técnico que possui autoridade para aceitar.

O PMaaS da ORQENA assume a gestão direta da iniciativa dentro de responsabilidades definidas. Para conhecer o modelo, veja PMaaS: o que é, como funciona e quando contratar.

Perguntas frequentes sobre critérios de aceite

O que são critérios de aceite em projetos?

São condições essenciais e verificáveis que precisam ser atendidas antes de uma entrega ser formalmente aceita.

Quando os critérios devem ser definidos?

Antes da execução ou, no máximo, antes de a entrega ser construída. Em abordagens iterativas, eles podem evoluir durante o refinamento, desde que a mudança seja conhecida antes da validação.

Quem escreve os critérios de aceite?

O responsável pela necessidade deve participar com executor, especialistas e validador. A redação pode ser facilitada pelo gerente, analista ou responsável pelo produto, mas a autoridade de aceite precisa confirmar o entendimento.

Quem aprova a entrega?

A pessoa ou papel com autoridade definida para aquela entrega. Pode ser responsável técnico, proprietário dos dados, gestor operacional, Product Owner, patrocinador ou outra autoridade designada.

Critério de aceite e requisito são iguais?

Não. O requisito descreve uma necessidade. O critério explica qual condição observável permite confirmar que a entrega atende ao compromisso.

Qual é a diferença entre critério de aceite e Definição de Pronto?

O critério geralmente trata uma entrega ou comportamento específico. A Definição de Pronto estabelece condições comuns de qualidade para o incremento ou classe de trabalho.

Uma entrega pode ser aceita com pendências?

Sim, quando as pendências não são críticas, o impacto é conhecido e existem responsável, prazo, evidência e consequência definidos. Não deve ser usada para esconder incapacidade de uso ou exposição relevante.

O que fazer quando o responsável não responde?

Aplicar o prazo e a regra de escalonamento previamente definidos. A ausência de resposta não deveria manter o projeto indefinidamente parado.

Um teste aprovado garante o aceite?

Não necessariamente. O teste pode verificar apenas parte dos critérios. A decisão também pode depender de documentação, integração, segurança, operação ou validação do usuário.

O termo de aceite é obrigatório?

Depende da governança, do contrato e da criticidade. Mesmo quando não existe um documento formal, a decisão precisa ser rastreável, com entrega, versão, responsável, data e evidências.

Critérios podem mudar durante o projeto?

Podem, desde que a alteração seja analisada, aprovada e comunicada. Mudar o critério depois de conhecer o resultado apenas para aprovar ou rejeitar uma entrega destrói a integridade do processo.

Conclusão

Uma entrega não está pronta porque alguém terminou de trabalhar nela. Está pronta para aceite quando pode ser verificada contra condições conhecidas.

O controle mínimo precisa conectar:

• entrega;
• requisito;
• condição esperada;
• método de verificação;
• evidência;
• responsável;
• prazo;
• tratamento do desvio;
• decisão de aceite.

Essa estrutura reduz retrabalho, conflito e conclusão fictícia. Também protege os dois lados: quem entrega sabe como será avaliado, e quem recebe consegue decidir com base em fatos.

O objetivo não é produzir mais formulários. É impedir que “está pronto” tenha um significado diferente para cada pessoa.

Se sua empresa precisa estruturar escopo, critérios, validação e aceite de uma iniciativa crítica, conheça o PMaaS da ORQENA.

Referências utilizadas

• APM Glossary of project management terms: definições de aceite, critérios de aceite, requisitos, testes, verificação, validação, retrabalho e conclusão.
• The 2020 Scrum Guide: Definição de Pronto, incremento utilizável, transparência, inspeção e adaptação.
• The PMI Guide to Business Analysis: referência para análise de necessidades, requisitos e avaliação de soluções.
• ISO 21502:2020: orientação de gestão de projetos aplicável a abordagens preditivas, iterativas, adaptativas e híbridas.